RFC Multi tenant #515
krzysztofwolski
started this conversation in
RFC / Ideas
Replies: 2 comments
-
@mmiszy @witoszekdev Summary from yesterday's meeting. Let me know if there are any missing parts or need to elaborate on something :) |
Beta Was this translation helpful? Give feedback.
0 replies
-
Implemented: #530 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Related issue: #339
POC PR: #514
Multi-tenancy allows one application deployment to register multiple Saleor instances.
To visualize this see graphs: saleor/saleor-app-template#72 (comment)
What's preventing us right now from handling MT?
I've created POC which addresses those issues: #514
Notable changes:
Checkout Frontend
Will communicate with the Saleor API based on
?domain=example.com
query param (code change)An additional change is required in the order confirmation view.
Registration
Handler use APL interface to save the data (code)
The interface is chosen based on file
The way data are stored can be dynamically changed as in App Template so we will be able to create APL with the old logic to maintain compatibility and use MT as needed.
Gateway configuration data
Since gateway configuration is kept at metadata, there are no changes needed for the configuration interface.
Using those data on the other hand will require a big refactor. Since we have to determine the configuration on a request basis, we'll need to rethink using the config. POC used a brute-force solution to pass the domain as an argument (code), but that solution is sub-optimal - a lot of duplicated code and multiple requests for metadata.
Gateway webhooks
The way app will be to determine which Saleor domain to use is a domain param in the URL (code).
Security - how will we determine if a webhook is sent from the account configured in the app? In Stripe, webhooks have a dedicated "webhook secret" set automatically by stripe and have to be set up in the App Configuration interface. If other providers do not have such functionality, we could add an additional query argument for a secret in the URL.
The App configuration view
The domain of the used dashboard is added in the user JWT tokens thanks to app bridge. No bigger changes are needed here.
Storefront
Did not change anything there since, in the MVP version, we do not intend to have a multi-tenant storefront part.
For sure, CHECKOUT_URL will need to be updated to contain a new
domain
param.Next steps
Beta Was this translation helpful? Give feedback.
All reactions