17 ms·

The Future of the Web Is on the Edge

230 points by 0xedb 4y ago

vcryan 4y ago
Companies that are banking on edge computing definitely seem to agree with this headline :)
deleted 4y ago
[deleted]
scarmig 4y ago
Are there any relational systems which store persistent shared state at the edge, with some kind of automatic geopartitioning?
- hderms 4y ago
  A relational system with the guarantees usually provided by them seems really difficult to do. Like cockroach db but considerably harder or with considerably worse performance. I always thought it was more common for stuff like KV stores with looser guarantees
- deleted 4y ago
  [deleted]
- babelfish 4y ago
  You could probably run a CockroachDB edge cluster
  - newaccount2021 4y ago
- dingosity 4y ago
  I know you're not asking for this, but distributed consistency can get pretty hairy in anything but the simplest of cases. I know you've probably heard all this, but for the people unfamiliar with CAP theory, if you're asking yourself the same questions and you haven't spent much time researching it, it's worth it to get an over-view. The WikiPedia page is pretty simple, but has links to decent references: https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem And if you want to get your math on, check out TLA: https://en.wikipedia.org/wiki/Temporal_logic_of_actions https://en.wikipedia.org/wiki/Temporal_logic_of_actions (Again, the wikipedia page is laughably incomplete, but has references worth clicking on.)
tommek4077 4y ago
> 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. 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.
- dcchambers 4y ago
  > Often you've got the feeling of "magicians" using technobabble to let things look much more difficult or new than they are. Just one of the ways people work to keep salaries up ;)
  - ThalesX 4y ago
    > Just one of the ways people work to keep salaries up ;) I get a bigger paycheck by explaining tech to business in business terms so I'm not sure that's a valid approach after a particular level of salary.
- horsawlarway 4y ago
  Yes - but even then... it's not really true unless your site is completely static resources. If you're pushing a blog out - Great! If you're pushing out anything that relies on application state... much less great. At best, you then end up in a world of trouble dealing with eventually consistent data, sharding/tenanting, CRDTs, "edge" KV stores (that are really just hiding the eventually consistent nature from you) and all sorts of other trade offs. If I'm directly collaborating with some half way around the globe in a web application - there is literally no magic way to wave a wand and make that latency go away.
  - Existenceblinks 4y ago
    One thing I don't understand CRDT hype is it doesn't solve semantics conflict problem, and solving it on app level would also be better by-passing CRDT completely. And one more thing, real-time collaboration just mean road without sign, lines, traffic light. Having process in place, in async way, is considerably more efficient.
asim 4y ago
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. 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.
newaccount2021 4y ago
Karellen 4y ago
Curse you Title Case!! 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. https://en.wikipedia.org/wiki/Microsoft_Edge https://en.wikipedia.org/wiki/Microsoft_Edge 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.
- tenebrisalietum 4y ago
  Proper nouns don't take articles. If Edge was intended as a proper noun the title would have been "The Future of the Web Is on Edge".
  - Karellen 4y ago
    Sorry, seen too many ungrammatical headlines in my time for that consideration to have swayed how I parsed that one.
- userbinator 4y ago
  Glad I'm not the only one who also thought the title was some sort of MS marketing slogan. ...or it could also be a pun about Edge becoming another Chrome-clone.
