This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # beginners (111)
- # calva (12)
- # cider (10)
- # cljdoc (1)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (38)
- # clojure-houston (1)
- # clojure-serbia (3)
- # clojure-spec (22)
- # clojure-uk (26)
- # clojurescript (4)
- # cursive (1)
- # data-science (1)
- # datomic (12)
- # klipse (1)
- # off-topic (28)
- # pathom (9)
- # protorepl (3)
- # quil (4)
- # shadow-cljs (43)
- # tools-deps (24)
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.
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.
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.
the gist I've heard from people who do graphql is that it shines in two specific areas: 1) you have many different clients with different data needs, 2) you have few clients with vastly different data needs.
it's a lot simpler to just return all the data they might need, and rest can cache extremely heavily, so balance your trade-offs
sometimes returning all the data they might need is impossible, of course, which is another trade-off. make them do multiple requests or add a graphql api where maintenance is harder
@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)
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.
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.
For doing REST there is also Yada https://github.com/juxt/yada library. It's built to take complete advantage of REST and HTTP.
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
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.
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.
Generic CUD operations are suited for communications with the database, not as an interface to your api.
> 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
With GraphQL you can have a subscription that does a mutation, so you can get feedback as soon as the command is handled.
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
GET /user/:id, it is expected that you also have a
I think this expectation depends on nature of resource and decision of owner of resource if he wants to provide
PUT operation for it.
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.
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.
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.
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.
> 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