6 ms·

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 di

by 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
- verdverm 4y ago
  You don't need the edge to have the same abstractions for your application. It's commonly called the 12-factor app and there are many ways to achieve it https://12factor.net/ https://12factor.net/
  - 40four 4y ago
    I’m confused. I don’t know how long it’s been around, but I was introduced to this document when I got into Web programming 5-6 years ago. It explicitly states as one of the main goals, ”- (Is) suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;”. I’m not familiar with all the authors, but they also say they came to these conclusions while developing on Heroku/ developing the platform itself. One of the earliest & biggest players in the ‘edge’ software market. Can you elaborate on why you said “you don’t need edge”, when these ideas were intuited by folks creating apps on the edge? Because the way I’m reading it. It seems that this is a methodology perfectly suited (if not designed) for the edge? I tend to agree with the article, that edge is the ‘future’. It might not be next month, or next year. But 5 years from now? It certainly seems to be trending in that direction. And for good reason I think. Don’t get me wrong, I love nerding out with an Ubuntu server, configuring everything, and making my app run on the internet by hand. But dang if it isn’t a lot of work. Most hobby projects I start nowadays, I start from a simple static site approach, keeping in mind I’ll need to progress to more complexity/layers as need be, and throw it up on Netlify or Cloudflare Pages. It’s so efficient, it’s hard for me to imagine starting off a personal project any other way now.
quickthrower2 4y ago
I agree. It is the HN curse in that what is posted here is often while very interesting, too highfalutin for most peoples needs. But it is good to know about. I do like web hosting services that make using CDNs etc. so simple that it is a nobrainer to use them and benefit. When you have to work alot harder to get your thing done to use the “webscale” tech though, this is where you might be burning complexity tokens. I never really see this happen at work though. Often at work it is erring on too conservative.
yellsatclouds 4y ago
one of the driving patterns behind the whole internet (in concept) has always been to have dumb pipes and very smart edges/endpoints so this is merely re-asserting one of the (now taken for granted) ideas that make the internet what it's become.
Comevius 4y ago
As far as I know Cloudflare Pages Functions with Durable Objects or D1 is the only edge infrastructure that can do this currently. D1 uses SQL as it is built on SQLite, and Durable Objects is used for coordination, but also has a transactional storage API. D1 is closed beta, Pages Functions is open beta, but limited to 100,000 requests. You don't need Pages Functions if you have an SPA, it's more of an MPA thing where Workers is used as a server for SSR. It let's you push more work to the server like in the good old days, except the server is a JavaScript runtime running on the edge. Durable Objects is the interesting part, because it gives you the data locality, but also strong consistency. Not shilling for Cloudflare, I just think that their stuff is cool and the rest of the industry is definitely playing catch-up to them. You can argue that most of us don't need the scale and it's true, but I would also argue that we can use the performance and the developer convenience, and by that I also mean time, which is by far the most important resource. Their runtime is also open-source, which makes you feel less tethered to them. https://blog.cloudflare.com/workerd-open-source-workers-runtime/ https://blog.cloudflare.com/workerd-open-source-workers-runt...
- pier25 4y ago
  There are a number of distributed databases in the market. Fauna, GC Spanner, Cockroach, etc. I love the CF stuff. I've been using Workers for a couple of years, even right now in production for streaming audio and other duties. But Workers are not a generalist solution for building complete applications.
  - ZephyrBlu 4y ago
    It looks like Cloudflare is moving towards that with functions in Pages, which allows you to call Workers within your Pages app. https://blog.cloudflare.com/cloudflare-pages-goes-full-stack/ https://blog.cloudflare.com/cloudflare-pages-goes-full-stack...
    - Comevius 4y ago
      Exactly my point, and I'm working on a complicated web app on top of Pages Functions and Durable Objects. The idea is that you can provide dynamic functionality without or with less client-side JavaScript, which is what SSR is about, and at the same time you can also build things like an authentication server, which traditionally requires an actual server, but can be done with just Workers and Durable Objects.
newlisp 4y ago
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. This is not targeted at you but at naive JS developers. JS has millions of users, if they can deceive a good chunk of them with their marketing, then they can make money.
- lucasyvas 4y ago
  Edge isn't only JS - it's potentially any language with WASM. Deno? sure. But surely you aren't conflating JS with Edge.
  - Scarbutt 4y ago
    Surely you aren't conflating WASM/JS with edge, it's also any edge service that can run docker :)
