Thanks but I find it a bit odd - if we're talking about the future of JavaScript - that this article doesn't mention Dart or Flutter (which compile to JavaScript)? Any opinion on those platforms?
I've spent a bit of time using Dart for web and... would probably recommend TypeScript. Dart only makes sense if you're using Flutter, which could possibly be a good fit depending on your team. It likely depends how much code/knowledge sharing you're trying to have across web and mobile teams. If the web team is on React, there's likely a stronger incentive to look into React Native for mobile.
I've always thought of Edge and Serverless at similar levels of abstractions, Edge being one way to do serverless. You just write your code and the platform does the rest.
Could you comment on why Edge is further abstracted compared to serverless?
The constraints of edge compute can actually be very freeing. I've seen quite a few serverless setups that try to repeat serverful patterns. For example, reusing direct database connections across multiple lambda invocations (https://github.com/jeremydaly/serverless-mysql). With the more constrained, lighter Node.js runtime for edge compute, you have one choice: HTTP. As a developer writing an edge function, you're writing exclusively business logic, fetching data over HTTP with standard Web APIs. You aren't reinventing the database connection wheel.
Now, the tradeoff is this: complexity doesn't disappear but shifts. Modern database platforms abstract away things connection pooling for you, or have incredibly high concurrent connections, such that this isn't a problem when you're using more lightweight compute options.
The point of edge is to get compute close to the user. This can be for a variety of reasons, including performance, avoiding unnecessary data movement, or data sovereignty. If you can centralize, you should, as that is where innovation will be fastest. But if an edge requirement exists for your application, it’s good to know the ecosystem is maturing.
Cloudflare Workers invented edge compute as the described by the article. By itself another great story for Javascript. Cloudflare Workers implement your browser's Service Worker API and run in Chrome V8 isolates running on the CDN for lowest possible request latency.
Functionality-wise, edge extends serverless. Edge can do all the same things serverless can (e.g. deploy code without caring about how deployment works), but it can also act as middleware, while serverless (e.g. Lambda functions) can only act as a request handler.
Edge middleware operates on incoming traffic to your website. If an edge function sees traffic (e.g. a request) it wants to operate on, it can:
- modify the request and send it to your server (middleware)
- send the request to your server and modify the response on its way back to the browser (middleware)
- handle a request and respond directly similar to a Lambda function (endpoint)
That's a good example. Others are authentication, authorization, cookie management, logging, proxying, modifying html, headers, and responses to name a few.
Can I translate it into Chinese? I will give the source.
You can cold boots node.js, but how to deal with the database 😂
Thanks but I find it a bit odd - if we're talking about the future of JavaScript - that this article doesn't mention Dart or Flutter (which compile to JavaScript)? Any opinion on those platforms?
I've spent a bit of time using Dart for web and... would probably recommend TypeScript. Dart only makes sense if you're using Flutter, which could possibly be a good fit depending on your team. It likely depends how much code/knowledge sharing you're trying to have across web and mobile teams. If the web team is on React, there's likely a stronger incentive to look into React Native for mobile.
I've always thought of Edge and Serverless at similar levels of abstractions, Edge being one way to do serverless. You just write your code and the platform does the rest.
Could you comment on why Edge is further abstracted compared to serverless?
The constraints of edge compute can actually be very freeing. I've seen quite a few serverless setups that try to repeat serverful patterns. For example, reusing direct database connections across multiple lambda invocations (https://github.com/jeremydaly/serverless-mysql). With the more constrained, lighter Node.js runtime for edge compute, you have one choice: HTTP. As a developer writing an edge function, you're writing exclusively business logic, fetching data over HTTP with standard Web APIs. You aren't reinventing the database connection wheel.
Now, the tradeoff is this: complexity doesn't disappear but shifts. Modern database platforms abstract away things connection pooling for you, or have incredibly high concurrent connections, such that this isn't a problem when you're using more lightweight compute options.
The edge concept is new to me, what are your best resources for it?
Nice post from a DevRel at Akamai: https://austingil.com/edge-compute-knitted-dog-hats/
Thank you
The point of edge is to get compute close to the user. This can be for a variety of reasons, including performance, avoiding unnecessary data movement, or data sovereignty. If you can centralize, you should, as that is where innovation will be fastest. But if an edge requirement exists for your application, it’s good to know the ecosystem is maturing.
Cloudflare Workers invented edge compute as the described by the article. By itself another great story for Javascript. Cloudflare Workers implement your browser's Service Worker API and run in Chrome V8 isolates running on the CDN for lowest possible request latency.
Functionality-wise, edge extends serverless. Edge can do all the same things serverless can (e.g. deploy code without caring about how deployment works), but it can also act as middleware, while serverless (e.g. Lambda functions) can only act as a request handler.
Edge middleware operates on incoming traffic to your website. If an edge function sees traffic (e.g. a request) it wants to operate on, it can:
- modify the request and send it to your server (middleware)
- send the request to your server and modify the response on its way back to the browser (middleware)
- handle a request and respond directly similar to a Lambda function (endpoint)
And its open source: https://github.com/cloudflare/workerd
thanks for the detailed response
can you give me an example of why I would like to modify request between server and client?
one possible answer i can think of is converting image urls to regional cdn url
That's a good example. Others are authentication, authorization, cookie management, logging, proxying, modifying html, headers, and responses to name a few.
What about GANs and development of large language models , do you think we still need abstractions at this stage ?
I like Jared's take:
> React, Vue, Svelte, etc. are likely to be the last JavaScript frameworks intended to be used directly by humans - https://twitter.com/jaredpalmer/status/1604163087401091072
I guess we'll find out!