Hacker News Reader

Comment by ulkesh | Hacker News Reader

What’s really missing is that every single GraphQL tutorial glosses over the server. Sure there’s a chapter on it. A whole chapter.

There are no good articles on server best practices, how best to use ORM with it (especially as it relates to lazy loading), etc.

While we are going full board with GraphQL, we’re having to really fly by the seats of our collective pants because practical GraphQL serving is a far cry from idiomatic GraphQL. Some of us have more complicated applications than NEWHOPE, EMPIRE, and JEDI.

View on HN

This is a fantastic point!

Co-creator of How to GraphQL here. I’m very excited to tell you that we’re currently working on a new iteration of the page and content that will include more in-depth chapters about dataloaders, authentication, authorization and other advanced topics.

Would be great to hear more thoughts on which topics you’d like to see covered.

For me to even start thinking about GraphQL instead of REST, there needs to exist Java, .NET and C++ mature libraries for GraphQL at the same level of available REST ones.

Using JavaScript ones is not an option. So that is the kind of thing I would care about.

I would add Python and Go to that set of required, mature server-side libraries.

If there's solid libraries for each of the common languages used to write serverless code, then I think that'd be a big plus for decision makers who are on the fence about adopting GraphQL

Sure, I was only listing the ones from my toolbox. :)

I've yet to go beyond a cursory skim of graphql - but my first impression is that in the end you get to write your very own query planner/optimizer - with the "benefit" of optimizing across wildly different data stores like unifying a few different sql databases, a few filsystem graph/hierarchies of meta-data and a handful of semi-structured document stores in the form of json/soap services... So a lot harder than the already pretty hard problem of writing a query planner for "just" an rdms.

But I think there's something "there" - graph dbs, datomic, web prolog - they all seem to point to clients asking a "what" with the server figuring out the "how" [ed: and not in the least: whence (from where)] .

I think there are actually a few reasons for this that are addressable.

GraphQL clients cover a ton of the functionality—so much so that you're more concerned about the basic concerns you're already familiar with: doing stuff with your data.

The server has the inverse problem. A GraphQL server library covers the low-level part of breaking down the query into actionable slices, but how you resolve those is more of an open-ended problem. And because there's such a variety of ways you could be fetching that data, it's hard for the server library to steer the implementer in any one direction. Every server is going to be vastly different, while every client is going to use very similar patterns.

Very true. In our case, we resolve queries against some pretty old legacy SOAP/XML services, so topics like selectively loading fields from databases and dataloaders don’t enter into our equations.

I thinks it important to remember that GraphQL should form a very thin layer of an application stack. I gave a 4 hour intro lesson at my employer and the bulk of it was not GraphQL, but how we resolve GraphQL against our specific backend data sources.

> how best to use ORM with it

GraphQL is not about the server-side - that's an implementation detail and is orthogonal to GraphQL itself. I think it's important that we don't conflate ORMs with GraphQL just because an ORM can be used to simplify the server-side implementation (take a look at Graphene [1] or Prisma [2]).

[1] https://github.com/graphql-python/graphene [2] https://github.com/prismagraphql/prisma

I’m referring to the fact that if you don’t directly use the ORM models as the model being returned in the GraphQL response, and instead use a DTO, in order to not have to eagerly load everything you would have to deep inspect the GraphQL request selections to determine just how much data to load. I don’t find it quite as orthogonal as some.

> GraphQL is not about the server-side - that's an implementation detail and is orthogonal to GraphQL itself.

And yet. Somebody has to be there to parse GraphQL and turn those queries into database or other external calls--and do so efficiently--for a large/combinatoric number of potential variations of entity graphs.

Isn't that the same as REST? Using that stops at the controller for the request, and then it's up to the sever how it wants to fulfill requests for entities.

The difference is that REST is more opinionated on the server for what gets returned, and how it is returned. With GraphQL, that power is in the client request. And allowing the client to dictate the full scope of data to be loaded on the server can cause some problems depending on how complex the data model is.

This is why we are going to surface the more complex children of certain models as root queries instead. It’s considerably less than ideal from an idiomatic GraphQL point of view, but it’s much more practical. If data models are simpler, then GraphQL works great. Or if the data model is flat, it works great. Anything else and it’s not as cut and dry.

It's less a criticism of GraphQL-the-specification and more a matter of GraphQL-the-community failing to provide any reference implementation for the most basic of usecases--the 95+% of apps that use ORMs.

That said, GraphQL-the-spec does highlight a key ORM weakness--it's not so easy to dynamically construct complex join queries with decently-optimized fetch plans.

GraphQL seems only slightly more sensible than exposing your SQL interface to the internet.

Yes it makes sense from a client-side / front-end perspective, but that's because the server is just a [handwave]. Someone else's problem.

From a 3-tier architecture perspective, when I hear "GraphQL is better than REST", I immediately think middleware replacement.

Took me a minute to grok that this comparison implicitly depends on a Graph DB server.

If I were writing a book, I would probably start by explaining use cases where graphs are a better data structure... then advance to query concepts.

GraphQL is to expose data. REST to expose services.

Can you explain the difference?

I’ve written many RESTlike APIs (no hypermedia) and they mostly returned data. In fact, the whole premise is to be able to access resources which typically boils down to some data model response.

Disclaimer: I come from the Semantic Web area. Where the client language is SPARQL, and the (graph) database is exposed publicly and understands SPARQL. The data are exchanged in RDF (a kind of JSON for graph data).

A SPARQL query can federate data from several SPARQL endpoints (this is all the point of the LinkedData movement).

So we have NO additional layers between the DB and the client (except for some security features, and query throttling)

This is a simple pattern that makes data access trivial. (if you manage to store your data in such a graph database, which is NOT trivial)

As far as I understand, if you follow a similar philosophy, then GraphQL will shine too (especially because the tooling on the client-side is infinitely superior with GraphQL, than it is with SPARQL).

But the more I read this HN thread, the more it seems GraphQL is used for service integration. And that is a completely different problem.

So, I feel like data access with GraphQL is super nice. (especially if you use best practices for your data, like in the LinkedData principles) But service integration sounds yet another hell. (because services are rarely designed to be properly integrated together).

I completely understand now where you’re coming from. Thing is, we’re taking an existing data model that has REST in front of it (a layer or two up), and trying to instead use GraphQL. I think, though anecdotal for me, that this is the more typical use case since most won’t be able to re-engineer the database to be more conducive to GraphQL.

And I think this now makes some sense as to why there is hardly any documentation with respect to practical GraphQL and ORM (in the vein of Spring Boot and Hibernate for us old Java folk).

Thanks for the explanation!

Reply on news.ycombinator.com