The site is nearly all excerpts including the section with “practical advice” - those ten suggestions are nearly verbatim from the book author from the last chapter
I noticed a fair amount of complaints about this in the thread, so am sorry for the poor experience.
In an attempt for simplicity I used a simple <input type=date> field which means it uses your OS or browser’s native date picker. As a Mac/iOS user I’m pretty familiar with those, but I’ll admit I did not test this across Windows or Android devices which apparently have not done a great job at this UI element.
Site creator here! Thanks to all who spent some time reading and scrolling through. I’m happy to see such great discussion here, and gives me some confidence the excerpts pulled were the right ones to get the core ideas across.
Great question. It applies to the variant of the spec as it exists today when the license was applied. Currently found at http://facebook.github.io/graphql/draft/
GraphQL's reference implementation (GraphQL.js) intends on not just being a great implementation, but also very closely following the spec, so you're in good shape.
Also, GraphQL.js has had a BSD3+PATENTS license until today, which meant you've always had that patent license. Later today I'll be releasing a version of GraphQL.js that is MIT license instead, understanding that the OWFa1.0 applies to all implementations including the reference implementation.
This is a pretty good distillation of some differences, but I just wanted to reiterate that I'm more excited about the similarities. Having options for what tools to use along with GraphQL is a great thing, and even better is when the best ideas make their way into many of them.
To clarify a bit: we've removed fields from and changed our database schema repeatedly over the years. In fact we've migrated between entire database technologies multiple times over.
What we haven't done is remove fields from our GraphQL API when those fields are still in use by shipped iOS, Android, or web apps.
GraphQL gives us a layer of abstraction to create consistency from the point of view of client apps while allowing iteration of backend services.
You're not off base at all! It's very similar to that. I think it's important to extract what was good and bad about this old website pattern.
The good is that within a single PHP file you could see both the logic for requesting data (SQL) AND the logic for rendering that data. This colocation was part of what made the early web take off, it was a great developer experience.
The bad is that these interspersed SQL statements were immediately invoked and blocking, which led to utterly awful performance.
One of the core ideas of Relay is that we wanted to bring back that developer experience of colocation while not only retaining good network performance, but actually creating opportunities for network optimization. When you see GraphQL in your Relay code, that is not a blocking immediately invoked network request. It's a description of a part of data needed. Relay aggregates these GraphQL fragments together to submit in few network requests in a non-blocking way to achieve the network performance we expect from modern mobile applications.
This technique of persisting the queries (and fragments) to the server at build time predates Relay - we've been using it on our iOS and Android apps since 2013.
At build time these clients submit their query strings to the server and get a small identifier in return which they can use at runtime to reference the whole query. This definitely means that old queries need to be kept around as long as the clients that use them are still active. Since iOS and Android apps seem to last forever, we're still getting traffic today from just about every version of our native apps we've ever shipped, even from 2012 and 2013. Because of this we decided to not bother with garbage collecting persisted queries, in terms of all the other data Facebook retains, persisted GraphQL queries is a grain of sand in a desert. However, with a bit more work, you could easily keep a hit counter per persisted query and go remove any persisted queries which had no recent hits.
1. Reactiflux Q&A is a great idea, perhaps someone who organizes that can help set that up.
2. We're a pretty small team and our primary focus is building great software for Facebook and the larger community, so unfortunately our ability to focus on answering questions is relatively limited. Many people on the team occasionally hop into StackOverflow to answer questions, but we definitely can't make any guarantees about answering them all or answering them in a certain amount of time.
You can run relay-compiler as part of your webpack config as a pre-compile step. Also, if you want to run relay-compiler while you're iterating on your code, pass --watch and it will rerun whenever a file is saved.
Awesome way to leverage the schema definition files to set up a super fast server. I see this being really useful for quick prototyping or for hackathons.
That theory is Facebook's practice. Four years later and we're on GraphQL API version 1. We add things which is safe, deprecate fields which we want to remove, and delete when hit rates drop to 0.
Granted, our clients are all Facebook engineers, so we have some pull in helping the migration away from deprecated fields, and GitHub will have to find the right process which works for a broader set of API consumers, but not only is this theory a good one, it's considered GraphQL best practice.
You're definitely right to point out that Immutable.js is really not always what you want for small values that change all the time. Immutable.js collections are best used for just that: collections. If you have to copy an array or map with a ton of entries to make a change, it's going to be super slow - Persistent Immutable data structures can help with that.
But I agree with your conclusion that any JS objects that are being used as small tuples are definitely better off staying plain JS objects.
You also don't have to use all Immutable.js or nothing at all. Similar to how using an ES6 Map collection means you don't have to stop using JS objects. Use Immutable collections where they offer benefits, but spreading it everywhere is not a performance panacea, as you rightly discovered.