> I failed to convey my points - hard enough in a foreign tongue and with
> not more context than plain ASCII ;) We'll just leave it open until
> concrete issues and questions come up.

No problem. Sorry if I misunderstood something obvious.

> The one thing that honestly frightens me a bit is the reliance on this
> one technical thing as the magic sauce to clarify all open questions.
> But again it's hard to discuss that up front as vague concerns, so let's
> focus on concrete steps.

That's a wise and understandable concern.

I didn't mean to say that all problems would be magically solved (though
I probably spoke so enthusiastically that it sounds like it). I mean
that I can't think of any approach that would be less problematic, and
that's why it's also the choice with the smallest risk. If we roll our
own REST API, we'll have most of the problems we'll have with GraphQL,
plus a large number of additional problems.

GQL has had very large deployments by now (Facebook, GitHub, Shopify,
MusicBrainz, etc.) By consensus, its biggest intrinsic problems are that
caching and authentication are difficult to arrange for complex APIs.
That's because of the flexibility (clients can freely combine objects
from the object model to make complex and unexpected queries). But with
REST APIs, those same queries were usually made by making many API calls
instead of just one, often to multiple different APIs. So it's not clear
that the old situation was less complex - the complexity was distributed
across multiple APIs or endpoints so any single one of them seems less
complex.

Anyway, if the rest of the group is skeptical about it (which is wise),
I'm willing to personally implement things in Scheme until you are
convinced that it works for our purposes. Then I can bear the risk.

On the client side, REST and GraphQL queries are equally simple to make.
There is practically no difference.