The future of GraphQL Yoga

[MichalLytek]

It's been almost 4 weeks since release of graphql-js v14. There's plenty of PRs with deps update but the last commit on this repo was 26 days ago.

I've tried to update the deps in my project but graphql-yoga is still in 0.13.x ecosystem which results in plenty of errors like this:

npm WARN apollo-cache-control@0.1.1 requires a peer of graphql@0.10.x - 0.13.x but none is installed. You must install peer dependencies yourself.
npm WARN apollo-cache-inmemory@1.2.10 requires a peer of graphql@0.11.7 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN apollo-server-core@1.4.0 requires a peer of graphql@^0.9.0 || ^0.10.0 || ^0.11.0
|| ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN apollo-tracing@0.1.4 requires a peer of graphql@0.10.x - 0.13.x but none is installed. You must install peer dependencies yourself.
npm WARN apollo-upload-server@5.0.0 requires a peer of graphql@^0.13.1 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-config@2.0.0 requires a peer of graphql@^0.11.0 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-import@0.4.5 requires a peer of graphql@^0.11.0 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-extensions@0.0.10 requires a peer of graphql@0.10.x - 0.13.x but none is
installed. You must install peer dependencies yourself.
npm WARN graphql-import@0.6.0 requires a peer of graphql@^0.11.0 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-middleware@1.6.6 requires a peer of graphql@^0.13.2 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-query-complexity@0.2.0 requires a peer of graphql@^0.13.2 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-subscriptions@0.5.8 requires a peer of graphql@^0.10.5 || ^0.11.3 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-tag@2.9.2 requires a peer of graphql@^0.9.0 || ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 but none is installed. You must install peer dependencies yourself.
npm WARN graphql-tools@3.1.1 requires a peer of graphql@^0.13.0 but none is installed. You must install peer dependencies yourself.

I also get famous Cannot use GraphQLSchema "[object GraphQLSchema]" from another module or realm. error while trying to use the subscriptions.
And it also rejects to compile new GraphQLServer({ schema }) in TypeScript as there's a conflict of GraphQLSchema typings between 0.13 and 14.0 😕

I would like to create a PR to fix that and upgrade the deps but someone has to merge it then 😄

[MichalLytek]

Mentoning @DakshMiglani @maticzav @divyenduz @timsuchanek as the latest commiters to this repo - I thought that Prisma now have a huge financial support to don't let the open source projects die 😕

[caseyduquettesc]

#439 related?

[MichalLytek]

@caseyduquettesc not only, all prisma packages has to be updated too:
https://github.com/prisma/graphql-middleware/blob/master/package.json
See v0.13.2 of graphql

[dodas]

This is probably reason why apollographql/apollo-server#1505 (comment) doesnt work in graphql-yoga?

By the way, i can't access request object inside context callback either. The only argument that is passed in is an object with connection property, which doesn't seem to help me when I need to access data from request object.

[frandiox]

In case somebody wants to migrate to Apollo Server v2, here's a reference. It uses the new Apollo errors and supports both directiveResolvers and schemaDirectives.

[LawJolla]

@frandiox I really like that... solid work and thanks for sharing!

[schickling]

Hey everyone, there have been a lot of questions and confusion around the future of graphql-yoga lately. We want to use this GitHub issue as a forum to openly discuss in which direction the project should be headed.

Context & History

For context, we have released graphql-yoga almost one year ago when setting up a GraphQL server (using apollo-server or express-graphql) involved a good amount of boilerplate and manual work; it certainly wasn't as easy as it should have been. This was true for rather simple GraphQL servers and became even more complex when features like subscriptions or middleware would have to be added.

Back then, we were striving to create the simplest solution for developers to get up-and-running with GraphQL. With graphql-yoga, we came up with a simple, straightforward and intuitive API to launch a GraphQL server that has been received very positively from the community.

GraphQL Yoga Today

Since the release of Apollo Server 2.0 which uses the same API as graphql-yoga and also comes with default support for GraphQL Playground (instead of graphiql), a lot of the value originally provided by graphql-yoga has vanished.

