Deployment environments
Does Convex have any plans to support environments other than “Production” and “Development”? My particular interest in this moment is in the ability to spin up a staging deployment per feature development branch, as e.g. Netlify supports (https://docs.netlify.com/site-deploys/overview/).
10 Replies
@james was just working on the plans with the team for how we're going to be supporting different deployment environments in an upcoming version of Convex. he can probably answer this the very latest
The very short term workaround (if you need one immediately) - would be to make a second project for your staging environment (with the same code).
But as Jamie and James are mentioning, we'll be looking into improved support for this kind of setup within one project.
I'm not feeling the pain of such features' absence at the moment, just interested in learning more about what will be available in the future, and roughly along what timeline. But appreciate the suggestion!
In a related vein, I'd be curious to hear thoughts (if there are any) on how seeding such ad-hoc environments would work (this could be relevant for dev environments as well).
Great question. Definitely open to input. There are a few routes that might make sense in different contexts
- Seeding data from production (or a snapshot of production)
- Seeding data from a script (particularly in dev environment)
- Starting from scratch
Have you had success or painpoints in your experience with seeding of data in non-production environments? Would love to hear more about it.
this is an area where we have a lot of ideas but want to work hard to make it as ergonomic as possible, since the distinction between dev and prod has been a point of confusion for some developers
short answer is that yes, we will absolutely have both dev, prod, shareable dev deployments, and staging deployments like you suggested
@nipunn's suggestion in the meantime is a good one, re just having an additional project for a third deployment, although it is obviously somewhat awkward
I've taken all three of these approaches for different projects/at different times, and found that each have their own pros/cons.
Seeding data from production (or a snapshot of production)
Pros
- The shape of the data is closest to the shape of production data... because it is the production data. Lots of benefits are downstream of this fact.
- It's easy to (manually, probably in the UI) test against cases that you know to be problematic or of particular concern/relevance to the development work you're doing.
Cons
- There may be privacy or security concerns with copying production data into a different environment.
- For example, you lose many of the benefits of restricting direct access to the production database to a subset of the engineers who have access to staging/dev environments, or who have permission to push to the app's codebase/deploy to production, which is something many orgs like to do (POLP).
- Some of this risk might be mitigated by scrubbing production data, but that's additional work and implementations are often brittle (it can be easy to miss sensitive data, especially for newly-added tables or columns—if your DB doesn't require a schema, like Convex, it seems particularly difficult).
- (EDITED) Another note here is that scrubbing out personal/sensitive data has to be done in a way that is invariant-preserving, and ideally preserving of the degree and kinds variation you'd expect to see in your production data.
- You need to be extra careful that you are parameterizing your other services (e.g. payment and email) by the environment you're in, as if you're not you might actually try to charge/email real users.
- Can be really slow and expensive, depending on the size of your production database (and your DB tech!).
Seeding data from a script (particularly in dev environment)
Pros
- No need to worry about sensitive or personally-identifiable information making its way into your development/staging databases.
- Usually fast.
Cons
- Maintenance costs are often high. Beyond trivially-sized applications, seeding a representative sample of the data that's in your production database is often tedious and difficult.
Starting from scratch
Pros
- Fast as it gets.
- No maintenance costs.
Cons
- You need to create all of the data that you want to manually test with. Sometimes this is trivial, more often it's not.
I'm sure none of these considerations are new to you all, but perhaps this is still helpful?
this is really helpful actually, definitely aligned with what we're thinking but you've articulated it really well
i think there's going to be demand regardless for seeding dev from production, in some form. you covered most of the key issues there. given the design of convex it would be easy for us to dynamically mirror production to dev, e.g., stream from one to the other
the privacy and config leakage issue is a big one, like you say
potentially we could populate dev with synthetic data that has the same shape as production, since we track the shape/types of the data that's in each table. the devil is in the details there re whether this ends up being useful seed data or ends up just being meaningless
potentially we could populate dev with synthetic data that has the same shape as production, since we track the shape/types of the data that's in each table. the devil is in the details there re whether this ends up being useful seed data or ends up just being meaninglessYes, I think this is very related to the edit I just added as well (see
(EDITED) in my message above).
Shapes/types in Convex would rarely capture all of the properties of the data that the application assumes exist or cares about. A simple example might be the assumption that a lastName field in a user document is capitalized. We can't express that (easily/straightforwardly, at least) with Convex types, but it might be an invariant that's enforced by the exposed API/the mutation that creates users, and then expected to hold by other app or API/query code.
i think there's going to be demand regardless for seeding dev from production, in some form. you covered most of the key issues there. given the design of convex it would be easy for us to dynamically mirror production to dev, e.g., stream from one to the otherYeah, I'll add to my previous comments that I've found this to be the overall best solution (for applications beyond a certain, non-trivial size), despite its many drawbacks and dangers.
Love this design exploration of the space of options. Thanks for having the discussion!
agreed re shapes. it's clever but probably just not sufficiently expressive in practice