News for hackers. Stuff that matters.

A comment on Monoliths Are the Future. Parent comment

Re:Monoliths Are the Future by JMTQp8lwXL on Thursday January 30, 2020 @01:46PM (#22194062)
Whether or not your system intentionally ended up with this architecture, GraphQL provides a unified way of fetching the data. You'll still have to implement the details of how to fetch from the various services, but it gives people who just want read access to everything a clean abstraction for doing so.
[ Parent | on HN ]
Re:Monoliths Are the Future by benwaffle on Thursday January 30, 2020 @01:50PM (#22194110)
REST can do the exact same thing.
[ Parent | on HN ]
Re:Monoliths Are the Future by nathankunicki on Thursday January 30, 2020 @02:04PM (#22194279)
With less flexibility, and more round trips.
[ Parent | on HN ]
Re:Monoliths Are the Future by MadWombat on Thursday January 30, 2020 @02:20PM (#22194440)
I am not sure about that. Both RESTful APIs and GraphQL APIs need to be designed and flexibility is basicaly a measure of how good your API design is. I don't see how GraphQL is intrinsically more flexible.
[ Parent | on HN ]
Re:Monoliths Are the Future by jsjohnst on Thursday January 30, 2020 @02:16PM (#22194393)
> With less flexibility, and more round trips

That all depends on the API.

[ Parent | on HN ]
Re:Monoliths Are the Future by nathankunicki on Thursday January 30, 2020 @08:17PM (#22198035)
Sure - but if you ever want it to be as flexible as GQL, you need to implement...a query language?
[ Parent | on HN ]
Re:Monoliths Are the Future by adamc on Thursday January 30, 2020 @02:34PM (#22194589)
It's nice to have a clean abstraction, but if the various services are on tables in different databases, things like joins get much more expensive, no? Performance is important.
[ Parent | on HN ]