Оригинальный адрес:The state of GraphQL by Reddit

Оригинальный автор:Robert Matyszewski

Перевод с:Программа перевода самородков

Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…

Переводчик:TiaossuP

Корректор:yangxy81118

Состояние GraphQL, как видно из обсуждения Reddit

Когда дело доходит до GraphQL, вы видите всевозможные рекламные статьи и дебаты, сравнивающие его с REST. GraphQL сейчас находится на ранней стадии глобальной популярности и полноценного использования, и никто точно не знает, где он остановится. Проведя исследование в Интернете, я нашел много статей Amway об этой новой технологии. Это просто реклама первых впечатлений?

Я изучил комментарии GraphQL на Reddit и выбрал самые популярные из них. Эта статья направлена на прозрачное и объективное обсуждение этой темы, поэтому я выбрал часть содержания пользовательских дискуссий и дебатов для различных точек зрения каждой фракции. Каждый приведенный ниже комментарий имеет ссылку на его автора, а также лайки для этого комментария в ( )(Аннотация: за оригинал голосую)количество. Обратите внимание, однако, что количество лайков может измениться после того, как я напишу и опубликую эту статью.

повестка дня

Общее состояние
Реакция и статус Аполлона
Крупные компании и GraphQL
тайник
запросить данные
Суммировать

Общее состояние

В целом, я выбрал два практических примера. первый,SwiftOneSpeaksПоказаны перспективы разработчиков переднего плана и потенциальные улучшения рынка. Второй,Scruffles360Показывает, как команды адаптируются к graphql и трендам своей стратегии с помощью конкретных инструментов. Вы найдете больше его комментариев позже. Второй комментарий — тот, у которого в этой статье выбрано наименьшее количество лайков.

SwiftOneSpeaks(23) говорит:

Когда я работаю с командой разработчиков серверной части, они более склонны предоставлять новые запросы для удовлетворения моих потребностей, поскольку это не влияет на существующие запросы, которые они должны поддерживать. (Тем не менее, я не знаю, как этот запрос будет масштабироваться с течением времени). GraphQL также уменьшает количество неправильных ответов, которые мне приходится повторно анализировать в структуры данных, пригодные для использования (для моих нужд). (Например, я получаю 3 массива, которые мне нужно сопоставить и сжать в набор объектов. Хотя на бэкенде еще предстоит проделать некоторую работу, с GraphQL у меня могут быть гораздо более богатые возможности для запроса форматов данных.)

Scruffles360(8) описывает три направления, которые он видит в пространстве GraphQL:

Монолитные приложения: это то, к чему сейчас стремится Apollo. Каждая компания имеет одну и только одну конечную точку API и прокси-сервер схемы для всего остального (principledgraphql.com/). Я полностью не согласен с этим ходом мыслей, но не буду повторять здесь свои аргументы (вы можете просмотреть мою историю комментариев, если хотите знать)

API-интерфейсы баз данных: по какой-то странной причине люди начали добавлять в базы данных плагины, которые могут обращаться к базе данных напрямую через graphql. Graphql великолепен по многим причинам, но его пока нельзя сравнить с родными языками запросов к базам данных. Что еще более важно, это удаляет ваш бизнес-уровень, предоставляя звонящим прямой доступ к вашему магазину. Никто, кроме приложения микросервиса, не должен иметь доступ к хранилищу — все остальные должны вызывать сервис через ваш API.

Средний путь: классический подход к API, каждое приложение имеет свой собственный API (в данном случае GraphQL). Он может изолировать бизнес-логику или прокси-серверы от микросервисов (либо через отдых, либо через сшивание схемы с другой схемой Graphql). Это путь, по которому мы пошли, и пока я ни о чем не жалею.

Реакция и статус Аполлона

Сочетание React и Apollo привлекает много внимания. такжеWronglyzorroа такжеLivelierepeatОбсудите, почему бэкэнд-разработчикам может не нравиться GraphQL. Ответ более опытного разработчика получил больше лайков. Кроме того, я выбрал более длинный, но очень подробный обзор.

Wronglyzorro(12):