We have been scratching our heads over the past few weeks thinking hard about the future of graphql-yoga, whether we can find a direction that makes it so distinct from apollo-server to invest further in the project or switch to minimal-maintenance mode.

As is obvious from the state of this repository, graphql-yoga has not been maintained properly over the past few weeks. We apologize for that!

The Future of GraphQL Yoga

There currently are a few urgent issues with graphql-yoga that make it unusable in certain contexts, e.g. the 0.14 release of graphql-js. We're already working on them and will release a new version in the coming days.

As for the mid-/longterm future of the project, we'd love to hear your opinions and discuss them openly! Do you have ideas or wishes how graphql-yoga could have a distinct value proposition over apollo-server? Are there any features that you're missing in the current version? Whatever comes to mind that helps us make a decision regarding the future is more than welcome in this thread!

Thanks 💚

[LawJolla]

I think Yoga, as is, still provides great value. For instance, it includes Apollo-Uploader out of the box for file uploads. The Express middleware API is miles better than Apollo 2.0.

Going forward, I think there's room to be an opinionated Apollo Server. For instance, does anyone really care that you can use Apollo Server on top of Hapi? Choosing Express simplifies and streamlines everything. And I'd like to see more opinions incorporated like best practices for authentication and authorization.

In other words, keep doing what made Yoga so great -- an opinionated, simpler API.

As a business decision, Yoga may not make sense any longer, but from a developer standpoint, I think it has legs... or downward dogs. (Oh yoga puns)

[jasonkuhrt]

Agree with @LawJolla.

Apollo Server 2.0+ is clearly aiming to be very usable by developers as their primary application framework, as opposed to a primitive. That means Yoga can only make sense if it fills a niche really really well. By becoming much more opinionated it will necessarily probably alienate some of its existing user-base. But I don't really see a way around that.

Vague sketch of opinion areas Yoga could maybe have:

• zero-config GraphQL on Rails kind of experience.
• prisma backend interop out of the box, whatever that means/entails
• folder and file structure conventions + corresponding DX benefit
• error handling, error codes, schemas, ways to streamline these parts which need to be done well, in a standard way, but maybe doesn't have value to be done bespoke/by the developer every time
• auth
• modular types+resolvers
• TypeScript centric
• curated custom scalers
• https://github.com/prisma/graphql-resolver-codegen integrated and works out of the box, zero config needed by user

[LawJolla]

@jasonkuhrt great post, couldn't agree more.

I'd like to expand on the folder / file structure suggestion. On one of my apps, I used an entity file structure where each GraphQL type got its own folder. e.g.

entity
-vehicle
--vehicle.graphql
--vehicle.resolver.js
-user
--user.graphql
--user.resolver.js
...

I used merge-graphql-schemas to walk the tree and merge the resolvers, and I manually imported every .graphql with graphql-import.. Setting up the system was a pain and it's still not fully automated (GraphQL-import doesn’t automatically import added files).

However, once set up, I've found the pattern very useful and clear. I think a closer integration with and development of GraphQL-import along with some king of resolver merge would be a huge boon.

[webberwang]

I believe if the efforts of maintaining Yoga were to move to creating extra plug and play features for Apollo Server, it would give more value to the GraphQL community.

These extra Yoga features added to Apollo Server could be extra opt-in features. New developers wouldn't have to make the tough choice of choosing between Apollo Server or Yoga, and they would have a single framework that supports most of the features they want.

I see the evolution of Apollo as becoming more modular when it refactored to 2.0, and this fits inline with the extra features Yoga could add.

I understand that Prisma probably wants something to call their own, but having a fragmented library base is one of the pain points of Javascript development.

[jasonkuhrt]

@webberwang makes sense. At the same time if there can be a significant enough differentiation for Yoga, and it becomes amazing at its niche, then it would seem to by definition avoid the user pain and community fragmentation risks.

I guess this thread has become about uncovering if such a product does/can exist.

[thenikso]

I found the port to Apollo very straight forward with virtually zero differences for my project.
Especially using graphql-import so that you can still use the .graphql file schemas.

