Graphql.js: A Simple and Isomorphic GraphQL Client for JavaScript | Hacker News Reader

Graphql.js: A Simple and Isomorphic GraphQL Client for JavaScript

github.com

77 pointsfka25 comments

Good job on creating a lightweight client. Apollo can be overkill for smaller projects.

You should be careful with the name though because it's named the same as the official reference implementation of the backend: https://github.com/graphql/graphql-js.

Exactly! That's why I created this. Apollo is nice but too heavy for a simple query for small projects. graphql.js also, can scale big projects (I'm using it in a large project) since it has fragment collecting feature which makes your codebase manageable.

Nice project, and congratulations on release. Could you compare this to Apollo Client? What are some advantages and disadvantages?

It's actually just a query-builder and request tool to a GraphQL server. It's only 9kb. And it's agnostic, doesn't require any other package(s). Just download and use without any dependency. Apollo is a very dependent tool to make a simple HTTP request. According to Apollo, it has less features, but the most required and important ones.

Bravo! Despite the fact that it doesn't have caching built in, which isn't needed by everyone, I'm glad to see that the GraphQL ecosystem gets much richer by having alternatives to the fat libraries Apollo and Relay. Well done and thank you!

Thank you! As just you said, it's first aim is to be a lighter client alternative to Apollo and Relay.

Just deployed this to production. It was by far the best js client I found for my needs.

I would love to see some sort of mutation batching if that's not too far out of the scope of the project. Right now I'm just using a class to build mutations in bulk and send them across in a single POST.

Nice job. I'd also suggest picking a different name. Maybe a prefix before graphql or something like that.

I may pick a shorter name.

sigql?

Sounds like SIGKILL :')

When Javascript projects write "Isomorphic", what do they mean?

It certainly isn't isomorphic in the usual sense in Math of a bijection between structures (categories), because even if it were it is a special case of some kind.

Isomorphic in this context means the library supports running in Node.js as well as in the browser. (This is mentioned further down in the README).

I wondered about it too! From what I read, the term seems to be controversial in the webdev community:

> "From the beginning there were people opposing the term, suggesting alternatives such as monomorphic or polymorphic" [1]

As I understand it, when an SPA is "isomorphic", it means it can be statically pre-rendered to some degree. This property is then used as follows:

- you pre-render some html of your app server-side

- when a client requests a page, send the pre-rendered html first

- then, send over all your JS (React or whatever), which will take over the rendering when it's ready.

[2]

So "isomorphic" refers to some sort of behavioral equivalence, i.e. "you can run it server-side and you'll get the same output".

Painting with broad strokes, I guess you could interpret "this app is isomorphic" as shorthand for "this app can be pre-rendered into a static form that's isomorphic to its usual dynamic form" (in roughly the same way a pure function is isomorphic to a lookup table). In reality that property would probably be too strong for most cases, but I guess it's "morally correct".

---

[1] https://medium.com/@ghengeveld/isomorphism-vs-universal-java...

[2] https://en.m.wikipedia.org/wiki/Isomorphic_JavaScript#Mechan...

Simply, you can use "isomorphic" libraries both in browsers and Node.js.

I’m all for a lightweight GraphQL client, but does this do any client side caching? Query diffing? Query merging? To me those are the killer features enabled by GraphQL.

No, it can collect fragments (query building) and auto-declaration. when I add features it's not lightweight anymore :)

That's the trick, right? Building just the features you need while keeping it minimal. Alas, that lightweight feature set is going to be different for most people. I'd like an approach of several different libraries where you can easily bring your own. Relay is certainly not it and I haven't played with Apollo much to comment.

Actually you are right; priorities change for everyone. But to run with GraphQL main requirements were "build query and send to the server". And I created this library does it. But writing queries were problem and wasn't DRY enough, and I added fragment collecting feature which feels another requirement. Auto-declaration is also a feature to make it DRY. And I stopped adding features not to make it fat, but you can create a tool with caching, merging, etc. that uses graphql.js. I try to make it as lean as it can be.

When using AWS, the GraphQL client in AWS' Amplify library is also nice if one doesn't need offline/caching support.

I spent a good amount of time getting AWS AppSync to work with different GraphQL clients last week.

Looking forward to check out this one.

Thanks for sharing!

I hope you'll find this useful, if you have any problems please create an issue!

Since is lightweight, I guess it doesn't support transport batching, doesn't it? It's a must-have for me

Anyway, good job!

I think I can do it with few simple hacks, I'll definitely try to add that, thanks for recommendation!

I'll check it out then :)

Also, I'm new to hacker news but.. shouldn't you tag this as 'Show HN: ' ?

Reply on news.ycombinator.com