First thoughts.
In part 1 i went through the goals of this series and why i wanted to create something like this.
In this part i discuss where i am right now and thoughts on how to achieve it.
Just a quick recap:
The idea is to make an “app” any app be it a newsletter system, billing platform or something else.
This “app” should offered as a SASS AND as a self hosted, distributed package which can be installed on any hosting environment (that supports the requirements of the app).
The “app” should be written once, delivered many times without distingquishable differences that need to be maintained seperately.
Idea 1
So the first idea goes as follows:
The app will be written to work self hosted, but with the functionality included to make it run for multiple tenants (wether this functionality is available to self hosted versions is matter i haven’t yet decided on).
The app would have some sort of “sassable” package functionality which will be a bridge to the sass offering.
This seems the most logical approach as refactoring for SASS i assume should be easier than refactoring for self hosted. But this has yet to be proven.
This key here is that the functionality for tenants of the app shouldn’t stop the app working if there are no tenants, it should just work for the domain pointed to it.
So far my Tenantable Laravel package does just this which is a good start.
Then on the SASS side of things a “different app” (bear with me, i know i said this is exactly what the goal is intending to prevent) would be created to simply provide the register/subscription part of the SASS.
The SASS app would have no knowledge of what the actual app offering was, just the ability for users to signup, make payment, and get directed to app.
The SASS app would have some sort of simple bridge to the actual app allowing for registering/modifying of a new app instance and logging into that app.
The way this works would mean:
- The “app” could be used self hosted.
- The SASS provider could also just install the self hosted version for example on a server which directs all domains to the app (and set some ENV vars to tell the app its “sassable”.
- The SASS providers main site would send api calls to the SASS providers self hosted version to register/modify/delete “tenants”.
I think the best way to visualise this is with domains:
Self hosted
The user would download the “app” install it in a folder and set the webserver to send requests from “selfhosted.com” to the app, run the installer and use it. Pretty simple. No tenants, or possibly 1 tenant with no ability to add others.
SASS
The SASS website: sassprovider.com would be a standalone website with an api package which communicates with the “app” via http to a different domain, maybe sassprovidertenants.com or simply tenants.sassprovider.com. All configurable of course.
The “app” would be installed on a webserver (possibly the same one in a different folder) that listens to any domain, plus tenants.sassprovider.com.
The SASS provider would install/update the app just like self hosted users would, ie file changes, migrations, etc.
The SASS website however would over the api send requests to the app to create/modify and delete tenants, assigning (probably based on subscriptions or free trials). When it registers a user it would create the tenant on the actual app with the domain of xyz.sassprovider.com.
From a users point of view when they register on sassprovider.com they can login there, manage billing and “goto their” app which would be on xyz.sassprovider.com.
xyz.sassprovider.com would via the server by resolved to the actual app instance where the tenant package handles loading the right data.
Via this method the “app” code wouldn’t be different for the sass provider or a self hosted user so development wouldn’t be seperated.
The only difference is the sass providers main website would communicate with its app instance over an api to create other tenants.
The sass providers website would need some sort of login share/sync between the sassprovider.com site and the app instance to make it a seamless process.
One thing not worked out yet is teams/other users.
Its pretty easy on a 1 user basis, but say for example user@email.com worked for two companies which both had a subscription for the sass version.
They would need to be able to login on both instances as themselves and user accounts on both instances would need to be updated if they changed there details, etc.
