4 ms·
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 l
by 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 agoTotally 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).