Hey all!
I am working on a graphql client based off hiccup-like data structures, calling it hql, for lack of a better name.
I think I have the “syntax” & transpiling to GraphQL queries are more/less completed. I think it is promising direction, given the library aims to be “closer to the metal” and tries stay true to how GraphQL queries look outside hiccup.
Still need to add support for cljs, as well as actual graphql over http clients.
Would appreciate any feedback or thoughts! 
I took a look at the code. It’s really clean and the tests are nicely done. some thoughts:
what do you mean by this?
Hey, thanks for taking the time to look over the code 
Those are great questions!
From a validation perspective, I do think so. I’d prefer to fail if the data doesn’t conform to what is expected. This would mainly manifest if a map was provided vs vectors, however, still is helpful.
Additionally, the runtime performance hit isn’t significant.
I had no idea venia existed. Tried to google “Clojure GraphQL Client” before I started on this, and it didn’t come up on my search results. Thanks for sending it along!
Most of the libraries I have come across only deal w/ parsing hiccup to graphql queries, leaving http client implementation up to the consumer of the library.
I would like a tighter integration, meaning that the hql library will provide a query function which performs “graphql over http”. Additionally, in order for the client API to be unified (and more Clojure-y), I am planning on the responses (either via queries, mutations or subscritpions) to communicate their results via clojure.core.async channels, which I haven’t seen much in the wild (though I may be prey to the search issue above).
It may be more pain than its worth to include clients which can handle queries/subscriptions in hql, but I’d like to try it out and see how it plays.
To be honest, I don’t really think the http thing is anything special. They are encoding something that everyone is doing already. The first question to ask is: do you need it?
What would be cool if you can provide a parser from GraphQL to hiccup and back.
Another thing would tight integration with a relational schema library for generating the graphs to then do actual sql generation.
Valid criticism & good question.
As far as the question of needing it, I think it depends. I have seen comments/issues raised on libraries both in clojure and out of it that critique either a “too much” approach or “too little”.
In this instance, while it may not be intrinsically needed, I would rather explore having a library/client which is homogeneous and can be extended/built upon, rather than leaving that as an exercise for a consumer of hql.
Those would be cool, and at the very least, a GraphQL → hiccup parser would be in scope for a project like this, albeit down the road.
I think you are a really great coder but I don’t think you understand WHY graphql is popular.
GraphQL spread because of Apollo and the way they do frontend caching, subscriptions and a bunch of stuff that is hard as hell, not to mention the sql transformations on the backend. That’s it. It’s not the specification itself or how you transform/transmit the query, it’s the underlying technology that makes it magic.
So to be perfectly honest, what you’ve done is pretty useless from a production standpoint when talking in terms of the graphql ecosystem. It may be a good tool to generate some pre-cached queries, but that’s about it.
Respectfully, that is quite the presumption, and not correct. There are many reasons for its popularity, some of which you have touched on some. I order to stay on topic here, I’ll not delve into my convictions on the technology.
I think this is getting off track. The fact is this library was put together in a couple days over a couple of weeks in order to tease out the hiccup syntax/idioms, not implement a full clj(s) framework. Getting feedback on the syntax/idioms was my main intention of this post, and what I am eager to collaborate on if anyone had feedback/other perspectives.
I have not claimed this is “production ready”, I have not claimed more than it is an early stage library. Even the whole http client/transport layer isn’t even implemented.
I don’t have a desire to continue our back and forth, as you’ve made you points clear. Therefore, I consider our exchange over.
look, I just think you’re being a bit disingenuous about wanting feedback. I’ve given you my feedback. You’re looking for praise.
You’re a great coder but I’m not that impressed with the library.
Not in the slightest, and is again very presumptuous. As I’ve said, I appreciate your input, and from my perspective you’ve made your points clear.
I appreciate the compliment, but that is not what this thread is about.
I know you’re not impressed, and again, that is not what I was looking for. I appreciate your bluntness, but there is no need for re-iteration on that point. You’ve made it very clear what features you’d expect out of a library/tool in the GraphQL ecosystem.
My earlier query still stands:
If you have feedback with respect to above, I am happy to hear you out!
from the actual query, I would not use meta tags for mutations, subscriptions, etc as you want that to be explicit.
My issue is that there is no way to typecheck or prove that you have a correct query. So what are you going to do? Use spec on a relational model?
Also, it’s perfectly valid to describe a graph structure in json instead of graphql making the whole convention pretty useless.
Who are you interfacing with? would the consumer be at the ui side or the server side? These questions all go beyond the scope of what you’re asking for so feel free to ignore it. I’m not convinced by such a limited scope and if I’m not convinced I’m going to see this as just educational exercise, which is okay too.