Fork me on GitHub
#off-topic
<
2019-08-10
>
Ahmed Hassan14:08:18

How do you decide if we need either REST API or EQL/Pathom (or say GraphQL based solution like Lacinia, Apollo, Relay) for any particular kind of problem? Both for frontend and backend.

gklijs15:08:32

It depends, in my experience there was not really a choice, because they did not want to use GraphQL. If it's the same team building the API as using it, and the API is not used by anything else it's just up to the team I guess. I really like GraphQL for having just one endpoint and being able to inspect the actual schema. Subscriptions are a nice way to keep clients up to date, with REST you need to polling to get something similar.

👍 4
Ahmed Hassan17:08:46

Is it about Graph Based query language (which includes EQL) or specifically about GraphQL(TM)? because Fulcro is based on EQL. Which uses Pathom for parsing EQL.

myguidingstar18:08:22

@UCMNZLJ93 if the decision involves choosing client side tech (ie Fulcro vs re-frame or anything else), then Fulcro saves you from lots of time fighting distracting http statuses and error handling. However, learning Fulcro takes time so it will only shine when the problem is complex enough (so its benefits exceeds the cost of learning)

👍 4
vemv22:08:04

I find the existence of https://www.apollographql.com/docs/platform/operation-registry/ funny/telling. If a graphql best-practice is to offer a finite set of endpoints, why not do them traditionally (REST) in the first place? 'Traditionally' doen't have to mean laborious. Clojure is extremely well-suited for authoring data-driven backends, where having N versions of essentially the same endpoint should be trivial. https://github.com/cognitect-labs/vase might be considered a state-of-the-art way of doing REST. Probably there are a few other ways in which adding more endpoints scales nicely in terms of maintainability.

👍 4
gklijs22:08:43

The nice thing of GraphQL in that respect is that you can add fields and it will be fully backwards compatible. While with REST you get different responses back which might break clients. I think ideally when working with GraphQL you just have one endpoint. Where it's possible to stitch schemas together, and/or get past if the information by REST. Another big difference is in error reporting. With REST this is often done by using the appropriate HTTP code, with GraphQL it's always 200, and the error could be 'hidden' in the response.

👍 4
Ahmed Hassan06:08:38

For doing REST there is also Yada https://github.com/juxt/yada library. It's built to take complete advantage of REST and HTTP.

helios15:08:58

Personally the choice also depends on the type of data and what shapes it does have. If it's shaped like a graph and edge traversal is something you think is relevant, GraphQL might be a good choice. But I have seen people use graphQL where a couple of well written REST endpoint would have been more than sufficient

slipset11:08:55

I’d be as blunt as to say that if you’re building an api to support a SPA, you need two end points. One for querying data, and one for issuing commands which alter data.

slipset11:08:06

REST is a bad choice, especially for altering data, since you are led to implement stuff in terms of generic CUD operations which hinders you from developing a domain language.

slipset11:08:41

Generic CUD operations are suited for communications with the database, not as an interface to your api.

Ahmed Hassan11:08:47

Fulcro does both querying and mutation with single endpoint.

slipset11:08:00

even better 🙂

vemv11:08:23

> REST is a bad choice, especially for altering data, since you are led to implement stuff in terms of generic CUD operations which hinders you from developing a domain language. not really. genericity and REST are unrelated concerns, if you are used to conflate them (or to see them conflated) that's just your personal experience

slipset11:08:53

I’d beg to disagree 🙂

slipset11:08:47

given GET /user/:id, it is expected that you also have a PUT /user/:id

gklijs11:08:18

With GraphQL you can have a subscription that does a mutation, so you can get feedback as soon as the command is handled.

vemv11:08:19

REST is a whole spectrum of practices. You'll have people doing a basic best-effort rest-y thing, and you'll have HATEOAS advocates... and some pragmatic choices in the middle

Ahmed Hassan11:08:30

>given GET /user/:id, it is expected that you also have a PUT /user/:id I think this expectation depends on nature of resource and decision of owner of resource if he wants to provide PUT operation for it.

slipset11:08:25

I was speaking in the context of an SPA, where I would assume that you’d want to be able to update a user in some way.

👍 4
slipset11:08:39

The problem that I see with a generic update of user (which you could easily implement in a command interface as well) is that you take away context.

slipset11:08:46

There are several things you might want to do with a user, all which may end up in an update, but there might be different business rules attached to these things.

slipset11:08:21

Which means that when the backend receives an update on a user, it has to try to divine what the intent was instead of being told what it was.

vemv11:08:20

> The problem that I see with a generic update of user (which you could easily implement in a command interface as well) is that you take away context. Agreed, but it's not uncommon at all to have multiple REST update endpoints for a user. As said, this is a separate concern from REST. Having a sense of design / good engineering is impl-agnostic

👍 4