How can our stack get closer to true modularity?

[harm-less]

Hello,

We're in the research phase of rebuilding an API of ours while we came across this library that seems very useful in our case.

We're already pretty comfortable with GraphQL (Apollo). Previously we used this in combination with TypeORM to collect our data from a single database. However, TypeORM (and any other ORM library I'm aware of) doesn't have a similar modular architecture as GraphQL Modules. I can foresee us having to write and maintain our entities in a single place even as our API grows. Only the queries build upon these entities can probably be moved into modules. This isn't the end of the world, but I'd rather be as modular as possible.

So I fear we will only achieve partial modularity which somewhat defeats the purpose of using GraphQL Modules I guess. Are there any recommendation in terms of techniques or libraries we can use in order to write modules properly on most if not all layers of our API if we favour ORM?
Stack recommendation that generally fit well with GraphQL Modules are welcome too.

Thanks in advance!

[smolinari]

I'm also interested in this, but haven't put modules fully to the test yet. My thinking is, though, at some point of scale, we'll switch to microservices. And, either we could have the db access as a service itself, since we've built it to be its own module (not a graphql module), or have the entities (we have models) inside each service as needed. Either way, the db access can also be scalable. I'm leaning to the latter choice though, since it keeps with the whole premise of microservices and developing teams being independent of each other. They would just be using the same "model" system everyone else is using.

At any rate, I'd also love to hear the guidance of the maker(s) of graphql-modules in how to best break up the db access architecture in a monolith to prepare for more decoupled modules/ microservices. 😄

Scott

[harm-less]

I understand what you mean.
Perhaps our API or resources aren't big enough for microservices yet, so for now that's out of the question at least for us.

What really interested me at first about GraphQL Modules was the ability to extend GraphQL types with new properties, so that's what we're looking to solve for our ORM as well as everything can be kept together. In theory isn't not impossible I guess, but it's not a feature I'm aware of currently in any ORM (I'd love to be corrected on this though!).

I therefore get the feeling other stack choices are favourable other than ORM, so I too am interested in guidance as well.

[smolinari]

What ORM are you using? I've also gone down this road I believe, however, we're using Mongoose with TypeGoose and TypeGraphQL and GraphQL Modules as the "final stage". Sounds a bit overloaded, but the overall developer workflow will be fairly simple (hopefully, once we're finished) and with modularization built in. 😁 I believe with TypeORM, you can get the same workflow too, which is a code first approach (and allows for both the extension of entities and GraphQL types at the same time).

Scott

[harm-less]

We already used TypeORM with great success.

I was looking in the documentation of TypeORM and found the following (perhaps that's what you meant as well?):
https://typeorm.io/#/separating-entity-definition

I'd rather use classes and decorators just like you, but that might not be an option. Even though an out of the box implementation isn't in the cards looking at this documentation, I think there's definitely room for a small framework/wrapper to achieve a similar code separation for extending types (or in this case entities/columns) GraphQL Modules offers 💪

Is there anything I'm missing here? You talked about GraphQL types, can you elaborate on this as I don't want to assume anything?

[smolinari]

Well, with Type-GraphQL (which might be missing in your stack?), you can define your entities and your GraphQL types with just one TS class and the necessary decorators, also with the ability to extend them at the same time too.

See these examples:
https://github.com/MichalLytek/type-graphql/tree/master/examples/typeorm-basic-usage
https://github.com/MichalLytek/type-graphql/tree/master/examples/typeorm-lazy-relations
https://github.com/MichalLytek/type-graphql/tree/master/examples/graphql-modules

This is also similar to what NestJS offers. Basically, you are using the power of TypeScript to also generate your GraphQL types, which just follow suite. That puts the GraphQL part of development purely in the background and you can concentrate on making things work for your business in the first instance.

As you can see in the last example, you can also use Type-GraphQL with GraphQL-Modules to get a more modularized (albiet somewhat more verbose) system. 😃

Scott

[harm-less]

I see, this could be useful. I'm also a big fan of class-validator package that's much better supported this way. Here's what I mean:
https://typegraphql.com/docs/getting-started.html#inputs-and-arguments
I was also using this for TypeORM.

I think I should make a small proof of concept soon to see how modular I can make the back-end through all layers from DB to GraphQL.