How to deal with types? about graphql-modules HOT 9 CLOSED

Hi @19majkel94 !

graphql-modules is agnostic to the language you use. We do prefer TypeScript we don't want to force users to use it. We suggest it, but we think that each developer should have the ability to choose his development environment. Flow is a strong alternative for TypeScript and so does JavaScript with ES6/ES7 features.
I agree that using GraphQL with TypeScript is not perfect the moment, so we don't want to force any solution on developers.

graphql-modules aims to provide a solution for implementing the architecture of the code that comes behind your resolvers, and not something else. It's a library/set of tools and not a framework.

Personally, I can recommend developer who loves TypeScript to use graphql-modules, along with tsc or babel-typescript for compilation, and to get type-safety to use graphql-code-generator to create typings for the server side entities, and for the resolvers signature (FULL DISCLOSURE: it's mine).

Regarding the rest of the discussion, graphql-modules approach is schema-first, which means that you write your schema first, and then implement your code or generate something out of it. What you do later with your code is a different issue, and we would like to let developers control this.

If you wish to generate typings per module, you can use graphql-code-generator for that matter, and generate typings for your module:

• You can do it as-is without config.
• You can wrap it with namespace per module.
• You can wrap it with the namespace for all modules (and then use declaration merging from ts).
• You can add custom prefix per module.
• You can also let me know what you think the best way to generate typings per-module, and I can do my best to help you with the codegen.

The decision is in your hand, but these are features that are part of graphql-code-generator, and that's not something that we would like to force developers to use.

A good developer experience in my point-of-view should be a library that can work with other libraries without forcing you a specific pattern. You can either use graphgen, or code-generator, or apollo-cli, that's your choice. We can only recommend and provide examples.

Also, graphql-modules is new it terms of open-source and it will take a bit more time to fill all docs, all preferences and all flavours that developers uses today.

I can only suggest you to give graphql-modules a try, test it with typescript+graphql packages and decide what works best for you, and share it with the community, we'll probably do the same very soon :)

from graphql-modules.

Solutions about schema typings are provided by tools like GraphQL Code Generator. GraphQL-Modules is just a solution to manage big scale in a modular approach.

Agree. But you advertise graphql-modules as a TypeScript compatible (all examples/docs use *.ts files) but looks like the API was designed with the JS in mind, leaving the TS support for other tools. You left types problem to users, so they have to solve them by their own and the DX is not so great. You should just have good recipes for that things in your docs or maybe a custom wrapper/template for GraphQL Code generator.

from graphql-modules.

What do you mean by advertise?

If you show examples written in TS in your medium article or docs, it's a clear signal that the library is focused on TS experience, so TS users might expect built-in support like e.g. Nest provide or graphqlgen offers.

I sounds a bit like you are advocating for a specific approach (generating from Typescript) and in your opinion anything else is a bad DX.

I've literally not even mentioned something like that.
GraphQL ecosystem and tooling are a bit immature for now (comparing to years of developing rest/http tools) and many people found lack of TypeScript support, so some of them prefer generating schema from TypeScript.

I'm just asking only about schema typings modularity as the guides/solutions might be helpful in implementing modules idea into other, TS class-based approaches.

I don't see any particular reason that denies the modular approach

Denies is a too strong word. I just think that users might expect a better support because your proposed solution might get users into troubles as the global types leaks through the module encapsulation. It might give them falsy feeling that they can use e.g. user.profilePicture property even when the ProfileModule is not imported by a ChatsModule, so reusing modules in new app will fail due to an implicit coupling (not listened in imports of module declaration). And that's the problem you should consider to address to give users even better DX 😉

from graphql-modules.

https://github.com/Urigo/graphql-modules/blob/master/docs/introduction/integrate-with-graphql-code-generator.md
You can use the recipe used here.

from graphql-modules.

Thanks! 😃

But this approach denies the idea behind graphql-modules, that modules should be portable =
not tightly coupled to other modules.

I mean that when we implement ProfileModule and inject UserModule to it, we only rely on the base user object type (id, username, email) but with this generated type we also receive user.chats from ChatsModule not imported in ProfileModule.

So I think that you should find a way to generate the types in a different way to encapsulate the signatures in modules, not from the global, merged schema.

from graphql-modules.

You can still create schema.ts files for each module that uses that module’s typeDefs; because each module has its own encapsulated schema.

from graphql-modules.

And how to use them after that? E.g. when my ChatsModule imports UserModule and ProfileModule but they have two different User interfaces.

from graphql-modules.

How about namespaces? You can use namespaces to differentiate them from each other. It will be possible in GraphQL Code generator by prepending
export namespace FooModuleTypes {
and appending
}
to the generated file by using add plugin of codegen.
We can add that kind of recipe to our docs. What do you think?
@dotansimha

As an answer for your previous comment; this problem is not directly related to graphql-modules; because it already exposes the encapsulated schema.
The idea behind graphql-modules is not just TypeScript or/and providing schema typings or etc. Solutions about schema typings are provided by tools like GraphQL Code Generator. GraphQL-Modules is just a solution to manage big scale in a modular approach.

from graphql-modules.

What do you mean by advertise?
I sounds a bit like you are advocating for a specific approach (generating from Typescript) and in your opinion anything else is a bad DX.
We are using only Typescript in all of our projects and using GraphQL Modules together with graphql-code-generator and it gives us a very good DX.
What would you add to the docs to make it better? Our seed has graphql-code-generator in it, but we don't want to force it on you.
To sum up, I don't see any particular reason that denies the modular approach, TypeScript support, schema encapsulation or other stuff as we promised in our docs, blog post and other platforms etc.
In my opinion, TypeScript compatibility means you can benefit typings *.d.ts provided in that package. For example, Apollo Server package has TypeScript support, and you can see what's inside of Apollo Server package, its classes, properties of them etc etc.
So, GraphQL-Modules package has TypeScript declaration files *.d.ts in its npm package to improve DX.

from graphql-modules.