The Future of the Web Is on the Edge
deno.com
deno.com
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.
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...
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.
so this is merely re-asserting one of the (now taken for granted) ideas that make the internet what it's become.
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...
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.
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!
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.
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.
200ms is fine for a website.
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.
> Arm-based Ampere A1 cores and 24 GB of memory usable as 1 VM or up to 4 VMs with 3,000 OCPU hours and 18,000 GB hours per month
We aren’t even close to hitting any bottlenecks at this point
99% of the startsup will never need anything more. They'll fail before that. The ones that succeed have a good problem on hand to actually Scale™.
What we're seeing is premature-optimi...errr scaling.
Edit more context:
For Postgres, setup streaming replication between postgres and hot standby. You need a remote server somewhere to check health of your primary and run promote to your hot standby if it fails. It is not that difficult. Have cron jobs to back up your database with pgdumpall in addition somewhere on Backblaze or S3. Use your hot standby to run Grafana/Prometheus/Loki stack. For extra safety, run both servers on ZFS raid (mirror or raidz2) on nvme drives. You'll get like 100k IOPS which would be 300x of base RDS instance on AWS. Ridiculous savings and performance would be just astonishing. Run your app to call postgres on localhost, it will be the fastest web experience your customers will ever experience, on edge or not.
This problem happens in AWS RDS as well: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_...
Actually, this might be much simpler with Cloudflare tunnels. So it failover scenario would be something like this:
1. Primary and Hot standby are active. CF tunnels are routing all traffic to primary.
2. Primary health check fails, use CF health alerts to promote Hot standby to primary (we'll call this new-primary).
3. Postgres promotion completes and new primary starts receiving traffic on CF tunnels automatically.
4. No traffic goes to old-primary. Backup data and use old-primary as a new hotstandby, configure replication again from new-primary.
Even better strategy would be to use Hot Stanby as read-only so traffic is split dynamically depending on write or read needs by the app. Take a look at StackOverflow infra architecture: https://stackexchange.com/performance
You might be surprised how fast it would be. And most companies blow their latency budget with 7 second redirects and touching 28 different microservices before returning a response.
All I am saying is don't get fixated on geo-latency issues. There is a bigger fish to fry.
But after all fish have been fried, you’re right. Servers on the edge would help.
Not arguing that DO is better that postgresql. I'm arguing that a lot of the developers wont realise that. Because the DX of durable objects is superior.
It sounds like a json file… is it a json file? C’mon, tell me it’s NOT just a json file…
I'm not saying it isn't an elegant design, but can we pls not talk about proprietary implementations of a particular design pattern as if they're some kind of industry standard?
Or else?
So, the future of the web might not be on the edge. It's rather: The future if the web will leverage the edge.
1. A strongly consistent globally replicated DB for most data that needs fast reads (<100ms) but not necessarily fast writes (>200ms). I've been using Fauna, but there are other options too such as CockroachDB and Spanner, and more in the works.
2. An eventually consistent globally replicated DB for the subset of data that does also need fast writes. I eventually settled on Dynamo for this, but there are even more options here.
I think for all but the most latency-sensitive products, 1. will be all they need. IMHO the strongly consistently replicated database is a strictly superior product compared to databases that are single-region by default and only support replication through read-replicas.
In a read-replica system, we have to account for stale reads due to replication delays, and redirect writes to the primary, resulting in inconsistent latencies across regions. This is an extremely expensive complexity tax that will significantly increase the cognitive load on every engineer, lead to a ton of bugs around stale reads, and cause edge case handling code to seep into every corner of our codebase.
Strongly consistently replicated databases on the other hand, offer the exact same mental model as a database that lives in a single region with a single source of truth, while offering consistent, fast, up-to-date reads everywhere, at the cost of consistently slower writes everywhere. I actually consider the consistently slower writes also a benefit since it doesn't allow us to fool ourselves into thinking our app is fast for everybody, when it's only fast for us because we placed the primary db right next to us, and forces us to actually solve for the higher write latency using other technologies if our use case truly requires it (see 2.).
In the super long term, I don't think the future is on what's currently referred to as "the edge", as this "edge" doesn't extend nearly far enough. The true edge is client devices: reading from and writing to client devices is the only way to truly eliminate speed-of-light induced latency.
For a long time, most truly client-first apps have been relegated to single-user experiences due to how most popular client-first architectures have not had an answer for collaboration and authorization, but with this new wave of client-first architectures solving for collaboration and authorization with client-side reads and optimistic client-side writes with server-side validation (see Replicache), I've never been more optimistic about the future (an open source alternative to Replicache would do wonders to accelerate us to this future. clientdb looks promising).
But the architecture itself has been used successfully in a bunch of apps, most notable of which is probably Linear (https://linear.app/docs/offline-mode, I remember watching an early video of their founder explaining the architecture in more detail but I can't seem to find it anymore (edit: found it! https://youtu.be/WxK11RsLqp4?t=2175)).
Basically the way authorization works is you define specific mutations that are supported (no arbitrary writes to client state, so write semantics are constrained for ease of authorization and conflict handling), with a client-side and server-side implementation for each mutation. The client side gets applied optimistically and then sync'ed and ran on the server eventually, which applies authorization rules and detects and handles conflicts, which can result in client state getting rolled back if authorization rules are violated or if unresolvable conflicts are present. Replicache has a good writeup here: https://doc.replicache.dev/how-it-works#the-big-picture
We hope their serverless tier meets feature parity soon.
Really looking forward to Cockroach's serverless options too. More competition in this space is very welcome.
I'm gonna try CockroachDB next.
Haven't found myself needing much else from a DB.
Also at some window heights, the "Deployed with Reflame in x ms" box obscures the "Have questions? Let's chat!" text without generating a scrollbar.
Cacheless
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CRDTs don't solve the semantic issue of a conflict, but nothing ever will, because the semantics are defined by business requirements, right?
Isn't the idea behind CRDTs to develop a set of "primitives" upon which one can build conflict free data structures?
And isn't all the hype about CRDTs a result of the fact that providing those primitives in a serverless way (ie, without requiring a central authority) was a hitherto unsolved problem?
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.
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?
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.
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...?
But then players from Singapore can't play with players from New York.
So single player games. In the browser. Yay.
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.
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
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.
...or it could also be a pun about Edge becoming another Chrome-clone.
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.
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?
For some apps that matters, for others it doesn’t. There are other ways to achieve snappiness even with sluggish network conditions, like optimistic UI, but those come with significant complexity too. But yeah if your site doesn’t need it then don’t do it.
Throw it all out and run everything off a PC in your basement, you'll thank me later.
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.
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.
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.
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.
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?
99% of the time that you want geo-distributed databases, I'd argue that building out a directory kind of service, where you use something like Cloudflare Workers KV to map the customer's ID to find which regional API endpoint to use (US/EU/APAC), is what you actually want.
The -I flag returns only the headers.
And yes, efforts are ongoing to identify and punish the hosting providers involved, their principals, and their principals' families.
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.
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...
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!
Querying large indexes is the most common use case that needs code to run. Sqlite would standardize storage & query implementation
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).
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.
The web is evolving. Python with SQLite running in the browser is part of the web.
For example: interactive documentation that runs code in the browser with an ephemeral/temporary database, possibly imported from the user's desktop. For teaching programming languages in the browser, with the compiler compiled to WASM, so the student doesn't have to set up a local development environment. Or a database explorer that's a purely static site with no server, neither remote nor directly on user's computer - just virtually in the browser, which is a more secure sandbox. You could have a folder of HTML, CSS, JS that's a full-stack application with client UI and server (theoretically).
Further reading:
• SQL Databases in the Browser, via WASM: SQLite and DuckDB - https://blog.ouseful.info/2022/02/11/sql-databases-in-the-br...
• Pyodide - https://pyodide.org/en/stable/ - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly.
• Client-side WebAssembly WordPress with no server - https://make.wordpress.org/core/2022/09/23/client-side-webas...
• Stackblitz - Instant development environments - https://stackblitz.com
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.
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
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.
I always thought it was more common for stuff like KV stores with looser guarantees
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
(Again, the wikipedia page is laughably incomplete, but has references worth clicking on.)
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.
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.
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.
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.
I believe that React Server components is also heading in that direction.
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.