How and why GraphQL will influence the Sourcehut alpha

Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself and rooted in a mindset I'd call based more on cultural beliefs rather than engineering. That said, a recent discussion [1] convinced me there are practical benefits in using GraphQL if you're working with "modern" SPA frameworks, and your backend team can't always deliver the ever-changing interfaces you need so you're using a backend-for-fronted (an extra fronted-facing backend that wraps your actual backend) approach anyway, though it could be argued that organizational issues play a larger role here.

[1]: https://news.ycombinator.com/item?id=23119810

If you don't like REST, don't use it.

Whatever you do, don't even think that GraphQL will solve your problems. You were on the right track staying away from it till now.

I can't also advise enough to stay away from a typed language (Go in this case) serving data in a different typed language (gql). You will eventually be pulling your hair out jumping through hoops matching types.

After my last web project that require gql and go, I did some digging around, thinking, there has to be a better alternative to this. I have worked with jQuery, React, GraphQL.

My conclusion was that next time I will stick to turbolinks (https://github.com/turbolinks/turbolinks) and try stimulus (https://stimulusjs.org/).