USE CASE EXAMPLE:
Offering an instant messenger plugin for Wordpress using Parse as the API (or BaaS if the kids these days still use that term) syncing with the user data from the Wordpress site it was installed on. Parse API driven SaaS instant messenger for Wordpress websites basically.
Users, messages, etc should be unique and isolated to that website only. For example website A installs the plugin and users on that site only interact with other users on that website. Website B also installs the plugin and they also now have their own unique instant messenger specifically for website B.
ONE PARSE APP SOLUTION:
We could probably run just one master Parse API server & put unique identifiers for what users should see and interact with so website A users only ever see stuff from other website A users & website B users only see stuff and interact with other website B users. It could all be done through queries and a psuedo-authentication function beyond the actual Parse authentication.
However, what happens when a user is already registered through website A but now also wants to use website B and that user has the same email address on both sites? We can’t have two users in Parse with the same email/username.
I should also mention that I do some dirty under the hood stuff in the plugin code to handle the registration & login so the end user doesn’t ever actually know that Parse exists or that it has it’s own separate user handling to keep it seamless with the Wordpress user handling.
I could do some more dirty hacky stuff under the hood and append the domain to the email address at registration and login to make sure the username/email in our system remains unique across multiple potential domains… but again, super hacky.
MULTIPLE APPS SOLUTION:
This method would somehow spin up a new Parse app unique to that domain name (website) where the Wordpress plugin was installed.
This would give complete separation and honestly add more security since it would have it’s own unique app id and all of that. Potential for user conflicts cross-sites wouldn’t be an issue at all since it’s a completely different set of users and sessions.
In my mind this is the correct way to do this however we can’t sit here and manually spin up an entirely new AWS server then install and configure the Parse server for every single new plugin install.
When we log into the actual Parse dashboard it gives an interface to select an app which makes me wonder if there is a way to run multiple separate Parse apps within one Parse server install?
This seems unlikely though since we have to add the app id into the server config making me pretty sure you can only have one parse app per parse server.
ADVICE?
I’m well aware that this is a use case well outside of the scope of what Parse was built to do but it seems there should be a way to do this one way or the other without getting to dirty and hacky.
What I really don’t want to do is take the actual logical step of just requiring end users to register and login directly through our system in addition to having to register/login through the Wordpress site that would be using it. It really takes away from that Wordpress site branding and is really just a bad UI/UX. It would remind me of the old Disqus comment system, it just always looked cheap and disjointed against the website it was on.
What do you all think? What would you all do for something like this?