[valbaca]

The first link in the article points to this: 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]

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

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]

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.

[kilburn]

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]

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

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

[skybrian]

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]

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.