jensneuse 4y ago
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 (https://wundergraph.com/ https://wundergraph.com/). 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.
- jstummbillig 4y ago
  > But they explicitly say that your serverless functions should be close to a database if you're using one. Or else?
  - tmikaeld 4y ago
    You'll get the latencies noted for Heroku in the article.
  - jensneuse 4y ago
    Let's say the user is in FRA, the database in SF. If the "server" is on the edge, you'll end up with 100-200ms between server and database, while the user has less than 10ms latency to the "edge". If the server does multiple round-trips to the database, it can take seconds until the first byte. If the server and database are both in SF, TTFB will probably be less than one second, as round trips between database and server are almost zero. One thing to mention is that it would be beneficial of the TLS handshake could be made on the edge, as it's a multi roundtrip transaction. Ideally, we could combine a server close to the DB with a stateless edge service. So, the future of the web might not be on the edge. It's rather: The future if the web will leverage the edge.
recursivedoubts 4y ago
OK, but what about data synchronization? 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. 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. 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. 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.
- solardev 4y ago
  One option is that you can abstract it away like cloudflare does using DBs or KV stores that live natively on the edge. Look up their IRC or Doom demos on the edge sometimes. There is no central server needed, the edge nodes just figure that out with each other behind the scenes and you don't have to worry about the low-level sync models. Less control, easier to use.
qprofyeh 4y ago
Are there other frameworks designed with edge deployment in mind?
- emschwartz 4y ago
  https://remix.run/ https://remix.run/ and https://qwik.builder.io/ https://qwik.builder.io/ are two others. I believe that React Server components is also heading in that direction.
- quechimba 4y ago
  I'm making one in Ruby. It's kinda like React but it streams all the DOM-patches to the browser (about 3-4kB of JS in total) Clicking stuff feel instant due to being so close to the edge node. I've been working on this full time for three months now, gonna keep going because I think it's a good way to make web apps. Hot reloading is pretty awesome. Event handlers/callbacks are just RPC-calls so no need to make a REST API or anything like that.
dingosity 4y ago
Meh. My future is a linux laptop with emacs and ssh. But yeah. I feel you. The Edge is where all the cool kids are hanging out. 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.
- marcus_cemes 4y ago
  That's perfectly sufficient for a large number of use cases, keeping things simple. The edge isn't just where the cool kids hang out, through. There is a very noticable latency hit over long distances, amplified by the number of round trips needed. If you have a local business, this isn't a problem. Making it super simple to deploy things to the edge, and developing systems to make it easier to push data that can be cached to the edge to avoid trips to a central database, is awesome even for hobbist programmers, like Heroku made it easy to deploy applications without worrying about VMs.
zitterbewegung 4y ago
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.
- imiric 4y ago
  That's neat, but it's not the web. You're merely using the web as a deployment mechanism, and the "browser" as a hypervisor. You might as well build an Electron app at that point if you want the desktop UX.
  - horsawlarway 4y ago
    Out of curiosity - what do you believe the web is, exactly? Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs).
    - imiric 4y ago
      Right, I was a bit harsh with the "it's not the web" remark. Ultimately, the web is what we make of it, and it's not up to anyone to claim it's one thing or the other. Initially, the "web" had a clear definition: a client-server architecture, a markup language to render data from the server, a protocol for the client to request data from the server, and a universal format to reference data. Then we added more technologies to improve styling, interactivity, P2P protocols, etc., and it's been evolving ever since. Instead of documents, we served apps. Thin clients were deemed unsuitable, until we realized performance might be an issue, and now we can choose whichever approach makes sense for the product. So I'd say I'm a bit of a traditionalist in this sense, and think that a web app should still involve frequent communication with a server. If you're building a product using web technologies, but it's running entirely (or mostly) offline, that's great, but it's not part of the World Wide Web. You could use any number of technologies to build a desktop app at that point, and using web frameworks and a web browser is a choice made out of convenience, rather than suitability. After all, if you download an installer over HTTP for an offline desktop app written in a non-web language, would that still count as a "web app"? We have to draw the line somewhere, and I suppose it's a matter of preference where that is done. Or maybe the line is forever blurred and web apps are all that we have now... > Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs). I don't think that's the case. I may disagree with the assertion that "the future of the web is on the edge", but the article still suggests a traditional client-server model. It's just that the server is now distributed and closer to the client, which in general is a good idea.
eddieh 4y ago
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.
- ocdtrekkie 4y ago
  Many definitions of edge computing are already this: Just running software on local hardware, but of course, still billing it like it's a cloud service with a SaaS model. Throw it all out and run everything off a PC in your basement, you'll thank me later.
deckard1 4y ago
The Future of the Web is Peddling Endless Amounts of Cloud Frameworks 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. 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.
- oceanplexian 4y ago
  You say that until you travel somewhere in Eastern Europe, South America, or Southeast Asia, and realize that 90% of the Western Internet is completely and utterly broken. Everything besides Google, Facebook, etc. (Because they’ve invested in solving the problem) are practically unusable. The problem isn’t just TTFB or latency, as some people are implying, it’s poor interconnectivity at the transit provider level. Those links are frequently congested and experience fiber cuts, and unless you’re peered in that country your application is going to perform poorly. The companies who understand this have a first mover advantage in some of the fastest growing economies in the world.
  - deleted 4y ago
    [deleted]
uncertainrhymes 4y ago
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. 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. For serverless, there is no origin -- even better for performance, assuming it has no need for a common data store.
- jacobn 4y ago
  > With enough traffic, their edge servers will keep connections open to origin. Except AWS CloudFront when used with a custom origin server (whole site acceleration) - their "clever" load distribution algorithm requires inordinate amounts of traffic for effective origin connection re-use. I run multiple sites in the top 100k websites globally and am getting effectively zero origin connection re-use. Badgered them about it but all I got was a wontfix :-/ Sigh.
  - jamesfinlayson 4y ago
    I'm glad it's not just me - I remember trying to improve site response times for a site using CloudFront and I thought I'd done the right thing as far a settings go, but got no improvement.
- pier25 4y ago
  > It should not be almost 400 ms from Amsterdam to Virginia on an existing connection. Exactly, it should be much closer to 100-150ms. My production server is in AMS and I'm in central Mexico (QRO). The response is around 200ms, often less than that.
