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

Thoughts on RethinkDB and GraphQL

github.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Thoughts on RethinkDB and GraphQL

#21

Post by lobster_johnson »

carterehsmith wrote: post #16
rspeer wrote: post #7

Baking Facebook's graph representation into a database sounds like the worst kind of database bloat. Worse than when Riak decided they needed "MapReduce" on their feature checklist, then warned developers to "Use MapReduce sparingly" because it kills your availability. Graph technologies change all the time. Almost nobody will be using GraphQL in 2020, just like almost nobody is using 2010's graph representations in…

To be fair, GraphQL is, just like SQL, a query language, it specifies "what" the client wants, not "how". There is no "baking in the database". Which means, the server can use SQL or NoSQL or graph or XML database, or LocalStorage or any combination of them, to provide a response to a query -- it does not matter, long as the response is there. This client-server separation setup has been around for some decades, and…

GraphQL is not a query language at all. It's an API-building DSL. It's analogue isn't SQL, it's REST. Or WSDL + SOAP.

It does not have things like filtering, ordering, subqueries, etc. -- you can implement those things, but that would be just one possible implementation, specific to your data model. You wouldn't be able to point just any GraphQL client at it; the client has to know what to ask for, and how.

Re: Thoughts on RethinkDB and GraphQL

#22

Post by jmgrosen »

egor83 wrote: post #20
antirez wrote: post #5

Earlier quoted context omitted.

The commenters are great, so they provide a discussion that makes sense, but is a wall of comments one after the other. It is possibly the most primitive way to interact, compared to something like Reddit comments with collassable threads, votes, and so forth.

> something like Reddit comments with collassable threads There are ways to add it here on HN with extensions. I'm using "hckr news" myself: https://chrome.google.com/webstore/detail/hckr-news/mnlaodle... Then there is "HN Enhancement Suite" with more users and more functionality: https://chrome.google.com/webstore/detail/hacker-news-enhanc...

I believe he meant the GitHub thread, though those are still useful extensions (for Chrome users...).

Re: Thoughts on RethinkDB and GraphQL

#23

Post by lobster_johnson »

schrockn wrote: post #18
phpnode wrote: post #8

Earlier quoted context omitted.

GraphQL is almost totally unrelated to graphs, it's a way to compose API requests in a manner that fits modern web / mobile usage patterns better than REST. GraphQL has nothing to do with the actual representation of the data. I think the name has led to a lot of misconceptions.

Hi I'm Nick Schrock and I actually came up with the name. Graph in this context means social graph or more generally the conceptual graph of data in your application, which you can query. It doesn't mean that it is a formalized graph database in any sort of way, nor does it seek to be. I understand the name causes a bit of confusion but the ship has kind of sailed on this one :-) I think people will get used to it if…

Ironically, the "query language" part also misses the mark, and I think that part confuses people more (as in that RethinkDB discussion).

GraphQL is closer to what we call a protocol; it has minimal syntax, a kind of data model, and it can only be used for declaring requests. You can't implement anything in GraphQL: absolutely all of its expressions are implementation-provided — contrast with, say, SQL, which, being an actual query language, defines operators, arithmetic expressions, mutations, etc. A defining quality of a protocol is that it's a medium through which clients can talk to multiple black-box implementations, which is exactly what GraphQL is.

I like GraphQL, but I wish you'd thought through the name before you started to publish about it. If you'd called it something like Extensible API Protocol, nobody would have batted an eyelid.

Re: Thoughts on RethinkDB and GraphQL

#24

Post by TheAceOfHearts »

I've been playing around with GraphQL and Relay recently. Initially I was using PostgreSQL, but I was using an ORM which made implementing pagination annoying.

Previously I had played around with RethinkDB, so I decided to give it a shot with GraphQL. It actually works out really nicely, you can do an almost 1:1 copy of the cursor helpers available in graphql-relay-js using ReQL.

I think the biggest pain-point for me has been having to dig in through all the source code, since there's not much documentation and examples available. Although, there's a ton of inline comments and type definition which has made it palatable.

As a related aside, I was researching what people had done and found a discussion surrounding GraphQL and ArangoDB [0], which may be of interest to other readers.

[0] https://github.com/arangodb/arangodb/issues/1468

Re: Thoughts on RethinkDB and GraphQL

#25

Post by possibleNoob »

jondubois wrote: post #13

I read somewhere that they're trying to add realtime support to GraphQL, but the problem which GraphQL solves is only an issue if you use HTTP as a transport. If you use a pub/sub realtime layer on the frontend, you don't need all the complexity which GraphQL introduces - You can make each component bind itself to a pub/sub channel which publishes changes to the resource which that component is interested in. It's a…

This is interesting. Do you have an example or perhaps a library i can look more into? Would this work with phoenix channels?

