Support application environments

[Janpot]

Problem

In pro-code I split my application from its execution environment. For example, my application can be defined as a docker image, and then can be configured in runtime by providing environment variables. Can we create a similar paradigm for Toolpad applications? More specifically:

• I want to be able to deploy multiple versions of a release of my application, analog to my pro-code environments. e.g. staging, test, production, [...]

Solution

We need a way to decouple application definition from runtime environment. Essentially making applications parametrizable. In the context of Toolpad we can distinguish the following types of parameters in an environment:

• parameters: public, accessible both on the server side and the browser side. these should be available in javascript bindings under global variable params (?). e.g. binding a text to `Details for "${params.customerName}":`
• secrets: private, only accessible on the server side,. Available under global variable secrets (?). e.g. binding a HTTP header to `Basic ${btoa(`user:${secrets.password}`)}`
• credentials: a specialization of secrets which is typed and tied to a datasource. Contains all information needed to connect to a datasource. Currently these are part of the application definition. We can remove that after this RFC gets implemented.

How it should work

• Every application should have a default environment.
• All environments must conform to the same shape. The user must be made aware if an environment is not fully configured. The shape of an environment should be embedded in the application DOM.
• Per application I can create as many environments as I want. Each having to conform to the shape of the default environment.
• When I make a release, I can preview it for each environment under its own immutable url.
• In the editor I can select one of the environments to view the app in while editing
• a deploy will be described by a version+environment. Meaning: I can deploy release 2 in "prod" environment while at the same time release 5 in "staging"

Future work

• I want to be able to import/export/share/copy/distribute my application without any environment information embedded (currently the application artefact contains encrypted credentials)
• I want to be able to use templates and configure it to work with my own databases/APIs. e.g. a reusable stripe dashboard.
• I want to be able to extend an environment. If "test" extends from "staging", then it takes all of its values, and allows for overriding
• ...

Benchmark

• Google Tag Manager https://tagmanager.google.com/#/admin/accounts/4702235651/containers/12240901/environments?containerDraftId=19

• Bubble.io, didn't implement the feature yet: https://forum.bubble.io/t/development-staging-qa-production/7479/9.
• Retool, https://mui.retool.com/settings/environments, it's global to the whole organization. This sounds pretty bad.

• Tooljet: no support
• Appsmith: no support
• Webflow: no support, but they have the notion of multiple deploy targets https://university.webflow.com/lesson/publish-your-project.
• dronahq.com

• Plasmic: https://docs.plasmic.app/learn/multiple-environments/

[oliviertassinari]

I would personally add the waiting for upvotes label to wait. My assumption would be that this feature would target developers that are not yet completely willing to make the speed vs. maintainability tradeoff of low-code. They might be the audience the hardest to convert to Toolpad (the late adopters), so why I doubt we should start there.

[Janpot]

Yes, for multiple environments I agree. I do think there is some value to split application definition from configuration early on. It could be helpful in implementing arbitrary secrets, and also in solving some of the issues we talked about around having secrets readable in the editor or not