Parse-sdk-js: Ability to instantiate Parse

[flovilmart]

While working on https://github.com/parseplatform/parse-server we face an issue with the shared state of Parse.
We'd need to be able to create instances of the Parse SDK, for cloud code functions, in the context of multiple apps running on the same server.

After investigating the code, it seems that the whole SDK design goes against an easy fix for that.

What do you think @andrewimm ?

[andrewimm]

@flovilmart you're absolutely correct that the SDK design goes against this style. Handling the scenario you describe isn't easy for something that's originally designed for client apps and sandboxed cloud environments.
We've explored this area before, but any changes needed to support it would break several APIs, and significantly complicate the structure of the API on single-app clients (which are the significant majority of use cases for the JS SDK). There are also weird issues that occur when instantiating different versions of Parse. For instance, a Parse.User from one instance can't be used with Parse.User of another instance. It places an extra requirement on the developer to avoid mixing and matching data types, which doesn't fit well with the general Parse mission to make development easier.

Unofficially, I'm looking for a way to separate the object representation format from the request structure -- essentially, a functional-programming API that would allow an object to be saved to any parse app. This would solve the problems you're looking for, and in my opinion it makes for much safer server code. I have not idea when or if it'll be released, but it's something I want to explore when I have the time.

[flovilmart]

@andrewimm we could explore together if you like, if we settle on an API early on, I could fill in the blanks on side branches.

[TylerBrock]

It would also be great to disable the object state store which makes it extremely difficult to reason about the state of objects in a running server application.

[andrewimm]

@TylerBrock isn't that the reason for disableSingleInstance() ?

[andrewimm]

@flovilmart @TylerBrock regarding this topic in general, I'm considering a standalone repo to house some of these experimental ideas. I'll see what I can get around to later this week.

[flovilmart]

@andrewimm I managed to get around the problem with subprocesses and HTTP as a transport which is OK as we'll need that eventually. But that would make it more efficient to not have this shared state due to the global nature of Parse and the a-synchronicity of node.

[TylerBrock]

@andrewimm is disableSingleInstance() called automatically by requiring parse/node?

[andrewimm]

Not exactly with that method, but it should be: https://github.com/ParsePlatform/Parse-SDK-JS/blob/master/src/ParseObject.js#L67 :)

[TylerBrock]

That's what I figured but we still see object state mutated by side effects of other queries/saves. I'll create a separate issue for that though (or update the existing one)

[andrewimm]

Hmm, that's troubling, open a new issue to track it

[oallouch]

is it related to https://github.com/parse-community/parse-server/issues/5278

[isokosan]

Does anyone have any suggestions on implementing two or more Parse instances at the moment?

Re-initializing Parse before making read/write requests is getting the job done for now, but I need to make multiple live query connections, and that is breaking when re-initializing the app.

Ps: I don't use authentication, I'm building for electron so I can easily use parse/node instead if that makes it easier to use multiple instances.

[sadortun]

@flovilmart Even if years have passed, I think this issue is still relevant and should be addressed.

[flovilmart]

As years have passed and no one has addressed the issue. It is only fitting to close it. If you really feel the issue should be addressed, why don't you take a stab at it?

[sadortun]

@flovilmart Indeed, I am currently looking into it. This is something that we'll need.

[sadortun]

@dplewis @mtrezza Your feedback would be appreciated. If we can find an agreement on this i could work on a PR in the next few months.

After some digging in the SDK, it seems that we need to

• CoreManager needs to be moved from global to an instance.
• Replace Parse and use a locally initialized CoreManager
• Parse.Xyz classes needs to be constructed with the local CoreManager

As for using it

• Preserve behaviour of Parse.initialize() for BC purposes

• Implement a new class ParseInstance
  
  
  
  • Then use const MyParse = new ParseInstance(config1)
  
  
  • Then use const MyParse2 = new ParseInstance(config2)
  
  

[mtrezza]

Can you lay out again what the objective would be?

[sadortun]

@mtrezza We need to connect to two different servers from the same app

[mtrezza]

We may want to keep the iOS and Android SDKs in mind. Ideally we find a concept that can be replicated to these.

Also, differentiation by app ID may make sense, to keep local cache separated. IIRC that is how it is currently done for Android and iOS SDK where app ID is part of the local storage path. There have been efforts in the past to remove the app ID from Parse Server entirely. It seems they have been abandoned, but some PRs have been merged. More relevant for multi-tenancy Parse Server but maybe also for this PR.

@dplewis is the JS SDK expert here, I'm sure he has