Unpopular opinion: GraphQL has no business knowing what HTTP is. Doesn't matter if it travels via http, sse, websocket, webrtc, or carrier pigeon. It's the WHAT not the HOW.
@jasonbahl@chrisgrabinski@moon_meister@nextjs I believe layouts must be deterministic at build time, not SSR time. I assume that’s how they’ve managed to relax the global asset constraint & you can do things like import external css files in it. Still wrapping my head around v13 though. seems… complex
@sseraphini - If you're open source, PRing the codebase should be the final step before hiring 😉
- Onboarding checklist in @NotionHQ for the first 2 weeks.
- Welcome video & code walkthroughs in @loom
- 1:1 sync time with team members. There's still no substitute for human connection
@michlbrmly@n1rual@notrab@GraphQL@graphqlwtf oh that's cool! i imagine you could unjoin, merge, & cache the response across a few dataloaders, too...
do you have an ORM between graphql and your database? i.e. how does it know to fetch some fields from postgres & others from redis?
@Dopamine_Driven that sounds like a solid authentication approach! How do you handle things like, e.g. a mutation inviteToTeam(teamId) where you want to make sure the viewer has permissions to call that based on the teamId passed in as a variable?
GraphQL folks, how do you keep authorization out of your resolvers? GraphQL Shield? graphql-tools resolver composition? custom directives? Show me the way!
@jasonbahl Ah good distinction. I'm talking about operation-specific and type-specific authorization. e.g. Who gets to call the "inviteToTeam" mutation?
@n1rual@shinzui Tell me more! I use graphql-jit to squeeze out every little bit of performance 😅 I've stayed away from graphql-middleware for that very reason, but what about new node versions has reduced the impact?