We’re putting together an app that holds potentially sensitive data (logins, access…) and we’d like to separate one customer from another. We could have single, big tables and tenant inside, or we could deploy multiple tables and separate clients this way. I also have a front-end application and an auth0 account to consider.
Are there any best practices? With serverless, I could deploy a set of api’s / website / tables per client. It’d be easy too, if I keep the client name variable in the .yml, I can deploy another version of the same app with very little effort. The only effort would be in updating all apps when we make changes.
It sounds like you might want to shift around your data model to accommodate for multiple users. (IE not having a separate databases for each user/tenant) Then you can lock down permissions on what data the given client could access in your lambda function by checking their JWT or other meta/headers sent with requests.
A new deployment for each new tenant will give you the problems you describe in the long run. (Out of date or hard to update individual “stacks”).
Alternatively, you can have individual stacks and use variables, you will want to script your deployments so Its not a huge pain in the ass to update 100+ stacks manually when software updates roll out. (I recommend the data modal approach. not this)
Hi David, thanks for your reply. I understand the complexity behind automating the deployment and synchronization of multiple stacks. I also understand the added complexity of changing my front / back end, although I have an approach in mind that I think will suit my needs.
It lead me to two follow up questions. If I want to separate my auth0 databases per client, I can see my environment variable section grow rather quickly. Is there a good approach for that?
Second, is there any implication in cost, one large table vs several small ones?