gqtx
graphql-live-query
Our great sponsors
gqtx | graphql-live-query | |
---|---|---|
6 | 7 | |
449 | 434 | |
- | - | |
0.0 | 3.1 | |
4 months ago | 13 days ago | |
TypeScript | TypeScript | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gqtx
-
Replacing Nexus
My favorites are Pothos and gqtx. In terms of documentation and adoption Pothos definitely wins over gqtx. You might also want to check out the "I'm struggling to find proper Graphql Stack" Reddit thread.
-
Solving the double (quintuple) declaration Problem in GraphQL Applications
By now you get a lot of typesafety without the need to write any types manually or having to generate them on the on the server by using https://github.com/sikanhe/gqtx
-
What do you think about nexus? I'm new at this and wondering if I should use it in my project.
There are multiple ways available of constructing a graphql schema. Usually, you can break down those into "SDL" First and "Code" First. A simple example of a Code First approach is the programmatic graphql.js API using `new GraphQLObjectType`. You define your schema with code. In an SDL First approach, you write your schema in the GraphQL SDL (as text) and define a resolver map. You can find some examples over here: https://graphql.org/graphql-js/constructing-types/ A lot of tooling has emerged of those two methods of building GraphQL schemas and you usually have to choose whether you wanna stick to Code First or SDL First. Tools like gqtx (https://github.com/sikanhe/gqtx), giraphql (https://github.com/hayes/giraphql), and nexus (https://github.com/graphql-nexus/nexus) are built around the Code First approach and improve the developer experience over the programmatic API form graphql.js by providing a more type-safe API when utilizing TypeScript. They ultimately all do the same, with slightly (more or less opinionated) different APIs. On the other hand tooling for SDL has also evolved. graphql-tools provides a more advanced interface over how you define the resolvers map and a lot of utilities for constructing your schema from SDL/resolver map partials distributed across different files (https://www.graphql-tools.com/docs/generate-schema/). Together, with graphql-codegen resolver type generation (https://www.graphql-code-generator.com/docs/plugins/typescript-resolvers) you can bring this to the next level if you are working with TypeScript and generate fully typed resolvers from the GraphQL SDL. You have to find out for yourself which approach is best suited for you. I have been using both on different projects and they both have benefits and trade-offs. My opinion is mostly based on the TypeScript developer experience. Code First seems to be the better pick for me if you have lots of computed fields that cannot be mapped 1:1 to the data sources, where you would have to add a lot of type resolver mappings configuration for codegen. With SDL I like that I have the feeling that I can write the schema faster and less clumsy, and the SDL is immediately readable. On Code First you, however, can still generate an SDL file from the coding schema. Maybe there is a niche open for an approach that combines Code and SDL First approaches. We will have to see what the future brings. Here are some more articles/threads regarding the topic: https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3 https://www.reddit.com/r/graphql/comments/fpkx7a/codefirst\_vs\_schemafirst\_development/ https://blog.logrocket.com/code-first-vs-schema-first-development-graphql/ Also, note that most GraphQL server/transports do or should not care about the way you construct your schema. E.g. the apollo-server docs show you only an SDL first way of constructing the schema (https://www.apollographql.com/docs/apollo-server/schema/schema/), but it is also possible to provide a schema instance(https://www.apollographql.com/docs/apollo-server/api/apollo-server/#schema). apollo-server defaults to advocating creating a schema with SDL (by using an old graphql-tools@4 version under the hood).
Tools like gqtx (https://github.com/sikanhe/gqtx), giraphql (https://github.com/hayes/giraphql), and nexus (https://github.com/graphql-nexus/nexus) are built around the Code First approach and improve the developer experience over the programmatic API form graphql.js by providing a more type-safe API when utilizing TypeScript. They ultimately all do the same, with slightly (more or less opinionated) different APIs.
-
Need guidance on apollo subscription fallback
If I can give you an additional tip: Think twice whether you actually need apollo-server. All you need is a way of constructing a schema, which you can either do with the graphql.js programmatic API, graphql-tools (https://www.graphql-tools.com/docs/generate-schema/), or type-safe code first schema builders such as https://giraphql.com/ or https://github.com/sikanhe/gqtx
-
What are your thoughts on Next/Apollo/Prisma stack? Should I use it for my project (see details in the description)? Can you share some advice?
You will also have to figure out which schema generation flow suits you best. E.g. you can use the programatic API from graphql-js, makeExecutableSchema from graphql-tools https://www.graphql-tools.com/docs/generate-schema/ or code schema builders like https://github.com/sikanhe/gqtx or https://github.com/hayes/giraphql
graphql-live-query
-
GraphQL Live Queries with live directive
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).
- Websocket with socket.io or GraphQL subscriptions
-
The fastest object diff library in JavaScript
Please compare with modern competitor: json-patch-plus https://github.com/n1ru4l/graphql-live-query/blob/main/packa...
-
The Stack #3
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
-
Need guidance on apollo subscription fallback
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.
-
How to maintain subsription websockets with authentication, while retaining the stateless nature that an API should have?
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
-
What is the performance loss with GraphQL mutations vs sending data over websockets in real-time apps?
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)
What are some alternatives?
pothos - Pothos GraphQL is library for creating GraphQL schemas in typescript using a strongly typed code first approach
laravel-echo-server - Socket.io server for Laravel Echo
mercurius-typescript - TypeScript usage examples and "mercurius-codegen" for Mercurius
graphiql - GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.
nexus - Code-First, Type-Safe, GraphQL Schema Construction
federation - 🌐 Build and scale a single data graph across multiple services with Apollo's federation gateway.
graphql-upload - Middleware and an Upload scalar to add support for GraphQL multipart requests (file uploads via queries and mutations) to various Node.js GraphQL servers.
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
TypeGraphQL - Create GraphQL schema and resolvers with TypeScript, using classes and decorators!
mercurius - Implement GraphQL servers and gateways with Fastify
graphql-compose-typescript
microdiff - A fast, zero dependency object and array comparison library. Significantly faster than most other deep comparison libraries and has full TypeScript support.