xwowsersx 4y ago
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?
- sgammon 4y ago
  that’s one way, yes, but it relies on DNSLB, which necessitates shorter TTLs, which means more round trips to DNS. the smooth way to do this (how Google and others do it, the big boys) is via Anycast routing, where you are IP-routed to the nearest available node (I.e. all nodes globally share an external IP identity and so DNS is not driving LB or routing). https://en.m.wikipedia.org/wiki/Anycast https://en.m.wikipedia.org/wiki/Anycast edit: i should say, DNSLB needs shorter TTLs, lots of monitoring, and you're already in reactive mode, but otherwise it is a great solution.
  - xwowsersx 4y ago
    Thank you. DNSLB = DNS-based load balancer or..?
    - sgammon 4y ago
      yes, with NLB = network load balancer, at least when i have encountered the terms.
jmcantrell 4y ago
The curl command mentioned in the article that's supposed to show the region being used for a request `curl -ls https://deno.land https://deno.land` doesn't seem to work as described. Does anyone know if this is a typo?
- snowwrestler 4y ago
  curl -I worked for me on a Mac. The -I flag returns only the headers.
  - jmcantrell 4y ago
    Thanks, this worked for me, too. I wonder why the command used in the article is so different.
- deleted 4y ago
  [deleted]
horsawlarway 4y ago
Frankly - who cares unless there's a persistence mechanism to go with this? The devil isn't in getting a static resource close to users (we've been able to do this for decades with CDNs) The devil is in getting application state pushed close to those users. "Eventually consistent" is a real bitch of a thing to deal with.
- Existenceblinks 4y ago
  My conclusion from trying to get erlang distribution works across regions is, just don't. Distributed postgresql on fly.io is cool .. though only for read heavy.
lifty 4y ago
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?
- Existenceblinks 4y ago
  Edgy PC!
- asim 4y ago
  Local first!
- mlrhazi 4y ago
  Applets ?
- billywhizz 4y ago
  a web browser?
- maxwellpeterson 4y ago
  picoservices
- doctor_eval 4y ago
  Distributed client-side edge cache.
  - doctor_eval 4y ago
    Oooh I know. Cacheless
- aliqot 4y ago
  At long last.. "Year of the linux desktop".
- hbrn 4y ago
  Sarcasm aside, this is actually a good point. Most apps are either unable to work without a semi-centralized database. Or can work with local database and slow syncs to the cloud (a la Dropbox). Very few apps fit between those two categories. Edge looks like a solution looking for a problem.
ludwigvan 4y ago
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. 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. 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...?
- deleted 4y ago
  [deleted]
- crabmusket 4y ago
  E-commerce. Significant static content, but also significant interactivity, and performance is important as your users are almost by definition "shopping around".
- hbrn 4y ago
  > Games: this is one area this might make a difference due to latency advantage But then players from Singapore can't play with players from New York. So single player games. In the browser. Yay.
Existenceblinks 4y ago
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.
- erikpukinskis 4y ago
  That’s a nice goal for a generic cloud provider, but within a company having many languages causes a lot of problems. You really want two or ideally one language across your stack. Maybe 3 if you have some really specific workload. If I’m a TypeScript Company or a Python Company I really don’t care if my cloud provider can run JVM. And vice versa.
  - Existenceblinks 4y ago
    I guess some nice wasm runtimes would suffice.
pier25 4y ago
As much as I love Deno, I think this is the wrong way to frame it. For a number of reasons. 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. 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. 3) Those latency numbers don't seem right to me. My production server in AMS returns a response in 200ms to here (central Mexico). 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. The edge is cool, but it's not "the future". It's just another tool with pros and cons.
- bavarianbob 4y ago
  I enjoyed reading your level-headed perception of this.
  - pier25 4y ago
    Thank you kind sir.
- heypeter01 4y ago
  > 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. --- Disagree with this, performance optimization is a statistical issue and considering only the time spent on a single request is very one-sided. You should also calculate the latency of all requests (how long the user waits in total in the application) over the lifetime of the application. 50 milliseconds and one second have a huge impact on the experience.
- brundolf 4y ago
  These are all valid points, though for me, one thing I like about the "edge" model for application servers (workers) is the abstraction that you don't have to think about where your servers live, how many there are, when they start and stop, etc. The fact that they basically have to be stateless also simplifies things Even if your storage is centralized (and it may not have to be; some companies are offering edge storage solutions that handle synchronization for you), it seems nice to be able to just ship code and let the provider worry about when and where and how much That said- I've never used edge workers in production, so I could be over-idealizing the reality
paxys 4y ago
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? 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.
Thaxll 4y ago
At the edge, so your app is at the edge but the DB is 80ms away. Too much focus on latency, trying to fix a non existing problem.
jgalt212 4y ago
I'm looking for a blog post the combines the best elements of the future of the web with the future of work.
cheriot 4y ago
> 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. 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. And no mention of where the data is? As far as I can tell, this is buzzword soup with no broadly applicable use case.
andirk 4y ago
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.
stevage 4y ago
Yet another web dev article assuming that every web app is massive scale, for a global audience of consumers that have alternative choices. I have worked on dozens of web sites for paying clients, and none were in that category. Also, mostly I just want to know, why is Singapore's connectivity so slow? Some sort of filter?
superkuh 4y ago
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.
- bitwize 4y ago
  Counterexample: Kiwi Farms, which transitioned to a distributed hosting setup across a variety of providers after the recent Kerfuffals. But that was more to avoid a single point of failure than to mitigate latency concerns. And yes, efforts are ongoing to identify and punish the hosting providers involved, their principals, and their principals' families.
  - superkuh 4y ago
    Proves the rule. I think we can all agree that what kiwi farms has to do is not what 99.999% of people will have to do. Due to their current high world profile they have many of the same needs as a corporation.
