- Underfetching gerando a necessidade de fazer muitas requisições ou de criar endpoints muito específicos - Overfetching e com isso problemas em performance
Desenvolvedores do Facebook -Mano vamo ter que usar SOAP. - Puts mas SOAP usa XML. Pra JS é tudo JSON. Seria loco se a gente usasse SOAP com JSON. - Hold my beer
type User { id: ID name: String avatarUrl: String description: String age: Integer status: Status musicalTaste: [String] posts: [Post] followers: [Follower] } enum Status { Active Blocked Inactive }
Já que GraphQL é agnostico de dados cada query ou mutation tem uma função resolver e nela é nossa responsabilidade buscar e estruturar os dados de acordo com o Schemas da forma mais perfomática pois o muitas vezes o client pode solicitar diversos dados com alta complexidade por de baixo dos panos
Mutations definem uma série de ações que mudam seus dados. Subscriptions definem uma série de eventos que você pode se inscrever(subscribe) pra quando os dados mudam.
DIFERENTES CLIENTES: Há a necessidade de criar várias versões de dados diferentes para múltiplos clientes. LINKAR DADOS: Quando os dados mudam com muita frequência e precisam estar linkados sempre. NECESSIDADE DE ENDPOINTS MUITO ESPECIFICOS
GraphQL Rest API HTTP METHODS POST GET POST PUT ETC Status Code Precisa lidar com todos os errors Default Cache do proprio navegador Precisa usar DataLoader. Default Peso da request Mais leve pois é só o necessário Overfetching / Underfetching Complexidade Escondida embaixo do tapete Explicita Documentação Default Precisa implementar
TIPS Deixar models extremamente dinâmicas(limits, orders, filters, pegar apenas os campos requisitados na query GraphQL). Usar context do graphQL para guardar estado Crie seu proprio status code
GraphQL JS graphql.org/graphql-js How to graphql howtographql.com/basics RobinWieruch Graphql Series robinwieruch.de/graphql-tutorial FunFunFunction Graphql Series