undefined | Better HN

0 pointshansonkd1y ago0 comments

> It ensures that the endpoints are maintainable and future-proof when people are working on different features

How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.

0 comments

randomdata1y ago

It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues.

But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the REST/RPC part, making GraphQL their entire service, violating its principles.

If it works it works, but it does not come tradeoff free.

hansonkdOP1y ago

? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.

randomdata1y ago

You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.

1 more reply

realusername1y ago

I don't think it would hold true for very long, devs will have specific cases which will pile into the definitions.

That's why GraphQL examples usually focus on querying data from users and not how you are going to manage 10 different views of the same data.

hansonkdOP1y ago

> pile into the definitions

That is how REST works but is the opposite of the way GQL works.

You don't pile into existing defintions but extend the current definitions out. A team needing new data doesn't affect the consumption of other teams. which is not the case of REST where if one team needs to change a REST endpoint to return different shape of data, they have to verify the new shape with other teams.

realusername1y ago

With REST, the endpoints are team based if you have even a semi-competent CTO so you never have this problem, you just check who owns the controller and that's it.

With GQL though, good luck retracing who owns what field and what does it affect if you change the definition of what it returns, especially that you you are not even using it on the same language.

Bonus points here if you are managing something outside of your control like a mobile app.

1 more reply

j / k navigate · click thread line to collapse

0 comments

randomdata1y ago

If it works it works, but it does not come tradeoff free.

hansonkdOP1y ago

? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.

randomdata1y ago

1 more reply

realusername1y ago

I don't think it would hold true for very long, devs will have specific cases which will pile into the definitions.

That's why GraphQL examples usually focus on querying data from users and not how you are going to manage 10 different views of the same data.

hansonkdOP1y ago

> pile into the definitions

That is how REST works but is the opposite of the way GQL works.

realusername1y ago

With REST, the endpoints are team based if you have even a semi-competent CTO so you never have this problem, you just check who owns the controller and that's it.

With GQL though, good luck retracing who owns what field and what does it affect if you change the definition of what it returns, especially that you you are not even using it on the same language.

Bonus points here if you are managing something outside of your control like a mobile app.

1 more reply

j / k navigate · click thread line to collapse