jmull 4y ago
IDK, I think this is getting overstated. Don't forget - there's very typically a runtime environment available that's a lot closer to the user... their browser. 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. If the data the edge needs is also 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. 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. 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. I think this will be more of a tool in the toolbox, not the general future of the web.
tonymet 4y ago
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. Querying large indexes is the most common use case that needs code to run. Sqlite would standardize storage & query implementation
Kass-y 4y ago
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. 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. Will your users pay for cutting your response time from 944.14ms to 45ms? And the additional complexity that comes with? 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. 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.
- presentation 4y ago
  Um 944.14ms is almost a second, much longer than the time it takes them to blink.
  - Kass-y 4y ago
    Granted. It is, however, the worst case scenario as quoted from a marketing piece that's going to render itself in the best light. According to DDG the average time for a blink is between 100-400 ms. Okay, maybe they blinked a few times. You're taking on a large complexity problem for the difference between one and a few blinks - and that's in the worst case scenario, which for most applications can probably be ameliorated with pre-loading assets. I'm just not seeing the user-value here. At least not compared to the investment required to adopt more complex architecture and the problems that involves - if your IO really does occur on those sorts of timeframes, (e.g. if you're doing meaningful things at sub 900ms, how are you dealing with race conditions in this distributed architecture? If you're not dealing with race conditions, and have an effectively static set of data that you're just pushing, why aren't you dealing with that via pre-loading the assets?) That stuff's gotta be paid for. Do you think the difference between one blink or... I dunno, let's be generous and say four - I think if I blinked four times it might take longer than a second, mostly due to the delay between blinks - constitutes a competitive edge sufficient to offset the cost?
hbrn 4y ago
> Better developer experience That's some wishful thinking right there. Though author admits that DX is worse right now. But then there are frameworks that abstract edge overhead. Ok, but abstracted overhead is still worse than no overhead. And then there's modeling your data without a centralized database. There's no world where it leads to better DX.
mwcampbell 4y ago
HN itself is hosted on a single US-based server. Does this actually bother people outside the US?
- Zababa 4y ago
  I'm in France and HN is almost always very responsive to me. I think one of the reasons why HN doesn't need to be "on the edge" as much as other applications is that servers roundtrips are relatively rare as it's more of a website, compared to web applications. To reply to you I clicked "reply", I'll click it again to post, but that's two interactions with the server in the time it takes me to write this post. If you're on an application that has to do rountrips to the server for each interactions, it could be useful to be on the edge, I think.
- spartanatreyu 4y ago
  No, and here's why: HN's page makes so few requests I can count them on one hand. Compare that to a typical website and you'll see a different story. For example: The main website of my employer makes 86 requests which takes 7.13s to load. But with some clever resource deferring/ordering I've been able to get the DomContentLoaded event to fire (and appear loaded) in 2.81s. Unfortunately I won't be able to get that number any lower without some considerable months of investment on optimising that website, but that developer time is always prioritised elsewhere.
nnx 4y ago
How does Fresh compare to SvelteKit?
55555 4y ago
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. 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) Or are Deno etc only used for database-less sites? Or is everyone just obsessed with TTFP (screen painting) load times because users hate waiting but like pretty loading spinner gifs?
- belmont_sup 4y ago
  There are a few threads here that discussed options for distributed databases. If you don’t need a single logical cluster for the entire system, it’s totally fine to deploy primary dbs at each region you need. You still gain some of the edge deployment benefits by virtue of no work required for multiregion app deployment. Otherwise, you’re configuring route53 to route requests to servers closest to them. But if you need a single logical database shared globally, any new distributed “new-sql” products work: Fauna, Cockroach, TiDB, and I’m sure many others. These are just the few I know that’s used heavily and publicly.
solatic 4y ago
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 most cases, you don't want 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? 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.
ehnto 4y ago
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" 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. 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!
ThinkBeat 4y ago
Or just drastically shrink how much data has to be pushed. Static content can be hosted via a CDN to get it close. Serverless workers distributed on a global basis running nanoservices backed by Sqlite on the edge that gets way complicated. 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. The usual answer is "we will build that ourselves", then over time the team discovers why it is definite hard problem to solve. You end up reimplementing parts of a database server with added level of complexity. Most architecture should start with "Distributed transactions". Do we need them If so how will we do it. That is just my obsession.
johnnyAghands 4y ago
Wow that really fell apart in the last couple paragraphs. Just glides over important topics like security and completely avoids others like data and application design. This hurts them and the edge space imo. This is just a paper ad for Deno Deploy.
quechimba 4y ago
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. 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. 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...

