[Feature] Choosing The scope of the DTO type to return in REST resources dynamically

Overview of the issue

Suppose you have to DTOs for your User entity: the heavyweight one, UserFullDTO, and the light one, UserLightDTO. and suppose the Generated resources could get the type of DTO you need as a query parameter —> localhost:8080/api/users?scope=full

a map could be generated for user — Map<String, Class> — which contains pair(“full”, UserFullDTO.class) and pair(“tiny”, UserTinyDTO.class) so the 1 REST resource could produce response with respect to the scope you provided, and if you don’t provide one, by default it could return the scopeless DTO --> UserDTO or anything that suits better (maybe UserDTO doesn’t fit anymore in this case, all DTOs should have a scope from now on —> UserFullDTO , UserLightDTO, UserUidDTO, UserLightDTO …

Motivation for or Use Case

so you don’t have to write many resource methods for just changing a DTO scope

[jdubois]

No. There isn’t a good GraphQL solution in Java, and also the way GraphQL works will probably be very inefficient with Hibernate, and quite troublesome with Spring Security.

I’m also waiting to see if the technology takes off. At the moment, after a lot of hype, the main GraphQL project has as many stars as JHipster. And the issue with something this complex, is that we need a lot of users in order to have something working. That’s how OSS works: we have typically 1 contributor for every 1,000 users. So if a complex technology is asked by too few people, we won’t be able to maintain it correctly.

So while I’d like to use GraphQL (I’m using it for a client, and like many parts of it), we’re not supporting it now, and probably not in the near future. Unless a great team of people decide to join the project and implement it & maintain it, of course.

[cbornet]

If you’re interested in GraphQL, don’t hesitate to do a module or blueprint !