pier25 4y ago
To elaborate... how should Deno market their stuff? IMO developer productivity/experience. Deno are in an extremely privileged position that AFAIK no one has. They have control of the runtime, the cloud platform, and the framework with Fresh. Compare Deno with say Vercel which really only have control over Next. They depend on AWS, Node, and React over which they have no control. No wonder they're investing on Svelte/SvelteKit and other projects. Or Cloudflare who are developing their cloud infra with mediocre DX (although improving) and no framework of their own to be able to sell the complete experience.
- strangescript 4y ago
  Pretty sure under the hood Deno's cloud is running on cloudflare.
  - pier25 4y ago
    How could that be? CF Workers have a custom runtime on which Deno cannot run.
  - belmont_sup 4y ago
    Believe they've called it their own proprietary runtime since they've announced their Deploy service. Their runtime supports TCP connections, so I can actually make db connections, unlike cf workers.
  - lucacasonato 4y ago
    It is not. It is a custom runtime on custom infrastructure. Why do you assume we use Cloudflare under the hood?
- intelVISA 4y ago
  Isn't the "runtime" mostly a wrapper around V8?
ZephyrBlu 4y ago
I disagree. If you look at what Cloudflare is building on top of Workers it definitely seems like the future. KV storage, Durable Objects and Queues (Message passing). You can build complex apps using these tools. E: and D1 and functions in Pages. Everything being on the edge feels like the natural evolution of the current approach. On the frontend there is a focus on more server side rendering and hydration/progressive enhancement. On the backend there is a focused on globally replicating/distributing data for quicker access. Edge is kind of the best of both worlds. For the SSR/hydration/progressive enhancement it's extremely fast because of much lower latency and for backend operations you can cache and/or store data at the edge so it's much quicker to access. Abstractions over the edge like Cloudflare's products also gives you distributed computation and storage for free, which is pretty big. You don't have to care about scaling or coordination the same way you do with a monolith. It seems likely that in 5yrs edge will be the default way to write and distribute new apps.
- nwienert 4y ago
  They are complex, expensive, locked in, partially closed source, and not nearly close to complete solutions. It’s a shiny thing, but at the cost of so much DX and optionality which is a worrying general trend with edge stuff.
  - ZephyrBlu 4y ago
    In what way are they more complex than doing it yourself and not complete solutions? Platform risk always exists, but in this case it seems pretty minimal. Cloudflare's solutions are not anything that can't be easily replaced, the value of them is that they are integrated with the rest of Cloudflare's platform and run on the edge. What do you mean by loss of control? Cloudflare has local dev in their Wrangler tool. I'm not sure how testing/scripting is affected here since the main difference is the deployment target.
    - nwienert 4y ago
      DurableObjects? It's a totally arbitrary API that's non portable and definitely not easily replaced. And once you opt out of db there's a lot less reason for the whole thing.
woojoo666 4y ago
It's a tool with pros and cons, but its still "the future" because it's in early stages and a lot of the possibilities have not been realized yet
snarfy 4y ago
50ms? I'm happy to get 50ms ping when I play quake/unreal tournament. 200ms is fine for a website.
sidlls 4y ago
Your comment regarding performance is on point. 50ms response times are reasonable targets for certain niche cases, e.g. high scale—which most aren’t at) or super time critical applications (e.g. certain sectors of finance, where sometimes 50ms is even too long). Almost every other application or platform would be fine with 100ms or 200ms (or longer!) response times.
benknight87 4y ago
I agree, I think this might be another side effect of clickbait, framing the edge as something that "replaces" traditional architecture, rather than en _evolution_ of the existing architecture where both paradigms can continue to exist side-by-side. As always.
Jataman606 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. That would be true if loading website was just single request. But today web apps load multiple requests and probably even more in the background since so many use microservices. When you say 200ms it sounds fast enough, but usually end result is between 3 and 5 seconds combined. If every request would go from 200 ms to 50 ms, total load time would be closer to 1 second, which is fast enough.
- dmitriid 4y ago
  What you described is the shitty world we live in, when a web "app" that is nothing more than a glorified static web page needs a few megabytes of Javascrpt and "multiple requests because microservices". This isn't solved my moving the apps to the edge
- pier25 4y ago
  Static assets should be loaded from a CDN. You can render the initial HTML in 200ms and load the microservices client-side later without making the user wait. Or even better, don't use microservices. Caching can also help.
  - intelVISA 4y ago
    Sorry I'm in the <50ms gang. B)

