GraphQL support

[glutengo]

Overview of the issue

Picking up from jhipster/generator-jhipster#4251 (comment)

I have decided to work on a GraphQL integration for nhipster in my master's thesis. I will start to work on this soon and I would like to hear the opinion of the developer team regarding the best approach on how to integrate my work in the jhipster ecosystem.

My initial idea was to create an own blueprint. This new blueprint would have generator-jhipster-nodejs as a dependency and add the new graphQL functionality where needed (using inheritance where possible). Would this be the right way to go? What other options are worth looking at? A PR in this project? A module rather than a blueprint?

Looking forward to hearing your thoughts!

Related issues

jhipster/generator-jhipster#4251

• Checking this box is mandatory (this is just to show you read everything)

[ghost]

Hi @glutengo , it's wonderful!
My opinion is to fork this blueprint and integrate the GraphQL support (merging with a PR).
The reason is that we already prompt a question for the database type, and you can add your graphql option.
Besides, NHipster uses TypeORM that easy could add graphQL support and is very similar to Hibernate (used in standard JHipster generator).
Last, but not the least, typeORM is already integrated in NestJS, that is the core nodejs backend framework of NHipster, so for nodejs backend implementation is advisable to use this blueprint, while for the client part you can use different templates to add in jhipster standard generator, or in NHipster blueprint (NHipster inherits the jhipster client templates and uses its own nodejs backend that works with its).

Here the configuration and the entity TypeORM main files of generated example app:

• https://github.com/jhipster/jhipster-sample-app-nodejs/blob/main/server/src/orm.config.ts
• https://github.com/jhipster/jhipster-sample-app-nodejs/blob/main/server/src/domain/user.entity.ts

Here the blueprint prompt point of database choice:

• https://github.com/jhipster/generator-jhipster-nodejs/blob/0f03a0f809ff339f81839cf1f86c44ce000346ed/generators/server/prompts.js

However, I advice to wait the next NHipster 2.0.0 release (a beta will be published in the next days after #211 validation) and fork that main branch.

For any questions feel free to contact me, I'm the full NHipster contributor (the main founder and stream lead), so there will be wonderful to collaborate together!

[glutengo]

Hi @amanganiello90 thank you so much for your quick reply and thank you for all the pointers!

I have worked with NestJS and TypeORM in the past and the docs have their own graphQL section: https://docs.nestjs.com/graphql/quick-start

As far as I understand, using GraphQL would not be an alternative to using a certain database (type) like mysql or mongodb but it would rather be an alternative/addition to using REST, right?
So there should rather be an additional prompt which asks if the user wants to use graphQL instead of/in addition to REST. I was also thinking about a custom annotation on the concerned entity in JDL which is evaluated when code is generated based on the JDL schema.

Also thank you for offering your support, I will definitely get in touch again.

[ghost]

Yes, the link section of NestJS that I have added in my comment is the same yours :)

However, when you customize the entity model template, you can define your service called by the controller REST api, so in my opinion when the user chooces the graphQL database automatically He will use your custom services and models (and you could add new questions after graphQL choice if there are other customization for the user).

For the JDL, if you need to specify an annotation to generate entity and services customization for GraphQL, you could use the jhipster standard databaseType. For example in NHipster I defined the sqlite value in devDatabaseType: https://github.com/jhipster/generator-jhipster-nodejs/blob/main/test-integration/samples/microservice-oauth2-jdl/.yo-rc.json

You could perform the same thing in JDL, and evaluate in the blueprint the different generation according the variable value.

Finally, you could give a look to the graphQL official jhipster module.

[ghost]

@glutengo yes you are right, maybe it's more correct to add another question to chooce graphQL support in server subgenerator prompt because it enables api that you can use with all database types (sqlite, sql and so on).

However you will have customized templates for entity model, service and controller according your choice. These templates will be in entity-server subgenerator, called automatically by import-jdl command or entity command.

[glutengo]

@amanganiello90 I agree and thanks for pointing out the existing jhipster module, that seems to be brand new and I had not seen that yet!

I was already typing and trying to make my case for not using the databaseType field but your latest comment shows we are on the same page now :)

[ghost]

@glutengo you rock !!! 💯 ;)

[ghost]

@glutengo go ahead with this issue. Thanks a lot @mraible for adding a bug bounty 💯. Markus is a great contributor 🥇

[glutengo]

@mraible @amanganiello90 Thank you a lot for that! It will be a while until I can provide a fully working version of this, but I will keep you updated with my work here. So far I have managed to set up the NestJS GraphQL module during app generation, create a GraphQL resolver for the user entity and generate a GraphQL resolver when a new entity is created via the entity generator. I have also taken some basic steps on the frontend side with Angular, but there is still plenty to do on that end.

I am also considering to move the code to its own module (instead of integrating it into this blueprint). The new module could be compatible with the Node.js backend in the first version and could be extended to be working with Spring in the backend (or any other technology - if someone decides to implement it) at some point in the future too. As I am planning to generate the frontend code for consuming the GraphQL API too, I think it would be best to have an own module because otherwise the frontend code (which could also be of use for JHipster flavours other than Node.js) would be locked away in this blueprint and could not be re-used anywhere else.

[ghost]

It is possible to have the entity backend part (nodejs) in the blueprint, and the frontend (i.e. Angular) in a module?
Remember that already exists an official Graphql jhipster module: https://github.com/ANDERSON1808/graphq-jhipster-generator for java backend side.

[glutengo]

My work for the GraphQL integration is continued as a JHipster module here:
https://github.com/glutengo/generator-jhipster-gql
For now, it supports Angular and React in the frontend. The backend part currently supports the NodeJS Blueprint only (backend part is omitted if the blueprint is not detected), but I think it would be possible to integrate the existing Graphql Module for Java Backends at a later stage.

It is still very much work in progress, I just wanted to give a quick update so that you know where the work is continued.

[ghost]

Thanks @glutengo!!

[glutengo]

First early version is now available: https://www.npmjs.com/package/generator-jhipster-gql

[ghost]

Good!!

[ghost]

Hi @glutengo. You can get your bug bounty if the issue is completed. So I close the issue. Thanks