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

I like GraphQL but if you're just serving a single SPA I wonder about all this busy work we still have to do. Why haven't we gone a step further and just abstracted all the networking and serialisation steps away and our models are synced for us in the background. Maybe the apollo team is heading in this direction but their offline story isn't great yet.

Edit: I remember now that the Apollo team is made up of members of the former Meteor team which worked in a similar way using a client side database.

You can use rxdb for replication and offline support.

Yeah good point, WatermelonDB, rxdb and pouchdb all fit this model. This to me feels like the future for web and mobile.

Hopefully not. In an ideal world, this would be the responsibility of the browser given the widespread web apps.

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/).

I don't follow, how do you mean?

> stimulus (https://stimulusjs.org/).

And here I thought Basecamp was still 100% rails. Interesting to see that they're also developing backend JS frameworks.

Stimulus is a frontend framework.

Turbolinks doesn't work with third party(js) anything.