Pagina 1 di 1
GraphQL non è sempre la scelta giusta. Per un'applicazione mobile con dozzine di view diverse sulla stessa entità può essere un game changer; per un'API B2B con dieci endpoint stabili è quasi sempre overkill. Il problema vero non è scriverlo: è gestire N+1, autorizzazione a livello di campo, query complexity e schema evolution.
In questa categoria scrivo di GraphQL applicato: GraphQL con Laravel Lighthouse valutato su un'applicazione mobile da 10.000 utenti (quando converte rispetto a REST e quando crea solo complessità), API Platform su Symfony per generare REST e GraphQL da modelli Doctrine, gestione concreta del problema N+1 a runtime.
Se stai valutando GraphQL per un progetto reale e vuoi un confronto onesto con REST, parliamone. Oppure scopri come lavoro.
API Platform genera in automatico endpoint REST completi, documentazione OpenAPI e client GraphQL da semplici annotazioni Doctrine. Ho usato questo approccio per costruire l'API di un SaaS gestionale in metà del tempo previsto. Ma ha anche i suoi limiti: vi racconto dove finisce la magia e inizia il lavoro custom. Continua a leggere
Ho valutato GraphQL per il refactoring dell'API di un'applicazione mobile Laravel usata da 10.000 utenti. La promessa del 'un endpoint per tutto' si scontra con la complessità di N+1 problem, autorizzazione fine-grained e caching. Vi racconto l'analisi completa e quando la scelta è giustificata. Continua a leggere