230 points by 0xedb 4y ago

vcryan 4y ago

Companies that are banking on edge computing definitely seem to agree with this headline :)

deleted 4y ago

[deleted]

scarmig 4y ago

Are there any relational systems which store persistent shared state at the edge, with some kind of automatic geopartitioning?

hderms 4y ago
A relational system with the guarantees usually provided by them seems really difficult to do. Like cockroach db but considerably harder or with considerably worse performance. I always thought it was more common for stuff like KV stores with looser guarantees
deleted 4y ago
[deleted]
babelfish 4y ago
You could probably run a CockroachDB edge cluster
- newaccount2021 4y ago
dingosity 4y ago
I know you're not asking for this, but distributed consistency can get pretty hairy in anything but the simplest of cases. I know you've probably heard all this, but for the people unfamiliar with CAP theory, if you're asking yourself the same questions and you haven't spent much time researching it, it's worth it to get an over-view. The WikiPedia page is pretty simple, but has links to decent references: https://en.wikipedia.org/wiki/CAP_theorem https://en.wikipedia.org/wiki/CAP_theorem And if you want to get your math on, check out TLA: https://en.wikipedia.org/wiki/Temporal_logic_of_actions https://en.wikipedia.org/wiki/Temporal_logic_of_actions (Again, the wikipedia page is laughably incomplete, but has references worth clicking on.)

tommek4077 4y ago

> 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. 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.

dcchambers 4y ago
> Often you've got the feeling of "magicians" using technobabble to let things look much more difficult or new than they are. Just one of the ways people work to keep salaries up ;)
- ThalesX 4y ago
  > Just one of the ways people work to keep salaries up ;) I get a bigger paycheck by explaining tech to business in business terms so I'm not sure that's a valid approach after a particular level of salary.
horsawlarway 4y ago
Yes - but even then... it's not really true unless your site is completely static resources. If you're pushing a blog out - Great! If you're pushing out anything that relies on application state... much less great. At best, you then end up in a world of trouble dealing with eventually consistent data, sharding/tenanting, CRDTs, "edge" KV stores (that are really just hiding the eventually consistent nature from you) and all sorts of other trade offs. If I'm directly collaborating with some half way around the globe in a web application - there is literally no magic way to wave a wand and make that latency go away.
- Existenceblinks 4y ago
  One thing I don't understand CRDT hype is it doesn't solve semantics conflict problem, and solving it on app level would also be better by-passing CRDT completely. And one more thing, real-time collaboration just mean road without sign, lines, traffic light. Having process in place, in async way, is considerably more efficient.

asim 4y ago

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. 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.

newaccount2021 4y ago

Karellen 4y ago

Curse you Title Case!! 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. https://en.wikipedia.org/wiki/Microsoft_Edge https://en.wikipedia.org/wiki/Microsoft_Edge 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.

tenebrisalietum 4y ago
Proper nouns don't take articles. If Edge was intended as a proper noun the title would have been "The Future of the Web Is on Edge".
- Karellen 4y ago
  Sorry, seen too many ungrammatical headlines in my time for that consideration to have swayed how I parsed that one.
userbinator 4y ago
Glad I'm not the only one who also thought the title was some sort of MS marketing slogan. ...or it could also be a pun about Edge becoming another Chrome-clone.

