Hacker News new | ask | show | jobs
by jaegerpicker 2894 days ago
There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more. GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

2 comments

> There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more.

That's not a unique benefit of GraphQL. Any HTTP based API can do this, regardless of how it's designed.

Some specifications even have it baked in (See: jsonapi.org).

> GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer.

Again, not unique to GraphQL.

> There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

Again...

> There are also a ton of maintenance benefits, like for example if you add a field in GraphQL that's perfectly fine to not change the version because that break any existing calls, which is not always true with REST.

Assuming you are using some from of Semantic Versioning, adding a field to a REST API should never break existing clients. Did you mean "removing" a field?