Evaluate viability of GraphQL API

[xla]

We take on a lot of complexity and extra tooling to have our GraphQL API running. Additionally it adds a layer of abstraction given that we have to model our domain into its type system. All of this while not entirely leveraging the upsides (highly specialised response payloads, fluidity for data shape). We ought to assess if the overhead is still warranted and investigate if simpler alternatives would fit the bill.

Proposed Alternatives

• build up a simple REST API that allows us to prototype a query interface that the user app can consume (@garbados)

[garbados]

GraphQL is an intriguing standard but the tooling ecosystem for it is fractured, creating scenarios of disputed responsibility and questionable reliability. In Rust, the Juniper library is recommended by the GraphQL Foundation, but the library has not been meaningfully responsive to contributions ([1] [2]) and the documentation is often lacking.

Using Juniper, we take on these shortcomings. To continue to use it, we must build up the knowledge to actively maintain Juniper because the absence of such will continue to block us: confusing errors, bad docs, missing features, mismatched assumptions, etc. We can't assume this work will get done for us.

Alternatively we can build up a simple REST API that allows us to prototype a query interface that the user app can consume. This would require re-instrumenting front-end tooling away from GraphQL, and would create work by way of needing to write the API and update it over time, but would otherwise avoid the problem of taking on maintainership of Juniper. I believe it would also simplify exploration of our domain by disconnecting "How do I deliver this feature?" from "How does Juniper want me to handle this?"

[xla]

As pointed out by @MeBrei there is some context misisng in this issue, so I gonna dump what I have communicated verbally a couple times to help people understand the motivation of that issue.

We don't benefit from round-trip reduction

Usually a single graphql query can save calls to many endpoints by clustering all necessary information at once. This is important in round-trip sensitive environments like mobile user agents. As we communicate on the process boundary and not the machine boundary we don't benefit from that./

We don't benefit from client defined data shapes

Another usual upside is that the client drives the shape of the respones and therefore only requests what's necessary to full-fill the current view. So far our design has been very resty, by having distinct queries per "page/view". This might be due to multiple potential factors:

• the surface of our entities is still too small
• we don't have enough slightly different views where fine-grained control is necessary
• we don't have enough experience and simply don't use it to best effect

The tooling has been a significant time sink

Our development ergonomics have been suffering from the overhead of the stack of tooling. Either over time by getting the right parts in place to have proper introspection, or ongoing trying to model and keep up with juniper. Generally speaking the tooling is in most places immature and hard to rely on. Frankly juniper the backbone doesn't instill confidence and doesn't support subscription or for the Rust context important features like async/await.

For reference: #153 #157

We suffer from potential domain incoherence

As mentioned in #124 there is a real risk with the current stack and the many domains we try to consolidate into one larger domain surface, that we loose the original meaning of concepts. Having GraphQL with its own, rather quirky, type system in the mix adds to that risk and we had a lot of cases were we spent time modelling it in a way that was agreeable with the type system (e.g.: unit variants in enums).