You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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.
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.
Hello @gfosco , @lacker ,
In the original parse website, we have options to add, and modify multiple app entries. So, is the open source a mini version of that? If that is the case, migrating a large number apps would require to have a large amount of servers.
Can't understand why this ticket is closed, as nothing has been decided so far.
IMHO this really is a must-have, I'm sure many of former Parse users were managing more than one app on their account. @lacker, could you explain why you're thinking that one server per app would be the cleanest approach?
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.
@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.
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
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
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
@kerbymart I use PM2 to start multiple parse server apps. Therefore, there is no cloud code concurrent issue. Each app run separately.
I create the repo named multiple-apps-parse-server, you can take a look on it.
Here show some features:
run and manage multiple parse apps (instances) in a server and using a single port.
one code, one database, create a parse app in one second.
parse dashboard integrated, each app's manager can log into parse dashboard to manage their app.
one admin account in parse dashboard to manage all apps
Reacted by Amine Bezzarga, Wagner CS Filho and Chung Minh Tú
@kerbymart I use PM2 to start multiple parse server apps. Therefore, there is no cloud code concurrent issue. Each app run separately. I create the repo named multiple-apps-parse-server, you can take a look on it. Here show some features:
run and manage multiple parse apps (instances) in a server and using a single port.
one code, one database, create a parse app in one second.
parse dashboard integrated, each app's manager can log into parse dashboard to manage their app.
one admin account in parse dashboard to manage all apps
Activity
gfosco commentedon Jan 29, 2016
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.
[-]More Questions[/-][+]Multi-app tenancy?[/+]kingmatusevich commentedon Jan 29, 2016
This should be done, though notifications and webui are first priority.
duergner commentedon Jan 29, 2016
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.
lacker commentedon Jan 30, 2016
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.
prkeshri commentedon Mar 22, 2016
Hello @gfosco , @lacker ,
In the original parse website, we have options to add, and modify multiple app entries. So, is the open source a mini version of that? If that is the case, migrating a large number apps would require to have a large amount of servers.
DanielsCode commentedon Mar 24, 2016
+1 multi app support would be great
takusen commentedon May 13, 2016
Can't understand why this ticket is closed, as nothing has been decided so far.
IMHO this really is a must-have, I'm sure many of former Parse users were managing more than one app on their account. @lacker, could you explain why you're thinking that one server per app would be the cleanest approach?
flovilmart commentedon May 13, 2016
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.
takusen commentedon May 13, 2016
Very clear explanation @flovilmart, now I get it, thanks a lot.
ericraio commentedon Nov 26, 2016
@flovilmart Sorry to bring up an old thread.
How would you achieve the ability to have the same users across multiple apps with parse?
4 remaining items
Merge pull request parse-community#15 from didierfranc/patch-1
flovilmart commentedon Jun 27, 2017
@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 commentedon Jun 27, 2017
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.
benishak commentedon Jul 3, 2017
@flovilmart
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
natanrolnik commentedon Jul 3, 2017
@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.
benishak commentedon Jul 3, 2017
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?
ronnno commentedon Jul 3, 2017
flovilmart commentedon Jul 3, 2017
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
flovilmart commentedon Jul 3, 2017
@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.
richjing commentedon Oct 2, 2017
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
kerbymart commentedon Oct 14, 2017
@richjing did you manage to run multiple apps on 1 Parse server without issues with Cloud Code?
richjing commentedon Oct 14, 2017
@kerbymart I use PM2 to start multiple parse server apps. Therefore, there is no cloud code concurrent issue. Each app run separately.
I create the repo named multiple-apps-parse-server, you can take a look on it.
Here show some features:
chungminhtu commentedon Feb 25, 2022
This is really great and it works for me.