Fork me on GitHub

So, I'm wondering how people handles HTTP status codes when using pathom. I'm using pedestal so I found some that just always returns 200s. Is this a common practice in Pathom/GraphQL? For example, under certain auth conditions I'd like to return a 401 with a bit of info about the error.


@franquito in a #fulcro app, your communication with the server is via EQL, "not via HTTP" HTTP will return 200 always that "the EQL request has been processed" if your EQL Query has a not allowed access, you will return a 200 with a response that contains that "not allowed" message. But it's nothing about #pathom , it's more about "how we develop SPA in 2020" I use #pathom to deliver a REST API, returning different codes for each request


I see. I'm using re-frame only with the POST /api endpoint now (that's the basic implementation I've seen in the wild). Now I'm looking to add JWT to the mix, which means setting headers. In this REST API you reify the status codes in Pathom? For example, a resolver or a mutation may return a :response/status and you use that with the HTTP server?


@franquito a bit of my opinion When you send a query with a mutation with a mutation, if the mutation run¹, it will return 200. It say nothing about success/fail of the mutaion. it says about the success of execution of the query IMHO, the mutation should return something like {my/mutation {:fail {:msg "can't because x" :some-explain {}}}} ¹ - mutation run: (parser env tx) => map? not trow


But it's a open system. #fulcro is just one impl. My current pathom usage is a SSR app where I usa "raw" HTML form's to create POST's and programmatically turn these POST's into an EQL tx, return 303 -> Location and get a new page (rended by hiccup) I all "EQL tx" a "query that contains a mutation"


Crap, I'm still very confused :thinking_face: but I get your idea of 200s expressing a successful execution. The biggest question is how much of your system you end up representing with the keywords. I think I need more hammock time here, thank you for the helpful thoughts Enzzo!


Thinking about "network stack": Your HTTP server do not send a TCP ACK when your application fails, it send's a TCP OK with a HTTP FAIL Your EQL server do not send 400 when the mutation fails, it send a HTTP OK with a ::p/errors


released [com.wsscode/pathom "2.3.0-alpha19"], this gives a fixes a problem with the jar, that previously included the compiled js data, the jar is reduced from 9.1MB to 103kb

👍 27