Does anyone know what did they use to build the docs? They look amazing.
Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
151–160 of 268 posts
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#152Does anyone know what did they use to build the docs? They look amazing. https://fly.io/docs/
Inspecting the source , it seems it's https://docsearch.algolia.com/
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#153Earlier quoted context omitted.
We're not solving db latency yet. A good place to start is aggressively caching at the edge. We offer an in-memory redis cache for this that can replicate commands globally. Beyond that you'd need read replicas which will be possible once we launch persistent storage. That said, latency between data centers on the same continent is often less than I would have thought!
Gotcha, honestly that feels pretty niche to me, which might be a good place for a startup to start. I can't think of many back-end applications between purely static content (just use a CDN) and needs a database connection. Probably video game servers, where you don't need the game state to be (immediately) stored/accessed globally.
I could see IoT device 'acceleration' to be a significant potential use-case. Something with a tiny bill of materials for the device itself, offloading any non-trivial processing to a virtual device on the closest 'real' infrastructure you can get. Especially for something human-interactive, you would want to be very aggressive about minimizing latency.
Also, depending on how tight the limits are for VM lifetime / bandwidth / outbound connections, I could see using these as a kind of virtual NIC / service mesh type thing for consumer-grade internet connections, to restore the inbound routing capabilities precluded by carrier-grade NAT and avoid their traffic discrimination, as well as potentially on-boarding to higher-quality transit as early as possible for use when accessing latency-sensitive services further 'interior' to the cloud.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#154Earlier quoted context omitted.
This is not an area I'm in a lot, so I may be wrong, the cloudflare workers page GP mentioned says that you only get 10ms CPU time per request (or 50ms with the paid plan). I'm assuming lambda etc have similar limits. So presumably anything that takes longer than 10/50ms.
lambda can run up to 30m I think (idk about lambda@edge). CF Workers fail when trying to use something like node-unfluff, because the CPU time takes too long. This seems to me, like a more controllable lambda@edge.
The containers on fly.io can go up to 8CPUs. So you can do a lot of computation for images, video etc.
They can also accept any kind of TCP traffic (and we're trialing UDP), so lots of interesting network services. This is especially interesting for people who want to do live video.
AND we have disks. So you can deploy Varnish, or nginx caches, etc. This is something we enable by hand per app.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#155Earlier quoted context omitted.
Gotcha, honestly that feels pretty niche to me, which might be a good place for a startup to start. I can't think of many back-end applications between purely static content (just use a CDN) and needs a database connection. Probably video game servers, where you don't need the game state to be (immediately) stored/accessed globally.
I could see IoT device 'acceleration' to be a significant potential use-case. Something with a tiny bill of materials for the device itself, offloading any non-trivial processing to a virtual device on the closest 'real' infrastructure you can get. Especially for something human-interactive, you would want to be very aggressive about minimizing latency. Also, depending on how tight the limits are for VM lifetime / ba…
These are great. IoT seems like a thing you could do but that's a really specific use case I hadn't even considered.
The second example would be interesting to try. There's no real limit on VM lifetime or outbound connections, bandwidth is more of a budget problem. VMs are ephemeral, so they _can_ go away but we're all happier if they just run forever.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#156What problem does it solve? Because latency is currently not an issue with all the regions from current cloud providers from my perspective. And for all static stuff you can use a CDN that has pop all arround the world / cities. Not sure I understand the use case of a single Docker image in a city outside of your entire backend services, especially the DB. If your Docker image talks to something else on AWS / GCP for…
There's a whole bunch of use cases people have today that don't require a database. Here's a few that I'm excited about:
- image, video, audio processing near consumers
- game or video chat servers running near the centroid of people in a session
- server side rendering of single page js apps
- route users to regional data centers for compliance
- graphql stitching / caching (we do this!)
- pass through cache for s3, or just minio as a global s3 (we do this!)
- buildkite / GitHub Action agents (we do this!)
- tensorflow prediction / DDoS & bot detection
- load balance between spot instances on AWS/GCP
- TLS termination for custom domains
- authentication proxy / api gateway (we do this!)
- IoT stream processing near devices
edit: formatting
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#157Earlier quoted context omitted.
This is exactly what we do! We have a Rails app exposing a graphql api for our cli and web app. The web app is a React SPA monster that we're replacing with another Rails app that runs at the edge and serves the customer UI, docs, marketing pages, and some other things. It's really pleasant. We love graphql.
Why not just have the rails app exposing GQL also expose the customer UI/etc?
That's actually the plan! The Ruby Graphql gem lets you resolve queries directly so the app can have an "edge" or "core" mode and make the right call (edge over HTTP, core direct to DB).
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#158If one API request makes on average 5-10 round trips to the database, and the database is in Virginia, this only makes the problem (much) worse. How do you solve this problem for this use case?
One good solution might be something like Datomic (the classic version, now called Datomic On-Prem), where each application process has the query engine embedded in it, and it pulls data from a relatively dumb storage service such as DynamoDB as needed, then aggressively caches it.
That would work great. Even something like FaunaDB would work really well.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#159Earlier quoted context omitted.
> Does it mean the backhaul is private and not tunneling through the public internet? Backhaul runs only through the encrypted tunnel. The Wireguard connection itself _can_ go over the public internet, but the data within the tunnel is encrypted and never exposed. > I use Cloudflare Workers and I find that at times they load-balance the traffic away from the nearest location [0][1] to some location half-way around th…
Any chance you have more details on GP's question about the tech basis of the router (ebpf, dpdk)? I didn't find this component among the OSS in the superfly org.
Doh, missed that. We're not doing eBPF it's just user land TCP proxying right now. This will likely change, right now it's fast enough but as we get bigger I think we'll have more time to really tighten up some of this stuff.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#160Earlier quoted context omitted.
This is exactly what we do! We have a Rails app exposing a graphql api for our cli and web app. The web app is a React SPA monster that we're replacing with another Rails app that runs at the edge and serves the customer UI, docs, marketing pages, and some other things. It's really pleasant. We love graphql.
Why not just have the rails app exposing GQL also expose the customer UI/etc?
Mostly because the path to here was not a straight one :)
Our main Rails app does a bunch of things that can't run globally and it takes a long time to build while the customer facing app is a lightweight Rails app that consolidated several static and single page react apps into one less gross place.