This question comes from my attempt to remove the requirement of x-parse-application-id in the header. Details can be found at: https://github.com/parse-community/parse-server/issues/6590
In short: to remove the requirement of this header in each request, we need to assume there is one and only one Parse server instances running. We’d love to hear from you if this is not the case and you have multiple Parse server instances in your code.
@sunshineo thanks for opening the discussion here in the forum. @Tom the idea here is to decide if we can assume or not that there will be only one instance of Parse Server per process. Currently it is not an assumption and it would be a breaking change. Could you please clarify what is it the right process to get approval of the community for this change? Maybe we should also setup the same process for getting approval to completely remove the X-Parse-Application-Id.
I have only one app in my server.
I wouldn’t say we have a process for community approval, I think you’re doing the right thing by giving people an opportunity to come forward. Although, I wonder whether it is ever responsible to assume it isn’t a breaking change as some people are not active in the community and thus we may not hear that the change causes a problem for them.
Although on the other hand, given that in Parse Server days I don’t think it’s ever been recommended to use an applicationId maybe we could write it off as a corner case on that basis?
Ultimately, if the core team can reach a consensus I wouldn’t say that there is any need for community approval beyond the usual open discussion in issues & PRs. In my mind the important thing is appropriately documenting the change (i.e. is it breaking)
Also if you want to get maximum visibility for this, I could tweet about it on @ParsePlatform?
I believe we don’t need to tweet.
In terms of removing the X-Parse-Application-Id header, I understand it is now a consensus of the core team that it should be removed but not worth for the effort it will take. We are all willed to review and approve a PR that anyone send towards this, though.
In terms of supporting a single instance of Parse Server per process, I understand we should still wait to listen the opinion of the other core contributors. I’d prefer to continue supporting multiple processes since some of my apps rely on this behavior, but I’m willed to go in another direction if the other core contributors believe that’s the best way to go.
OK. I have a different idea. How about make X-Parse-Application-Id not required in header and not used to identify the app if there is only one Parse server instance?
Maybe that’s the easier way to go.
We do use multiple instances of the parse server and this has worked great for us so far. Am I to understand that this wont be possible as of (which?) version of Parse Server? Would be great to know as this is a breaking change for us.
This isn’t implemented.
I understand, thanks. Just answering the RFC. Is it still correct to assume that future versions of Parse Server will support running multiple instances in the same thread? From my understanding of the current (4.10.4) version everything (caches, triggers, …) except Cloud Code (we use hooks instead) work just fine with many instances. I’m curious if there is a consensus in the community for this, one way or the other?
We also need multiple instances of the parse server.
My proposal clearly did not get anywhere. Let me just provide some of my final thoughts
I had a particular issue talking to Parse server from a system that I do not control that cannot add the ‘x-parse-application-id’ header. I tried to intercept all request on the Parse side and add that header to solve the problem, then it messed up the dashboard which always do POST for GET/PUT/POST operations. I resolved that by some special handling code for dashboard requests.
After all those, I had a look at Parse code and see a lot of stuff around the id to support multiple instances. I was like who does things this way? I will create and deploy multiple servers if I need different ones. Then the code can be simplified.
Now I realized that people do need this. But I would say the header is not a good place for it. If it is on the url, it will be more flexible and easy to use in different system