As much as I love Deno, I think this is the wrong way to frame it. For a number of reasons.<p>1) Sure, big web apps for a global audience would benefit from a distributed application and distributed data. But, honestly, most web apps I've worked in my 20+ years in web dev have been for an audience in a single country or even city.<p>2) It's easy for Deno to say "get a distributed app running at the edge!" when the hard part is having distributed data which they don't solve. If you don't need distributed consistent data then you're probably more than fine with a monolith with a CDN.<p>3) Those latency numbers don't seem right to me. My production server in AMS returns a response in 200ms to here (central Mexico).<p>4) Performance evangelists and salesmen will try to convince everyone they need to get a response in 50ms, but for most use cases that's just ridiculous. Most people are fine getting a response in under a second. Just use a CDN for your static assets and your monolith will be fine.<p>The edge is cool, but it's not "the future". It's just another tool with pros and cons.
Instead of "edge", a lot of websites should just have 3 locations (us,eu,apac) with a non geo replicated Serverless database in each region. At least that's what we're building at WunderGraph (<a href="https://wundergraph.com/" rel="nofollow">https://wundergraph.com/</a>). Edge sounds super cool, but if you take state and consistency into consideration, you just can't have servers across the globe that also replicate their state consistently with low latency. TTFB doesn't matter as much as correctness. And if stale content is acceptable, then we can also just push it to a CDN. Most importantly, you'd want to have low latency between server and storage. So if your servers are on the "edge", they are close to the user, but (randomly) further away from the database. Durable objcets might solve this, but they are nowhere near a postgres database. I think the "edge" is good for some stateless use cases, like validating auth and inputs, etc., but it won't make "boring" services, even serverless in "non-edge" Locations obsolete. You can see this on Vercel. Serverless for functions, server side rendering, etc. and cloudflare workers for edge middleware. But they explicitly say that your serverless functions should be close to a database if you're using one.
Wait till we get to the final stage, where we install apps on people's computers directly. That way, we get ZERO latency. Can't wait! What should we call it?
IDK, I think this is getting overstated.<p>Don't forget - there's very typically a runtime environment available that's a lot closer to the user... their browser.<p>The edge, as a place to run code, is a bit of a tweener... farther from the user than the browser, farther from the data than the database environment.<p>If the data the edge needs is <i>also</i> on or near the edge, you can really start to do something with it. But that means your data is distributed. You want to have a really solid plan on how your edge data is kept valid.<p>That's not so hard with static assets but edge processing on static assets seems like a relatively narrow case, because it needs to make more sense than pre-computing all the cases and just having a more static files.<p>Edge processing on dynamic data is pretty interesting, but having coherent distributed dynamic data tends to be app specific and hard to get right and keep right. There are certainly cases, but I don't think they usually tend to comprise the whole app. I think it will usually be a partial solution and add a bunch of complexity, so apps will want to use it sparingly, where it's really needed.<p>I think this will be more of a tool in the toolbox, not the general future of the web.
OK, but what about data synchronization?<p>One of the tremendously simplifying aspects of traditional web applications was that they were, to a first order of approximation, stateless. The state lived on the server in a centralized location. When an update occurred, it was done via an HTTP request that failed or succeeded.<p>If shared state between users is stored on the edge it needs to be synchronized between edge nodes, leading to collisions that may appear at a point significantly after a user has "clicked save". I can imagine this becoming a nightmare as a user accretes dependent local changes, all of which eventually have to be rolled back as edge data stores synchronize with one another.<p>Now, there are advanced technologies for this sort of thing, but they are relatively complex, hard to program against and often don't and can't offer great end user experience.<p>I am not saying that the edge isn't going to be useful for some applications, but it is throwing out one of the main simplifications that the original, REST-ful model of the web gave us.
I like deno.com, but I am deeply suspicious of their speed test methodology. I hope I am wrong, but it really looks like they are comparing time-to-first-byte (TTFB) including TLS, i.e. a 'cold start'. It should not be almost 400 ms from Amsterdam to Virginia on an existing connection.<p>If your app makes one and only one connection, then fair enough, that is a real penalty. Otherwise, this is just the benefit of literally every single CDN. With enough traffic, their edge servers will keep connections open to origin.<p>For serverless, there is no origin -- even better for performance, assuming it has no need for a common data store.
Frankly - who cares unless there's a persistence mechanism to go with this?<p>The devil isn't in getting a static resource close to users (we've been able to do this for decades with CDNs)<p>The devil is in getting application state pushed close to those users.<p>"Eventually consistent" is a real bitch of a thing to deal with.
> When people say “the edge,” they mean that your site or app is going to be hosted simultaneously on multiple servers around the globe, always close to a user.<p>This is the first time I see such a simple description of this. Often you've got the feeling of "magicians" using technobabble to let things look much more difficult or new than they are.
Right. I think we did global deployment, multi-region with geo based DNS and anycast like 10 years ago. I guess the difference here, it's now a product. I'm still not convinced. Why 3 years ago I started building it as a product and you know it just didn't matter. It makes a cool story and blog post but the technical details just don't matter. Tell me you can deliv er sub 100ms response times globally and give me a framework to build for that but the rest is details I just don't care about. I used to care, I used to think developers should know these details, the reality is it's not important. Delivering developer experience means the user not having to care about those details.<p>Delivering sub 100ms definitely important but mostly if it's just static pages and there's no database IO or calling of external third party APIs during that process then it's not relevant. The large majority of software is now not just serving a static assets but a lot of complex logic which ends up dictating a lot of the page load times, not the traversal of light across the globe.
Can someone explain how this can actually work for a medium sized CRUD app? I’m a dev and don’t understand. I get hosting static or cached files at the edge and serving them. And I get how you could run PHP or another server-side language on edge servers too. But you want a single source of truth and if there’s a database involved, you still need to host that somewhere and the true latency will be at this step.<p>Are there simple modern solutions for maintaining the same database on servers all over? (This doesn’t even sound like a good idea, or at least like it would either be impossible or would have tradeoffs, and sounds like a minor optimization anyway)<p>Or are Deno etc only used for database-less sites?<p>Or is everyone just obsessed with TTFP (screen painting) load times because users hate waiting but like pretty loading spinner gifs?
I'm yet to come across a non-trivial website or web app that runs on the edge in the way they have described. While it may or may not be the future, as it is commonly touted as, who exactly is testing edge computing in the real world today? What database are they using? How are they synchronizing application state across all these regions?<p>From practical industry experience I can say that deploying to 1-3 data centers is still the way to go, and that isn't going to change for the ~50-100ms of latency this approach will save.
For which type of web sites would this make a difference? I think for this to matter, the audience should be almost global, in which case it will cater to a small percentage.<p>Some examples:
- News sites: These heavily use CDN's and caching, wouldn't make much difference.
- Most CRUD apps which target a small number of users? Probably no significant difference being on the edge would bring.
- Games: this is one area this might make a difference due to latency advantage.<p>Could someone give some real examples from the net that would make switching to this edge architecture a difference? For example, something like, it would be good if HackerNews/CNN/Intuit did this so that...?
> The benefits of serverless are two-fold:
> You only pay for what you use—just those 10 seconds if that’s all that’s happening on your app.
> You don’t have to worry about all the DevOps side of servers. No planning, no management, no maintenance.<p>The second benefit can be had without serverless. Anything that runs containers offers that. The first one is a nice to have for side projects, but pretty irrelevant in the cost of a business building and shipping a product. If they're referring to autoscaling then, again, anything running containers can do that.<p>And no mention of where the data is? As far as I can tell, this is buzzword soup with no broadly applicable use case.
Curse you Title Case!!<p>With the convention that articles and prepositions are not capitalised, if you have a title that is mostly articles and prepositions, then the remaining few words which are capitalised can easily be confused with proper nouns, especially if those nouns are relevant to the title's subject. e.g.<p><a href="https://en.wikipedia.org/wiki/Microsoft_Edge" rel="nofollow">https://en.wikipedia.org/wiki/Microsoft_Edge</a><p>I thought that the article was going to be about how the author thought Edge was going to (somehow) dominate the browser space sometime in the forseeable future.
944.14ms - that's the worst case stated on the time to first byte for conventional architecture. That's not bad. Will your user notice it? Probably not for most applications and the ones that they do you can probably cache that locally.<p>There are performance limited applications - e.g. stock trading - but in those you're talking about choosing specific processors and disabling certain caching approaches to increase the performance that you want, choosing certain network switches, using microwave transmitters where existing physical infrastructure doesn't serve your needs... like fast is _fast_... and people pay for that in expertise and infrastructure.<p>Will your users pay for cutting your response time from 944.14ms to 45ms? And the additional complexity that comes with?<p>In some cases the answer is, in all honesty, yes - yes they will. And they'll pay you for every additional fraction of a second it takes light to go from the top of the Empire State building to the bottom, if it gets their trade in first.<p>More generally, however, your users probably aren't interested in delays measured in less than the time it takes them to blink. How fast is your ballpoint pen? Do you care? To your user's use case, it's all either categorised as instant or something you have to wait for.
Seems like we’re headed full circle. At some point in the future someone will rediscover the insanely overpowered machines in everyone’s home and hand with almost no latency.
The Future of the Web is Peddling Endless Amounts of Cloud Frameworks<p>The number of web sites that need global edge computing is vanishingly small. More realistically you need a 20+ year old technology called a CDN to run your mostly static site.<p>Edge computing doesn't even solve any of your real problems here. I18n, l10n, international taxation/currency/payments, data-at-rest/GDPR/privacy laws. And then it introduces new problems, such as data partitioning. Are you going to partition at the edge and deal with tricky sync issues (CAP, anyone??) or are you just going to call back to your centralized DB server a thousand miles away from that edge? You know what's even faster than running that code on an edge device? Running that code on the user's phone or laptop. And you can get there. With a CDN.
Meh. My future is a linux laptop with emacs and ssh.<p>But yeah. I feel you. The Edge is where all the cool kids are hanging out.<p>And as much as it sounds like a buzzword, terminating TLS at the edge is and calling back to central services via a proxy w/ warm connections to the backend is pretty easy to deploy and does wonders for perceived latency.
Yet another web dev article assuming that every web app is massive scale, for a global audience of consumers that have alternative choices.<p>I have worked on dozens of web sites for paying clients, and none were in that category.<p>Also, mostly I just want to know, why is Singapore's connectivity so slow? Some sort of filter?
The first deeper problem is state. Other commenters have talked about distributed databases.
But the second deeper problem is data sovereignty. In, what I would argue is <i>most</i> cases, you don't <i>want</i> your data to be replicated around the globe. Local laws forbid it, and the marginal utility of having better latency when your customer goes on vacation somewhere that needed a 12 hour flight is pretty close to zero anyway. So why play with fire?<p>99% of the time that you want geo-distributed databases, I'd argue that building out a directory kind of service, where you use something like Cloudflare Workers KV to map the customer's ID to find which regional API endpoint to use (US/EU/APAC), is what you actually want.
The curl command mentioned in the article that's supposed to show the region being used for a request `curl -ls <a href="https://deno.land" rel="nofollow">https://deno.land</a>` doesn't seem to work as described. Does anyone know if this is a typo?
The future of the money-web is on the edge. But the money web is for corporate persons, not human persons. Humans will continue to use a single server somewhere on earth. Let's not get cargo-cult'y here.
I'm working on a framework in Ruby that's designed to be deployed on the edge. It's got a Virtual DOM on the server and it streams updates to the browser, so having low latency is very important. It doesn't matter if the database is far away, its fine if it takes time to load data as long as the UI is fast.<p>I'm running the example app on fly.io, and if each instance can have 30 concurrent sessions, that means I can have 90 concurrent sessions on their free plan. 30 more sessions for another $1.94... I haven't done any benchmarks yet, but it will be interesting to check the performance on different instance types.<p>Deploying apps like this will certainly reduce costs, because you can deploy your app to where your users are. If you have a lot of users during daytime and few users at night time, you only pay for the users you got during daytime. You could have more servers in regions with active users during daytime and less servers in regions where users are sleeping...
If we push everything to the edge we might end up with an ecosystem where it's not affordable to run your own VM, and we'll be stuck building only on the technologies offered by edge providers. Even if it's not literally the case, for the working dev it might end up being the practical reality if edge hosting ends up being the trendy default. The equivalent to "no one got fired for buying IBM" and now "no one got fired for choosing React"<p>Cloud functions are cool, when you need them, and when you want them. But if they were the only option I would go do something else for a living.<p>I am already imagining the day where some young developer comes to the bold new idea that we could write better software, if only we hosted our own runtimes! Much like frontend architecture broke new exciting ground when they recognized they could compile their pages on the server before sending them. Wow!
This vision will become real when we can distribute indexes & query engines to the edge. A simplified model would be a lightweight CDN deployment of sqlite with distributed updates.<p>Querying large indexes is the most common use case that needs code to run. Sqlite would standardize storage & query implementation
The future of the web could also be back to the browser. Python can run in the browser with SQLite. I have had ideas of taking Django or fastapi and then either using the browser or put it in an app which runs it in WebKit or blink and syncing to the servers if that is even needed for the app.
Or just drastically shrink how much data has to be pushed.
Static content can be hosted via a CDN to get it close.<p>Serverless workers distributed on a global basis running
nanoservices backed by Sqlite on the edge that gets way
complicated.<p>My favorite sanity test is "distributed transactions".
Do you need them? If so how complicated will it be to
synchronize all edges when changes comes in from all edges.<p>The usual answer is "we will build that ourselves",
then over time the team discovers why it is definite
hard problem to solve.<p>You end up reimplementing parts of a database server with
added level of complexity.<p>Most architecture should start with<p>"Distributed transactions".<p>Do we need them
If so how will we do it.<p>That is just my obsession.
Is our current DNS on the edge? Decentralized all the way down to one's host file. Fully centralized all the way up to the 13 DNS servers. It has the issue of keeping up with state yet almost the entire internet rests on its shoulders and it works.
I have been trying to find what algorithms or techniques are used to actually accomplish the routing whereby the edge server closest to the user is chosen. Is this accomplished by pinging multiple servers and choosing the one with the lowest TTFB?
> Better developer experience<p>That's some wishful thinking right there.<p>Though author admits that DX is worse <i>right now</i>. But then there are frameworks that abstract edge overhead.<p>Ok, but abstracted overhead is still worse than no overhead.<p>And then there's modeling your data without a centralized database. There's no world where it leads to better DX.
Wow that really fell apart in the last couple paragraphs.<p>Just glides over important topics like security and completely avoids others like data and application design. This hurts them and the edge space imo.<p>This is just a paper ad for Deno Deploy.
The future of the web and the only way it's growing in healthy way is, we, having vm that can runs many languages .. not thing that runs a single language .. everywhere.