Thanks, great answer and as always you guys provide quick and good help here.
So, yes, I also think of a Community Extension in the first place. I also agree to keep things as easy as possible.
The options I found are:
Here we can ask: do you allow direct DB mutations?
The third option - to make it more complete - would be
3) graphql-java - as the name says it's a GraphQL Java implementation. In this case the GraphQL server would be written in Java (which I hesitate to do in the case of GraphQL).
So, lets check this points in more detail:
Some remarks here:
- we need something real fast and directly connected to the Camunda core, so I believe the REST-API is not an option (although its valuable for other use cases). REST would diminish the advantages of GraphQL (something like DataLoader could bring some relief here and help out through caching and batching, but the basic problems of REST remain)
For the second point I am a little bit scared, because normally you are told not to do such bad things as directly connecting to the database when there are nice APIs available for a good reason.
Anyway, lets elaborate on this point a little bit:
GraphQL is a specification that defines a query languages for your data / API. It also defines 'mutations'. This means we can potentially change data (through the implemented resolvers behind the scenes that do the magic) and so can consumers of the GraphQL API, when mutations are made available.
Question is: Does Camunda encourage or "not disallow" direct DB-mutations by using a direct Camunda database connection? Would that be accepted by customers? I doubt it a little bit. I see problems. But maybe with the blessing from Camunda we can make it happen?