Repository navigation
Remove GraphQL API from codebase #7979
Description
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
The GraphQL API has been implemented into the core codebase of Parse Server. This has shown to cause many complications since its implementation, for example:
- the GraphQL API is heavy; it adds a swath of complex dependencies that need to be kept up-to-date
- developers who are not using GraphQL are still carrying the weights of an - unused - GraphQL API on their server, being affected by vulnerabilities in GraphQL dependencies, etc.
- the implementation into the core codebase was really violating a core philosophy of Parse Server which is modularity, allowing developers to optionally add adapters as needed, to keep their deployment as lightweight as possible
Feature / Enhancement Description
Move GraphQL API out of Parse Server into its own adapter. Despite its initial hype, GraphQL won't be the last API of its kind and we will see it become obsolete at some point in the future.
An adapter implementation of the GraphQL API should follow #7744 (comment) since it is the most sustainable approach, without just shifting the technological debt to another one-of-a-kind adapter interface with its custom specifications.
Example Use Case
n/a
Alternatives / Workarounds
n/a
3rd Party References
n/a
Activity
parse-github-assistant commentedon May 6, 2022
Thanks for opening this issue!
[-]Remove GraphQL API from core codebase[/-][+]Remove GraphQL API from codebase[/+]ga262 commentedon Jun 19, 2026
I would like to support this direction.
For users who do not use GraphQL, it feels unfortunate that GraphQL-related dependencies are still installed as part of
parse-server. Beyond package size, this also means non-GraphQL deployments may be affected by dependency updates or vulnerability reports for code paths they never use.Maybe a smaller first step, before fully moving GraphQL into its own adapter package, could be:
dependencies;This would not solve the full modularity question, but it could reduce install size and unused dependency exposure without requiring a complete adapter extraction immediately.
Longer term, extracting GraphQL into a dedicated package still seems cleaner, but optional installation + lazy loading might be a lower-risk intermediate PR.
mtrezza commentedon Jun 21, 2026
Sounds like a plan. Incremental steps are always preferred. This should involve @Moumouls, since he's an expert in GraphQL.
Moumouls commentedon Jul 6, 2026
Hi @mtrezza, I think the best approach here is a two-phase migration: introduce a new API layer adapter that can handle the Parse GraphQL server end-to-end with traditional inversion of control, and optionally expose some specific internals currently used by the GQL server (if I remember correctly). Create a separate repo for parse-server-graphql-server.
For a specific major release, support both the integrated GQL server and the new parse-server-graphql-server, with a deprecation notice. In the next major release, remove the internal GQL server. A one-time switch feels unrealistic and would be hard to ship correctly.
The project needs some work, but @ga262, if you’re open to it, with AI assistance it’s completely feasible.
For now, @mtrezza, the GraphQL dependencies should not be moved — otherwise usage of the GQL API will break for users relying on Docker images or the Parse Server CLI (not programmatic usage).
About lazy loading: it’s a good first step to reduce startup time and memory footprint.