Re: Thoughts on RethinkDB and GraphQL

#26

Post by phpnode »

schrockn wrote: post #18
phpnode wrote: post #8

Earlier quoted context omitted.

GraphQL is almost totally unrelated to graphs, it's a way to compose API requests in a manner that fits modern web / mobile usage patterns better than REST. GraphQL has nothing to do with the actual representation of the data. I think the name has led to a lot of misconceptions.

Hi I'm Nick Schrock and I actually came up with the name. Graph in this context means social graph or more generally the conceptual graph of data in your application, which you can query. It doesn't mean that it is a formalized graph database in any sort of way, nor does it seek to be. I understand the name causes a bit of confusion but the ship has kind of sailed on this one :-) I think people will get used to it if…

I'm sure you're right because you have the power of facebook behind you but yeah the name is problematic. I agree with lobster_johnson in that it's not a "query language" either, it's more like an analogue of JSON.

Virtually every graph database vendor now gets requests that they implement GraphQL, because from the name it sounds like it fits but in reality it's totally unrelated.

Re: Thoughts on RethinkDB and GraphQL

#27

Post by sanderjd »

ori_b wrote: post #17
sanderjd wrote: post #10

Earlier quoted context omitted.

Agreed. It's a trade-off – threading leads to repetition and/or references to already-mentioned ideas. The more truly linear a conversation is, the better Github's style is, and the more a discussion splits into multiple independent conversations, the better the threading style is. Unfortunately, you can't know a priori which kind of discussion it will be, and most discussions are a hybrid. Personally, I find a linea…

Here's the wonderful thing about email and nntp: It provides a list of backlinks, and it's up to clients to decide to render it in the form of either backlinks and mentions, or in the form of threads, instead of forcing the choice on you.

That sounds very nice in theory, but in practice I've never seen an implementation that is as easy (for me!) to follow as Github's or Discourse's linear flow. Links to the great implementations that I've missed are very welcome!

Re: Thoughts on RethinkDB and GraphQL

#28

Post by ori_b »

sanderjd wrote: post #27
ori_b wrote: post #17

Earlier quoted context omitted.

Here's the wonderful thing about email and nntp: It provides a list of backlinks, and it's up to clients to decide to render it in the form of either backlinks and mentions, or in the form of threads, instead of forcing the choice on you.

That sounds very nice in theory, but in practice I've never seen an implementation that is as easy (for me!) to follow as Github's or Discourse's linear flow. Links to the great implementations that I've missed are very welcome!

I have no idea what you find easy to follow -- I have no idea what's going on in a typical Github or Discourse thread. Gmail is also pretty confusing.

Re: Thoughts on RethinkDB and GraphQL

#29

Post by hinkley »

jondubois wrote: post #13

I read somewhere that they're trying to add realtime support to GraphQL, but the problem which GraphQL solves is only an issue if you use HTTP as a transport. If you use a pub/sub realtime layer on the frontend, you don't need all the complexity which GraphQL introduces - You can make each component bind itself to a pub/sub channel which publishes changes to the resource which that component is interested in. It's a…

I always figured that a pub/sub implementation at the database (instead of the application layer) would shine brightest in infrastructure and reporting situations.

Yes, there are a million ways to arrange for my landing page to 'listen' for every time I make an account change. But getting auditing and analytics and read replicas all working properly has always been a very big drain on developer resources, and if done wrong can create site-wide performance problems. I can't tell you how many times someone has demanded a handful of reporting indexes on the highest (write) traffic tables and then doesn't understand how the whole app got so slow. "I want to know every second how much money we're making today and I don't care if I drive away 10% of our income to get it" sigh

What I've wanted every time I've done persistence work in the last 15 years is to be able to have one database that's a partial clone of my 'real' data but with different indexes and lifetimes, without having to re-invent the wheel to get it. I have my fingers crossed that RethinkDB will become that product.

Re: Thoughts on RethinkDB and GraphQL

#30

Post by sanderjd »

ori_b wrote: post #28
sanderjd wrote: post #27

Earlier quoted context omitted.

That sounds very nice in theory, but in practice I've never seen an implementation that is as easy (for me!) to follow as Github's or Discourse's linear flow. Links to the great implementations that I've missed are very welcome!

I have no idea what you find easy to follow -- I have no idea what's going on in a typical Github or Discourse thread. Gmail is also pretty confusing.

Do you mean you have no idea what I find easy to follow, or that you can't understand how I find it easy to follow? I don't have any trouble at all with the typical Github or Discourse thread, and I don't think there's anything confusing about Gmail. On the other hand, when I go to Gmane or someplace, things seem all over the place. But I recognize that my experience isn't universal. Like I said, we'll never all agree. I really like the idea of leaving it up to a client to organize things however works best for an individual, but I'm not aware of a good implementation of such a thing.
Post reply on HN