[Solution Added]How do you design your API Sandbox environment?
We are providing an API service which needs sandbox environment for B2B consumers to test.
Along with production environment, we have dev and stage.
We are currently planning this way.
- Each environment (dev, stage, production) will have its own sandbox server each
- However, for dev and stage, the sandbox server can be self. i.e, for dev, sandbox server is same as the dev server
- Only for production environment, we want to maintain a separate sandbox server.
Can anyone share a workflow on how usually api sandbox is done?
I have the following questions
- What ever user created in production needs to be created in sandbox server too?
- Should we maintain two different servers for each environment (one for actual environment and one for sandbox)?
- How to maintain the server code so that its easy to handle sandbox sync in all environments?
Update
This is how we are implementing sandbox mode.
Production server maintains a draft copy with in its entity object (document). As soon as it's written to db, we fire a pub/sub notificaiton.
Sandbox server listens to the pub/sub notification (cross project listening - as production project is diff from sandbox project) and writes to its own database.
This way we are totally avoiding custom code in the main backend code. Just we need to have a custom subscription(pubsub) code for sandbox to consider drafts as the main data so the dev can test it. So, ideally we are changing the database as per the sandbox environment and everything is fine!
Thanks a lot for the inputs :)
At Authress we recommend our users use one account for everything. Users aren't frequently different between different environments they have. It's the same user. In general we expect a common denominator of use production everywhere.
There are rare circumstances where this can't be done, however. If your service either:
Then they would need separate versions. For us that just means they create two accounts, end of story. We don't copy data between them, sync them, etc... Why would we these are completely separate accounts, and if they have a strange requirement to do so, then they can themselves. We give them all the tools they need, but since that isn't the core value we offer, we aren't an enabler of that.
I would suggest allowing your customers to setup "projects" or "environments" that are separate from each other, essentially separate accounts from each other.
The typical use case for this is that your customers might want isolated accounts for their own dev/staging/production environments.
Then if they need to a create a "isolated sandbox for screwing around in" environment, they can do that too.
Yea! Please check my updated post with the solution we are following. Thanks for confirming about isolated projects.
Hi
Most of the resources should be separates, ideally you should be able to recreate your DEV env with an script, nowadays it is very easy with docker compose for example.
I would recommend that you have the production env completely separated and the dev env running on your local machine, you can use tunnels, a proxy and lets encrypt to bring anything that you need to your local pc
Make sure that the only difference between your PROD env and DEV env are env variables in a git ignored file.
This is what I do and hence what I recommend, good luck!
Yea! Please check my updated post with the solution we are following. Thanks for confirming about isolated projects.
I honestly think that's a overhead to have 4 different environments for a small company. (I'm assuming that you are small)
If I was you, I'd let companies test on my stage environment at the moment. You will need to be a little bit more careful with stage, but I'm sure they will understand if the env is not up all the time.
Don't waste too much money, time and effort with customers that you haven't even converted yet.
That's my 2 cents, hope it helps a bit.
Agreed. It's something we can't deny. At the same time, going public without letting users to test is difficult to handle on our end.
However, multiple env's are just for our convenience and didn't take any effort from our end (w.r.t our project).
What is your API and what does it do?
It offers profile and save service for apps where developers can store their app users profiles, save data through our api service.