Build Your GraphQL APIs Faster with Nexus Schema
Ryan Chenkie
@ryanchenkie
GraphQL Dev Rel at Prisma
Building a GraphQL API
@ryanchenkie
@prisma
Most often, developers start with an SDL-first approach
Easy to get going
Most examples show SDL-first but it's not the only way
Schema Definition Language
@ryanchenkie
@prisma
type Post {
id: ID!
title: String!
body: String!
}
type Query {
posts: [Post]
}Resolvers
@ryanchenkie
@prisma
const resolvers = {
Query: {
posts: (_, args, context, info) => {
return context.db.posts.findMany()
}
}
}Issues with SDL-First
@ryanchenkie
@prisma
Schema and Resolvers in different places on the filesystem, modularization challenges
Need to context switch between Schema and Resolvers
Need for tooling
Code-First GraphQL APIs
@ryanchenkie
@prisma
const Post = objectType({
name: 'Post',
definition(t) {
t.id('id');
t.string('title');
t.string('body');
}
});Code-First GraphQL APIs
@ryanchenkie
@prisma
const Query = queryType({
definition(t) {
t.list.field('posts', {
type: 'Post',
resolve(_, args, context, info) {
return context.db.post.findMany();
}
});
}
});Code-First GraphQL APIs
@ryanchenkie
@prisma
Everything is in one place, no need for extra modularization and context switching
No need for extra tooling
Codegen produces artifacts like SDL and types
Easy to move quickly and collaborate
DEMO
@ryanchenkie
@prisma
Thank You!
@ryanchenkie
bit.ly/graphql-galaxy
Build Your GraphQL APIs Faster with Nexus Schema
By Ryan Chenkie
Build Your GraphQL APIs Faster with Nexus Schema
Developing a real-world full-stack app often involves tedious threading of data across multiple layers of the stack. This is particularly undesirable during prototyping phases where the main goal may be just to demonstrate an idea or design. It’s also risky when going to production since data inconsistencies between the layers can lead to bugs. We show one solution to this velocity and type-safety dilemma via Nexus combined with Prisma.
