If 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?
Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
131–140 of 268 posts
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#132What 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…
They just updated it from being JS only to being able to run any Docker image. Cloudflare gives you a persistent key/value store and Fly provides a non-persistent Redis cache.
You don’t have to move your entire app but there are plenty of use-cases where you can move more logic to the edge.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#133Earlier quoted context omitted.
That's awesome, your use case is perfect for region scoped persistent storage. We're testing persistent storage privately with a few customers now and the results are exciting. My favorite is using minio as a private global s3 for caching. What are you using for the index storage engine?
I would be really interested in Fly if it abstracted persistent storage. An exciting use case to me would be something that doesn’t with “...for caching.”
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#134Earlier quoted context omitted.
This basically bumps the amount of behavior you can stuff into the edge by several orders of magnitude. Previously, Lambda@Edge will like, maybe validate a JWT. Now, you can put like half your app in there. It sounds like a tiny incremental change but it's big enough that it simply redefines what's even possible in a POP.
I'm interested, what is now possible with this? Is it high bandwidth VR sort of stuff?
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#135The max monthly spend is awesome, I'l probably try it out just because of that :) Its a bit unclear to me though how exactly the heroku deploy works? Is it basically a replacement for the web dynos that heroku provides, but then still connecting to existing postgres instances for example? What are the limits for the redis store? I'm using it on heroku but constantly running into max connection issues, if you can impr…
you might be running into max connection issues because your library is leaving stale connections. i know this is the case for ruby & php. check if you have timeout set. see this github issue for ruby: https://github.com/redis/redis-rb/issues/524
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#136Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#137Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#138So it’s google cloud run that scales to many servers?
Cloud Run automatically scales your container image to thousands of container instances ("servers") if needed, maybe you mean "scales to many regions"?
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#139> 2. Max monthly spend: unexpected traffic spikes happen, and the thought of spending an unbounded amount of money in a month is really uncomfortable. You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month. I like this, not having caps is a major problem with some of your competition for smaller projects/compani…
I don't think I like the failure mode of your app getting slower (losing your ApplicationDN) right at the time it's really popular. I don't have a better solution though.
Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users
#140Earlier quoted context omitted.
You should solve this by making one request to a db api layer (use GraphQL!) And have that layer do the back and forth with the db, from right next to it. Holding transactions open for long distance round trips is going to get you into trouble in a myriad of ways. It does not scale.
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.