The open source project Nexus has reached version 1.0. The declarative approach to creating GraphQL APIs should be stable for productive use with the new release, and there are some significant changes associated with the version jump. Nexus is now available under a new package name, and fields may by default have the value null .

Everything is code The Nexus Project relies on a code-first approach for the creation of GraphQL interfaces: The definition of the APIs takes place entirely via JavaScript, instead of describing the schemas and associated resolvers for using the endpoints, as is otherwise usual with GraphQL.

The approach requires a rethink at the beginning, especially for the definition of the schemes, but should be easier to maintain in the long run and for larger projects. One advantage is that schemes and resolvers are not separate from each other, but are in one file.

SDL and TypeScript from tape Nexus can automatically create suitable SDL files (Schema Definition Language) by calling the function makeSchema , which can be used, among other things, to provide the appropriate schemes for applications such as development environments. In the same block, TypeScript types can be created that ensure type safety when the interface is called from Microsoft’s programming language, as the following example from the blog post on the release of Nexus 1.0 shows:

import path from ‘path’ const schema = makeSchema ({types: , outputs: {schema: path.join (__ dirname, ‘generated / schema.gen.graphql’), typegen: path.join (__ dirname, ‘generated / nexusTypes.gen.ts’),},}) A web-based SDL converter helps with the reverse Way: converting SDL definitions to Nexus.

Zero is an option Version 1.0 brings a few innovations that can lead to incompatibilities. Nexus 1.0 can now be found in the uniform package called nexus and no longer in @ nexus / schema . Developers must adapt the import accordingly:

import {makeSchema} from ‘nexus’ In addition, fields are now allowed by default have the value zero . While this nullability previously required an explicit declaration, there is now a function for fields that cannot be null :

const Post = objectType ({name: ‘Post’, definition (t) {t.nonNull.id (‘id’) t.nonNull. string (‘title’) t.nonNull.string (‘body’)},}) In the schema definition language, the correspondingly declared fields are given a final exclamation mark to indicate that the value is not null may be:

type Post {id: ID! title: String! body: String! } The nullability can be customized globally for any API created with Nexus. If you decide to deactivate it by default, you can set the value null for individual fields using the function nullable .

Lists and abstracts Nexus 1.0 also introduces the new function list for processing lists as input or output values, for example to [String] to be defined as list (‘String’) .

In addition, can Nexus describe the abstract types of GraphQL in the form of unions or interfaces. To do this, it uses one of the three strategies integrated in the official GraphQL JavaScript package, Centralized, Discriminant Model Field or Modular. A detailed description of the individual procedures with examples can be found in the Abstract Types Guide on the Nexus site.

Source: GraphQL.org

GraphQL is a specification for describing APIs. It defines how clients can describe and execute queries and how, on the other hand, the server has to process the queries. With GraphQL, data changes can be read and written in real time.

Facebook had the query language 2012 initially developed internally and 2015 published . The SDL has been part of the specification since the beginning 2018, and the end 2018 the language got its own GraphQL Foundation under the umbrella of the Linux Foundation, which has been taking care of further development ever since.

More details about Nexus 1.0 can be found in the blog post. The full list of new features can be found in the changelog on GitHub. The source code of Nexus is also available there under MIT license.

(rme)