fauna / fauna-go Goto Github PK

Golang 1.19+ has introduced structured logging -- looks like this could be a more extensible/long-term solution: https://www.youtube.com/watch?v=gd_Vyb5vEw0&list=PLxNYxgaZ8Rsf8PLPWeUPRA3iZoK9uu3lU

I don't think we're going to have clients locked to older versions thanks to: https://www.youtube.com/watch?v=moS35OlJBmY

@cynicaljoy @cleve-fauna

Just thinking about the loss of this info in the (common case?) of a user who doesn't use the DefaultClient

Should we roll with the standard logger or should we take a dependency on zerolog? I'm sure we will have users that have varying opinions on logging libraries, but the interface for zerolog should be pretty easy for them to implement for the desired logger.

Considerations:

• Let's talk about logging
• Structured logging will be part of std lib "soon" -- GitHub Discussion exp/slog package docs

I'm not completely sure if I can replicate ReadIdleTimeout in the python driver ...

As I understand it -- the above uses http2 ping frames to implement a health-check for a connection, which serves to both keep the connection alive across things like load balancers which require traffic flow, and also to detect when a connection is down (which, without read/write timeout, would otherwise potentially just block forever).

I asked this question on the httpx repo to see if maybe there's a way to support a similar behavior as golang provides here as the golang behavior definitely seems like the most ideal behavior ...

But -- especially if we can't duplicate this in other drivers - I sort of think we should rename this env var to be a little more informative as to its meaning ...

Should we be always returning the same instance here ...? If we are tracking things like LastTxnTime per client instance then getting a new instance everytime would be doing the 'wrong' thing in scenarios where a user calls DefaultClient lazily or per request

I'm trying to sort out a good UX for creating a query, what do people think about:

var addr string
...
client.Query(FQL(`IndexedRead.byAddress(${address}) { name: .data.name }`, QueryArgs(Arugment("address", addr)))

This would change the Query method contract from:

type QueryArgs map[string]interface{}

func (c *Client) Query(fql string, args QueryArgs, obj interface{}, opts ...QueryOptFn) (*Response, error)

to:

func (c *Client) Query(query FQLQuery, obj interface{}, opts ...QueryOptFn) (*Response, error)

func FQL(input string, args QueryArg) FQLQuery

we'd parse the string for all ${vars} and iterate through all of the QueryArg and if any are missing we'd return an error. I like wrapping in ${} as it makes it a bit easier to read, it's easier to parse out (we can actually use os.Expand almost turnkey) and it's inline with the current proposal for adding string interpolation the language. Though, that's also a con IMO...feels like we'd eventually be trampling on std lib in a bit of a weird way, but that proposal might never be accepted so probably best to sort it out if it ever becomes an issue if we're otherwise happy with that pattern.

I'm not loving the naming though...maybe something like:

func (c *Client) Do(query QueryInput, obj interface{}, opts ...QueryOptFn) (*Response, error)

func Query(query string, args QueryArgs) QueryInput

I feel like Do is a little more idiomatic Go (see: http.Client.Do) and we avoid Query(<query>) or using the language acronym as a struct type.