More than one app per parse server or a way to compartmentalize across multiple unique groups of users?

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.

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.

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.

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?

Hi, I think 2 solution for this.

Solution 1: If the user does not know that there is a Parse-server under WordPress and it does not matter to them, they can create a unique username and email record for users by adding a separate username and email timestamp to the WordPress registration. The user does not need to know this. When the users are synced to the Parse-server server via the plugin, the unique email and username records created in WordPress can be used and the real email and username information can be kept in a field such as username_1 and email_1 that is not unique on the Parse server. This solution is valid in scenarios where WordPress applications are yours.

Solution 2: Create a new Parse-server with each WordPress plugin add-on, deploy the image of this new Parse-server application in a k8 cluster with a shared gateway, and add a common key to be used by the gateway for redirection between servers to the API requests, so that the gateway can be directed to the relevant image. However, there is no need for K8 here either. If you write your own orchestration system, your application can also manage this.

Thanks for the reply!

We were already considering solution 1 pretty much exactly as you laid it out, simple one parse server solution.

Solution 2 seems like it might have some big advantages though with complete separation for better security and efficiency. Only problem with this solution is Kubernetes and more complex AWS stuff starts to get a little out of our wheelhouse but I’m sure we could muddle through it with enough head banging.

1 Like