4 ms·

It took me a while to get some context here but the article makes sense. Maybe more outside the topic but related: why would you put business logic closer to th

It took me a while to get some context here but the article makes sense. Maybe more outside the topic but related: why would you put business logic closer to the user when that's rarely the performance bottleneck? You could cache computed data closer to the user (on the edge) to avoid the longer round trip to your host, but putting your Node backed closer to the user just makes the trip from backend to the DB longer? Is the latency from edge to DB really that much better? Maybe what you're optimizing for is something like serving cached data behind auth which does require some business logic (hence the caching of part of the DB at the edge as well)? Seems cool but back to the article which claims that it changes modern web development. Modern web development sounds for the most part the same. Maybe the article can be called "How Modern SQL Databases Are Enabling Distributed Web Development"?

satyrnein 3y ago
If your server is just fetching data, then it doesn't seem like much benefit to have the server close to the user unless the data is also close to the user at least some of the time (caching, distributed db, etc). However, if your server is doing other work, it might be useful to be close to users even if the data isn't. This is why fly.io sponsors stuff like Phoenix Liveview or Laravel Livewire.
- ppeetteerr 3y ago
  Totally agree that function locality is important, especially if latency reduction is your biggest opportunity. Edge compute feels like a niche problem for most businesses, and it comes with high overhead costs in setup and maintenance. You mentioned Liveview and Livewire. Both are great and they would work equally well in any context, not exclusively a server less front-end. I would propose that switching to a more efficient programming language (i.e. not using Elixir or PHP) and investing in better data structure optimization would result in equal if not better performance improvements than investing the same amount of time wrangling data replication issues and infrastructure maintenance caused by edge compute. To the point of the original article, modern web development remains the same: start with a single server, server-side render your content, and expand when the need arises. What we're talking about in the comments is performance web development for geographically distributed audiences (for instance, if you're building a global social network).
skybrian 3y ago
Yeah, the headline isn't great, but it's describing something real that database service providers are working on. You're right that the question is whether you want the high-latency link to be between the web browser and the web backend, versus the web backend and the database. Either way works; it's just a matter of where you're going to spend effort reducing round trips. For database driver developers, optimizing for minimizing round trips is new, but they're making progress. As an app developer, you can use stored procedures to reduce round trips, or even have app logic in both places. As you say, serving a result from an edge cache is a way to avoid any database round trip. This brings up issues around cache invalidation that haven't really been tackled yet; with Postgres you could use listen/notify, but it assumes a persistent connection that isn't there for these new drivers. An alternative would be to use read-only database replicas, but that seems relatively heavyweight compared to a bit of local caching.
- ppeetteerr 3y ago
  Yeah, DB replication and caching would be a pain in this scenario. Akamai cache busting is challenging enough in complex cases. I can also imagine how you can have localized datasets with a centralized auth database, for instance. That way, you have something akin to sharding of the dataset to bring real-time functionality closer to a global user-base. For example, you can have an edge game server with a local state serving 20-30 players close to their physical location. I wouldn't recommend this for 99% of web development tho.
eternityforest 3y ago
What about caching the database itself on the application server? Is there some kind of SQL client library that can somehow cache records from the DB, and P2P cache with other application servers, but then make sure everything is synced with the main server? Wouldn't it be ideal to have just the parts of the DB that each user needed kept close to that user?

satyrnein 3y ago

If your server is just fetching data, then it doesn't seem like much benefit to have the server close to the user unless the data is also close to the user at least some of the time (caching, distributed db, etc). However, if your server is doing other work, it might be useful to be close to users even if the data isn't. This is why fly.io sponsors stuff like Phoenix Liveview or Laravel Livewire.

ppeetteerr 3y ago
Totally agree that function locality is important, especially if latency reduction is your biggest opportunity. Edge compute feels like a niche problem for most businesses, and it comes with high overhead costs in setup and maintenance. You mentioned Liveview and Livewire. Both are great and they would work equally well in any context, not exclusively a server less front-end. I would propose that switching to a more efficient programming language (i.e. not using Elixir or PHP) and investing in better data structure optimization would result in equal if not better performance improvements than investing the same amount of time wrangling data replication issues and infrastructure maintenance caused by edge compute. To the point of the original article, modern web development remains the same: start with a single server, server-side render your content, and expand when the need arises. What we're talking about in the comments is performance web development for geographically distributed audiences (for instance, if you're building a global social network).

skybrian 3y ago

Yeah, the headline isn't great, but it's describing something real that database service providers are working on. You're right that the question is whether you want the high-latency link to be between the web browser and the web backend, versus the web backend and the database. Either way works; it's just a matter of where you're going to spend effort reducing round trips. For database driver developers, optimizing for minimizing round trips is new, but they're making progress. As an app developer, you can use stored procedures to reduce round trips, or even have app logic in both places. As you say, serving a result from an edge cache is a way to avoid any database round trip. This brings up issues around cache invalidation that haven't really been tackled yet; with Postgres you could use listen/notify, but it assumes a persistent connection that isn't there for these new drivers. An alternative would be to use read-only database replicas, but that seems relatively heavyweight compared to a bit of local caching.

ppeetteerr 3y ago
Yeah, DB replication and caching would be a pain in this scenario. Akamai cache busting is challenging enough in complex cases. I can also imagine how you can have localized datasets with a centralized auth database, for instance. That way, you have something akin to sharding of the dataset to bring real-time functionality closer to a global user-base. For example, you can have an edge game server with a local state serving 20-30 players close to their physical location. I wouldn't recommend this for 99% of web development tho.

eternityforest 3y ago

What about caching the database itself on the application server? Is there some kind of SQL client library that can somehow cache records from the DB, and P2P cache with other application servers, but then make sure everything is synced with the main server? Wouldn't it be ideal to have just the parts of the DB that each user needed kept close to that user?