A GraphQL API solution would be redundant with a REST API.
Having a GraphQL API would therefore allow to save on development efforts.

The contenders:

• Seaography
• Juniper
• async-graphql

Seaography

• Pros:

  • Integration with SeaORM

• Cons:

  • Mutations not available yet
  • Seems not very actively maintained

Juniper

• Pros:

  • Actively maintained

• Cons:

  • Actix-web not maintained by Juniper

async-graphql

• Pros:

  • Was built with Async/Await in perspective
  • Supports middleware
  • Supports redacting sensitive inputs (logs without worrying about leaking this stuff)
  • Actively maintained

• Cons:

  • I haven't find any yet

From above, async-graphql seems to be the better candidate for us.

Well I'm worried about having GraphQL and not using it for serving API endpoints where it helps.

I believe this is a strategic decision to be taken because REST and GraphQL features overlap each others to serve an API.
Let me explain why.

Depending on the type of a project, one or the other could be used.
From simple or very specialized API, REST is perfectly fit for the task where GraphQL schema overhead would be overkill.
For an application requiring a complex API, GraphQL makes more sense because it brings powerful features, the first one being efficiency to retrieve entire set of data with a single network request, and API aggregation would be another benefit.

Of course since the Trustify project is micro services then we could use REST for some services and GraphQL for other services.
My concern here remains for the more complex APIs we ought to implement with GraphQL as the the ideal targets for GraphQL meanwhile if we start serving the API with REST (out of habit ) then we end up not using GraphQL where we should or we either create tech debt.

The feedback from some devs on the trustification expressed a bad experience with GraphQL from GUAC.
I don't know why that happened.
Meanwhile I'm not trying to push GraphQL blindly.
I did a proof of concept for MTV (Konveyor) serving GraphQL from Golang (our back-end) for a JS/TS/React front-end.
That works perfectly fine and showed how we could benefit from GraphQL powerful features. (We never pushed that to production because we downsized MTV).

Of course with a new/recent tech we have to draw the line between stability, community support against technology jump that a new paradigm can bring. This is not the case here, GraphQL has been out long enough

Therefore to decide which tech to use for a project or its micro services parts boils down to evaluate the API needs and match its complexity against the more adapted tool.

Then if Seaography doesn't support mutations then it cannot be used to fulfill a proper API service.

@gildub if you find success before next week's meeting, I'd vote for plonking a link to a video or whatever write-up/example/demo you have here. Relentless forward progress!

@bobmcwhirter,

Juniper ended up to be the most straightforward to implement and is pretty aligned with GraphQL standard.

The following branch contains a basic GraphQL API using Juniper with requests for SBOMs (get all sboms, get one sbom and create a sbom).
More objects and relationships will be next :

https://github.com/gildub/trustify/tree/graphql-poc

GraphQL API examples

Using CURL

Retrieving SBOMs

$ curl -s localhost:8080/graphql -H "Content-Type: application/json" -d '{ "query": "{sboms { id location sha256}}" }' | jq
{
 "data": {
 "sboms": [
 {
 "id": 1,
 "location": "file:///home/gildub/pro/rhtpa/SBOMs/test/batch1/736DA1C6A24D404.replicate1.cdx.json",
 "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
 }
 ]
 }
}

Create (Mutate) a SBOM

$ curl -s localhost:8080/graphql -H "Content-Type: application/json" \
-d '{ "query": "mutation CreateSbom($sbom: SbomInput!) { createSbom(sbom: $sbom) {location sha256}}",
"variables": { "sbom": { "location": "file:///home/gildub/pro/rhtpa/SBOMs/test/batch1/736DA1C6A24D405.cdx.json","sha256": "123456"}}}' | jq
{
 "data": {
 "createSbom": {
 "location": "file:///home/gildub/pro/rhtpa/SBOMs/test/batch1/736DA1C6A24D405.cdx.json",
 "sha256": "123456"
 }
 }
}

Using Graphiql

The Juniper initial easiness was shadowed once we approached more advanced features such as exploiting one to many (1:m), or many to many (n:m) relationships. Juniper unfortunately requires to replicate the model's structure (because the object's structures must be in the same crate scope which doesn't work for us because the model is in another crate).

The next step is to investigate Async-graphql which I initially put aside because mutation are not available yet. And also because in practice Juniper was really easy to get started with.
Meanwhile since our initial needs for graphql require only read access, this is not a limitation.

@bobmcwhirter, from what we've learned and my above comment I'm working on a graphql POC using async-graphql.

Initial POC using async-graphql framework : https://github.com/gildub/trustify/tree/async-graphql-poc

The following PR is adding an /graphql endpoint to the existing web service along the REST API.

https://github.com/gildub/trustify/tree/server-grapqhl

This is replacing the former async-graphql-poc branch mentioned above.
If the POC is accepted it will be submitted as a PR to trustify/trustify.