Skip to main content
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
    • Looking for older versions of the documentation?
    Which UI do you use?
    Custom UI
    Pre built UI