jensneuse 4y ago

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 (https://wundergraph.com/ https://wundergraph.com/). 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.

jstummbillig 4y ago
> But they explicitly say that your serverless functions should be close to a database if you're using one. Or else?
- tmikaeld 4y ago
  You'll get the latencies noted for Heroku in the article.
- jensneuse 4y ago
  Let's say the user is in FRA, the database in SF. If the "server" is on the edge, you'll end up with 100-200ms between server and database, while the user has less than 10ms latency to the "edge". If the server does multiple round-trips to the database, it can take seconds until the first byte. If the server and database are both in SF, TTFB will probably be less than one second, as round trips between database and server are almost zero. One thing to mention is that it would be beneficial of the TLS handshake could be made on the edge, as it's a multi roundtrip transaction. Ideally, we could combine a server close to the DB with a stateless edge service. So, the future of the web might not be on the edge. It's rather: The future if the web will leverage the edge.

recursivedoubts 4y ago

OK, but what about data synchronization? 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. 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. 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. 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.

solardev 4y ago
One option is that you can abstract it away like cloudflare does using DBs or KV stores that live natively on the edge. Look up their IRC or Doom demos on the edge sometimes. There is no central server needed, the edge nodes just figure that out with each other behind the scenes and you don't have to worry about the low-level sync models. Less control, easier to use.

qprofyeh 4y ago

Are there other frameworks designed with edge deployment in mind?

emschwartz 4y ago
https://remix.run/ https://remix.run/ and https://qwik.builder.io/ https://qwik.builder.io/ are two others. I believe that React Server components is also heading in that direction.
quechimba 4y ago
I'm making one in Ruby. It's kinda like React but it streams all the DOM-patches to the browser (about 3-4kB of JS in total) Clicking stuff feel instant due to being so close to the edge node. I've been working on this full time for three months now, gonna keep going because I think it's a good way to make web apps. Hot reloading is pretty awesome. Event handlers/callbacks are just RPC-calls so no need to make a REST API or anything like that.

dingosity 4y ago

Meh. My future is a linux laptop with emacs and ssh. But yeah. I feel you. The Edge is where all the cool kids are hanging out. 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.

marcus_cemes 4y ago
That's perfectly sufficient for a large number of use cases, keeping things simple. The edge isn't just where the cool kids hang out, through. There is a very noticable latency hit over long distances, amplified by the number of round trips needed. If you have a local business, this isn't a problem. Making it super simple to deploy things to the edge, and developing systems to make it easier to push data that can be cached to the edge to avoid trips to a central database, is awesome even for hobbist programmers, like Heroku made it easy to deploy applications without worrying about VMs.

zitterbewegung 4y ago

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.

imiric 4y ago
That's neat, but it's not the web. You're merely using the web as a deployment mechanism, and the "browser" as a hypervisor. You might as well build an Electron app at that point if you want the desktop UX.
- horsawlarway 4y ago
  Out of curiosity - what do you believe the web is, exactly? Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs).
  - imiric 4y ago
    Right, I was a bit harsh with the "it's not the web" remark. Ultimately, the web is what we make of it, and it's not up to anyone to claim it's one thing or the other. Initially, the "web" had a clear definition: a client-server architecture, a markup language to render data from the server, a protocol for the client to request data from the server, and a universal format to reference data. Then we added more technologies to improve styling, interactivity, P2P protocols, etc., and it's been evolving ever since. Instead of documents, we served apps. Thin clients were deemed unsuitable, until we realized performance might be an issue, and now we can choose whichever approach makes sense for the product. So I'd say I'm a bit of a traditionalist in this sense, and think that a web app should still involve frequent communication with a server. If you're building a product using web technologies, but it's running entirely (or mostly) offline, that's great, but it's not part of the World Wide Web. You could use any number of technologies to build a desktop app at that point, and using web frameworks and a web browser is a choice made out of convenience, rather than suitability. After all, if you download an installer over HTTP for an offline desktop app written in a non-web language, would that still count as a "web app"? We have to draw the line somewhere, and I suppose it's a matter of preference where that is done. Or maybe the line is forever blurred and web apps are all that we have now... > Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs). I don't think that's the case. I may disagree with the assertion that "the future of the web is on the edge", but the article still suggests a traditional client-server model. It's just that the server is now distributed and closer to the client, which in general is a good idea.

eddieh 4y ago

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.

ocdtrekkie 4y ago
Many definitions of edge computing are already this: Just running software on local hardware, but of course, still billing it like it's a cloud service with a SaaS model. Throw it all out and run everything off a PC in your basement, you'll thank me later.

deckard1 4y ago

The Future of the Web is Peddling Endless Amounts of Cloud Frameworks 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. 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.

oceanplexian 4y ago
You say that until you travel somewhere in Eastern Europe, South America, or Southeast Asia, and realize that 90% of the Western Internet is completely and utterly broken. Everything besides Google, Facebook, etc. (Because they’ve invested in solving the problem) are practically unusable. The problem isn’t just TTFB or latency, as some people are implying, it’s poor interconnectivity at the transit provider level. Those links are frequently congested and experience fiber cuts, and unless you’re peered in that country your application is going to perform poorly. The companies who understand this have a first mover advantage in some of the fastest growing economies in the world.
- deleted 4y ago
  [deleted]

uncertainrhymes 4y ago

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. 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. For serverless, there is no origin -- even better for performance, assuming it has no need for a common data store.

jacobn 4y ago
> With enough traffic, their edge servers will keep connections open to origin. Except AWS CloudFront when used with a custom origin server (whole site acceleration) - their "clever" load distribution algorithm requires inordinate amounts of traffic for effective origin connection re-use. I run multiple sites in the top 100k websites globally and am getting effectively zero origin connection re-use. Badgered them about it but all I got was a wontfix :-/ Sigh.
- jamesfinlayson 4y ago
  I'm glad it's not just me - I remember trying to improve site response times for a site using CloudFront and I thought I'd done the right thing as far a settings go, but got no improvement.
pier25 4y ago
> It should not be almost 400 ms from Amsterdam to Virginia on an existing connection. Exactly, it should be much closer to 100-150ms. My production server is in AMS and I'm in central Mexico (QRO). The response is around 200ms, often less than that.

xwowsersx 4y ago

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?

