Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principled GraphQL

principledgraphql.com

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Principled GraphQL

#71

Post by orta »

debergalis wrote: post #21
pseudoramble wrote: post #6

One question I have is with the "One Graph" idea. I get the principle, and it does seem like it would be nice. However, it's hard for me to imagine what this looks like in practice. I haven't done anything with GraphQL in a few years. But when I did, we basically had several teams in a part of our organization (one of many in a huge giant megacorp) which built an API with GraphQL. We shared that code base and did the…

[author here] > So assuming what we did wasn't good, what is a way you might make this work? Do you have a single code base like we did and just be more disciplined? Do you have a project whose job is to stitch together other schemas and pull in submodules? A monorepo for the entire company? Do you actually limit what the idea of the company is at some point to limit what the scope is that this should cover? I think…

We do this at Artsy in production too, here's an overview of how it works for us: http://artsy.github.io/blog/2018/12/11/GraphQL-Stitching/

Re: Principled GraphQL

#72

Post by thanatropism »

jonahx wrote: post #36
thanatropism wrote: post #17

Earlier quoted context omitted.

That's the general argument for key value storage versus normalized relational databases as well.

Can you elaborate on that?

On a second reflection I may have oversimplified your point.

There's this trade off between having logically structured databases and having data stores that are faster to access. An all-too-superficial scan saw your point as just an iteration of that, which it may not be.

The word "graph" itself might have a different meaning than in mathematics. Of course something like wikidata is a directed multigraph (or a tuple of incidence relations on the same nodes). Still I was under the impression that you were talking about optimizing data stores for access at the cost of having to explicitly maintain consistence in your code and not be able to rely on the database properties themselves -- like what happens when you move from SQL to Mongo.

Re: Principled GraphQL

#73

Post by danpalmer »

samblr wrote: post #56

Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I see it's advantages of having auto-documentation for each API. Thumbs up here. Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and-server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn i…

> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.

I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations.

If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.

Re: Principled GraphQL

#74

Post by lsjroberts »

We've been working on doing something similar to create "one graph" at my job (though using our own library instead of graphql [1]).

There are definite difficulties to doing this, you need some strong cohesion between teams. If you try to do it in an agile manner, you're going to end up with a lot of duplication with minor differences. You'd need a way to flag existing similar data when trying to add new branches and nodes.

Our hope is to make our graph explorable and interactive so teams we don't have direct contact with, often in other countries, are able to find the data they would be interested in and see immediately how to read it out.

[1] https://dwstech.github.io/muster/

Re: Principled GraphQL

#75

Post by spiritcat »

danpalmer wrote: post #73
samblr wrote: post #56

Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I see it's advantages of having auto-documentation for each API. Thumbs up here. Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and-server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn i…

> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations. If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.

"If you just want JSON over HTTP with some status codes"

yes this

Qualifier: have not been able to use graphql yet, and I'd still like to try it out at least before making and judgements

Re: Principled GraphQL

#76

Post by DownGoat »

topspin wrote: post #38

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected. I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing so…

It depends on your needs, on the server side you are probably not missing much. Apollo tracing might be nice if you want some statistics on how your graph is consumed.

The client side depends on the client, we have a Angular SPA that extensively uses Apollo Client together with some code generation tools. The benefits we see from this are:

* The whole schema is automatically defined in frontend, so it is easy to keep types in sync between frontend and backend. * .gql files are scanned, so services that consumes the queries/mutations are automatically generated with correct typing. * The Apollo Client cache makes it easier keep the data updated across different components.

This greatly reduces the boilerplate code our developers have to create, and it makes it much easier to share type definitions from backend to frontend without having to worry about them getting out of sync. We are still exploring different tools, to see what we might benefit from.

Re: Principled GraphQL

#77

Post by PaulHoule »

mhuffman wrote: post #42
PaulHoule wrote: post #22

Earlier quoted context omitted.

How about having N base graphs and the ability to make unions of the graphs, as well as other kinds of algebra. It is relatively easy to do this in the RDF world since the graph is composed of individual facts which may or may not be in a particular graph.

Which triplestore are you using that gives great front-end performance at load?

None of them are really "great". I get acceptable results with OpenLink Virtuoso if I give it a lot of RAM, tweak the configuration, and baby it when needed.

Re: Principled GraphQL

#78

Post by samblr »

danpalmer wrote: post #73
samblr wrote: post #56

Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I see it's advantages of having auto-documentation for each API. Thumbs up here. Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and-server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn i…

> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations. If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.

If only Facebook was not behind GraphQL - this would have faded to oblivion (RIP Parse)

The innumerable patches/packages trying to fix what GraphQL lacks - goes to show it's a good idea at surface level yet poorly thought out from ground up.

Re: Principled GraphQL

#79

Post by danpalmer »

spiritcat wrote: post #75
danpalmer wrote: post #73

Earlier quoted context omitted.

> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST. I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations. If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.

"If you just want JSON over HTTP with some status codes" yes this Qualifier: have not been able to use graphql yet, and I'd still like to try it out at least before making and judgements

GraphQL costs a lot more to do, but also gives you a lot more.

Just some benefits we've seen:

- Automatic codegen in the client removes a lot of boilerplate.

- Verification of schemas in CI makes sure we don't "go backwards" on the API inadvertently.

- Documentation tooling that makes it easy to show API structure.

- Easy to generate schemas automatically from underlying data models in the backend service (database tables, ORM models, enums, etc).

- Great type safety compared to JSON over HTTP.

Re: Principled GraphQL

#80

Post by danpalmer »

vanwalj wrote: post #68

We should probably add another point which is "you probably don't need Apollo tools". I'm using GraphQL in production since 2015 and I feel like the only Apollo contribution to the ecosystem was pushing lot of marketing content around their hacky tools and "best practices", leading teams to poorly designed backends.

Yeah, I haven't seen a lot that has been particularly useful from Apollo so far.

They supposedly have a slightly different recommended way of doing the things Relay tries to do, but it's poorly documented and only compatible with Apollo, whereas the Relay spec is relatively clear (just the spec, I haven't used the Relay library).

Also they seem entirely JS focused. Our backend is Python and our frontend so far is Swift. They have no Python tooling, and their Swift codegen has a lot of issues, our iOS devs use it pretty reluctantly and replace a lot of parts of it, and even that tooling is all in JS, not Swift, which means our iOS builds suddenly need Node, Yarn, NPM, etc, a whole load more complexity, caching, and so on.

Post reply on HN