Ideas for Improving the GraphQL Layer

Hi from The Guild !

We’ve recently built and open-sourced a new plugin system for GraphQL that we think would be a huge improvement for Parse developers - GitHub - dotansimha/envelop: Envelop is a lightweight library allowing developers to easily develop, share, collaborate and extend their GraphQL execution layer. Envelop is the missing GraphQL plugin system.

parse-server already comes with a full-fledged GraphQL implementation based on apollo-server-express which is awesome! As we are trying to constantly improve the GraphQL ecosystem not for specific frameworks but for everyone this is the main driving force behind developing envelop. The idea is that the envelop core provides an API for hooking in all kinds of stages of the parse, validation, and execution phase of a GraphQL request. The clue behind envelop (compared to most GraphQL frameworks today), is that it just takes the parse, validation, execute and subscribe functions from graphql-js and enhances them, which allows to use it with almost every graphql server/framework that is built upon these functions. GraphQL server frameworks like apollo-server give you a very framework-specific and inflexible approach of hooking into those phases. We believe that the latter is counterproductive for the whole ecosystem as a whole as customizations and cannot be easily shared between developers and must be reinvented on a project basis.

This write-up has been highly theoretical until now, let’s look at some of the plugins every parse-server user could immediately adopt if envelop was built into parse-server:

  • useLogger Add a custom logger to the GraphQL execution
  • useGraphQLJit precompile reoccurring GraphQL operations yielding in much faster server response times
  • useRateLimiter add rate limit to specific fields in the schema
  • useDepthLimit: prevent execution of excessive and deeply nested queries from potential attackers

Additionally, every parse-server user would be able to write and share his own plugins that can be used to customize the graphql execution layer.

We want to help to improve the overall GraphQL experience. Here is a list of the things we found that can be improved by looking at the codebase.

Envelop plugins. Easily share execution layer customization logic with not just parse users but also other graphql adopters. A niche for parse-server-specific envelop plugins could evolve!

Keeping up with the latest GraphQL features. Apollo Server is only moving slowly. There better alternatives available, such as graphql-helix. Instead of being a full-blown Framework like graphql server, it tries to serve one purpose: Reading GraphQL parameters from a request and executing them (all customization would be done by envelop). graphql-helix furthermore allows executing GraphQL operations via HTTP SSE, which compared to the available WebSocket protocols does not require a huge overhead of implementing the protocol on the client, it is all HTTP.

Supporting the official GraphQL over WS protocol. The currently used graphql-ws protocol is abandoned by apollo and the new graphql-transport-ws protocol is taking over. For backward compatibility, we believe it is still important to support the old protocol in a hybrid approach, while still giving parse-server users the power to opt into only using the new or old protocol if desired.

Further stuff. @defer and @stream and our new live queries implementation

Out of curiosity we already tried to check how easy it would be to apply some of the things mentioned above (while having complete backwards-compatability) in a draft pull request over here: GraphQL with graphql-helix, graphql-ws and envelop by n1ru4l · Pull Request #7394 · parse-community/parse-server · GitHub

We would love to collaborate with the parse community in order to improve the overall graphql experience :slight_smile:


Thanks for suggesting!

I think GraphQL is still under-leveraged in Parse Server and I am happy to see this initiative. Maybe this is a good time to re-think our current Parse SDK strategy and see whether it makes sense to use GraphQL as a common, platform-independent denominator.

1 Like