-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-app tenancy? #15
Comments
Right now it is intended to run a single app, and in a single database, yes. The capability to run more than one exists (see cache.js and testing-routes.js) but that doesn't allow for different cloud code per app. I'm open to making it multi-app capable. |
This should be done, though notifications and webui are first priority. |
I've been thinking about adding provisioning tools that can be used to spin up new instances of parse-server for a new app. Something like using nginx for loadbalancing to different NodeJS instances. Would make it easier to scale out and wouldn't introduce additional code on the main code base. Furthermore it'll be easier to move specific apps over to dedicated hardware if they require it. |
IMO I would advise people to have separate servers for separate apps. I think it is much cleaner. I think people will disagree on this aesthetically though - it probably depends on your use case. |
+1 multi app support would be great |
Can't understand why this ticket is closed, as nothing has been decided so far. |
Due to some restriction in the Parse node.js SDK we're unable to properly manage multiple apps within the same node process. Cloud Code can't support multiple apps as the JS SDK is a singleton and node js is event based. Race conditions occur during asynchronous calls, and the state of the Parse global may change. You can run multiple parse servers in different node processes with different ports. Depending your configuration, you can achieve routing the traffic with nginx from a single endpoint or from a front express server. |
Very clear explanation @flovilmart, now I get it, thanks a lot. |
@flovilmart Sorry to bring up an old thread. How would you achieve the ability to have the same users across multiple apps with parse? |
That's not possible across multiple appIds |
@flovilmart Will there by any problem if one of the ParseServer instances does not have any cloud code, and they both share the same appId and Master Key? The configuration I need is for the dashboard to use readPreference. All I need is to change the mongoDb connection string, so that heavy Dashboard queries will go to my secondary rather than stall the primary. currently I've set this up and it seems to be working. But if it's not recommended or if the databaseUrl can leak between the two servers that is a problem because I assume strict consistency in my cloud code logic.. |
I won't comment as I don't recommend running that setup at all |
Well, after looking in the database logs it looks like most if not all of my queries went to the secondary since I deployed this "multi-server" setup so I got my answer - the connection string leaks as well. |
Update index.js
I managed to create a multi-tenant server and using the cloud code that pulls and initialize multiple (different) config json files with unique ports and app credentials and noding the
} ); ` |
@tinocosta84, I strongly suggest that you cease running that code in production. I probably works because you don’t have many concurrent requests nor async code in CloudCode that takes long enough so the Parse SDK get re-initialized by a request coming in to another app. |
@flovilmart Running pretty well for now with no isolation as I deployed pm2 ecosystems, I had as much doubt but even all the modules for all the apps are fired up. Its perhaps best to suggest a fewer number of apps as I am testing it on a 2GB RAM |
It’s not about the RAM! It’s about concurrent requests, Cloud Code and calls against multiple apps. Again, this is explicitly discouraged and yes the side effects are not obvious, instead of going butt-head and claiming this is a valid method, I can guarantee that it isn’t. |
Do you know how Parse.com managed multiple apps? did they use AWS Lambda or something else? I'm talking from generally from a technical perspective not referring to enable this in Parse Server |
@benishak Parse.com backend initially started with Ruby on Rails, and later on they changed it to a Go backend. You can read about it here. |
Thanks a lot that sounds good but Cloud Code was always JavaScript. But how did they manage all these cloud code, I don't think they were loading all the cloud codes in memory at the startup, that's not going to scale whether they used Go or NodeJS, right? |
i think they launched a dedicated node process for each incoming request. i
read this somewhere, and it's supported by the fact that user information
is useMasterKey were global/static variables in node - the entire process
isolated for each request. that is very aggressive segregation at the
request level...
…__________________________
Ron Bresler | Milestone Sports
Director of Product Management
+972 54.815.1274
On Mon, Jul 3, 2017 at 12:28 PM, Ben Ishak ***@***.***> wrote:
Thanks a lot that sounds good but Cloud Code was always JavaScript. But
how did they manage all these cloud code, I don't think they were loading
all the cloud codes in memory at the startup, that's not going to scale
whether they used Go or NodeJS, right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APEWUK74j7UY2XBgPJ7XjULt5BZOaQW7ks5sKLRPgaJpZM4HO9hN>
.
|
Yes, an isolated custom node runtime was launched for every hook, which was slow AF. This works well if you run everything on beefy machines, as the process startup time and memory consumption isn’t a big dead, but in the scenario of parse-server, this doesn’t make sense. Initially when I was working on it, I made Cloud Code run in a separate process (started at the beginning), and communicate through HTTP to it (so I didn’t have to rewrite an IPC protocol). This made multitenancy possible but ultimately rejected as a PR. If you wanna read the discussion, #263 |
@zealmurapa I'm not sure what you mean or where you wanna go with it. Multi-tenancy is likely to never land, and is not a priority. |
I developed multiple apps parse server in the safe way(not that efficiency but should not having the concurrent issue in cloud code), and make it easy to setup, take a look on this repo |
@richjing did you manage to run multiple apps on 1 Parse server without issues with Cloud Code? |
@kerbymart I use PM2 to start multiple parse server apps. Therefore, there is no cloud code concurrent issue. Each app run separately.
|
This is really great and it works for me. |
Super sad Parse is closing down. Got a question do we need to have separate parse servers / mongoDB's for each app? How do we migrate multiple Parse hosted apps? Thanks!
The text was updated successfully, but these errors were encountered: