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-runt...
this indie-stack shows how to use the remix framework, fly.io, SQLite and Prisma together.
https://github.com/remix-run/indie-stack
I think fly.io will only expand their SQLite features with the creator of Litestream onboard. Exciting stuff!
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.
https://blog.cloudflare.com/cloudflare-pages-goes-full-stack...
I’m actually thinking that with GDPR and similar regional lock-in laws, the future might well be “distributed but independent” DBs, and then both the compliance and the performance problems are solved using more traditional architectures.
I haven't used it for anything yet, so I don't know how well it works.
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.
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
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.
There have been many trends in software, some stay, some go, some evolve
Maybe you are conflating "edge" with "serverless" and over applying the latest buzzword? None of the technologies you have mentioned are "edge" and telecoms have been doing edge since before it had a buzzword.
It's all about deployment and running infra. The "edge" has a lot of complications, and while closer in spirit to the early internet, we gravitated towards centrally controlled compute because it is much easier to manage and maintain at scale. See other comments for why
I think it's fair to call Heroku (and 12factor apps) a pre-cursor to edge computing, but certainly not an early player.
[0] https://web.archive.org/web/20201126133614/https://devcenter...
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.
CF Workers have a custom runtime on which Deno cannot run.
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.
It’s a shiny thing, but at the cost of so much DX and optionality which is a worrying general trend with edge stuff.
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.
I'm on the apprehensive side, but optimistic. Let the early adopters give it a shot so the rest of us can see how worth it it is.
> As hinted above, the full Cloudflare Workers service involves a lot of technology beyond workerd itself, including additional security, deployment mechanisms, orchestration, and so much more. workerd itself is a portion of our runtime codebase, which is itself a small (albeit critical) piece of the overall Cloudflare Workers service.
The parts we did not release are the parts that would only really be useful for building your own hosting service to compete with Cloudflare. These parts would not be particularly useful to someone who merely wants to run their own code -- in fact, they'd be excessively difficult to operate for that use case. This is on par with other services, e.g. my understanding is Deno Deploy has not released this part of their code either.
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.
200ms is fine for a website.
so this is merely re-asserting one of the (now taken for granted) ideas that make the internet what it's become.
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.
This isn't solved my moving the apps to the edge
---
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.
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.