Repository navigation
Remove GraphQL API from codebase #7979
Description
Activity
Thanks for opening this issue!
- 🎉 We are excited about your ideas for improvement!
- pinned this issue
on May 6, 2022 - changed the title
[-]Remove GraphQL API from core codebase[/-][+]Remove GraphQL API from codebase[/+]on Oct 12, 2022 - unpinned this issue
on Oct 12, 2022 - added and removed
on Oct 2, 2025 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:
- move GraphQL/Apollo-related packages out of regular
dependencies; - make them optional peer dependencies;
- lazy-load the GraphQL implementation only when GraphQL is actually enabled;
- show a clear runtime error if GraphQL is enabled but the optional dependencies are not installed.
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.
Reacted by Manuel- move GraphQL/Apollo-related packages out of regular
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.
Reacted by Manuel
New Feature / Enhancement Checklist
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:
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