Чи є недоліки у GraphQL? [зачинено]

Всі статті про GraphQL розкажуть вам, як це чудово, але чи є недоліки чи недоліки до нього? Дякую.

Недоліки:

• Вам потрібно навчитися налаштовувати GraphQL. Екосистема все ще швидко розвивається, тому вам доведеться не відставати.
• Вам потрібно надіслати запити від клієнта, ви можете просто надсилати рядки, але якщо ви хочете більше комфорту та кешування, ви використовуєте клієнтську бібліотеку -> додатковий код у своєму клієнті
• Потрібно заздалегідь визначити схему => додаткова робота, перш ніж отримати результати
• Потрібно мати на сервері кінцеву точку graphql => нові бібліотеки, яких ви ще не знаєте
• Graphql запити - це більше байтів, ніж просто перехід до кінцевої точки REST
• Серверу потрібно зробити більше обробки для розбору запиту та перевірки параметрів

Але це більш ніж протидіє цим:

• GraphQL не так важко вивчити
• Додатковий код - лише кілька Кб
• Визначивши схему, ви запобіжите набагато більше роботи після виправлення помилок та тривалого оновлення
• Дуже багато людей переходять на GraphQL, тому розвивається багата екосистема , яка має чудові інструменти
• Використовуючи стійкі запити у виробництві (замінюючи GraphQL-запити просто ідентифікатором та параметрами), ви фактично надсилаєте менше байтів, ніж REST
• Додаткова обробка вхідних запитів незначна
• Забезпечення чистої розв'язки API та бекенду дозволяє значно швидше ітерацію вдосконалених програм

Я знайшов важливі проблеми для всіх, хто розглядає можливість використання GraphQL , і до цих пір основними моментами є:

Запит у невизначеній глибині : GraphQL не може здійснювати запит у невизначеній глибині, тому якщо у вас є дерево та хочете повернути гілку, не знаючи глибини, вам доведеться виконати деяку сторінку.

Конкретна структура відповіді : у GraphQL відповідь відповідає формі запиту, тому якщо вам потрібно відповісти в дуже конкретній структурі, вам доведеться додати шар перетворення, щоб змінити відповідь.

Кеш на мережевому рівні : Через звичайний спосіб GraphQL використовується через HTTP (POST в єдиній кінцевій точці), кеш на рівні мережі стає важким. Спосіб її вирішення - використовувати постійні запити.

Поводження з завантаженням файлів : нічого не стосується завантаження файлів у специфікації GraphQL, і мутації не приймають файли в аргументах. Для її вирішення можна завантажувати файли за допомогою API інших типів (наприклад, REST) ​​та передавати URL-адресу завантаженого файлу до мутації GraphQL або вводити файл у контекст виконання, щоб у вас був файл всередині функцій резолюції.

Непередбачуване виконання : Характер GraphQL полягає в тому, що ви можете запитувати, комбінуючи будь-які поля, які ви хочете, але ця гнучкість не є безкоштовною. Є деякі проблеми, які добре знати, такі як запити продуктивності та N + 1.

Супер прості API : Якщо у вас є сервіс, який представляє дійсно простий API, GraphQL додасть лише додаткову складність, тому простий API REST може бути кращим.

Ця найбільша проблема, яку я бачу з graphQL, тобто якщо ви використовуєте реляційну базу даних, це приєднання .

1. Те, що ви можете дозволити / заборонити декілька полів, приєднує нетривіально (не просто). Що призводить до додаткових запитів.

2. Також вкладені запити у graphql призводять до кругових запитів і можуть завершити роботу сервера . Необхідно дотримуватися додаткової обережності.

3. Обмеження кількості дзвінків стає важким, тому що зараз користувач може запускати кілька запитів за один дзвінок.

ПОРАДА : Використовуйте завантажувач даних facebook, щоб зменшити кількість запитів у випадку javascript / вузла

З кожним роком вона стає все кращою і кращою, і, як і зараз, спільнота GraphQL зростає, і як результат, існує набагато більше рішень для багатьох проблем, які були висвітлені в інших відповідях раніше. Але, щоб визнати, що все ще тримає компанії від перекидання всіх ресурсів на GraphQL, я хотів би перерахувати деякі проблеми та рішення, за якими слідують невирішені.

• Кеш на мережевому рівні - як сказав Бруно, це постійні запити, і, звичайно, ви можете кешувати клієнта, і ніхто не заважає вам використовувати кешування на рівні бази даних або навіть Redis. Але звичайно, оскільки GraphQL має лише одну кінцеву точку, і кожен запит відрізняється - робити цей тип кешування набагато складніше, ніж з REST.
• Вкладені запити в GraphQL призводять до кругових запитів і можуть збивати сервер - вже не проблема з великою різноманітністю рішень. Деякі з них перераховані тут
• Обробка файлів для завантаження - ми вже багато з рішень для нього

Але є ще кілька випадків, які можна вважати недоліками:

• надмірність котлованної панелі (маю на увазі це, для створення, наприклад, нового запиту, вам потрібно визначити схему, резолютор і всередині резолютора, щоб явно сказати GraphQL, як вирішити ваші дані та поля всередині, на стороні клієнта створити запит з точно полями, пов'язаними з ці дані)
• поводження з помилками - мені потрібно сказати, що це більше стосується порівняння з REST. Тут можливо з аполлоном, але в той же час це набагато складніше, ніж у REST
• аутентифікації і авторизація - алеяк я сказавспівтовариство ростуть з винятковою швидкістю і є вже пара з рішень для цієї мети.

Підводячи підсумок, GraphQL - це лише інструмент для конкретних цілей, і напевно, це не срібна куля для всіх проблем і, звичайно, не заміна REST.

Дійсно чудово мати єдину кінцеву точку та оголити всі дані. Нижче я знаходжу точки, які слід враховувати для GraphQL:

1. Реалізація завантаження / завантаження файлів стає складним (перетворення в рядок може бути не найкращим варіантом для великих файлів)
2. Багато кодового шаблону та коду схеми як на фронті, так і на вихідному.
3. Дотримуйтесь та підтримуйте пагинацію, надану в специфікації GraphQL.
4. Дозволити користувацький порядок та пріоритетність логіки для впорядкування полів. Приклад, якщо ми отримуємо дані користувачів та пов’язані групи та ролі. Користувач може декілька сортувати дані на основі імені користувача, назви групи чи назви ролі.
5. Аутентифікація та авторизація залежатимуть від базової бази.
6. Переконайтеся, що оптимізація бекенда та підтримка баз даних для запуску одного запиту для кожної команди graphql може стати складним.

Також слід врахувати плюси після його впровадження:

1. Дуже гнучка для підтримки нових елементів та оновлення існуючої поведінки.

2. Легко додавати умови, використовуючи аргументи та спеціальне замовлення після їх впровадження

3. Використовуйте безліч спеціальних фільтрів і позбудьтеся всіх дій, які потрібно створити, наприклад, користувач може мати ідентифікатор, ім’я та ін. Як аргументи та виконувати фільтрацію. Крім того, фільтри можна застосувати і до груп користувачів.

4. Простота тестування API шляхом створення файлів, що містять усі запити та мутації GraphQL.
5. Мутації прості та легко здійснити, колись зрозуміла концепція.
6. Потужний спосіб отримати декілька глибин даних.
7. Підтримка інтерфейсу Voyager та GraphiQL або ігрового майданчика дозволяє легко переглядати та використовувати.
8. Простота документації при визначенні схеми з дійсними методами опису.

Я думаю, що graphql на даний момент повинен бути частиною архітектури бекенда, для завантаження файлу ви все ще потрапляєте у звичайний api