From this:

import { GraphQLServer } from 'graphql-yoga';

const server = new GraphQLServer({
  typeDefs: __dirname + '/schema/schema.graphql',
  context: req => {
    // using req.request
  }
});

To this:

import { ApolloServer } from 'apollo-server';
import { importSchema } from 'graphql-import';
import { parse } from 'graphql';

const server = new ApolloServer({
  typeDefs: parse(importSchema(__dirname + '/schema/schema.graphql')),
  context: ({ req }) => {
    // `req.request` is now just `req`
  }
});

I believe that Apollo2 offers all the simplicity that made me use garphql-yoga in the first place. Freeing time to focus on Prisma instead would be excellent I think!

[tomyjwu]

Here is my take on porting to Apollo2, with prisma.

import { ApolloServer, gql } from 'apollo-server'
import { Prisma } from './generated/prisma'
import { importSchema } from 'graphql-import';

import resolvers from './resolvers'

const importedTypeDefs = importSchema(__dirname + '/schema.graphql');
const typeDefs = gql`${importedTypeDefs}`

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: req => ({
    ...req,
    db: new Prisma({
      endpoint: process.env.PRISMA_ENDPOINT, 
    }),
  }),
})
server.listen({ port: 4000 }).then(() => console.log('Server is running on http://localhost:4000'))

So I think effort should be put into migrating all the online prisma tutorial to using the Apollo2, including excellent howtographql site.

[stale]

Due to inactivity of this issue we have marked it stale. It will be closed if no further activity occurs.

[schickling]

Update: We started working on the foundation of Yoga 2 🎉

It's still very early but if you're interested feel free to get involved in the issues! 🕵️‍♀️

[stale]

Due to inactivity of this issue we have marked it stale. It will be closed if no further activity occurs.

[stale]

Due to inactivity of this issue we have marked it stale. It will be closed if no further activity occurs.

[stale]

Hey 👋, It seems like this issue has been inactive for some time. In need for maintaining clear overview of the issues concerning the latest version of graphql-yoga we'll close it.
Feel free to reopen it at any time if you believe we should futher discuss its content. 🙂

[alan345]

I migrate today to apollo server.
Hope the Prisma team will give us a clear guideline regarding this matter: should we migrate GraphQL Yoga to apollo server?

[gotexis]

@tomyjwu @thenikso

Hey total noob here, so nooob question alert:

What is supposed to be the /schema.graphql - do I automatically generate that using some prisma magic or do i write it myself? I don't see any .graphql file generated for me, running prisma generate.

[junaid33]

@gotexis think of Prisma as your backend and GraphQL Yoga or Apollo Server on top of that. This is what your client will be accessing. /schema.graphql is your GraphQL Yoga/Apollo Server schema and determines what mutations and queries your client can access.

If you go to your GraphQL Yoga/Apollo playground, the schema tab on the right is your /schema.graphql essentially.

[bradleykhan]

This is a very informative thread, thanks guys! @schickling there has been little to no activity in the yoga2 repo since April, is this still in active development? Currently the only option is to migrate to Apollo Server 2, but ideally want to avoid multiple migrations if the suggestions here for what Yoga2 could provide becomes a reality

[jasonkuhrt]

Hey @bradleykhan in the coming weeks we will begin on a framework that realizes ideas alluded to in this thread. Can't give any precise timelines but do want to underscore a project will be getting underway.

[bradleykhan]

Ah lovely, thanks for the update!

[riginoommen]

Hey everyone, there have been a lot of questions and confusion around the future of graphql-yoga lately. We want to use this GitHub issue as a forum to openly discuss in which direction the project should be headed.

Context & History

For context, we have released graphql-yoga almost one year ago when setting up a GraphQL server (using apollo-server or express-graphql) involved a good amount of boilerplate and manual work; it certainly wasn't as easy as it should have been. This was true for rather simple GraphQL servers and became even more complex when features like subscriptions or middleware would have to be added.

Back then, we were striving to create the simplest solution for developers to get up-and-running with GraphQL. With graphql-yoga, we came up with a simple, straightforward and intuitive API to launch a GraphQL server that has been received very positively from the community.

