This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.
Implicit initialization of Multitenant recipe
This is just a proposal so far, it hasn't been accepted and needs further discussion.
- rishabhpoddar, sattvikc
- Proposed by:
#Context and Problem Statement
All the dynamic config management functions are exposed from the Multitenancy recipe.
Should the Multitenancy recipe be implicitly initialized by the SDK, or explicitly initialized by the user, for the user or the SDK to be able to use those functions?
- Multitenancy recipe is initialized explicitly by the user
- Multitenancy recipe is initialized implicitly by the SDK
Chosen option: Multitenancy recipe is initialized implicitly by the SDK, because
#On the backend:
- Allows the usage of the config management functions in the Multitenancy recipe without having to initialize it. So implementation of other recipes would be simpler - they can assume this recipe is available as opposed to first checking if the recipe is initialised and then using it.
The user can still explicitly initialize the recipe in case the recipe functions needs overriding.
#On the frontend:
- Since the Multitenacy is implicitly initialized, and the dynamic config is handled by this recipe, for the Single tenant / Dynamic config use case, the user configuration is simplified to just enabling
The user will need to explicitly initialize the recipe in case of a multi-tenant setup, to be able to provide the tenantId