Мы строго используем реакцию + аполлон в нашем веб-приложении. Мы также заставляем мобильных клиентов использовать его. Как бы абсурдно это ни звучало, это действительно большой тренд. Бэкэнд-разработчики, конечно, ненавидят это, потому что они привыкли к тому, что они есть, и не любят меняться. Однако из всех сбоев, которые у нас были за последний год, это никогда не было GraphQL, это всегда сбои устаревших серверных служб.

Livelierepeat(40) Ответ:

Бэкэнд-разработчики, конечно, ненавидят это, потому что они привыкли к тому, что они есть, и не любят меняться.

Возможно, вы захотите узнать мою точку зрения, я был молодым разработчиком, использовал все новейшие инструменты и смеялся над людьми, которые «не могли вписаться». Я узнал, что часто есть более интересные причины, чем «люди ненавидят перемены». Например, не слишком ли сложна абстракция GraphQL? Они сопротивляются увеличению рабочей нагрузки, но в чем именно заключается увеличение?

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

CapajПодробное резюме (11):

Мы начали использовать GraphQL в продакшене в мае. Мы команда полного стека, поэтому нам не нужно полагаться на милость сотрудничающих бэкэнд-команд. Нелегко убедить всех, но GQL имеет встроенный пример, и все думают, что он выглядит лучше, чем REST. Graphiql очень помогает в этом.

Это хорошо. Мы используем движок apollo на бэкэнде, и мне очень нравится использовать метрики для выявления ошибок API в продакшене. Мы используемdecapiукрасить нашobjection.jsМодель БД. Мы определяем модель в отдельном месте, а затем автоматически генерируем GQL, ничего не делая.

На фронтенде мы используем apollo-client, но пока не использовали кеширование. Наш внешний интерфейс направлен на то, чтобы избавиться от предыдущего кода angular.js, поэтому у нас еще не было времени экспериментировать с внешним кэшированием.

Я не использовал apollo для управления состоянием на стороне клиента, потому что все отзывы, которые я слышал до сих пор, заключаются в том, что он не готов к работе. Кроме того, я должен сказать, что это выглядит многословно, и его многословно писать. Вместо этого я хотел бы расширитьGitHub.com/Маха Аган говорит/Прошлое…и использовать его для наших нужд управления состоянием. MST хорошо работает с машинописным текстом. Если бы мы могли динамически генерировать модель MST из запроса при редактировании запроса GQL, мы могли бы значительно повысить нашу производительность.

тайник

я был изSwiftOneSpeaksа такжеScruffles360Увидел много отличных и одобренных комментариев в , которые были упомянуты выше. Ниже приведены проблемы кэширования и возможные решения, которые они обсуждают.

SwiftOneSpeaks(23) написал:

Хотя вы можете настроить GraphQL для работы различными способами, на самом деле это всегда POST-запросы. Это означает, что все кеши браузера, кеши CDN, кеши прокси, основанные на соглашении о том, что GET является идемпотентным, а POST — нет, по умолчанию не будут работать. Все обрабатывается как новый запрос. Хотя вы можете самостоятельно выполнить более разумное кэширование на стороне клиента, на самом деле это просто решение проблемы, которую вы создаете сами (имеется в виду GraphQL).

Scruffles360(11) Ответ:

У Apollo есть решение — «Динамический постоянный запрос», но я его еще не пробовал. Грубо говоря, клиент будет использовать запрос GET (хешировать запрос) и вернуться к POST, если это не удастся. Последующие вызовы GET завершатся успешно и будут применены ко всем кэшам прокси.

запросить данные

Эти люди также предложили разные взгляды на извлечение данных. существуетgraphql-vs-rest (Перевод здесь)В статье автор описывает пример приложения для ведения блога с несколькими авторами и возможность использования GraphQL с REST.

SwiftOneSpeaks(23) говорит:

Все подчеркивают проблему «чрезмерной просьбы»(Аннотация: Исходный текст Over fetching, что означает, что в запрошенных данных есть много полей, которые вам не нужны. Также есть похожее понятие: Under fetching, что означает, что возвращенных данных интерфейса недостаточно, и некоторые поля отсутствуют, что приводит к необходимости запрашивать второй интерфейс, проблема в обоих случаях в том, что лишние сетевые ресурсы тратятся впустую)вопрос. Я не думаю, что это вообще оправдание для разработки плохих сервисов (на самом деле проблема в том, что если разработчик всегда был лохом, его сервис GraphQL вдруг не может оказаться полезным). Это легко исправить, просто добавьте службу перед исходной службой — GraphQL выполнит эту работу, но подойдет и что-то еще. Проблема не в чрезмерных запросах, а в центральной службе.а такжеИсправить проблемы с кэшированием.