by pier25 4y ago

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

verdverm 4y ago
You don't need the edge to have the same abstractions for your application. It's commonly called the 12-factor app and there are many ways to achieve it https://12factor.net/ https://12factor.net/
- 40four 4y ago
  I’m confused. I don’t know how long it’s been around, but I was introduced to this document when I got into Web programming 5-6 years ago. It explicitly states as one of the main goals, ”- (Is) suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;”. I’m not familiar with all the authors, but they also say they came to these conclusions while developing on Heroku/ developing the platform itself. One of the earliest & biggest players in the ‘edge’ software market. Can you elaborate on why you said “you don’t need edge”, when these ideas were intuited by folks creating apps on the edge? Because the way I’m reading it. It seems that this is a methodology perfectly suited (if not designed) for the edge? I tend to agree with the article, that edge is the ‘future’. It might not be next month, or next year. But 5 years from now? It certainly seems to be trending in that direction. And for good reason I think. Don’t get me wrong, I love nerding out with an Ubuntu server, configuring everything, and making my app run on the internet by hand. But dang if it isn’t a lot of work. Most hobby projects I start nowadays, I start from a simple static site approach, keeping in mind I’ll need to progress to more complexity/layers as need be, and throw it up on Netlify or Cloudflare Pages. It’s so efficient, it’s hard for me to imagine starting off a personal project any other way now.

quickthrower2 4y ago

I agree. It is the HN curse in that what is posted here is often while very interesting, too highfalutin for most peoples needs. But it is good to know about. I do like web hosting services that make using CDNs etc. so simple that it is a nobrainer to use them and benefit. When you have to work alot harder to get your thing done to use the “webscale” tech though, this is where you might be burning complexity tokens. I never really see this happen at work though. Often at work it is erring on too conservative.

yellsatclouds 4y ago

one of the driving patterns behind the whole internet (in concept) has always been to have dumb pipes and very smart edges/endpoints so this is merely re-asserting one of the (now taken for granted) ideas that make the internet what it's become.

Comevius 4y ago

As far as I know Cloudflare Pages Functions with Durable Objects or D1 is the only edge infrastructure that can do this currently. D1 uses SQL as it is built on SQLite, and Durable Objects is used for coordination, but also has a transactional storage API. D1 is closed beta, Pages Functions is open beta, but limited to 100,000 requests. You don't need Pages Functions if you have an SPA, it's more of an MPA thing where Workers is used as a server for SSR. It let's you push more work to the server like in the good old days, except the server is a JavaScript runtime running on the edge. Durable Objects is the interesting part, because it gives you the data locality, but also strong consistency. Not shilling for Cloudflare, I just think that their stuff is cool and the rest of the industry is definitely playing catch-up to them. You can argue that most of us don't need the scale and it's true, but I would also argue that we can use the performance and the developer convenience, and by that I also mean time, which is by far the most important resource. Their runtime is also open-source, which makes you feel less tethered to them. https://blog.cloudflare.com/workerd-open-source-workers-runtime/ https://blog.cloudflare.com/workerd-open-source-workers-runt...

pier25 4y ago
There are a number of distributed databases in the market. Fauna, GC Spanner, Cockroach, etc. I love the CF stuff. I've been using Workers for a couple of years, even right now in production for streaming audio and other duties. But Workers are not a generalist solution for building complete applications.
- ZephyrBlu 4y ago
  It looks like Cloudflare is moving towards that with functions in Pages, which allows you to call Workers within your Pages app. https://blog.cloudflare.com/cloudflare-pages-goes-full-stack/ https://blog.cloudflare.com/cloudflare-pages-goes-full-stack...
  - Comevius 4y ago
    Exactly my point, and I'm working on a complicated web app on top of Pages Functions and Durable Objects. The idea is that you can provide dynamic functionality without or with less client-side JavaScript, which is what SSR is about, and at the same time you can also build things like an authentication server, which traditionally requires an actual server, but can be done with just Workers and Durable Objects.

newlisp 4y ago

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. This is not targeted at you but at naive JS developers. JS has millions of users, if they can deceive a good chunk of them with their marketing, then they can make money.

lucasyvas 4y ago
Edge isn't only JS - it's potentially any language with WASM. Deno? sure. But surely you aren't conflating JS with Edge.
- Scarbutt 4y ago
  Surely you aren't conflating WASM/JS with edge, it's also any edge service that can run docker :)

