привет ~ Уважаемые зрители Привет всем ~ В последнее время я увлекся практикой применения GraphQL. Как только приближается хакатон компании, я привлек двух небольших партнеров в сочетании с реальными бизнес-сценариями и поставил GraphQL в качестве промежуточного уровня. решение. ~Завершение проекта неплохое, и у меня есть более глубокое понимание GraphQL. Я буду записывать достижения всего процесса здесь.
Примечание~ Эта статья не посвящена изучению синтаксиса GraphQL, вы можете повернуть налево для изучения синтаксиса.портал. Но если у вас есть определенное понимание GraphQL и вы хотите знать, с какими проблемами вы можете столкнуться на практике, считается, что эта статья может вам немного помочь. Ниже приведен основной текст:
Дилемма в бизнесе
Поскольку вы хотите использовать GraphQL, вам все равно нужно понимать, что это такое:
GraphQL — это и язык запросов для API, и среда выполнения, которая удовлетворяет вашим запросам данных. GraphQL предоставляет полный, простой для понимания описания данных в вашем API, что позволяет клиентам получать именно данные, которые нужно без каких-либо избыточности, что облегчает топливо, чтобы API со временем можно использовать и может использоваться для создания мощных инструментов разработчика Отказ
Это не кажется сложным.Может быть, вы видели введение GraphQL и думаете, что его синтаксис очень сложен (я этого не отрицаю), но в конечном итоге он рожден для запросов. По сути, это что-то передать серверу.После того, как сервер интерпретирует эту часть информации, он возвращает вам соответствующие данные.Все грамматики служат этой цели.
После краткого введения в GraphQL я также вкратце расскажу об истории бизнеса. Настоящий бэкэнд-сервис нашей группы написан на C++, с тонким слоем Go в качестве шлюза и промежуточным слоем, отвечающим за связь между страницей и Серверная часть C++ и в то же время предоставляет базовые услуги, такие как расшифровка и аутентификация. Однако, поскольку узкое место бизнеса находится не во внешнем интерфейсе (что также приводит к относительно небольшому количеству голосов), серверная часть C++ часто ведет себя менее «делово» и не думает, что предоставление услуг для внешнего интерфейса является одним из ключи для работы. Заставляет их закрывать глаза на многое из того, что серверная часть может и должна делать. Неявное отношение серверной части в основном такое: «Дело не в том, что его нельзя использовать~». Но это негативно сказывается на качестве внешнего кода и эффективности НИОКР.
С точки зрения внешнего интерфейса текущая система имеет следующие проблемы:
- Избыточность интерфейса влияет на производительность конца страницы;
- Тело данных не стандартизировано, одно и то же значение различных интерфейсов, ключ может быть непоследовательным;
- Документ интерфейса сложно поддерживать, регистр ключа и тип значения в документе часто несовместимы, в документе есть задержка после изменения поля;
- Невозможно предоставить услугу Mock.
По разным причинам сложно вносить изменения в бэкэнд, поэтому давайте создадим его самостоятельно. новый средний слой, используяTypeScriptразработан, отобранEgg.jsДля кадра магия измениласьegg-graphqlЭтот плагин служит основой для службы GraphQL. Предоставляйте документы интерфейса спецификации в реальном времени, сервис 0-config Mock, динамическую настройку и горячее обновление и другие функции.
Вот несколько скриншотов функции и различия между ними до и после использования:
Документация по интерфейсу:
Настройте бэкэнд:
Перед использованием GraphQL на стороне страницы:
После использования GraphQL на стороне страницы:
Изменения, вызванные новыми услугами
Я считаю, что у всех есть четкое представление о преимуществах GraphQL.Через описание нового среднего слоя выше вы также можете почувствовать преимущества GraphQL. Я не буду вдаваться в количество слов, чтобы подробно описать экономию полосы пропускания, прирост производительности и другие преимущества переднего плана. Главное, что я хочу обсудить здесь, это то, что в конечном счете мы хотим высвободить производительность, так что же освобождает GraphQL?
Мы считаем:GraphQL может уменьшить конфликты между интерфейсом и сервером и позволить друг другу больше сосредоточиться на себе!
Хоть я и жаловался на back-end одноклассников выше, с другого ракурса их подход понятен. Это разумный дизайн, чтобы иметь единый интерфейс и фокус.Избыточный интерфейс из-за версии и потребности в нескольких терминалах, а служба Mock не имеет ничего общего с бэкэндом. Независимо от внешнего или внутреннего интерфейса, они думают о бизнесе со своей точки зрения и предлагают решения для бизнеса на основе собственных технологий. Но бизнес — это единое целое, а программисты делятся на фронтенды и бекенды. Серая зона между двумя концами, хотя и может улучшить возможности исследований и разработок на одном конце, довольно проблематична для другого конца. Так:
All problems in computer science can be solved by another level of indirection.
Поскольку с серыми областями трудно иметь дело, давайте абстрагируемся еще на один уровень! GraphQL появился ~ Он интегрирует и предоставляет большое количество функций, включая, помимо прочего: службу документов, фиктивную службу, единую запись, исключение избыточности, агрегацию данных и другие функции. Противоречие между фронтендом и бэкэндом разрешено, бэкенд может сосредоточиться на себе, предоставлять стабильные и надежные сервисы и больше не заботиться о данных, требуемых интерфейсным интерфейсом, и его значении; -end фокусируется на страницах и взаимодействиях и получает соответствующие данные по запросу со стабильными интерфейсами и четкими документами.
На мой взгляд, фундаментальное преимущество GraphQL заключается в том, что он позволяет каждому концу больше сосредоточиться на себе и более эффективно отделять друг друга.
тень на солнце
Раз есть свет, должны быть и тени.Настало время отказаться от использования GraphQL (смеется). Поскольку я довольно хлопотный и сдающийся человек, всякий раз, когда я сталкиваюсь с системой, которая работает хуже существующей или довольно громоздкой для внедрения, я автоматически думаю о том, подходит ли новая технология для текущей ситуации. Ниже приведены некоторые мысли о практическом процессе (недостатки, которые были выяснены: такие как кэширование, проблемы n+1 и т. д., здесь подробно не рассматриваются):
Использование GraphQL на среднем уровне может быть ложным предположением
GraphQL очень хорош, он четко определяет тип и значение каждого поля, и на основе этого расширяются такие функции, как документ-сервис, фиктивный сервис и устранение избыточности. Однако Xiao He также победил Xiao He. Как промежуточный слой, он, как правило, относительно легкий и тонкий. Как правило, необходимо только проверять и динамически пересылать контент. Однако GraphQL на самом деле довольно тяжелый. Это приводит к тому, что когда серверная часть изменяет поля, необходимо освободить не только серверную часть, но и средний уровень. Чтобы решить эту проблему, мы испробовали все средства для динамической настройки и горячего обновления службы GraphQL.Хотя эта функция реализована, она использует черную магию JavaScript.Как мигрировать на другие языки (например, Go, компания использует язык Go в приложениях Go) более зрелый), честно говоря, я действительно не знаю. Для оптимизации мерж-реквестов GraphQL — не единственное решение, Http2 также может решить проблему.
Неловкая ситуация в BFF
Если GraphQL используется не в качестве технологии пересылки среднего уровня, а в качестве основного языка запросов, запрашиваемого в BFF (Backend For Frontend), он столкнется с более неловкой сценой. В BFF внешний интерфейс управляет сервером, поэтому качество интерфейса фактически может управляться внешним интерфейсом. В настоящее время GraphQL — это только вариант, он не решает слишком много проблем, но затраты на его обучение и доступ не малы. Небольшое ощущение того, что ты слишком высок или слишком низок.
Оценка стоимости доступа
Стоимость доступа здесь относится не только к стоимости написания кода, связанного с GraphQL, но и к стоимости доступа к текущей системе компании. Из-за того, как GraphQL получает данные, существует возможность запроса большого количества данных в одно мгновение, что может легко перегрузить базу данных, но запрашивающий не имеет об этом представления. Это немного похоже на то, когда система электронной почты только появилась, пользователи забрасывали видеофайлы в электронные письма, хотя это было непреднамеренным действием, но это нанесло большой вред системе. В то же время, кто его заберет, тоже вопрос открытый. В конечном счете, это «крутая» фронтенд-технология, и бэкенд-студентам она не очень интересна. Однако для доступа требуются соответствующие возможности разработки, эксплуатации и обслуживания. Студенты, работающие с интерфейсом, могут не иметь достаточных возможностей для доступа. В конце концов, не каждый студент является полным стеком. Другие проблемы включают доступ rpc, контроль разрешений и многое другое. Прежде чем план будет реализован, все это необходимо тщательно оценить и нельзя слепо «гоняться за новым».
резюме
Подводя итог, GraphQL может принести нам много удобства, но стоимость его подключения не является низкой. Лично GraphQL принципиально проблемы не решает, но улучшает несколько грязных мест между фронтом и бекендом. Есть несколько соображений, которые следует принять во внимание, прежде чем принимать решение об использовании GraphQL. Он больше подходит для следующих ситуаций:
- Техническая нагрузка относительно невелика, и бизнес постоянно повторяется.
- Сервисный интерфейс представляет собой сложную или мультисовместимую версию сцены (например, системы отчетности, основанные на универсальном интерфейсе и т. д.).
- Интерфейс в порядке, но он очень чувствителен к сети.
Последнее спасибо@ScottСоответствующее руководство, хотя каждое из ваших предложений было реализовано другими способами (смеется) ~ Но оно, несомненно, расширило наш кругозор.
Вышеизложенное является небольшим личным мнением, спасибо всем зрителям за то, что увидели это. Легче сказать, чем сделать, надеюсь, эта статья будет вам полезна~ Спасибо!