3 ms·
>This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin
by treis 7y ago
>This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin
I don't get how this would work. For someone logging in you still have to talk to a central database holding the authentication information. Really anything with a database has a similar problem if you want to enforce consistency.
To use the subdomain example, say you want to prevent two people from reserving the same name. That means the reservation from someone in Sydney has to propogate to the worker in NYC before you can confirm that it has succeeded. Otherwise, simultaneous reservations will result in two successful reservation. So you've lost the benefit of edge workers.
- rita3ko 7y agoSure, the initial login itself has to be done at the origin, or connect to a database, but token authentication can be done at the edge. That means that if, for example, users have to pay for articles, you can still cache the article because the authentication can be validated at the edge. There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here. In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.