Parse Server compatibility with Serverless environment

[Moumouls]

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

I'm currently investigating the usage of Parse Server in a serverless env. The current tested setup is:

• Parse Server with Defined Schema and GraphQL packaged in a Docker image
• This Docker image is used on Google Cloud Run, with CPU allocated only during init/requests
• Use MongoDB Atlas Serverless as the database

Refactors/workarounds:

• Parse Server express app call listen() too early (before serverStartComplete), so request cloud be routed to parse-server with a partial/incomplete initialization. For example, defined schema migration could not be finished. A workaround is to call a new "parse.expressApp.listen(1339)" on a different port in serverStartComplete to tell the serverless env (GCP Cloud Run) to start sending requests to the 1339 port.

Errors:

• Mongo Collation on Serverless service, reported here: Parser Server not fully compatible with Mongo Atlas Serverless #7937

Limitations:

• On many serverless env background tasks (actions performed after a request is returned by the server): like Parse.Jobs will not work
• LiveQuery needs an additional setup (not tested)

Stats:

• Parse Server with defined schema start in 7sec when Parse needs to create all schema (should only happen one time)
• Parse Server with defined schema start in 3-4sec when Parse is already initialized (defined schema done, DB init done, etc...), this is the real cold start if Parse Server scale to 0 instances.

Feature / Enhancement Description

The cold start is mainly related to dependency size.
To reduce cold start we need to start some code splitting. All adapters should be moved out of parse-server. Developers should be able to only import wanted adapters/servers, like LiveQuery, GraphQL server, PostgresAdapter, etc...

Then some tiny cache optimization could help to make the parse-server start under maybe 1-2sec.

Example Use Case

Fully serverless usage (with mongo serverless) to allow Parse developers to leverage Serverless computing like:

• No infra management
• Super scalable
• Scale to Zero
• Huge cloud cost reduction

Alternatives / Workarounds

None

3rd Party References

Cloud providers that support scale to zero container instances

https://cloud.google.com/run
https://www.scaleway.com/en/serverless-containers/
https://docs.microsoft.com/en-us/azure/container-apps/
https://aws.amazon.com/ecs/

Database provider with serverless (pay as you go) pricing
https://www.mongodb.com/cloud/atlas/serverless

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

See #483

[Moumouls]

Note: I'm currently not investigating proprietary serverless environments like AWS Lambda/Cloudflare Workers/Vercel serverless. Since it needs specific adaptations/bundling, it's not easily testable in a local env. From my point of view, it's a less standard approach.

Docker helps to get some execution abstraction.

I'm currently focusing on making a parse-server at least compatible to run in a container on a serverless orchestrator: like GCP Cloud Run, Knative.

I'm also focusing on containers since Knative is now part of CNCF, and could be the next cloud standard (like Kubernetes ) to deploy serverless containers across cloud providers: https://www.forbes.com/sites/janakirammsv/2022/03/06/cncf-accepts-knative-projectwhat-does-it-mean-to-the-cloud-native-ecosystem/?sh=72413dfe174b

[mtrezza]

So is this still a general discussion? In that case it should continue in our community forum. We use GitHub to track concrete issues and feature suggestions.

[Moumouls]

It's not a general discussion, it's an issue, and I will work on a PR to fix the app. listen to the issue.
I'll also work on a distinct pr to fix the collation issue for Mongo Serverless.

[mtrezza]

What you are describing seems to be a refactoring of Parse Server that won't be done with a few small PRs. These seems to be several individual issues (adapters, cache, collation), each of which will likely require its own GH issue and discussion. Could you make a roadmap for this with a TODO list to see for which points we need to discuss in more depth?

[Moumouls]

@mtrezza

Roadmap:

Minimum compatibility requirements

1. Fix errors (developers do not have workarounds):

• feat: allow to disable collation (case-insensitivity) on User queries/indexes (email/username)

2. Parse Server listens too early

• feat: add a new "startCompletePort" option to be handle correctly public requests (from a internet/balancer) once parse server startComplete resolve. We need an additional port since internal parse-server code, developers' code inside before/afterMigration, and startServerComplete could use Parse Node JS SDK that internally uses a serverUrl.

At this point Parse Server (without livequery and Parse Jobs) should be able to run in a containerized serverless env out of the box (for example on Cloud Run GCP)

Performance improvement (road to 1-2 sec cold start)

3. Code splitting

• feat: move out adapters of the parse-server package, and allow developers to only install and provide needed adapters, to reduce nodeJS require time currently approximatively 2sec

4. Init speed up

• feat: use the hash (SHA1) mechanism on schema and some configs to easily detect changes, I think parse-server could be optimized and can reduce init time.

5. Dynamic module loading investigation

• feat: some modules of parse could be required dynamically once needed, for example, an auth provider, should be loaded only if a request uses it. The server should not load/require all the code by default at startup time.

Support feature not "Serverless Friendly" like LiveQuery, Parse Jobs

• feat: test and support LiveQuery limitations on serverless
• feat: (i need some investigation on this) add "serverless" Parse Job option, if activated, when a job is triggered from a client (ex: parse-dashboard), to be able to handle the background job, parse-server will need to call itself or another parse-server instance via parseServerJobPublicURL, since many serverless environments only attribute CPU during a request (like GCP). The new jobServerlessEndpoint need to await job completion before returning an HTTP response, to keep access to the CPU. The parseServerJobPublicURL could be also used to allow developers to run Jobs on a dedicated remote parse-server, not running in serverless env.

[Moumouls]

@mtrezza we can split this one into many issues. I think we should also keep this issue open to tracking the work progress.

I'll work on point 1 and 2 may be the next week?

[mtrezza]

Yes, this should be split into smaller PRs as much as possible because large, monolithic PRs are more difficult to manage and take more time to get merged. We can keep this issue open to track the progress; maybe you want to move a compact TODO list of your roadmap to the post at the very top and add checkboxes and PR references to each one so everyone can easily see the status of this.

[Moumouls]

Just for reference, the readiness probe, exposing the server to public traffic needs to be handled by the developer.

Linked comment : #7914 (comment)

The #7914 will allow developers to design graceful start easily using startAsync or serverStartComplete thanks to @dblythy

[Moumouls]

@mtrezza what do you think about adding a section on the docs about some tips for a graceful start in environments like PM2, GCP Could Run, Kubernetes, etc...

[mtrezza]

Sure, please feel free to open a PR.