pier25 4y ago

To elaborate... how should Deno market their stuff? IMO developer productivity/experience. Deno are in an extremely privileged position that AFAIK no one has. They have control of the runtime, the cloud platform, and the framework with Fresh. Compare Deno with say Vercel which really only have control over Next. They depend on AWS, Node, and React over which they have no control. No wonder they're investing on Svelte/SvelteKit and other projects. Or Cloudflare who are developing their cloud infra with mediocre DX (although improving) and no framework of their own to be able to sell the complete experience.

strangescript 4y ago
Pretty sure under the hood Deno's cloud is running on cloudflare.
- pier25 4y ago
  How could that be? CF Workers have a custom runtime on which Deno cannot run.
- belmont_sup 4y ago
  Believe they've called it their own proprietary runtime since they've announced their Deploy service. Their runtime supports TCP connections, so I can actually make db connections, unlike cf workers.
- lucacasonato 4y ago
  It is not. It is a custom runtime on custom infrastructure. Why do you assume we use Cloudflare under the hood?
intelVISA 4y ago
Isn't the "runtime" mostly a wrapper around V8?

ZephyrBlu 4y ago

I disagree. If you look at what Cloudflare is building on top of Workers it definitely seems like the future. KV storage, Durable Objects and Queues (Message passing). You can build complex apps using these tools. E: and D1 and functions in Pages. Everything being on the edge feels like the natural evolution of the current approach. On the frontend there is a focus on more server side rendering and hydration/progressive enhancement. On the backend there is a focused on globally replicating/distributing data for quicker access. Edge is kind of the best of both worlds. For the SSR/hydration/progressive enhancement it's extremely fast because of much lower latency and for backend operations you can cache and/or store data at the edge so it's much quicker to access. Abstractions over the edge like Cloudflare's products also gives you distributed computation and storage for free, which is pretty big. You don't have to care about scaling or coordination the same way you do with a monolith. It seems likely that in 5yrs edge will be the default way to write and distribute new apps.

nwienert 4y ago
They are complex, expensive, locked in, partially closed source, and not nearly close to complete solutions. It’s a shiny thing, but at the cost of so much DX and optionality which is a worrying general trend with edge stuff.
- ZephyrBlu 4y ago
  In what way are they more complex than doing it yourself and not complete solutions? Platform risk always exists, but in this case it seems pretty minimal. Cloudflare's solutions are not anything that can't be easily replaced, the value of them is that they are integrated with the rest of Cloudflare's platform and run on the edge. What do you mean by loss of control? Cloudflare has local dev in their Wrangler tool. I'm not sure how testing/scripting is affected here since the main difference is the deployment target.
  - nwienert 4y ago
    DurableObjects? It's a totally arbitrary API that's non portable and definitely not easily replaced. And once you opt out of db there's a lot less reason for the whole thing.

woojoo666 4y ago

It's a tool with pros and cons, but its still "the future" because it's in early stages and a lot of the possibilities have not been realized yet

snarfy 4y ago

50ms? I'm happy to get 50ms ping when I play quake/unreal tournament. 200ms is fine for a website.

sidlls 4y ago

Your comment regarding performance is on point. 50ms response times are reasonable targets for certain niche cases, e.g. high scale—which most aren’t at) or super time critical applications (e.g. certain sectors of finance, where sometimes 50ms is even too long). Almost every other application or platform would be fine with 100ms or 200ms (or longer!) response times.

benknight87 4y ago

I agree, I think this might be another side effect of clickbait, framing the edge as something that "replaces" traditional architecture, rather than en _evolution_ of the existing architecture where both paradigms can continue to exist side-by-side. As always.

Jataman606 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. That would be true if loading website was just single request. But today web apps load multiple requests and probably even more in the background since so many use microservices. When you say 200ms it sounds fast enough, but usually end result is between 3 and 5 seconds combined. If every request would go from 200 ms to 50 ms, total load time would be closer to 1 second, which is fast enough.

dmitriid 4y ago
What you described is the shitty world we live in, when a web "app" that is nothing more than a glorified static web page needs a few megabytes of Javascrpt and "multiple requests because microservices". This isn't solved my moving the apps to the edge
pier25 4y ago
Static assets should be loaded from a CDN. You can render the initial HTML in 200ms and load the microservices client-side later without making the user wait. Or even better, don't use microservices. Caching can also help.
- intelVISA 4y ago
  Sorry I'm in the <50ms gang. B)