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
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.
Thanks for your site and message. Sorry but personally I found your article difficult to read. Your font choice and background, which seemed to me to overwhelm the text with little contrast, made it hard for me to see and parse the words. Sadly I think much of your message was lost on me. For reference I'm in my sixties and have poorish eyesight. I'm using Firefox. Best wishes.
Thank you for making this! I read the book twice last year and it made a deep impact on me and my relationship to basically everything. The book, coupled with coaching has greatly improved my life.
Your site is a great summary reminder of the key points and it brought me back into the experience of reading the book.
For folks reading this, I do recommend reading the book since the website is just a taste of the book. It's lessons may hit different not having gone through the full journey.
Thank you for making this, also one of the most impactful books I read last year. And last but not least, thank you for GraphQL and your contribution to the open source community!
This is what's frustrating with Google's Material Design. If tech-savvy users like me can't even find or know that the year is clickable, what hope do most non-technical folks or seniors have?
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.
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.
Oh hey thanks for the reply. I think I misunderstood before. But what you are saying is what I meant to say. That GraphQL is fantastic in that it gives a layer of abstraction away from versions apis with different endpoints.
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.
We did this for the whole schema (in an Erlang port of the GraphQL server). It turns out to work extremely well for our use case, and it seems to fit better to the Erlang model of working with the code.
