important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Multitenancy as a separate recipe

Status

This is just a proposal so far, it hasn't been accepted and needs further discussion.

Status:: proposed
Deciders:: rishabhpoddar, sattvikc
Proposed by:: sattvikc
Created:: 2022-12-08

Context and Problem Statement#

To support the management of dynamic config, such as thirdparty provider list for each tenant, SDK must expose a set of management functions, to create, update, etc.

These functions are specific to each recipe. As an example, for thirdparty, we would need functions like:

createOrUpdateThirdPartyProviderConfig
deleteThirdPartyProviderConfig
so on

Should these functions be exposed from individual recipes or a common Multitenancy recipe?

Considered Options#

Exposed via individual recipes
Exposed via Multitenancy recipe

Decision Outcome#

Chosen option: Exposed via Multitenancy recipe, because

Avoids duplication of the management functions. For example, thirdparty and thirdpartyemailpassword would expose same set of functions for the config management.

Pros and Cons of the Options#

Exposed via individual recipes#

Causes duplication since we have thirdpartyemailpassword and thirdparty passwordless

Exposed via Multitenancy recipe#

One place to expose functions for multi-tenant config management

Easily expand functionality to other recipes without function duplication