netflix = have their own renderer. that is lot of hours of good engineers dedicated to that.
facebook = probably hack away all the low level stuff they need to tweak.
bbc = they probably have the same problem we have here. that does not stop them or we to boast that we use react all over the place. doesn't mean we like it.
As an ex-Facebook employee, I can't wait for this to be released to the public. It is hard for me to overstate how much this infrastructure makes building products a joy, not to mention the tremendous developer and server efficiency that can be attained. I miss having the GraphQL stack so much when working on my own stuff.
The client application should drive the decisions about what data to fetch. After all it's the client that knows what it is actually going to be doing with the data, not the server. Current approaches like having a "fields" option on a REST endpoint are at best a hacky approximation to this.
I'm curious to learn how API response caching is affected by GraphQL. In a REST setup, there's a possibility that API responses can be cached. But if the response structure is dictated by the client, it seems like responses might differ and not be cacheable.
In practice it wouldn't make much sense to cache whole query responses to GraphQL queries because your hit rates would be too low due to the variability of the queries. You end up pushing a lot of the caching to the client. That's not really a big issue because if you're writing something like a Android or iOS app because you already need to be caching lots of data on the client-side to make the app responsive.
On the server you end up caching at lower levels in the stack. For example a query for user(id: 123456) {id, name} is going to need data from a key-value store containing user info. That access can easily be cached with something like memcache, saving load on the database. Cache-invalidation problems are also much easier to solve at these layers.
Worth noting there's a massive performance penalty to pay when caching at the app level depending on your stack. On hardware where rails + memcached is struggling to handle 500 concurrents varnish or Nginx will easily handle tens of thousands.
As someone who's used OData for this sort of strong typed, ad-hoc interaction with the server, I'm really happy to see Facebook push this idea. Compared to OData, I really like how GraphGL's approach of making a query look like the data it's requesting.
I don't know, there are some tradeoffs there. Their sample appears to be "nearly JSON", which doesn't seem too helpful. Being close to but noncompliant with a standard doesn't bring anything but confusion.
And it isn't obvious what they're using for transport, but it seems like they aren't attempting to model programmatic resources as web resources the way that OData does. This is an okay decision if they're trying to make it transport-neutral (i.e. you can issue the same GraphQL request via Thrift or by HTTP POST), but in that direction lies the sins of SOAP.
In the past I've written a client-side caching layer for OData which was capable of doing the same automatic batching and partial cache fulfillment for hierarchical queries that they describe in the article. It is a good tool for writing complex client applications against generalized data services without giving up performance, and I'm not surprised that companies in our post-browser world are starting to move in that direction.
I'm a little bummed that Facebook is throwing its considerable weight behind yet another piece of NIH-ware, though. Beating up the REST strawman was a poor use of half of this article; I'd be much more interested to hear why we need GraphQL when there exists a standard like OData.
CSS is evaluated right to left, so this means every time an <a> is encountered in the page it has to at its parent chain to see if any has class Foo. This can cause performance issues especially for really large pages.
That said, for most pages it won't make a noticeable difference so it's kind of up to you to decide if you care.
What's the more performant/"proper" way to narrowly target CSS in that situation? Just tacking classes directly on the links (e.g. `<a href="#" class="foo-link">` starts to get very cluttered very fast if you want the benefits of deeper nesting, targeting and namespacing (e.g. `<a href="#" class="foo-bar-baz-link">`. Is it best to simply try to avoid nesting of styles altogether and keep namespaces as flat as possible?
In case you're not familiar with them, the basic idea is treating a image of a face as a very high dimensional vector, and then doing what amounts to PCA on a collection of them. I'm leaving off a few steps, but the resulting eigenvectors converted back into images helped me grasp what was going on in a much more intuitive fashion.
About a year ago I repeated this experiment (well a very simplified version) with MegaMan sprites, including a quick write up of the process for anyone interested: http://willkurt.github.io/EigenMan/
This is how we introduce it to our undergrads. Using the faces is a great way to demonstrate model reduction and snapshot method as well as a glimpse into one of the algorithms used in face recognition software.
It is not possible. This is a serious flaw in Android's permissions model IMO. Everything must be asked for up-front in the app's manifest. You cannot ask for more permissions at run time.
These pie charts are bad. You shouldn't have the same browser switch colors as you go through the charts. IE starts as purple then is blue; Firefox makes it from blue to purple to red.
Like Facebook? Netflix? The BBC?