GraphQL is the peanut butter to Reacts chocolate at FB.
It works there because
1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck?
2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want.
3. everything at FB is some sort of blended context (my user, someone else's user, a permissions interaction)... security is baked in to every field.
4. Because of permissions, and login requirement it's hard to be a bad actor (FB just locks you out, nothing is public).
If you have a SPA and logged in user requirement and that robust permissions model then GraphQL might make sense... Otherwise its a shining example of conways law and might not be fit for your org... The same can be said for react too.
Candidly, I think a lot of the "security" is baked into the data model of what FB is... Are we linked on the graph, are we linked directly, what do your permissions allow me to do based on that relationship. It isn't a difficult query to wrap most requests in. I dont think FB needs that many people keeping an eye on this.
That having been said, outside that data model, your absolutely correct that its going to be costly to maintain those extra layers of relationships.
No, GraphQL makes sense at facebook because at their scale, dealing with the consequence of allowing all possible queries was less work that having to create dedicated enpoints for all the possible client queries.
People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.
Which in a app and team as huge as facebooks' made sense, especially since they have the so-called facebook apps that could do... anything.
> People completely missed the point of GraphQL, which is you TRADE flexibility for the client for added cost on the server.
I mean, isn't this THE selling point of GraphQL? How was it missed so badly? I think every elementary resource about the technology covers this in the pros and cons section...
What if Facebook wanted to open up parts of the site for users without an account, would that require a major reengineering? I've wondered why Facebook (and Instagram) are so strict about not showing anything to logged-out users, could technical reasons be part of that decision?
I think this currently exists in some shape or other, I don’t have a facebook account but I can click on profiles of businesses and get their opening hours and pictures of their menus or whatever. In think there must be some stuff with a public context.
presumably there is still some authorization requirements though? The logged in user is authorized to see details about Friend 123, but not about Non-Friend 456?
It works there because
1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck?
2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want.
3. everything at FB is some sort of blended context (my user, someone else's user, a permissions interaction)... security is baked in to every field.
4. Because of permissions, and login requirement it's hard to be a bad actor (FB just locks you out, nothing is public).
If you have a SPA and logged in user requirement and that robust permissions model then GraphQL might make sense... Otherwise its a shining example of conways law and might not be fit for your org... The same can be said for react too.