4 ms·
From the Vercel point of view, this promises to answer one of the most frequent, interesting, and technically challenging questions since we first launched our
by Rauchg 5y ago
From the Vercel point of view, this promises to answer one of the most frequent, interesting, and technically challenging questions since we first launched our "immutable deploys".
That is: how can I pair a brand new frontend preview deploy, with a serverless database with the specific schema my new feature needs?
This technology makes the whole serverless stack feel complete.
- adamfeldman 5y agoBranching wasn't mentioned in the linked blog post, but I assume that is what the parent comment is excited about: https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching
- Rauchg 5y agoIndeed, thank you!
- eurasiantiger 5y agoIt doesn’t solve the N+1 queries problem in a generic way. That is a major hurdle in scaling complexity-wise, which in turn is often deeply coupled with business realities. More to the point, it probably cannot solve it efficiently at all, since it is not a graph database and thus cannot be paired with a generic GraphQL resolver (would generate join queries instead of lookups across edges) and a stack of generated static queries in the backend (no need to allow generic queries, just make it possible to write queries once and only once).
- ransom1538 5y ago"It doesn’t solve the N+1 queries problem in a generic way." IMHO, this isn't trying to solve people looping queries. The fastest way to solve this is to not loop queries. This solves auto-sharding (well vitness did). See slack architects comment below.
- eurasiantiger 5y agoYou are misunderstanding the nature of the problem and how it arises in any system that uses multiple entities to represent real-world entities.
- manigandham 5y agoHow's that related? This is a commercial managed version of Vitesse - which is an open-source system for horizontally scaling MySQL: https://vitess.io/ https://vitess.io/