GraphQL

GraphQL is the default API architecture for MemberJunction, offering a flexible and efficient way to expose data-driven operations. It supports partial retrieval of information, allowing users to query specific fields from their schema, even in hierarchical relationships. This means you can opt to include or exclude certain data collections based on your needs.

MemberJunction’s API can be interacted with in various ways, with GraphQL being notably efficient.

📘

In GraphQL, “mutations” refer to operations that modify data, including inserting, updating, or deleting records. You can also perform bulk actions using mutations.

Our approach at MemberJunction involves a CodeGen strategy combined with metadata from our database. This generates a GraphQL API automatically. The process starts with the MemberJunction metadata, specifically an entity called “entities” stored in the admin schema (admin.Entity table). Here, a field named IncludeInAPI determines whether an entity is incorporated into the API. Setting this field to zero excludes a table from the API. By default, CodeGen sets this field based on the config.json file value during initial setup, typically set to one, assuming most tables should be included.

There are other settings within the entity metadata, covered in the CodeGen documentation, that govern modifications and other aspects. However, the primary setting is IncludeInAPI.

Once enabled, you can specify additional settings. After CodeGen generates the API, it’s run through the MJAPI project, a Node server that primarily uses the NPM package @memberjunction/server. This package contains all functionality needed to operate the API. MemberJunction places this functionality inside an npm package to encapsulate it, simplify updates and reduces deployment complexity.

📘

The core of the GraphQL API is a concept called the ‘resolver.’

A resolver is a class containing all queries and mutations for a portion of the API, typically associated with a single type or table. Each resolver can have multiple queries and mutations for its type.

MemberJunction’s CodeGen automatically creates resolvers for each included entity. We use the open-source version of the Apollo Server for an effective GraphQL server engine, alongside TypeGraphQL for exposing TypeScript types in GraphQL. We also use an ORM library called TypeORM in some areas of the server. The reason is that TypeORM provides a nice interface with TypeGraphQL and Apollo Server. However, these implementation details are generally unnecessary for users unless they wish to work directly with the GraphQL layer of MemberJunction.

Most developers will focus on modifying server-side business logic, enforcing rules, and implementing workflows, typically outside the GraphQL API layer, within a subclass of an object called BaseEntity.