Hi! Today I've open sourced

GraphQL Modules

- a toolset we've been developing for a few months which will help create reusable GraphQL based modules and scale your GraphQL servers. https://medium.com/the-guild/graphql-modules-feature-based-graphql-modules-at-scale-2d7b2b0da6da It is a bunch of individual libraries that you can use separately if you believe like us that you should spilt your GraphQL servers into feature based modules. I would love to hear any feedback or questions! 🙂

This looks really good @urigo - can't wait to try it out.

thank you 🙂

appModule

finally need to import list of all used modules? So, it splits your codebase in modules, but does not help micro-services way, right?

@Serhii Kyrychenko https://graphql-modules.com/docs/guides/microservices

The nice thing is that you don't have to use it. We will release a blog post soon about how and when we recommend

How does this differ from nestjs/graphql?

I think they very different in terms of structure and philosophy (but I also might be wrong, I'm in conversations with Kamil to maybe come up with a joint blog post about the comparisons). One thing I see is that it's a full buy-in. very much feels like Angular on the server. Classes, annotations and dependency injection from the start. that is not what GraphQL Modules is. we have multiple separate tooling that you can add to your existing GraphQL server without needing to change a lot. Then I felt that with Nest the Typescript class is the base of your app, and see that the source of truth should be the GraphQL schema IDL. but yesterday Kamil wrote me they also do GraphQL first schema approach but from all the example I've seen, you describe everything in a Typescript class and annotate it to generate GraphQL which I personally don't like. I thought of NestJS as a similar approach to a lot of the Java frameworks. Write your Java class and generate GraphQL, Swagger, REST, JSON API or whatever from those classes. I believe that there is a need for a GraphQL framework that use GraphQL as the source of the generation of everything else, not just as another type of API you expose. (I have many more things we are going to add based on that approach that I will share soon). I also saw they use

merge-graphql-schemas

under the hood so I think they are not trying actually to solve the same problem as you can't really merge modules with the same type... that's why we created

@graphql-modules/epoxy

. But I actually hate this answer that I wrote, it feels a bit general and you don't hear Kamil's side of the story. I want to create a deep dive with examples. I will try to publish a comparison next week but I guess like everything, the best thing is to try both and share with me what you think from your experience 🙂

Brilliant. Thank you for taking the time to answer. I agree with the GraphQL schema-first approach also.