@slipset Yea, that's the purpose. Why do you think REST is the wrong approach for this use case?

@rgb.ide Because a SPA is basically doing two things: It’s querying a database (through a proxy which is your backend). GraphQl and it’s likes are bette at this than vanilla REST. GraphQl lets the client decide the shape of the data it needs and also lets the client request all the data it needs in one request, avoiding the n + 1 problem. https://secure.phabricator.com/book/phabcontrib/article/n_plus_one/

The other thing it’s doing is issuing commands. Yes you can do this with REST, but I think you’ll see over the course of time that by thinking in terms of commands, the vocabulary of your system will appear. IMO REST mutability in REST is about mutating resources. When you need to mutate several resources in a transaction, REST is not a good fit.

The stupidest example, which can be refuted easily is “transfer funds between two accounts”

How do you do this in REST? I’d probably do

POST /transfer/:from-acount/to/:to-account/:amount

Which is just a very convoluted way of doing:

POST /do-it
{:command :transfer-funds
  :from-account ...
  :to-account ...
  :amount ...}

If you adopt this pattern implementing new commands on the backend is just a matter of adding another defmethod to your (defmulti execute :command)

And it becomes quite clear what your application is about, since you’ve now enumerated all the commands available as implementations of the execute function.

standard GraphQL has a huge problem with N+1, unless you add dataloader

What it is good at is giving frontend flexibility.

With a well-designed schema you have a huge potential for data exploration.

It’s especially beneficial when your schema grows and your entity graph is densely interconnected.

Here’s a list of publicly available APIs, have a play and see for yourself. https://github.com/APIs-guru/graphql-apis

(Happy to talk more about specifics when you have questions, I’ve been working on a graphql backend serving a huge graph from multiple datasources for the last 2 years)

@lady3janepl just so I understand. I was referring to n+1 between client and API, and that’s the n+1 problem I see GraphQL solving.

What happens on the server wrt n+1 is a different problem 🙂

well, the location of the problem basically moves from client to API.

Then we agree.

I’ve seen people are unaware about n+1 within the server, adopt the technology and get confused when they hit performance problems; so I wanted to make that specific.

We’ve ended up with a bunch of ad-hoc aggregated REST-endpoints to “fix” the n+1 between client and server. Doesn’t really scale all that well.

All the companies that used it heavily that I know of had their own server implementation (that was not dataloader)

And yes, we have a bunch of n+1 problems on the server because we’ve composed our “fetch n things” out of a bunch of “fetch 1 thing”.

Facebook has TAO, shopify (I think) has something of their own as well although it’s more publicised.

One thing you can do in that case (if you want a quick solution to improving performance, and if you don’t want to faff with batching through dataloader) is log queries and check which ones come from your downstream(s) the most, and build in optimised solutions for those ones in particular. It’s a “discovery” approach similar to how public planning discovers where to put down asphalt pedestrian paths: check where people walk often enough to create visible tracks and then put a path there.

Is that how most people do it, or are solutions like join-monster better suited to solve the n+1 problem b/w the server and the DB? (Assuming its a SQL DB)

Or pathom + walkable in the clojure world.

But the last I've seen walkable still does table joins on the server.

As with everything in programming, I doubt there’s a good answer to how most people do it because it’s hard to know what goes on in closed projects 🙂 What I outlined above is a quick and universal solution.

I’d strongly caution against using anything that ties your graphql schema too tightly to your sql schema, or that generates graphql from sql.

(And I don’t have much experience with join monster because I’m stitching disparate data sources in different kinds of stores)

Perhaps d2q will solve it: https://github.com/vvvvalvalval/d2q

README sounds promising. Haven't checked it out still.

hm… I have to prod around it some more

(if you’re interested in graph data specifically, you can also take a look at gremlin, but now we’ve drifted far off from the question of whether to REST or not)

(and also: for some uses REST is still best.)