Live data from Hacker News

Thoughts on RethinkDB and GraphQL

github.com

1–10 of 32 posts

Re: Thoughts on RethinkDB and GraphQL

#2
Apart from GraphQL itself, two things are pretty impressive about this thread. 1) Impressive community to have such an informed set of comments in a matter of a few days. Congrats. 2) People have to talk like that in a very hard to follow way since we used to have better ways (NNTP, mailing lists) but now they are gone in favor of worse systems.

Re: Thoughts on RethinkDB and GraphQL

#3
post #2

Apart from GraphQL itself, two things are pretty impressive about this thread. 1) Impressive community to have such an informed set of comments in a matter of a few days. Congrats. 2) People have to talk like that in a very hard to follow way since we used to have better ways (NNTP, mailing lists) but now they are gone in favor of worse systems.

Anything specific you find hard to follow here?

Re: Thoughts on RethinkDB and GraphQL

#4
post #3
post #2

Apart from GraphQL itself, two things are pretty impressive about this thread. 1) Impressive community to have such an informed set of comments in a matter of a few days. Congrats. 2) People have to talk like that in a very hard to follow way since we used to have better ways (NNTP, mailing lists) but now they are gone in favor of worse systems.

Anything specific you find hard to follow here?

GitHub issues aren't threaded, which means that there's a whole nest of @mentions to identify the specific person to whom you're referring.

Re: Thoughts on RethinkDB and GraphQL

#5
post #3
post #2

Apart from GraphQL itself, two things are pretty impressive about this thread. 1) Impressive community to have such an informed set of comments in a matter of a few days. Congrats. 2) People have to talk like that in a very hard to follow way since we used to have better ways (NNTP, mailing lists) but now they are gone in favor of worse systems.

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.

Re: Thoughts on RethinkDB and GraphQL

#6
post #3

Earlier quoted context omitted.

Anything specific you find hard to follow here?

GitHub issues aren't threaded, which means that there's a whole nest of @mentions to identify the specific person to whom you're referring.

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.

Re: Thoughts on RethinkDB and GraphQL

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

I have high hopes for RethinkDB to be a DB that does things right in the long term, so I hope things like this appear only in the form of plugins that are easily disabled by users, and easily deprecated by developers.

Re: Thoughts on RethinkDB and GraphQL

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

Re: Thoughts on RethinkDB and GraphQL

#9
post #8
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.

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.

Re: Thoughts on RethinkDB and GraphQL

#10
post #6

Earlier quoted context omitted.

GitHub issues aren't threaded, which means that there's a whole nest of @mentions to identify the specific person to whom you're referring.

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 linear style with mentions, quotes, and backlinks (a la Discourse) strikes the best balance for most conversations. But of course we'll never all agree.

Post reply on HN