Să extindem problemele cu GraphQL Avantajul nucleului GraphQL nu este așa-numitul sistem de tipuri; de fapt, constrângerile puternice de tip pot fi implementate bine în sistemele RESTful. Folosind pe deplin schema orpc a lui Zod, care poate genera cod multi-terminal, soluția FastAPI + Pydantic din ecosistemul Python poate obține efecte similare Avantajul principal al GraphQL este că permite clienților să solicite date flexibil, în funcție de nevoile lor. Aceasta este, de asemenea, una dintre principalele funcții implementate de stratul tradițional BFF. Totuși, diferența față de stratul tradițional BFF este că implementarea GraphQL este de obicei puternic legată de afacere și nu există o infrastructură separată pentru a gestiona probleme similare. În acest caz, flexibilitatea va aduce multe probleme în sistemul GraphQL (sau scheme similare BFF vor apărea după ce se integrează în afacere). La cel mai simplu, flexibilitatea va conduce la o suprafață de atac mai mare. La cel mai simplu, un utilizator rău intenționat poate construi o interogare suficient de complexă încât să consume multe dintre resursele serverului tău prin parsing AST simplu. Desigur, mulți oameni ar putea spune: "Ah, de ce nu limitați complexitatea Query?" Așadar, lasă-mă să te întreb, este necesar să rezolvi AST-uri sau să rezolvi AST-uri atunci când calculezi complexitatea interogării? Desigur, unii oameni ar putea spune: de ce să nu limităm tiparul Query-ului? Atunci lasă-mă să te întreb, tiparele tale trebuie să rezolve și AST-urile? Și limitezi cel mai mare avantaj al GraphQL, care este diferența dintre tine și API-urile tradiționale RESTful? Mai mult, dacă analiza AST a GraphQL nu este rezolvată de business, cu modelul single-threaded Node, lag-ul în bucla de evenimente va fi direct amplificat, iar experiența utilizatorului va crește la niveluri N Multe dintre lucrurile pe care GraphQL însuși trebuie să le facă trebuie rezolvate de o infrastructură separată pentru a rezolva afacerea, cum ar fi limitele de rată la nivel de interogare, logica specială de autentificare etc Sincer, GraphQL poate fi o alegere bună pentru platforme de date sau servicii interne. Totuși, pentru serviciile toC cu volum mare, GraphQL va aduce mai multă complexitate și incertitudine decât API-urile tradiționale RESTful, care vor ocupa mai multă dezvoltare a infrastructurii.