(https://thepracticaldev.s3.amazonaws.com/i/712x78426cyq8kj5ab3c.png)
title: "I made a fetch-wrapper for making graphql api calls!"
published: false
description: "An overview of a fetch-wrapper for making graphql queries that I built."
tags: graphql, javascript, node, fetch
The other day, I was playing around with GraphQL queries for a side-project that I'm building, when I realized that eventually - I'm gonna need to make calls to that API on the client-side. My first instinct was to look around for a way to do it using fetch, because I love the fetch API. However the way to do it using fetch is kinda gross, if I'm being honest. The first answer I found on stack overflow, showed it like this:
note that, for the examples, an example API that I created is used
fetch('https://csb-xpwq1o2824-xravvsjkul.now.sh/', {
method: "POST",
body: JSON.stringify({query: "query {items{title}}"})
})
Now, that's pretty nasty-looking. You could make it better with some variables, maybe a template string, something like this:
const url = "https://csb-xpwq1o2824-xravvsjkul.now.sh/";
const query = {
query: `
query{
items{
title
}
}
`
}
const body = JSON.stringify(query);
fetch(url, {
method: "POST",
body
})
Now while that may look satisfying, it didn't feel like a healthy-enough balance between the feel of fetch, and graphql. So I created a function that did just that for me. I realized how useful this could be to other developers, so I wrapped it up in an npm module, and published it. I call it jraph
, and it works like this and thanks to a comment from @qm3ster
, it now works like this:
import { jraph } from "jraph";
let jql = jraph(
"https://csb-xpwq1o2824-xravvsjkul.now.sh/",
{
method: "POST"
}
);
let result =
jql`{
items{
title
info
}
}`
I making a major update to the syntax that I think that graphql fans of the world will love.
If you like it, you can check it out on npm, here!
Have a great day guys!
Top comments (2)
It would be more concise to take these non-optional parameters as arguments:
jraph(url, query[, {...options}])
:But, I feel like taking
(url)(query)
would be more ergonomic, for reuse:Maybe return a Template Tag?
That’s actually exactly what I was planning to do. I’m glad i got some positive feedback on that kind of syntax. I’ll publish the new syntax tomorrow!