I have built an app for a customer, and am now getting interest from other companies.
Does anyone have any experience or thoughts on the best way to scale a Retool app?
I have 2 options in mind.
Create a separate app & database etc for each customer. Great for data separation / security etc, but not so good for code sync
Have 1 app for multiple customers. Much better for code management, but would need logical data separation in the DB (Firestore), and similar in the app.
Any thoughts or experience around these options (or other options) would be most welcome.
Both options require a fair amount of discussion and understanding of how to design architecture to support your ideas and definitely not something that could be conveyed in this forum in writing. More than willing to discuss but your suggestions require a more in depth understanding of what you’re trying to accomplish on either front.
Hey @ScottR - it would be great to have a chat about this - even at a high level for the time being. Whilst there is no huge rush, I am starting to make some design decisions that might be painful to unravel!
So in the end I went with the 1 database option (i felt that maintaining seperate databases and apps per customer would have painful - when I started this project, source control was not available on retool Cloud, but I think that it is now for GitHub). Initally I was using Google Firebase as my DB, and so had separate collections for each customer, (both for transactional data and app config data) which worked quite well. I have no idea how this would scale (I only have a few customers using the app at the moment). Recently however I have started to migrate my app to the native retool DB, and am using a foreign key on each table to identify the customer id for each record. Hope this helps. Very happy to have a chat / call to go through things in more detail if that would be useful. Good luck!
PS - I notice that you are based in London - I am going to be at the Retool Roadshow in Shoreditch tomorrow afternoon (Wed Oct 11th), so we could catch up if you are going to that.
Cool, sounds like things are going well for your apps.
Question, besides data from Databases, are you connecting to other apps via Oauth/API rest resources? If so, how are you dealing with having a resource for each customer within the app?
Thanks
Ah, I wasn't aware of the Retool roadshow, I would have love to be there! I'll keep an eye for the next ones
Hi Miguel - that is a great question. I am connecting to a 3rd party ordering system via a scheduled Workflow. Currently only 1 customer is using it, so its not an issue - however I know that I will need to find a solution soon as other customers will be using the same ordering system.
At the moment my (very rough) idea is to create customer specific Workflow triggers, which will grab the data from their own instance of the 3rd party ordering system - and then pass this into a shared Workflow to push the data in the app & DB. I have not thought too hard yet about the best place to store API keys etc - for now I will likely end up creating customer specific Resources for each instance of the 3rd party supplier.
This feels manageable for a few customers, but if it scaled to many 10's or 100's i am not sure what I would do! If you have any thoughts around this, I'd love to hear them
Right now Retool provides environments which are mostly related to resources, rather than to the apps components. As such, for every environment the same resource could have their own credentials, tokens, etc. Variables for resources are managed in the main retool settings, and I think it can give you a good option.
The problem is, that end customers can freely change environments, thus making this solution incompatible for a multi-tenancy customer app.
From what I ready in the forum, there has been a lot of feature requests to manage permissions at an environment level (currently only possible at an app level), which could provide a good solution.
I'm thinking a combination of environments + embed could be a way to do (which is something we're exploring right now).
Of course, source control is the way to go when having 100s of customers, and that will be a good problem for us to have if we get there
