«Ненавижу GraphQL»: разработчик назвал минусы языка запросов и объяснил, когда от него лучше отказаться

«Больше не буду использовать в новых проектах», — так решил для себя фулстек-разработчик Эндрю Ли, который, мягко говоря, недоволен некоторыми фундаментальными проблемами, заложенными в языке обмена данных GraphQL. Что с ним не так, специалист рассказал в своем блоге.

Стоит отметить, что неприязнь разработчика к GraphQL выражается исключительно с позиции бэкенд-специалиста. На фронтенде же, по словам Эндрю Ли, он любит язык, потому что тот позволяет ему творить. По мнению разработчика, GraphQL — это отличный выбор для крупных IT-компаний, так как наличие сервера языка в качестве слоя API над разными микросервисами позволяет фронтенд-разработчикам работать над продуктом, не отвлекаясь на сложности. 

Разработчик не планирует использовать GraphQL именно в новых проектах, под которыми подразумевает проект без четкого соответствия рынку и проект с небольшой командой (до трех человек). Вот с чем связаны его претензии. 

Производительность

«Я ненавижу GraphQL как бэкенд-разработчик», — уточнил Эндрю Ли. Причина в том, что язык очень гибкий на стороне клиента, а сервер нельзя оптимизировать также агрессивно. 

Проверять производительность сервера GraphQL нужно с максимальной осторожностью. По мнению разработчика, такие действия не оправданы, если команда уже хорошо разбирается в производительности GraphQL. Например, если разработчики должны узнать, как использовать загрузчики данных, чтобы избежать n + 1 запросов. 

Безопасность

В REST API можно обезопасить каждый из маршрутов. В GraphQL API нужно учитывать, что может быть бесконечное множество перестановок запросов, которые могут быть вызваны. 

Типы и доступ к типам должны быть организованы с осторожностью. Нужно быть уверенным, что неожиданно не добавится подзапрос, раскрывающий конфиденциальные поля. 

Популярность

Для многих айтишников работа с GraphQL бывает в новинку, чего не сказать о REST API, который в качестве концепции известен уже почти 20 лет. Это еще одна технология, которую нужно изучить, прежде чем можно начать работать над проектом. 

Прежде чем перейти на GraphQL, нужно убедиться, стоит ли игра свеч, особенно на ранних этапах проекта. 

Бытует мнение, что стоит начинать с GraphQL, только если есть в планах переход на него, когда проект станет большим. Если есть гарантия, что это случится, тогда, уверен автор, риски и ожидающие команду неудобства оправданы. В противном случае, по мнению Эндрю Ли, будет более разумно перейти на GraphQL позже, когда компания станет больше.

А как вы считаете?