4 ms·
This is the second post I see about this edge functions, and while I appreciate the advantages (decreasing network latency should definitely have an impact), wi
by felipeccastro 8y ago
This is the second post I see about this edge functions, and while I appreciate the advantages (decreasing network latency should definitely have an impact), will this matter much if the database is still centralized? If most edge functions still need to talk to a centralized database, won’t that be essentially the same, performance wise?
- steveklabnik 8y agoYou are 100% right. I said this in the post: > My role as part of Storage will be to consider “what does data access and storage look like in this world?” If your code is moved to the edge, but your data is still in a central server, you don’t gain the full benefit of having the code close to the client. There’s a lot of interesting stuff in this space! Fixing this problem, or at least coming up with the plan to fix it, is now literally my job :) (There is of course already a plan in motion, given that Workers KV exists today...)
- felipeccastro 8y agoOh, I must have skipped that part... nice! Yeah, I'm definitely looking forward to see where that goes. Having reliable, easy distributed data storage + edge functions would certainly be a game changer.
- yashap 8y agoFWIW, I think “edge compute but centralized db” is often not just “not gaining the full benefit of edge compute”, it’s actually “way slower than everything centralized.” I’ve worked on plenty of systems where a single web facing endpoint results in 10+ db queries. With “everything centralized”, this means 1 big round trip to the data centre, then lots of tiny/fast within-datacentre round trips. But move compute away from the db, and suddenly you’re triggering tonnes of really slow db calls on every client request, and the whole system slows down tremendously.
- steveklabnik 8y agoYep, this sounds fair! For smaller things that aren't 10+ queries, I can imagine it not being that bad, but for that, yeah, that sounds much slower.
- zzzcpan 8y agoThis is why edge computing is going to be different. You have to be able to fetch and rely on data from the closest nodes, prefetch all the likely queries all at once, merge updates locally to keep relying on them while resyncing in background, etc. All while also not having data loss or weird hard to reason about inconsistencies. Basically all the reasons CRDTs were invented.
- kentonv 8y agoThat's why we need edge storage -- which is exactly what Steve is going to be working on. :) Yes, until we have actual edge storage, the use cases are more limited, but "edge functions" can be used for: * Stateless / static use cases. * Optimizing use of edge cache. * Intelligently redirecting traffic to geographically-diverse back-ends -- including other cloud services that are already globally distributed. For example on the last point: If you want to use Google Spanner as your database but you need to put business logic on top of it, then where does that business logic go? If it goes in a VM, either you have to make sure to replicate that VM all over the world (can be cumbersome and/or expensive) or you've lost Spanner's advantage of being globally distributed. You could put your logic at the edge, and then it will usually sit between the user and the nearest Spanner node to that user, which is ideal.
- zzzcpan 8y agoYes, edge functions need proper distributed strongly eventually consistent infrastructure to make them actually useful, including databases and object storages. But it's too cutting edge for Cloudflare, not sure if they can even get there.