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

11–20 of 32 posts

Re: Thoughts on RethinkDB and GraphQL

#11

Post by sanderjd »

rspeer wrote: post #9
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.

Oh, right, I've encountered examples before of Facebook saying "graph" when they mean "API". That sounds like an even sillier thing to put in a database, then.

It's a query language. Every database supports at least one query language. It's certainly reasonable to argue that natively implementing multiple query languages is "bloat" or "feature creep" (as some in the comment thread point out and suggest alternate approaches to avoid), but I don't think it's silly.

Re: Thoughts on RethinkDB and GraphQL

#12

Post by phpnode »

rspeer wrote: post #9
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.

Oh, right, I've encountered examples before of Facebook saying "graph" when they mean "API". That sounds like an even sillier thing to put in a database, then.

APIQL would have been a better name

Re: Thoughts on RethinkDB and GraphQL

#13

Post by jondubois »

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 lot simpler and more direct.

Re: Thoughts on RethinkDB and GraphQL

#14

Post by msvan »

As someone who is currently experimenting with RethinkDB and GraphQL for a personal protect, I have been impressed with both technologies and they have been rather straight-forward to integrate with my React frontend, even without the blessing of official support. I expect the productivity gains could be huge when working on bigger apps. It's a refreshing perspective compared to the RESTful single-page app I maintain at my dayjob.

Re: Thoughts on RethinkDB and GraphQL

#15

Post by segphault »

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…

It's understandably a little difficult to extract all of the relevant context out of that thread in the issue tracker, but the current consensus is indeed that this feature should be built with a plugin system--on top of the database's existing query language and feature set.

The plugin system will provide a sort of middleware layer alongside the database so that we don't have to bake in a lot of things that are domain specific or only relevant to particular use cases.

There's more discussion about the plugin system here: https://github.com/rethinkdb/rethinkdb/issues/4785

(Disclosure: I work at RethinkDB)

Re: Thoughts on RethinkDB and GraphQL

#16

Post by carterehsmith »

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 it obviously works well. For example, there is a bunch of NoSQL databases that will accept at least some SQL syntax. That is good.

Re: Thoughts on RethinkDB and GraphQL

#17

Post by ori_b »

sanderjd wrote: post #10
rev087 wrote: post #6

Earlier quoted context omitted.

I might be the exception, but I find Github comments much easier to digest and manage as an archive than mailing lists. In all the years working in the industry, I could never get used to mail lists.

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.

Re: Thoughts on RethinkDB and GraphQL

#18

Post by schrockn »

phpnode wrote: post #8
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…

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/when it becomes a widely known name.

Re: Thoughts on RethinkDB and GraphQL

#19

Post by schrockn »

msvan wrote: post #14

As someone who is currently experimenting with RethinkDB and GraphQL for a personal protect, I have been impressed with both technologies and they have been rather straight-forward to integrate with my React frontend, even without the blessing of official support. I expect the productivity gains could be huge when working on bigger apps. It's a refreshing perspective compared to the RESTful single-page app I maintain…

That sounds awesome. Are you developing this on github? I'd be curious to see what your integration looks like.

Re: Thoughts on RethinkDB and GraphQL

#20

Post by egor83 »

antirez wrote: post #5
rgbrgb wrote: post #3

Earlier quoted context omitted.

Anything specific you find hard to follow here?

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...

Post reply on HN