GraphQL Yoga Today

Since the release of Apollo Server 2.0 which uses the same API as graphql-yoga and also comes with default support for GraphQL Playground (instead of graphiql), a lot of the value originally provided by graphql-yoga has vanished.

We have been scratching our heads over the past few weeks thinking hard about the future of graphql-yoga, whether we can find a direction that makes it so distinct from apollo-server to invest further in the project or switch to minimal-maintenance mode.

As is obvious from the state of this repository, graphql-yoga has not been maintained properly over the past few weeks. We apologize for that!

The Future of GraphQL Yoga

There currently are a few urgent issues with graphql-yoga that make it unusable in certain contexts, e.g. the 0.14 release of graphql-js. We're already working on them and will release a new version in the coming days.

As for the mid-/longterm future of the project, we'd love to hear your opinions and discuss them openly! Do you have ideas or wishes how graphql-yoga could have a distinct value proposition over apollo-server? Are there any features that you're missing in the current version? Whatever comes to mind that helps us make a decision regarding the future is more than welcome in this thread!

Thanks 💚

I still believe graphql-yoga still have the value. Please do update this project. This brings a big value .

[jasonkuhrt]

@riginoommen Check out https://github.com/prisma-labs/graphql-santa

Note that it's still under active development and graphql-santa is just a temporary code name.

-- update

https://nexusjs.org/

[nargetdev]

I've spent a fair amount of time sifting through this now. Here's my two cents from the hours "booting up" on this stack.

Fullstack example comparison Apollo vs Prisma

The apollo fullstack template is by far the most complete fullstack example out there. In my experience the Prisma fullstack template is broken, or very inconsistent.

As someone relatively new the fullstack examples are my jumping off point and I'm extremely biased towards one that works well "out of the box".

High level direction

It seems that Prisma1 was more focused on infrastructure (in addition to ORM functionality). The docker-compose.yml based workflow was a nice zero-config solution that booted up flawlessly every time - infrastructure.

It seems to me that Prisma2 was a move to focus on the core offering: the ORM. I think this is a great move. Infrastructure is still being built by Prisma team, i.e. yoga and yoga2 But to me it seems less mature than the Apollo project. I feel like Prisma should focus solely on Prisma2 and port all the examples to Apollo-Server.

With this said, I imagine that projects like nexus and yoga2 contain sage wisdom and architectural opinionation around graphql best practices, but I have yet to grok the nuances behind the differences. To me it just feels fragmented and spread out resulting in many examples which are out of date and broken.

I realize this is a time of flux. One of the most frustrating things getting booted up is the multitude of examples using Prisma before the "@prisma/client": "2.0.0-beta.1" release, which conform to outdated (breaking) API.

[cktang88]

Update for anyone reading now, Nexus is the recommended complete GraphQL backend framework (https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack) which comes with a plugin for Prisma2. Nexus originally was nexus-schema and transitioned to a framework.

There's also an opinionated full-stack framework (with React frontend) called Blitz.js which also uses Prisma2.

Update (9/30/2020) - seems Nexus is also being deprecated prisma-labs/graphql-framework-experiment#1432

[Urigo]

Hey, @Urigo from The Guild here!

You might know us from projects such as graphql-code-generator, envelop or graphql-tools.

For a long time we thought that the Javascript ecosystem is still missing a lightweight cross-platform, but still highly customizable GraphQL Server.

In the past the awesome Prisma team took on that great challenge and now we are happy to announce that we are continuing them and just released GraphQL Yoga 2.0 - Build fast, extensible, and batteries-included (Subscriptions, Serverless, File uploads support) GraphQL APIs in Node.js 🚀

We have been working a long time on version 2.0 and have been using it in our clients projects for a few months now and shared a couple of alpha cycles here.
Thank you all for your feedback and suggestions, you made this release possible!

Please try Yoga out again, give us feedback and help us spread the word on the new release!

• Announcement and blog post
• V2 Roadmap #704
• https://www.graphql-yoga.com/