Hacker News Reader

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

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.

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

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.

Too bad distributed DBs are very expensive atm. Their multi-region offerings are only good for companies who can spend thousands on a database each month.

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.

yugabyte looks quite interesting in that space. From what I can tell their OSS product allows for "Row-level geo-partitioning" https://docs.yugabyte.com/preview/explore/multi-region-deplo...

I haven't used it for anything yet, so I don't know how well it works.

Cloud flare made a blog post about this. I tried to find it but I couldn’t. The general idea was that in a post GDPR world as more and more countries put legal limits on the movement of data about their citizens, it gets harder and harder to serve these users with classic web tech. However, they say, that cloudflare workers and durable objects the user data is kept in region and thus you have a clean scalable architecture without legal worries about data jurisdiction.

Check out fly.io as well. They've been adding some SQLite stuff. They also have the added benefit that you can run just about any docker image, not just functions.

I'm building an app using fly.io and SQLite and it's pretty interesting.

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!

https://fly.io/blog/all-in-on-sqlite-litestream/

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.

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.

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.

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.

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.

Counterpoint - every API is non-portable in the beginning. All it takes is a killer app - for example, S3.

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.

They have open sourced the workers runtime to alleviate lock-in fears: https://blog.cloudflare.com/workerd-open-source-workers-runt...

Still though:

> 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 released are the parts you'd need to host your app on other typical cloud hosting services in a typical way (e.g. using kubernetes), which should address lock-in concerns.

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.

I get it, but it means you end up with the arbitrary and limited API that you’d mostly only use for the benefits at the edge, except now you aren’t at the edge and still have all the limitations.

My guess is more conservative - 10 years. But yes I concur with trajectory.

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

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/

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.

heroku was never touted as an edge platform, where are you getting this idea from?

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

Heroku was not a player in the 'edge' market. I just googled to confirm. They actually had a "Heroku Edge" CDN that they added in 2020 for the first time[0], which to me is their entry into Edge style hosting.

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

You often need to have your code close to the database or api servers for requests/queries that depend on each other.

A lot of time the code runs in the browser, which is probably further from the database, and you still need an API inbetween.

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.

Pretty sure under the hood Deno's cloud is running on cloudflare.

How could that be?

CF Workers have a custom runtime on which Deno cannot run.

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.

It is not. It is a custom runtime on custom infrastructure. Why do you assume we use Cloudflare under the hood?

Isn't the "runtime" mostly a wrapper around V8?

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.

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

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

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.

Sorry I'm in the <50ms gang. B)

50ms? I'm happy to get 50ms ping when I play quake/unreal tournament.

200ms is fine for a website.

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

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.

Edge isn't only JS - it's potentially any language with WASM. Deno? sure. But surely you aren't conflating JS with Edge.

Surely you aren't conflating WASM/JS with edge, it's also any edge service that can run docker :)

I enjoyed reading your level-headed perception of this.

Thank you kind sir.

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.

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

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.