Expose Parse Server config in Cloud Code

[mtrezza]

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

Customization is a key characteristic of Parse Server. There have been scenarios in the past in which developers need to access adapters / controllers of Parse Server, which is done via the server config. The suggested way to access the config is:

const Config = require('../node_modules/parse-server/lib/Config');

That is not a stable reference and may break if server files are refactored.

See:

• "Clean Up Files" Feature #1023 (comment)
• Is there a way to access MongoDB instance in cloud code. #1859 (comment)

Feature / Enhancement Description

Expose the server config via an official method, for example:

const Parse = require('parse/node');
const Config = Parse.config;

// or considering multitenency:
const Config = Parse.getConfig(Parse.applicationId);

Example Use Case

const config = Parse.config;
const url = config.filesController.adapter.getFileLocation(config, filename);

Alternatives / Workarounds

n/a

3rd Party References

n/a

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[Moumouls]

@mtrezza i can suggest another implementation. What about just adding a config key under the request object used in all triggers? A lot easier to implement and follow the internal architecture of the parse server. Currently, the config is transferred through function args, not by a method from the Parse singleton :)

[Moumouls]

magic will happen here:

parse-server/src/triggers.js

Line 248 in 42c9543

export function getRequestObject(

[mtrezza]

That means config would only be accessible in a request. If config is static per Parse instance and doesn't change per request, why would you tie it to a request? And how would you access config outside of a request?

[Moumouls]

If config is static per Parse instance and doesn't change per request

For DX purposes. Parse Server internally heavily use dependency injection by passing config during request execution. This is smart, easier for testing purposes and there is no reason to not expose the config through the request object. Also in a multi-tenancy config config/request makes sense.

NOTE: for example on the graphql API the full Parse Server context, with config and auth is available in the GraphQL resolver context arg

And how would you access config outside of a request?

Not supported in my PR, it could be an additional implementation. But not currently motivated to look into it. I've not seen this use case on my side since I use Parse Server.

So it sounds that const Config = Parse.getConfig(Parse.applicationId); is still up for grabs.

[mtrezza]

What's the point of adding code to every request route and add tests for each individual route, if exposing the config via Parse is a solution that requires less code, less tests and covers even more use cases? This seems to be blowing up the code unnecessarily?

Not supported in my PR, it could be an additional implementation.

Why would that be an additional implementation, wouldn't that make your PR obsolete?

[Moumouls]

@mtrezza I suggested a quick implementation without any tradeoff. This implementation follow dependency injection strategy well know to facilitate tests (like unit test on cloud function etc...) and also flexibility.

Feel free to send a PR for the Parse.Config strategy.

My PR will not be outdated or useless. Some properties of the config are already used in each request. There is no reason to not extend the request and allow developers to access to the full config through the request interface.

[mtrezza]

My PR will not be outdated or useless.

How so? If config is accessible via Parse, why would it be useful to provide the config additionally in a request?

[Moumouls]

why would it be useful to provide the config additionally in a request?

Because dependency injection is another way to consume data. I agree that Parse.Config is also useful but it's also another way to consume the config through a singleton. These 2 solutions can easily coexist and make sense.

Dependency injection strategy is easier also to use in a multi-tenant app. User will not need to care about which config to get in his cloud function/hooks.

[mtrezza]

These 2 solutions can easily coexist and make sense.

Why does it make sense for them to co-exist?

in a multi-tenant app

Does Parse Server currently support multi-tenancy?

[Moumouls]

Why does it make sense for them to co-exist?

Sure, one use dependency injection strategy with it's own benefits and the other use the singleton/import strategy with also it's own benefits

Does Parse Server currently support multi-tenancy?

It seems that some users started to succeed to use Parse in multi tenancy config, so it make sense to still implement code "multi tenancy friendly" (ie: #7951)

[mtrezza]

It seems that some users started to succeed to use Parse in multi tenancy

We don't consider unofficial / hacked-in features. For Parse Server to support multi-tenancy more internal restructuring is needed. Just like there is Parse.applicationId, there can be Parse.config. If multi-tenancy ever becomes an official feature, both (and more) need to be reconsidered. Multi-tenancy is an issue that is discussed since Parse Server was open sourced and never made it so far. There have also been contrary efforts to remove the app ID in order to simplify the codebase. Both is on the table, neither can reasonably influence our current decision making.

So far I don't see any benefits for config as part of a request; but I do see downsides, as it requires more code, more maintenance and more tests. We want to reduce code. In every request, the Parse object is accessible and can provide a single path and logic to obtain the config.