PostGraphile (formerly PostGraphQL) builds a powerful, extensible and performant GraphQL API from a PostgreSQL schema in seconds; saving you weeks if not months of development time.
PostGraphile is formed of three layers.
- At the very top is the PostGraphile CLI. This layer is the most user-friendly and is responsible for three things: accepting common options from the command line; spinning up a HTTP server (or a cluster of them, or none at all depending on what options you’re using); and mounting the PostGraphile middleware (see next). Most users should start with this layer, many users use it successfully in production, and it’s where we recommend you start.
- The PostGraphile CLI wraps the PostGraphile middleware (“library”). This middleware is suitable for mounting in Node.js HTTP, Connect, Express or Koa applications. This layer is responsible for receiving, deciphering and validating the GraphQL HTTP request from the user according to the options supplied; configuring a PG client with the relevant settings; and then sending the query on to the GraphQL schema to be resolved. About 70% of PostGraphile users end up using this layer in their applications; reasons to use this over the CLI include the ability to add Express middlewares before PostGraphile (e.g. to perform rate limiting, sessions, authentication and other concerns) and the ability to take greater control over the PostGraphile system.
- Deepest down is the PostGraphile GraphQL schema (“schema-only”) itself which contains all the types, fields and resolvers. (The schema is constructed dynamically, so cannot be written to disk.) Most users will never use this level.