sgammon 4y ago
that’s one way, yes, but it relies on DNSLB, which necessitates shorter TTLs, which means more round trips to DNS. the smooth way to do this (how Google and others do it, the big boys) is via Anycast routing, where you are IP-routed to the nearest available node (I.e. all nodes globally share an external IP identity and so DNS is not driving LB or routing). https://en.m.wikipedia.org/wiki/Anycast https://en.m.wikipedia.org/wiki/Anycast edit: i should say, DNSLB needs shorter TTLs, lots of monitoring, and you're already in reactive mode, but otherwise it is a great solution.
- xwowsersx 4y ago
  Thank you. DNSLB = DNS-based load balancer or..?
  - sgammon 4y ago
    yes, with NLB = network load balancer, at least when i have encountered the terms.

jmcantrell 4y ago

The curl command mentioned in the article that's supposed to show the region being used for a request `curl -ls https://deno.land https://deno.land` doesn't seem to work as described. Does anyone know if this is a typo?

snowwrestler 4y ago
curl -I worked for me on a Mac. The -I flag returns only the headers.
- jmcantrell 4y ago
  Thanks, this worked for me, too. I wonder why the command used in the article is so different.
deleted 4y ago
[deleted]

horsawlarway 4y ago

Frankly - who cares unless there's a persistence mechanism to go with this? The devil isn't in getting a static resource close to users (we've been able to do this for decades with CDNs) The devil is in getting application state pushed close to those users. "Eventually consistent" is a real bitch of a thing to deal with.

Existenceblinks 4y ago
My conclusion from trying to get erlang distribution works across regions is, just don't. Distributed postgresql on fly.io is cool .. though only for read heavy.

lifty 4y ago

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?

Existenceblinks 4y ago
Edgy PC!
asim 4y ago
Local first!
mlrhazi 4y ago
Applets ?
billywhizz 4y ago
a web browser?
maxwellpeterson 4y ago
picoservices
doctor_eval 4y ago
Distributed client-side edge cache.
- doctor_eval 4y ago
  Oooh I know. Cacheless
aliqot 4y ago
At long last.. "Year of the linux desktop".
hbrn 4y ago
Sarcasm aside, this is actually a good point. Most apps are either unable to work without a semi-centralized database. Or can work with local database and slow syncs to the cloud (a la Dropbox). Very few apps fit between those two categories. Edge looks like a solution looking for a problem.

ludwigvan 4y ago

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. 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. 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...?

deleted 4y ago
[deleted]
crabmusket 4y ago
E-commerce. Significant static content, but also significant interactivity, and performance is important as your users are almost by definition "shopping around".
hbrn 4y ago
> Games: this is one area this might make a difference due to latency advantage But then players from Singapore can't play with players from New York. So single player games. In the browser. Yay.

Existenceblinks 4y ago

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.

erikpukinskis 4y ago
That’s a nice goal for a generic cloud provider, but within a company having many languages causes a lot of problems. You really want two or ideally one language across your stack. Maybe 3 if you have some really specific workload. If I’m a TypeScript Company or a Python Company I really don’t care if my cloud provider can run JVM. And vice versa.
- Existenceblinks 4y ago
  I guess some nice wasm runtimes would suffice.

pier25 4y ago

As much as I love Deno, I think this is the wrong way to frame it. For a number of reasons. 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. 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. 3) Those latency numbers don't seem right to me. My production server in AMS returns a response in 200ms to here (central Mexico). 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. The edge is cool, but it's not "the future". It's just another tool with pros and cons.

bavarianbob 4y ago
I enjoyed reading your level-headed perception of this.
- pier25 4y ago
  Thank you kind sir.
heypeter01 4y ago
> 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. --- Disagree with this, performance optimization is a statistical issue and considering only the time spent on a single request is very one-sided. You should also calculate the latency of all requests (how long the user waits in total in the application) over the lifetime of the application. 50 milliseconds and one second have a huge impact on the experience.
brundolf 4y ago
These are all valid points, though for me, one thing I like about the "edge" model for application servers (workers) is the abstraction that you don't have to think about where your servers live, how many there are, when they start and stop, etc. The fact that they basically have to be stateless also simplifies things Even if your storage is centralized (and it may not have to be; some companies are offering edge storage solutions that handle synchronization for you), it seems nice to be able to just ship code and let the provider worry about when and where and how much That said- I've never used edge workers in production, so I could be over-idealizing the reality

paxys 4y ago

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? 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.

Thaxll 4y ago

At the edge, so your app is at the edge but the DB is 80ms away. Too much focus on latency, trying to fix a non existing problem.

jgalt212 4y ago

I'm looking for a blog post the combines the best elements of the future of the web with the future of work.

cheriot 4y ago

> 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. 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. And no mention of where the data is? As far as I can tell, this is buzzword soup with no broadly applicable use case.

andirk 4y ago

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.

stevage 4y ago

Yet another web dev article assuming that every web app is massive scale, for a global audience of consumers that have alternative choices. I have worked on dozens of web sites for paying clients, and none were in that category. Also, mostly I just want to know, why is Singapore's connectivity so slow? Some sort of filter?

superkuh 4y ago

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.

