12 ms·
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 ag
by tannhaeuser 6y ago
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 https://news.ycombinator.com/item?id=23119810
- jamil7 6y agoI 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.
- searchableguy 6y agoYou can use rxdb for replication and offline support.
- jamil7 6y agoYeah good point, WatermelonDB, rxdb and pouchdb all fit this model. This to me feels like the future for web and mobile.
- searchableguy 6y agoHopefully not. In an ideal world, this would be the responsibility of the browser given the widespread web apps.
- jamil7 6y agoI don't follow, how do you mean?
- zapf 6y agoIf 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 https://github.com/turbolinks/turbolinks) and try stimulus (https://stimulusjs.org/ https://stimulusjs.org/).
- square_usual 6y ago> stimulus (https://stimulusjs.org/ https://stimulusjs.org/). And here I thought Basecamp was still 100% rails. Interesting to see that they're also developing backend JS frameworks.
- odensc 6y agoStimulus is a frontend framework.
- Scarbutt 6y agoTurbolinks doesn't work with third party(js) anything.