graphql-live-query VS graphql-js

There are even more implementations of live queries available by now. e.g. https://github.com/samsarahq/thunder (go) or https://github.com/n1ru4l/graphql-live-query (JavaScript).

Please compare with modern competitor: json-patch-plus https://github.com/n1ru4l/graphql-live-query/blob/main/packa...

Also note that subscriptions are not the only way to do real time communications in GraphQL. There are also things like Live Queries with great libraries like this from Laurin which you can use

Last but not least, I also created a GraphQL over Socket.io (https://github.com/n1ru4l/graphql-live-query/tree/main/packages/socket-io-graphql-server) transport. I am using this in two smaller apps with a maximum of 10 concurrent users and did not encounter any issues with stale data yet. Maybe this might be somethign you are looking for.

So after having tried to answer you questions (instead of just telling you to not use WebSockets, although that wasn't your question 🙃). I also wanted to point you to a "new" way of handling real-time data with GraphQL that I am experimenting one. https://github.com/n1ru4l/graphql-live-query

There will always be an overhead for sending the mutations via a Post http request vs sending them over the already established WebSocket connection. graphql-ws is not only a subscription transport but can be used for any GraphQL operation including queries and mutations. In real-time applications I tend to use my own GraphQL over Socket.io transport (https://github.com/n1ru4l/graphql-live-query/tree/main/packages/socket-io-graphql-server)

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