Давайте розглянемо проблеми з GraphQL Перевага ядра GraphQL полягає не в так званій системі типів, насправді сильні типові обмеження можуть бути добре реалізовані в системах RESTful. Повністю використовуючи схему Zod orpc, яка може генерувати багатотермінальний код, рішення FastAPI + Pydantic в екосистемі Python може досягти подібних ефектів Основна перевага GraphQL полягає в тому, що він дозволяє клієнтам гнучко запитувати дані відповідно до своїх потреб. Це також одна з основних функцій, реалізованих традиційним шаром BFF. Однак відмінність від традиційного рівня BFF полягає в тому, що реалізація GraphQL зазвичай тісно пов'язана з бізнесом, і немає окремої інфраструктури для вирішення подібних проблем. У цьому випадку гнучкість призведе до багатьох проблем у системі GraphQL (або подібні схеми BFF виникнуть після входу в бізнес). У найпростішому вигляді гнучкість призведе до більшої поверхні для атаки. У найпростішому вигляді зловмисний користувач може створити запит, достатньо складний, щоб споживати значну частину ресурсів вашого сервера за допомогою простого парсингу AST. Звісно, багато хто може сказати: «Ах, чому б вам не обмежити складність Query?» Тож дозвольте запитати: чи необхідно розв'язувати AST чи AST при розрахунку складності Query? Звісно, деякі можуть сказати: чому б не обмежити шаблон запиту? Тоді дозвольте запитати: чи потрібно вашим патернам також розв'язувати AST? І ви обмежуєте найбільшу перевагу GraphQL, у чому різниця між вами та традиційними RESTful API? Крім того, якщо парсінг AST у GraphQL не вирішується з бізнес-моделлю Node з однопотоковою моделлю, затримка петлі подій буде безпосередньо збільшена, а користувацький досвід підніметься на N рівнів. Багато з того, що має робити сам GraphQL, потрібно вирішувати окремою інфраструктурою для вирішення бізнесу, наприклад, обмеження швидкості на рівні запитів, спеціальна логіка автентифікації тощо Відверто кажучи, GraphQL може бути хорошим вибором для платформ даних або для внутрішніх сервісів. Однак для високооб'ємних toC сервісів GraphQL принесе більше складності та невизначеності, ніж традиційні RESTful API, які займатимуть більше розвитку інфраструктури.