Let's Learn GraphQL
learngraphql.com
learngraphql.com
The homepage seems to be a bit confusing, I think. You don't have to sign up to read some of the content. There is a small link below the large button: https://learngraphql.com/basics/introduction.
Correction: As sync pointed out, you still need to sign up to access the full content.
You can do stuff and get points. This is a good way to learn something. We've prior experience in with our BulletProof Meteor course.
I also came here to the comments to ask why I would want to hand over account information on an unrelated service.
Perhaps a short sentence in Gray near "Next Lesson" telling you will never sell emails (or similar) would help
That's why you need to login with GitHub. See more on this: https://news.ycombinator.com/item?id=10384683
I very much would prefer the content to be accessible without this ego-bolstering crap.
Sorry, but local storage or a cookie dropped would suffice. Why should this introduction be in any way tied to me or my Github profile?
It may be so easy, to just log in with Github. But for me this just kills it. I assume, that a lot of people think alike - that might be the reasons for downvotes.
Disclaimer: I'm pro-Github... well, other than the fact that it's centralizing a decentralized SCM. ;)
It seems a lot of effort goes into making this tutorial. The guy working on it seems to be running a business. Although it can be done without requiring a sign-up as you said, I also understand how the author would like more people to sign-up, follow the competition, and potentially use his company's service.
Writing good tutorial is actually pretty hard and time-consuming. Just making it open and not getting any benefit out of it is not a sustainble business.
... well you get the point. If I want to have it on my resume, I will put it there. If not it should not be findable, because I once looked into it, but maybe didn't have the stamina to push through.
So maybe "ego-bolstering" was a bit harsh. But non the less - this requirement just killed it.
I had to swallow it (just bile)
If storage was some kind of NoSQL and stores everything as one huge JSON, then we can filter out data while retrieving, but what would happen if data storage is RDBMS? Are we going to do multiple joins to retrieve data?
seems GraphQL work really well with graph databases, but if you have 2-3nesting in GraphQL query, then you need to do multiple big joins on the server side
Also, keep in mind that this is a query language and not an API spec. If you want to allow clients to perform massive joins then GraphQL will facilitate that, but that's your decision to make. Ultimately you still need to decide what clients can and can not query.
GraphQL is different and trying focus on the API end. (You can think it's trying to replace REST). GraphQL's client side part it Relay for now. It's somewhat complex compared with Falcor. But, I believe we can have a easy to use React independent client for GraphQL.
Meteor is a full stack. It has no direct relationship(or cannot compare with) GraphQL. Meteor also a realtime framework, but GraphQL does not address realtime aspects (yet).