5 ms·

The first link in the article points to this: https://www.netlify.com/products/#netlify-edge-functions https://www.netlify.com/products/#netlify-edge-functions

The first link in the article points to this: https://www.netlify.com/products/#netlify-edge-functions https://www.netlify.com/products/#netlify-edge-functions How to use them Drop JavaScript or TypeScript functions inside an edge-functions directory in your project. Use cases Custom authentication, personalize ads, localize content, intercept and transform requests, perform split tests, and more.

nawgz 5y ago
> Use cases > A bunch of server functionality Why is that the use case? I don't see how an edge function can be faster than a centralized server endpoint if it has to reach out to literally any other component of the system involved in auth / persistence
- FinalBriefing 5y ago
  It's just serverless architecture. It may not fit for every project. We use the concept to add meta tags to our client-side-rendered webapp for search indexing. We can decouple our client app from our server and deploy each separately. We use "serverless functions" to add some meta tags that need to be added server-side.
  - nawgz 5y ago
    I mean, it's incredibly easy to deploy client apps separately from the server in a lot of ways To me, the only value I see for Edge compute is when some chunk of data requires processing going one way across the network, and that processing can be done entirely locally. I suppose what you describe with the meta tag qualifies in this case, otherwise I think serverless architecture looks like a pretty sweet deal for the cloud companies promoting it.
- skybrian 5y ago
  Even if it doesn't reduce latency, it could reduce bandwidth and load on other servers. (Or increase it, if it's used badly.)
  - nawgz 5y ago
    I can't imagine a successful argument that you use less compute cycles spinning up Edge functions to interact with your app than just hitting an already-running API endpoint on an already-running server. And rearranging your load just because you can isn't worth consideration.
- kilburn 4y ago
  You are replying to a message that very explicitly didn't say "A bunch of server functionality". Specifically, it said: > Custom authentication You can most definitely authenticate requests based on signed tokens and the like, meaning you don't necessarily need to reach any other component in the system. > personalize ads Same here. You can most definitely pick different adds depending on some cookie value or such, no need to reach anywhere. Even if you want to track what ads you've served, that can be done _after_ the response is sent to the user, meaning the extra latency of going to your persistence layer isn't perceived by the user. > localize content Again, you can have your translations in your edge function (or some edge cache if that platform supports it) and apply them at the edge. Admittedly this sounds like the shakiest use-case. > intercept and transform requests You can implement redirections, security headers, etc. in this layer. No need to go to your persistence layer. > perform split tests Same idea here. You can have multiple versions of (cached) pages and serve one or the other depending on the user's cookies, ip (country?), some frequency, etc. You may be doing all these things from your backend layer, which is arguably easier, but it doesn't mean that they can't be offloaded to the edge and have a positive impact.
  - nawgz 4y ago
    > You are replying to a message that very explicitly didn't say "A bunch of server functionality". Right, let's see... > You can most definitely authenticate requests based on signed tokens and the like Sure, you can, you just have to give up the ability ever invalidate tokens > personalize ads How can this not just be done on the client? > localize content How can this not just be done on the client? > intercept and transform requests How can I implement redirections and security headers here? What context does the Edge function have to do something meaningful here that couldn't have been done on the client? > perform split tests I would prefer to serve my static content from static content hosts with caching capabilities, not Edge functions I am saying this: Edge functions and serverless are loss-leaders for cloud vendors to get you to integrate deeply into their systems. Using them for their tiny, imperceptible gains in the face of the massive engineering efforts (complexity) and risk of vendor lock-in is ridiculous. These use-cases do not justify binding yourself to a cloud vendor.
- valbaca 4y ago
  > if it has to reach out to literally any other component of the system Maybe it doesn't have to "reach out to literally any other component" Sometimes code can be self-contained. That's why they're called "Edge Functions" and not "Edge Services" The advantage is edge functions are physically closer to the customer (lower latency) and can be updated at-will and all at once (unlike client-code, you cannot force a user to update their app).

nawgz 5y ago

> Use cases > A bunch of server functionality Why is that the use case? I don't see how an edge function can be faster than a centralized server endpoint if it has to reach out to literally any other component of the system involved in auth / persistence

FinalBriefing 5y ago
It's just serverless architecture. It may not fit for every project. We use the concept to add meta tags to our client-side-rendered webapp for search indexing. We can decouple our client app from our server and deploy each separately. We use "serverless functions" to add some meta tags that need to be added server-side.
- nawgz 5y ago
  I mean, it's incredibly easy to deploy client apps separately from the server in a lot of ways To me, the only value I see for Edge compute is when some chunk of data requires processing going one way across the network, and that processing can be done entirely locally. I suppose what you describe with the meta tag qualifies in this case, otherwise I think serverless architecture looks like a pretty sweet deal for the cloud companies promoting it.
skybrian 5y ago
Even if it doesn't reduce latency, it could reduce bandwidth and load on other servers. (Or increase it, if it's used badly.)
- nawgz 5y ago
  I can't imagine a successful argument that you use less compute cycles spinning up Edge functions to interact with your app than just hitting an already-running API endpoint on an already-running server. And rearranging your load just because you can isn't worth consideration.
kilburn 4y ago
You are replying to a message that very explicitly didn't say "A bunch of server functionality". Specifically, it said: > Custom authentication You can most definitely authenticate requests based on signed tokens and the like, meaning you don't necessarily need to reach any other component in the system. > personalize ads Same here. You can most definitely pick different adds depending on some cookie value or such, no need to reach anywhere. Even if you want to track what ads you've served, that can be done _after_ the response is sent to the user, meaning the extra latency of going to your persistence layer isn't perceived by the user. > localize content Again, you can have your translations in your edge function (or some edge cache if that platform supports it) and apply them at the edge. Admittedly this sounds like the shakiest use-case. > intercept and transform requests You can implement redirections, security headers, etc. in this layer. No need to go to your persistence layer. > perform split tests Same idea here. You can have multiple versions of (cached) pages and serve one or the other depending on the user's cookies, ip (country?), some frequency, etc. You may be doing all these things from your backend layer, which is arguably easier, but it doesn't mean that they can't be offloaded to the edge and have a positive impact.
- nawgz 4y ago
  > You are replying to a message that very explicitly didn't say "A bunch of server functionality". Right, let's see... > You can most definitely authenticate requests based on signed tokens and the like Sure, you can, you just have to give up the ability ever invalidate tokens > personalize ads How can this not just be done on the client? > localize content How can this not just be done on the client? > intercept and transform requests How can I implement redirections and security headers here? What context does the Edge function have to do something meaningful here that couldn't have been done on the client? > perform split tests I would prefer to serve my static content from static content hosts with caching capabilities, not Edge functions I am saying this: Edge functions and serverless are loss-leaders for cloud vendors to get you to integrate deeply into their systems. Using them for their tiny, imperceptible gains in the face of the massive engineering efforts (complexity) and risk of vendor lock-in is ridiculous. These use-cases do not justify binding yourself to a cloud vendor.
valbaca 4y ago
> if it has to reach out to literally any other component of the system Maybe it doesn't have to "reach out to literally any other component" Sometimes code can be self-contained. That's why they're called "Edge Functions" and not "Edge Services" The advantage is edge functions are physically closer to the customer (lower latency) and can be updated at-will and all at once (unlike client-code, you cannot force a user to update their app).