Scruffles360(12) Ответ:

Чрезмерные запросы действительно являются проблемой. Когда у вас есть сотни клиентов, каждый из которых вызывает вашу систему по-своему, добавление свойства к остальным API является огромной неэффективностью. Многие люди предлагают предоставлять разные фасадные интерфейсы для мобильного клиента и веб-стороны, но это не очень масштабируемо. В мой проект звонят сотни клиентов, каждый из которых немного отличается тем, как и что он просит.

Крупные компании и GraphQL

Всем, кто интересуется Facebook, Netflix, Coursera и другими крупными компаниями, а также их использованием GraphQL. За этоgraphql-vs-restВ комментариях на Reddit мы можем найти две основные причины в качестве статуса автора. Первый поднятый комментарий был самым популярным, который я нашел.

В начале 2010-х количество мобильных пользователей резко увеличилось, и возникли некоторые проблемы, связанные с маломощными устройствами и медленными сетями. REST — не лучший выбор для решения этих проблем;
По мере роста использования мобильных устройств растет и количество различных интерфейсных фреймворков и платформ, на которых выполняются клиентские приложения. Поскольку REST недостаточно гибок, сложнее разработать единый API, отвечающий потребностям всех конечных приложений.

Greulich(62) Ответ на эту статью:

Это слишком далеко от темы, чтобы иметь смысл. Другой способ структурирования запросов не сделает сеть, в которой находятся эти запросы, ни лучше, ни хуже. Я думаю, что описание автора — это конечная точка, а не API, потому что любая конечная точка, сколько бы ни было конечных точек, — это только часть API. Если предположить, что это так, то почему нам нужна только одна конечная точка?

Scruffles360(16) Ответ Грейлиху:

Первые два пункта в статье не очень удачно сформулированы, но все же верны. REST API могут быть универсальными, многоразовыми или специально разработанными для известных клиентов. В первом случае, когда вам нужно снова обращаться к системе, чтобы получить больше данных(Примечание переводчика: упомянутая выше неполная выборка)(особенно в сетях с высокой задержкой, как у нас было на мобильных устройствах 10 лет назад), вы не получите хорошей производительности. Если вы делаете API для конкретного клиента, вы, очевидно, столкнетесь с проблемами масштабируемости.

Суммировать

Есть что сказать или выбрать, когда дело доходит до выбора правильного обзора, чтобы обобщить состояние GraphQL.На сегодняшний день самые популярные материалы на Reddit — тематические исследования Facebook или Netflix., но комментариев к этим материалам не так много. Это дает нам хорошее представление о том, что Reddit думает о GraphQL. Подумав о повседневной жизни разработчиков, я не могу игнорировать то, что написал Kdesign (36):

GraphQL делает вашу работу безопаснее, это точно.

Вам придется потратить время на то, чтобы найти, где находятся данные во всех N слоях между внешним интерфейсом и фактическим хранилищем данных.

Kollektiv(44) перечисляет множество вопросов по GraphQL:

Ограничение частоты запросов и оценку разрешений сложно реализовать.

То, как работают типы и загрузчики данных, группирует запросы без написания полного модуля, затрудняет эффективную привязку запросов к уровню базы данных.

Валидация проверяет только тип, поэтому вам по-прежнему нужна какая-то схема JSON для выполнения других проверок формата.

Запросы GraphQL допускают только левые соединения, поэтому воссоздание SQL, такого как INNER JOIN, плюс фильтрация становится сложной задачей.

Разбивка на страницы (объединения), навязанная такими фреймворками, как Relay, по-прежнему беспорядок.

О моем первоначальном исследовании GraphQLSwiftOneSpeaks(24) написал:

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

Наконец, я выбралMando0975(28) резюмируя эту статью:

Разработка всегда связана с выбором правильного инструмента для работы. GraphQL — это не панацея. REST не умер, и GraphQL не собирается его убивать.

Каков ваш опыт работы с GraphQL?

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.