4 ms·

What are you implying?

• cratermoon 6y ago
  I appreciate your question and thought it deserved some thought time, in contrast to my initial off-the-cuff comment. I had difficulty putting it into words, but today I was reading another article posted here on HN and it cut to the heart of the problem: https://macwright.com/2021/01/15/rust.html https://macwright.com/2021/01/15/rust.html "GraphQL basically lets your frontend application define queries, instead of the backend. You give it a range of things it could query, and the application - React or something else - sends arbitrary queries to the backend. This makes things hard for the backend. Any sort of SQL-level optimization is impossible - your server is writing dynamic SQL, so you rely on the intelligence of your GraphQL server, which is not always high. Juniper, for example: n+1 queries by default. The workaround - a dataloader - is rough and independently maintained. So at the end of the day, you’re going to have a blisteringly-fast application layer that’s spending all of its time inefficiently querying your database." This is the data coupling problem, allowing the front end to see and arbitrarily query the data model. Yes, you can put a great deal of effort into optimizing the GraphQL server, but then you've just introduced middleware again, and at that point it's hard to see what the GraphQL protocol has over REST.