Server selection ability while making any cloud function calls

[yog27ray]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Not able to make cloud function calls to another parse server via Parse.Cloud.run('anotherServerFunctionName').

Feature / Enhancement Description

Ability to pass server selection details with option while make cloud function calls.

new ParseServer({
...
serverURL: 'current server url',
masterKey: 'current server masterKey',
otherParseServer: [
  { serverName: 'anotherServer1', masterKey: 'another server1 masterKey' },
  { serverName: 'anotherServer2', masterKey: 'another server2 masterKey' },
],
...
})

Parse.Cloud.run('anotherServerFunctionName', {}, { serverName: 'anotherServer1', sessionToken, useMasterKey } );

Example Use Case

1. Create Parse Server project A with cloud functions "serverACloudFunction".
2. Create Parse Server project B with cloud functions "serverBCloudFunction".
3. Server A wants to call server B cloud function "serverBCloudFunction" using the parse library function.

Alternatives / Workarounds

ServerA can make a rest-API call to serverB to access serverBCloudFunction. But it would be better if parse can support this functionality.

3rd Party References

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

It seems to be an elegant convenience wrapper for a REST call. Any other benefits this could have?

[yog27ray]

As of now that I can think of are

1. Consistency in making cloud function calls between different parse server (different database). Currently making rest API call breaks it.
2. Current project can be divided into small projects sharing same database and keys. This feature make this split easier without making function call syntax change.
3. This can be extended to Query calls also as for making rest-api call someone has to learn about the request body syntax.

@mtrezza if this feature looks good. I can try implementing the pr.

[mman]

Sorry for hijacking the discussion, but I do not think this provides any benefit to general parse server use. Will need more convincing I think.

Your case is probably very specific in that you may have multiple different projects, all of them based on parse-server, that want to talk to each other via REST, but you want to simplify that, and believe that cloud function call with explicit server name will make this easier (for you). But I do not think this is the case. It may work in your concrete case, but to make it really generic for all parse users, such wrapper function may become very complex. To explain: does this method target the load balancer before the parse server instances?, does it use SSL? Does it target just one concrete instance behind the load balancer? Where does the server name come from?

My suggestion for you would be to write a simple javascript module with one exported function that will wrap axios http library to perform a http call against a named parse server, with specified master key, and then require that module in your cloud code where needed. This will achieve the same faster, without requiring changes in the parse-server itself.

What do you think? More reasons why this should be a core function of the parse-server?
Martin

[mtrezza]

To explain: does this method target the load balancer before the parse server instances?, does it use SSL? Does it target just one concrete instance behind the load balancer? Where does the server name come from?

I think that all would be determined by the server address. It seems to be more of an architectural decision than a Parse Server configuration. Parse Server is currently unaware of whether its a single instance or part of a multi-instance target group behind a load balancer. Same for TLS, that's part of the connection string.

I think what's missing here is a server address in addition to the server alias in the config:

otherServers: [
  { name: 'server1', masterKey: 'key1', url: 'https://one_instance' }, // TLS connection to a single instance
  { name: 'server2', masterKey: 'key2', url: 'http://load_balancer' }, // non-TLS connection to a group of server instances
],

It may be a convenient wrapper in a micro-service environment where references to other servers are more common. For now it's just a simple http request trapper, but I would be curious to see what other server interactions and co-configurations people come up with.

[davimacedo]

The limitation here is actually regarding Parse JS SDK, which does not support instantiate multiple clients: #203

I think that would be a good addition to the JS SDK and I'd re-open the mentioned issue in the case someone is willed to tackle it. Anyways, I believe that this current issue does not belong to Parse Server repo.

[mtrezza]

Closing as duplicate of #203.