Connecting between Fastly Compute (WASI) and a distributed database platform

Compute
1

I’ve noted Fastly Compute instances can only connect over HTTP (precluding use of the postgres wire protocol, for example) which prevents the use of serverless-oriented and strongly consistent relational database providers like CockroachDB. Google Spanner is a viable option with gRPC over HTTP/2, but I have some questions.

  1. What benefit does for_grpc confer when enabled on a dynamic backend? I see this is unavailable for static backends.

  2. Is max_conn (available on static backends) the number of connections per POP to the backend or the total number of connections globally?

1 Like
2

I can answer #2 - max_conn isn’t per pop or global, it’s per cache. Each POP has many caches in it, and each maintains its own set of backend connections.

1 Like
3

For Item #1, this configuration instructs Fastly that the backend itself is gRPC aware. It’s currently only available for dynamic backends at the moment.

1 Like
4

That seems to make reasoning about the number of connections to a backend rather difficult, doesn’t it? I wonder if a number like four connections per cache makes sense in the context of a distributed database backend…

I’m not quite clear on what that does, though. Is this to ensure the connection remains open long enough? Support got back to me on this one; it forces HTTP/2 and ALPN to h2.

I suppose if you need to limit the number of connections and use a gRPC backend, the solution isn’t quite there yet?

–

Edit: Perhaps the limited release pool resource is a solution to that first point (unclear): Pool | Fastly Documentation

5

Fauna is shutting down (and on very short notice) which further narrows available options. Perhaps gRPC can be made available for static backends in the short term to open a window of opportunity?

1 Like