I'm glad someone else mentioned the authorization problem. What if a user is allowed to access some of the resources declared in the GraphQL but not all of them

I'm glad someone else mentioned the authorization problem. What if a user is allowed to access some of the resources declared in the GraphQL but not all of them... Do you block the request or do you allow it? Filtering out the non-accessible parts of the GraphQL seems like overkill. I work mostly with realtime WebSocket connections so my view is probably biased towards usage with realtime transports... But my favourite alternative approach to GraphQL is to just deal individual fields/properties of objects independently (for update operations). This avoids conflicts (like accidentally overwriting sibling properties with old values as part of an update operation). On create, you can create the whole object at once (with all properties) but for update, you only update each field independently. You end up with a realtime CRUD layer with field-level granularity. You do have to give up on transactional atomicity but I've found that the approach I've described above covers the vast majority of use cases. In those cases where you do need to update a whole object at once, you can setup a separate endpoint for that one - For me this usually only happens when I need to make a complex operation like 'Reset password' or 'Send email' which involves some specialized backend processing - Not something GraphQL would handle either.