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