Solución:
Uno de los puntos de venta de GraphQL es permitir que el cliente tenga mucha flexibilidad para definir la forma de los datos que desea consultar en un número mínimo de solicitudes. También animan a los desarrolladores a “pensar en gráficos” al diseñar el esquema.
Por lo tanto, optaría por una consulta anidada que se parece más a un gráfico. Además, es mucho más flexible. Si el usuario desea obtener los datos de su perfil de usuario con sus invitaciones, puede obtenerlos en una sola solicitud. Si solo quieren obtener los datos del perfil, simplemente ignoran la parte de la invitación en la consulta y el servidor no desperdiciará ningún recurso para obtener los datos de la invitación debido a la naturaleza del diseño de GraphQL.
Yo diría que realmente depende del caso. Personalmente, trato las propiedades anidadas como una contexto: si el consumidor de API quiere obtener notificaciones mías, Entonces es me { notifications { ... } }, no notifications { ... }. Si tiene sentido tener una clave de nivel superior, por ejemplo, existe un concepto de global notificaciones (no depende del usuario), entonces hazlo. Si cada usuario tiene sus propias notificaciones (que supongo que es cierto), entonces me de tipo User debería tenerlo, como cada User lo hace. Dicha generalización fomenta el pensamiento reutilizable: un panel de administración, donde user(id: ...) { ... } se está utilizando en lugar de me { ... }, puede usar el mismo código de interfaz de usuario gratis.
Como regla general, es mejor pensar en consumir esa API, no en proporcionarla.