3 ms·
It can work as a "smart cache" - like for example: https://fly.io/docs/app-guides/graphql-edge-caching-apollo/ https://fly.io/docs/app-guides/graphql-edge-cach
by e12e 6y ago
It can work as a "smart cache" - like for example:
https://fly.io/docs/app-guides/graphql-edge-caching-apollo/ https://fly.io/docs/app-guides/graphql-edge-caching-apollo/
I'm not entirely convinced this is a great idea (and apparently the example uses plain http between the graphql prox/cache and openlibrary.org - that might be considered a bug, I suppose:
https://github.com/fly-apps/edge-apollo-cache/blob/master/src/books-api.js#L6 https://github.com/fly-apps/edge-apollo-cache/blob/master/sr...
At any rate I'd assume whatever source you're proxying (eg your own openapi rest end points) - you might want ssl - or connect the db/api to fly.io via vpn a la:
https://fly.io/blog/building-clusters-with-serf/ https://fly.io/blog/building-clusters-with-serf/
See also the linked:
https://fly.io/blog/incoming-6pn-private-networks/ https://fly.io/blog/incoming-6pn-private-networks/
).
- tptacek 6y agoThe Apollo thing is just an illustration of a pattern a bunch of our customers want to be able to do --- fine-grained API caching. I hope it's obvious than the HTTP connection to OpenLibrary isn't the point. :) But: while you can very easily use TLS to backhaul to an API, a more "modern" Fly.io way to solve this problem is with WireGuard gateways; it's trivial --- I'd argue, easier than configuring SSH certs --- to get a WireGuard link from your cache app on Fly back to AWS, GCP, or wherever your non-Fly legacy database lives. I really think WireGuard is going to change a lot of the ways we design systems like this.
- kasey_junk 6y agoI for one absolutely agree (disclosure a friend of the fly folk and an absolute fanboy). One of the most interesting things about wireguard to me is cheap ubiquitous application neutral secure comms.