bitwize 4y ago
Counterexample: Kiwi Farms, which transitioned to a distributed hosting setup across a variety of providers after the recent Kerfuffals. But that was more to avoid a single point of failure than to mitigate latency concerns. And yes, efforts are ongoing to identify and punish the hosting providers involved, their principals, and their principals' families.
- superkuh 4y ago
  Proves the rule. I think we can all agree that what kiwi farms has to do is not what 99.999% of people will have to do. Due to their current high world profile they have many of the same needs as a corporation.

jmull 4y ago

IDK, I think this is getting overstated. Don't forget - there's very typically a runtime environment available that's a lot closer to the user... their browser. 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. If the data the edge needs is also 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. 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. 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. I think this will be more of a tool in the toolbox, not the general future of the web.

tonymet 4y ago

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. Querying large indexes is the most common use case that needs code to run. Sqlite would standardize storage & query implementation

Kass-y 4y ago

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. 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. Will your users pay for cutting your response time from 944.14ms to 45ms? And the additional complexity that comes with? 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. 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.

presentation 4y ago
Um 944.14ms is almost a second, much longer than the time it takes them to blink.
- Kass-y 4y ago
  Granted. It is, however, the worst case scenario as quoted from a marketing piece that's going to render itself in the best light. According to DDG the average time for a blink is between 100-400 ms. Okay, maybe they blinked a few times. You're taking on a large complexity problem for the difference between one and a few blinks - and that's in the worst case scenario, which for most applications can probably be ameliorated with pre-loading assets. I'm just not seeing the user-value here. At least not compared to the investment required to adopt more complex architecture and the problems that involves - if your IO really does occur on those sorts of timeframes, (e.g. if you're doing meaningful things at sub 900ms, how are you dealing with race conditions in this distributed architecture? If you're not dealing with race conditions, and have an effectively static set of data that you're just pushing, why aren't you dealing with that via pre-loading the assets?) That stuff's gotta be paid for. Do you think the difference between one blink or... I dunno, let's be generous and say four - I think if I blinked four times it might take longer than a second, mostly due to the delay between blinks - constitutes a competitive edge sufficient to offset the cost?

hbrn 4y ago

> Better developer experience That's some wishful thinking right there. Though author admits that DX is worse right now. But then there are frameworks that abstract edge overhead. Ok, but abstracted overhead is still worse than no overhead. And then there's modeling your data without a centralized database. There's no world where it leads to better DX.

mwcampbell 4y ago

HN itself is hosted on a single US-based server. Does this actually bother people outside the US?

Zababa 4y ago
I'm in France and HN is almost always very responsive to me. I think one of the reasons why HN doesn't need to be "on the edge" as much as other applications is that servers roundtrips are relatively rare as it's more of a website, compared to web applications. To reply to you I clicked "reply", I'll click it again to post, but that's two interactions with the server in the time it takes me to write this post. If you're on an application that has to do rountrips to the server for each interactions, it could be useful to be on the edge, I think.
spartanatreyu 4y ago
No, and here's why: HN's page makes so few requests I can count them on one hand. Compare that to a typical website and you'll see a different story. For example: The main website of my employer makes 86 requests which takes 7.13s to load. But with some clever resource deferring/ordering I've been able to get the DomContentLoaded event to fire (and appear loaded) in 2.81s. Unfortunately I won't be able to get that number any lower without some considerable months of investment on optimising that website, but that developer time is always prioritised elsewhere.

nnx 4y ago

How does Fresh compare to SvelteKit?

55555 4y ago

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. 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) Or are Deno etc only used for database-less sites? Or is everyone just obsessed with TTFP (screen painting) load times because users hate waiting but like pretty loading spinner gifs?

belmont_sup 4y ago
There are a few threads here that discussed options for distributed databases. If you don’t need a single logical cluster for the entire system, it’s totally fine to deploy primary dbs at each region you need. You still gain some of the edge deployment benefits by virtue of no work required for multiregion app deployment. Otherwise, you’re configuring route53 to route requests to servers closest to them. But if you need a single logical database shared globally, any new distributed “new-sql” products work: Fauna, Cockroach, TiDB, and I’m sure many others. These are just the few I know that’s used heavily and publicly.

solatic 4y ago

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 most cases, you don't want 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? 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.

ehnto 4y ago

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" 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. 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!

ThinkBeat 4y ago

Or just drastically shrink how much data has to be pushed. Static content can be hosted via a CDN to get it close. Serverless workers distributed on a global basis running nanoservices backed by Sqlite on the edge that gets way complicated. 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. The usual answer is "we will build that ourselves", then over time the team discovers why it is definite hard problem to solve. You end up reimplementing parts of a database server with added level of complexity. Most architecture should start with "Distributed transactions". Do we need them If so how will we do it. That is just my obsession.

johnnyAghands 4y ago

Wow that really fell apart in the last couple paragraphs. Just glides over important topics like security and completely avoids others like data and application design. This hurts them and the edge space imo. This is just a paper ad for Deno Deploy.

quechimba 4y ago

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. 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. 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...