Hacker News Reader

Comment by zer00eyz | Hacker News Reader

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.

View on HN

FB have a lot of resources to manage the complexity of this.

For most people "security is baked in to every field" is going to be very expensive.

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.

Yep, GQL can make sense if you have tons of clients.

> 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.

My guess would be they SSR those pages and partially hydrate the page on the client if the user is logged in.

Are they? I have full access to all the Instagram reels, posts, comments, etc. friends send me, without being logged in.

Not really, it’s 100% business reasons. Facebook and especially Instagram used to be much more open to logged-out users in the past.

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?

That might be what they meant by "robust permissions model".

Does TAO help? I imagine it's a lot easier to embed all this additional logic and metametametadata in a single service than distribute.

Nah, it's one level up having basically everything as an Ent (ORM object) with an associated data access policy that does that.

Reply on news.ycombinator.com