graphql-js VS graphql-spec

To begin, I'm going to start with GraphQL. This repo is a JS-specific implementation for GraphQL, for which projects written in JS/TS can utilize to build an API for their web app. The reason why I chose this project is because I've always been intrigued by how GraphQl challenges the standard way of building an API, a.k.a REST APIs. I have very little knowledge about this project since I've never used it before at work or for my personal projects. I only have theoretical knowledge about it which I gained from watching YouTube videos. It also uses TypeScript which is fascinating because type safety is very important when building software considering it cleans out a lot of bugs early on before the software is shipped.

When I asked this in StackOverflow over a year ago I reached the solution of using graphql + graphql-zeus.

In short, we chose not to pursue GraphQL due to some limitations with union types and a lack of support for maps. This is further detailed in this link: limitations.

benchmarks: This directory contains benchmark tests that help measure the performance of the package's code, these tests can be are very useful when experimenting with performance optimizations, and to ensure no slowdowns are introduced between releases. Example from graphql.

GraphiQL (and many other tools) relies on introspection query which AFAIK is not guaranteed to have any specific order (and many libs don't support it). Apollo Server is built on top of graphql-js and it relies on it for this functionality.

GraphQL.js + Knex.js + knex-types (TypeScript generator for Knex)

Yoga v2 supports some experimental GraphQL features such as @defer and @stream, allowing you to get a taste of the future of GraphQL (with compatible clients such as URQL).

Visitors are used for many reasons like extensibility, plugins, printing an entire schema somewhere, etc.

support for @defer and @stream

GraphQL's first draft release was 8 years ago. [1]

It's first non-draft release was 5 years ago. [2]

It's first release under a community foundation was 2 years ago. [3]

[1] https://spec.graphql.org/July2015/

[2] https://github.com/graphql/graphql-spec/releases/tag/June201...

[3] https://github.com/graphql/graphql-spec/releases/tag/October...

I'm a big believer in GraphQL (in fact, at time of writing I'm #2 contributor to the GraphQL spec itself) so it pains me that a tool I built doesn't always have easy ways to achieve the "versionless schema" design that GraphQL encourages when it comes to making significant breaking changes to your underlying database tables. (Personally, I think you should aim for your database schema itself to be versionless, but this is not always possible.) Of course you can build your PostGraphile schema over views instead of tables, but views have their own problems that I won't go into here…

I created a proposal for Map type but didn’t make it through.

https://github.com/graphql/graphql-spec/pull/888

The issue with GraphQL is it tries to appease too many masters.

Similar to jsx. The language isn’t evolving.

The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can encompass the flexibility of json schema can do.

Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?

https://github.com/graphql/graphql-spec/issues/284

You’ve probably figured it out by now, but for others who may be in a similar position; GraphQL is a specification (with various implementations) and you can read up on the spec here: https://spec.graphql.org/

If you're asking whether GraphQL supports anonymous objects that can be arbitrarily nested then no, it doesn't.

show this feature request some love https://github.com/graphql/graphql-spec/issues/174

* Performance: It's just hard to track down what makes an operation slow. The waterfall nature of resolvers is a big contributor

[1] https://github.com/graphql/graphql-spec/issues/488

:::note GraphQL Union is available for Types only, not for Inputs. However, the oneOf directive will bridge the gap in the future.