Hacker News Reader

Comment by cercatrova | Hacker News Reader

Any ORM will handle getting data with joins just fine when it constructs the SQL. Or you can write your own SQL with joins to pass along to the query.

If you mean GraphQL doesn't have joins, I'm not sure in what use case that would matter when you're declaratively asking the server for some data, not hand constructing SQL. What would you need joins in? You mean like this example [0]?

[0] https://stackoverflow.com/questions/51805890/how-to-do-a-sim...

View on HN

Right so, again, what exactly is the purpose of graphql?

It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism.

What can graphql do that an ORM can’t?

You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.)

You can then implement a server which, given a GraphQL query, turns it into the data that's expected. The client doesn't care how you implement that. You can write raw SQL, use an ORM, whatever. Since people don't want to reinvent the wheel they use libraries like Apollo Server, but again you can do it all by hand if you really want to.

Have you actually used GraphQL? This is all explained within the first 15 minutes of any GraphQL tutorial.

So if front-end devs get everything they need client side, what’s the point of having backend devs?

https://imgflip.com/i/6u4obk

SPAs and REST APIs moved a lot of the complexity around data to the client side. GraphQL moved it back to the server side. I think that's a reasonable decision, as the client - compared to the server - runs in a much more unpredictable environment. Of course some backend devs complain about more work, especially work that could be moved to the client side at first. Making things the proper way is hard, yes.

The backend still needs to implement the endpoints for the frontend? Not sure what you mean, if anything the backend work increases because everything is done on the backend now.

And did you really link me to a meme you made specifically for this conversation?

The pitch I remember back when it first was released was that GraphQL was meant for development, when the API was still changing a lot, and was supposed to be replaced with dedicated API calls before going to production. During development frontend devs has something flexible they could use without pestering the backend constantly, then the dedicated non-GraphQL production version would be stable and could be significantly more optimized than the GraphQL version.

> If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.

Obligatory note: this really is just supposed to be REST. GraphQL seems to be the final expression of throwing in the towel on REST's original capabilities.

As such it's not clear of it's a step forward (REST as it should be) or a step back (let's just use a crippled SQL and ship)

Reply on news.ycombinator.com