Search code examples
gogoogle-cloud-platformgoogle-cloud-datastore

Should there be a new datastore.Client per HTTP request?


The official Go documentation on the datastore package (client library for the GCP datastore service) has the following code snippet for demonstartion:

type Entity struct {
    Value string
}

func main() {
    ctx := context.Background()

    // Create a datastore client. In a typical application, you would create
    // a single client which is reused for every datastore operation.
    dsClient, err := datastore.NewClient(ctx, "my-project")
    if err != nil {
        // Handle error.
    }

    k := datastore.NameKey("Entity", "stringID", nil)
    e := new(Entity)
    if err := dsClient.Get(ctx, k, e); err != nil {
        // Handle error.
    }

    old := e.Value
    e.Value = "Hello World!"

    if _, err := dsClient.Put(ctx, k, e); err != nil {
        // Handle error.
    }

    fmt.Printf("Updated value from %q to %q\n", old, e.Value)
}

As one can see, it states that the datastore.Client should ideally only be instantiated once in an application. Now given that the datastore.NewClient function requires a context.Context object does it mean that it should get instantiated only once per HTTP request or can it safely be instantiated once globally with a context.Background() object?

Each operation requires a context.Context object again (e.g. dsClient.Get(ctx, k, e)) so is that the point where the HTTP request's context should be used?

I'm new to Go and can't really find any online resources which explain something like this very well with real world examples and actual best practice patterns.


Solution

  • You may use any context.Context for the datastore client creation, it may be context.Background(), that's completely fine. Client creation may be lengthy, it may require connecting to a remote server, authenticating, fetching configuration etc. If your use case has limited time, you may pass a context with timeout to abort the operation. Also if creation takes longer than the time you have, you may use a context with cancel and abort the mission at your will. These are just options which you may or may not use. But the "tools" are given via context.Context.

    Later when you use the datastore.Client during serving (HTTP) client requests, then using the request's context is reasonable, so if a request gets cancelled, then so will its context, and so will the datastore operation you issue, rightfully, because if the client cannot see the result, then there's no point completing the query. Terminating the query early you might not end up using certain resources (e.g. datastore reads), and you may lower the server's load (by aborting jobs whose result will not be sent back to the client).