Технологический подход: в каких аспектах обеспечивается синергетическая эффективность интерфейсов и серверов?

Авторские права принадлежат автору. Для коммерческой перепечатки, пожалуйста, свяжитесь со Скоттом для получения разрешения, для некоммерческой перепечатки, пожалуйста, укажите источник.

За последние два года, будь то на собеседованиях или в автономном и онлайн-режиме, Скотт познакомился со многими передовыми студентами.По причинам команды, личным причинам, карьерному росту, техническому направлению и даже семье и т. д. между идеальной страной и реальность , Между отказом и настойчивостью, мы постоянно колеблемся, и мы опечалены. Вы можете поговорить со мной о юге и севере, чтобы лучше понять судьбу инженеров, увидеть и услышать больше, Скотт WeChat : кодирование мечты. В этой серии 18+ статей (15+ статей в начале и будет расширено до 15+ статей в будущем).30 статей - нажмите на эту ссылку), это шестая разминка [обновил и дополнил старую статью с большим количеством просмотров], если вам интересна более поздняя статья, то можете кликнуть подписаться, а потом переслать в круг друзей, буду доволен .

текст начинается

Увеличение скорости железных дорог Китая относится к тому, что с 1997 по 2007 год китайские железные дороги осуществили в общей сложности шесть крупномасштабных повышений скорости.В 1993 году, до увеличения скорости, средняя скорость движения поездов по стране составляла всего 48,1 км/ч. выделенная высокоскоростная пассажирская линия имеет максимальную скорость 350 км.Сегодня огромная система координации высокоскоростных железных дорог намного сложнее, чем раньше, и эффективность диспетчеризации и перевозки также переворачивается с ног на голову.

Технологическая революция приведет к большим изменениям в организационной структуре, а также принесет новые возможности и новые вызовы для координации между организациями, что также верно для интернет-компаний. Когда мы говорим об интернет-компаниях, мы всегда думаем о словах «гибкий», «быстрый», «легкий» и «подрывной».На самом деле, за исключением некоторых отделов головных компаний-гигантов и некоторых небольших и красивых малых и средних предпринимательских команд, компании, которые действительно могут Быть гибкими не так хороши, как предполагалось. Этим компаниям не только не хватает гибкости и эффективности для постоянной оптимизации мышления и осознания организационной модернизации, но и не хватает мужества свергнуть и начать заново с самореволюцией. Поэтому 996 свирепствует и можно полагаться только на рабочую силу и время, чтобы компенсировать недостаток эффективности и способностей, чтобы добиться так называемой быстрой итерации продукта.

На самом деле, для продукта может быть достигнута непрерывная и правильная быстрая итерация.На это влияет множество факторов, таких как: принятие решений и их выполнение бизнес-командой, отраслевые знания менеджера по продукту, управленческие способности менеджера по продукту. руководитель проекта, проектный опыт инженера, разница между фронтендом и бэкендом, совместная работа и т. д. От стратегического проектирования на высшем уровне до понимания и продвижения руководства, до разработки и выполнения процессов на переднем крае, любой сбой звена в любом звене приведет к проблемам в направлении или скорости итерации продукта, и точка зрения инженера проста. чтобы идти спереди назад.Слева направо, изнутри наружу, часто не хватает нисходящей перспективы.Мы фокусируемся на пути оптимизации фронтенд и бэкэнд совместной работы.

Ключевой фигурой процесса НИОКР является менеджер проекта.

Это большой проектный процесс исследований и разработок, которому мы следуем в технологическом отделе Xiaocai, который часто является линейным:

Среди них на этапе разработки, который тесно связан с инженерами переднего и заднего плана, существует большая стоимость сотрудничества на уровне стыковки данных, Мы рисуем этот линейный процесс следующим образом:

Давайте взглянем на красные, проектирование системы, которое включает в себя создание проекта на стороне сервера Java, построение скелета и разделение сервисов. структура базы данных и таблицы.Эти таблицы выше Какие поля . Затем дизайн интерфейса, одноклассники по серверу предоставят документацию по интерфейсу, например, он предоставит вам пять интерфейсов, каждый с 15 полями, а затем войдет в интерфейсную и внутреннюю стыковку, а затем поможет вам сделать mock data , а затем интерфейс реконструирует стиль страницы на странице, затем корректирует поддельные Mock-данные, а затем переключается на официальный интерфейс после настройки процесса взаимодействия со страницей, что, вероятно, и является этой процедурой. Здесь есть много стеков инструментов, и можно использовать много сторонних инструментов с открытым исходным кодом.Затем мы обнаружили, что передняя и задняя часть заблокированы на этом этапе, и блокировка не может быть решена в течение многих лет, потому что контроль дизайна интерфейса в руках сервера, а фронтенд не знает сколько интерфейсов дадут, а то во время обзора интерфейсов, 15 минут или час, фронтенду в принципе сложно понять бизнес смысл за каким полем , а потом приходится повторно связываться с одноклассниками сервиса для подтверждения, из-за блокировки в этом пункте.В результате вышеперечисленные три проблемы решаются плохо.

Часто возникает проблема с итерацией продукта, может быть проблема в ссылке на картинке выше, поэтому нам понадобится сильный и надежный PM для более тщательного управления проектом, и в то же время техническая команда также должна возлагать на менеджеров по продукту и операции.Давление, чтобы выжать самые реальные потребности, здесь сильно зависит от деловых способностей менеджера проекта и способности проекта, чем надежнее менеджер проекта, тем более эффективной и разумной будет итерация проекта, в противном случае может быть бесчисленное множество подводных камней.

Внедрив сюда более надежного менеджера проекта, мы можем значительно снизить точки риска в процессах front-end и back-end и R&D pre- и post-production, а итерация будет более ритмичной, а затем спуститься на соединение на уровне интерфейса данных и пользовательского интерфейса.Показывая эффективность, менеджер проекта беспомощен.

Стоимость синергии и эффективности уровня представления

В сочетании с мультитерминальным отображением разнообразных отчетов первоначальные затраты на НИОКР были высокими.С точки зрения внешнего интерфейса это выглядело так:

Во-первых, это синхронизация отчетов между несколькими терминалами. Сейчас вы разрабатываете внешний интерфейс, и вы можете разрабатывать небольшие программы, приложения и ПК. Терминалов будет несколько. Для сценария нашей компании наш терминал более сложный, и мы может потребоваться открыть отчеты в ERP. , открыть отчет в приложении и открыть отчет в апплете, но измерения, раскрываемые отчетом для людей с разными разрешениями, разные, но по сути следующий источник данных один и тот же, тогда мы можем разработать множество интерфейсов. Чтобы соответствовать различным приложениям, нереально полагаться исключительно на внешний интерфейс для нарезки и сборки данных.

Второй - многомодульное совместное использование между несколькими терминалами.Этот модуль еще не является компонентом.Например,есть пользовательский модуль,модуль заказа,модуль логистики.В каждом модуле может быть один или два компонента.Базовый данные могут по-прежнему быть одинаковыми или двумя одинаковыми, но рендеринг пользовательского интерфейса на разных терминалах отличается. Потом нам сложно разделить данные между этими модулями.Мы разрабатываем компонент на разных концах и привязываем интерфейс.Этот компонент берется в другой, и при его использовании в том модуле обнаруживается, что он не работает. , что тоже большие затраты.

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

Абстрактные три вопроса, собственно эти три:

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

Во-вторых, это дублирование Mock-обязанностей. Я также знал, что многие компании в отрасли создали свои собственные фиктивные инструменты и платформы. Мы всегда пользовались услугами сторонних разработчиков. сервер идет на сервер.обслуживание, но короче есть стоимость совместной работы, и кто за нее отвечает пока неясно. После того, как одноклассники на стороне сервера закончили издеваться над вами, вы, наконец, можете успокоиться и заняться основным развитием бизнеса, но обнаружили, что поле необходимо временно скорректировать, поэтому вы настроили интерфейс, но забыли обновить фиктивный документ, фронт -end не знал об этом, перейдите к следующим двум Пара людей обнаруживает, что поля не совпадают, что является типичной проблемой совместной работы рабочего процесса.

Последний вопрос, это же относится и к компании toB или toC, что является отчетом.Отчет может быть просто нужен.Для руководства фактически необходимо видеть весь масштаб,тоннаж,логистику,инвентарь компании транзакции за прошедшую неделю и месяц Данные наблюдений разных размеров. Когда бизнес-стиль изменится, размеры отчета также изменятся.Традиционная разработка отчета требует одного внешнего и внутреннего интерфейса.Сервер обрабатывает базу данных, запросы между таблицами и базами данных и обеспечивает стандартную структуру полей.Внешний интерфейс просто помещает его в таблицу Table. , это дело очень простое, но оно может быть запланировано на один день, два дня или три дня, и скорость создания отчетов может быть очень ограничена.

Возможен ли GraphQL в качестве решения?

С точки зрения совместной работы и эффективности первое решение, которое мы попробовали, было через GraphQL, От небольшого теста в 2017 году до реализации определенного масштаба в первой половине 2018 года у нас также было много обменов с детской обувью в отрасли. В то время мы собрали следующие вопросы:

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

В ответ на вопрос только сейчас давайте сначала сделаем песню Tak в своей собственной бизнес-сцене, технологическое решение выберет его всем. Наше текущее решение находится на воротах, совокупная служба, интегрированная с GraphQL, а второй архитектор расскажет о конкретной архитектурной диаграмме, которая отдельно от этой точки. Наш идеальный метод доступа GraphQL должен быть встроен внутрь внутри с тем же уровнем шлюза, но теперь наша реализация, учитывая быструю бегущую, временно поставить его в шлюз, это аутентификация для него с безопасностью слишком много затрат на разработку, я Дадут ему ворота, чтобы сделать это, поэтому только оно только агрегация данных, посредством трансформации системы, мы также получили некоторые преимущества:

Тогда в 2016 и 2017 было всего 50 отчетов, разработанных всей компанией за более чем 2 года, и скорость разработки отчетов стала узким местом, когда мы выявили это на конце через GraphQL, включая некоторые сборочные действия на стороне сервера, теперь мы предоставляем Разработана система визуального редактирования отчетов.Эта система ориентирована на менеджеров по продуктам и операциям, а также на серверных инженеров.Они настраивают ее через визуальный интерфейс, отчет генерируется, и эффективность разработки отчетов напрямую разблокируется. После того, как система будет подключена к сети, 200 Multiple report удовлетворит потребности всей компании в отчетности.

Есть интересный случай.Продакт-менеджер провел встречу с бизнес стороной.Бизнес сторона сказала:Мне нужно посмотреть отчетные данные некой СТО за неделю.Хочу сделать запрос,и мне это нужно индикатор. Потом, еще до окончания встречи, продакт-менеджер закончил отчет и сразу ушел в интернет, теперь вывод отчета идет в таком ритме. Создав эту систему, мы обнаружили, что GraphQL может принести нам большое удобство, поэтому мы продолжили копать глубже, и ценность GraphQL продолжала снижаться со стороны приложения на сторону сервера. предыдущий отчет Система большая (возьми) таблица (таблица) брат (сетка), что является омонимом взятия таблицы Excel, вот мой шурин, продукты компании, они все родственники.

Brother-in-law — это решение для сборки данных, которое мы сегодня обсуждаем. Благодаря ему небольшой ежедневный проект для одного человека, который обычно занимает 4 дня, теперь может быть сокращен до 3 дней. задействованы люди на стороне и стороне, тем ниже стоимость стыковки с несколькими людьми.Многие, благодаря этому решению, соответствующие функции передней и задней частей также претерпели некоторую эволюцию и в то же время оказали некоторое положительное влияние на два вида работы:

После окончания распродажи мы поговорим о том, как построить такую систему, а также вкратце познакомим всех со знаниями GraphQL:

Прежде всего, давайте взглянем на систему агрегации данных моего зятя, где она находится во всей нашей системной архитектуре. На диаграмме видно, что он находится посередине нашего шлюза и внутренней службы данных. Как только что объяснил Скотт, сам наш шлюз уже существует, поэтому он выполняет такие функции, как аутентификация и безопасность. Поэтому, когда мы выполняют услуги по агрегации данных, мы размещаем эту услугу за шлюзом. Почему он называется GPM?Полное название — GraphQL Pipe Manager, система, обеспечивающая сборку данных, предоставляемых серверными службами.

Это общая структурная схема всей нашей внутренней архитектуры GPM, разделенная на две части: одна часть — это формальная служба, вы можете видеть, что формальная служба относительно проста, потому что мы хотим обеспечить стабильность формальной службы данных, поэтому мы пытаемся упростить его. Другая часть немного сложнее, это служба разработки.В службе разработки мы можем редактировать тип и управлять им, затем тестировать его в службе разработки и, наконец, применять его к нашей службе формальных данных.

После представления общей ситуации с нашим использованием GraphQL, поскольку некоторые из присутствующих студентов, возможно, раньше не сталкивались с GraphQL, я сначала расскажу, что такое GraphQL.Полное название GraphQL — Graph Query Language, а официальный слоган — « Для вашего API «Настраиваемый язык запросов», который объясняется традиционным способом: это эквивалентно обработке набора всех ваших серверных API как базы данных, пользовательский терминал отправляет оператор запроса, ваша служба GraphQL анализирует оператор и передает ряд правил Возвращает результаты запроса данных на терминал из вашей «базы данных API», а GraphQL эквивалентен языку запросов для этой системы, точно так же, как SQL для MySQL.

Каковы преимущества использования GraphQL

После непродолжительного периода практики Сун Сяокай обнаружил, что использование GraphQL дает нам пять удобств: одно — это однократная запись, второе — отображение и написание документов, а третье — более характерное, то есть избыточности данных можно избежать, с использованием GraphQL.Четвертый момент заключается в том, что агрегация данных является наиболее важной функцией самой системы, а последний пункт — имитация данных, что эквивалентно большой добавленной стоимости.

Однократная

Давайте сначала поговорим о единственной записи. В традиционном RESTful API и клиентская часть, и серверная часть должны управлять API: одна — это управление версиями, а другая — управление путями, что очень хлопотно и увеличивает сложность управления проектом. Но если вы используете GraphQL, вам нужна только одна точка входа. Я только что упомянул, что GraphQL эквивалентен базе данных.У него есть только одна запись.Нам нужно только получить доступ к этой записи, отправить оператор, который мы хотим запросить к этой записи, а затем мы можем получить соответствующие данные, так что это один endpoint + Такая структура для диверсифицированных методов запросов.

Задокументировано

Второй момент — это документация, хотя документация здесь не может полностью заменить традиционную документацию, но в определенной степени может нас облегчить. Для традиционного управления документами RESTful API на рынке существует множество инструментов, таких как Swagger, RAP с открытым исходным кодом Alibaba и showdoc. Но есть определенная стоимость обучения при использовании этих инструментов управления документами API. Как и Swagger, ветеранам может быть несложно использовать его, но разработчикам, которые только начинают, требуется немного времени. Затем возникает головная боль «API и синхронизация документов» при использовании этих платформ.Во многих случаях для ее решения нужно делать API и плагины синхронизации документов.

Если вы используете GraphQL, вы можете в определенной степени решить некоторые проблемы документов API: когда мы определяем тип GraphQL, мы можем добавить описание к типу и атрибутам типа, что эквивалентно аннотированию типа. тип скомпилирован Вы можете увидеть детали типов, которые мы редактировали на соответствующих инструментах.Например, тип Статья в примере, его описание "статья".Какие его атрибуты и каковы значения будут отображаться для всех, пока мы стандартизируем тип письма во время разработки, и отображение всего документа более стандартизировано.

У Graphql есть замечательная особенность, то есть каждый тип graphql фактически эквивалентен Collection в Mongo или MODEL внутри Mongoose, и каждый тип отношений также может быть реализован с помощью инструментов. При такой модели в системе она соответствует тому, что выделено ее взаимосвязью.

Связь:APIs.guru/graph up - снова ВО...

Давайте продемонстрируем это здесь.Вы можете отправить его, чтобы увидеть GraphQL API, открытый в Github API 4.0, который предоставляет все внешние типы Github. Вы можете видеть, что определения и пояснения, соответствующие каждому типу, отображаются слева. Каждый тип имеет соответствующее отображение диаграммы UML, которая является относительно большой и сложной диаграммой UML. Основной тип, который мы в основном используем, на самом деле является типом репозитория. Мы видим, что этот тип относительно сложен, и в то же время он также является относительно основным. С ним связано много типов. Если мы ссылаемся на открытый API Github 4.0, мы можем разрабатывать соответствующие плагины на Github.

Избегайте избыточности данных

Третье преимущество использования GraphQL заключается в том, что он позволяет избежать избыточности данных. У нас есть примерно три способа справиться с избыточными полями данных в традиционном RESTful:

Во-первых, выбор внешнего интерфейса не должен отображать эти поля;
Второй — либо сделать средний слой (BFF) для фильтрации этих полей, а затем вернуться в терминал для их отображения;
Третий более традиционный и более хлопотный, и он может не вступить в силу.Это соглашение между интерфейсом и сервером.Если поле этого интерфейса больше не нужно, вы можете обсудить с бэком -end, чтобы удалить это, но есть ситуация, которая может быть. Избыточные поля не могут быть удалены, т. Эта страница также может использоваться на другой странице, может использоваться в этом приложении и может использоваться в другом приложении. " интерфейс, чтобы справиться с этой ситуацией для удобства. Со временем было обнаружено, что поля избыточны, но удаляйте их небрежно. терпеть это.

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

Возьмем это на примере PPT: мы собираемся взять статью с id 1. Если мне нужны только id и контент, и я указываю эти два поля в запросе, то возвращаются id и контент. id и контент. Когда мне нужна информация об авторе, мне нужно только указать автора в запросе, и GraphQL вернет информацию об авторе. Таким образом, внешний интерфейс может решить, какие данные он хочет вернуть.

Множественная агрегация данных

Самым важным моментом, конечно же, является агрегация данных.Существует несколько решений для агрегации данных при использовании традиционных методов RESTful:

Интерфейсный сервер инициирует запросы данных по отдельности для нескольких источников данных на этой странице, а затем отображает их один за другим, что может привести к несинхронизированной загрузке данных страницы.
Во-вторых, разработать средний уровень (BFF) для сборки данных, который используется для сборки данных, предоставленных серверной частью, и последующего возврата их во внешний интерфейс.
Также есть решение, которое Сун Сяокай использовал на раннем этапе, то есть студенты back-end пишут API для страниц, так называемый связующий код, чтобы сшивать данные каждого сервиса и возвращать их во front-end.

Если это третий случай, нам нужно будет поддерживать множество проектов и множество API, которые нам нужно поддерживать. Но если вы используете GraphQL, ни одной из этих проблем не будет, потому что он по своей природе поддерживает сборку данных.

Почему он создан для поддержки сборки данных? Позвольте мне попытаться объяснить это с точки зрения принципа выполнения GraphQL. Это общий процесс выполнения GraphQL. Первым шагом является проверка стандартов, которые необходимо выполнить для GraphQL, и в то же время проверка легитимности запрашиваемого оператора запроса. Второй шаг — создание выполнения контекст. Ключевые моменты находятся в третьем и четвертом шагах. Третий шаг - получить поля, которые будут запрошены оператором запроса, который здесь называется полями. Все поля, которые необходимо запросить, могут быть получены с помощью алгоритма в операторе запроса. Здесь мы можем объяснить, как только что упомянутый GraphQL может избежать избыточности возвращаемых данных. После получения всех полей, которые необходимо запросить, четвертым шагом является выполнение своего преобразователя для каждого поля.Вы можете получить данные, соответствующие полю, из данных, возвращенных преобразователем, и, наконец, отформатировать результат и вернуть его.

На четвертом шаге позвольте мне объяснить, что в GraphQL существует понятие типа, называемое типом.Каждый тип соответствует одному или нескольким полям.Каждое поле привязано к распознавателю.Функция этого распознавателя заключается в получении полей соответствующих данных. В соответствии с только что упомянутым примером, таким как тип статьи, он имеет четыре поля: идентификатор, автор, содержание, комментарий. Каждое поле соответствует распознавателю. И этот преобразователь на самом деле может быть переопределен разработчиками.Если он не определен, GraphQL предоставит преобразователь по умолчанию.Например, тип поля автора статьи — пользователь, а пользователь может быть получен из пользовательской службы, поэтому мы можем использовать автор Переопределите преобразователь полей для получения информации о пользователе через UserService. То же самое верно и для следующих комментариев.Мы можем получить данные комментариев через CommentService, чтобы при запросе этой статьи мы могли получить не только данные самой статьи, но также информацию об авторе и информацию о комментариях через UserService и CommentService. сборка возвращается клиенту, так что цель использования GraphQL для сборки данных достигнута.

Удобный макет данных

Пятый пункт — это дополнительный пункт, мы можем правильно использовать GraphQL для имитации данных. Так как же использовать GraphQL для мока?

Типы GraphQL можно условно разделить на два типа:

Скалярный тип, как и распространенный язык разработки, предоставляет скалярные типы, такие как Int, Float и String. Этот тип также использует преобразователь в GraphQL. Мы можем переопределить его преобразователь для достижения скалярного типа. mock, например, какой диапазон возвращается Int, каков диапазон, возвращаемый Float? Каков формат возвращаемой строки? Ждать. В то же время, для некоторых простых, но регулярных типов данных, которые мы обычно используем в разработке, таких как номер мобильного телефона, адрес изображения, идентификационный номер, идентификационный номер, мы также можем использовать пользовательские скалярные типы для имитации данных.
Второй — это общий тип, такой как тип статьи в только что приведенном примере. Под общим типом может быть несколько полей. Тип данных, соответствующий каждому полю, может быть общим типом или скалярным типом. Этот тип также может имитировать , если мы сделаем правильный макет скалярного типа, данные макета, такие как Article, будут сгенерированы автоматически.

Еще одно удобство использования GraphQL для фиктивных данных заключается в том, что классические фиктивные данные можно легко использовать повторно. Например, вы можете использовать эту функцию при запросе поля author типа User под статьей в только что приведенном примере, потому что тип информации о пользователе (User) используется не только для автора статьи, но и для автора комментарий, поэтому мы ориентируемся на тип пользователя. Создайте фиктивные данные. Эти фиктивные данные можно использовать при запросе автора статьи и автора комментария. В то же время мы также можем сыграть некоторые трюки при возврате фиктивных данные, такие как случайный возврат информации о пользователе из нескольких пользовательских данных, или возврат соответствующих поддельных данных в соответствии с условиями запроса и т. д.

Использование GraphQL для имитации данных имеет несколько преимуществ:

Одним из преимуществ является то, что фиктивные данные идут вместе с типом, когда мы изменяем тип, его фиктивные данные также будут изменены синхронно, и не будет ситуации, когда фиктивные данные и тип не синхронизированы;
Второе преимущество заключается в том, что легко получить мелкозернистые фиктивные данные Принцип только что был объяснен, что может значительно повысить эффективность нашей разработки.
Третье преимущество заключается в том, что фиктивные данные можно использовать повторно, что экономит время разработки.
Последний момент заключается в том, что ответственность за фиктивные данные может быть разделена между интерфейсом и сервером. Или пусть внешний интерфейс сделает это сам, потому что обычно потребители фиктивных данных сами являются внешним интерфейсом, так почему бы не производить и не продавать его самостоятельно, экономя много коммуникационных затрат.

Форма системы агрегации данных GraphQL

Вот простая демонстрация окончательной формы GPM:

В GPM каждый сгенерированный тип будет отображаться в виде формы.Конечно, форма кода также будет представлена в определенном месте.Мы просто визуализируем каждый тип.Если вы используете его как новичок, вам нужно только чтобы нажать кнопку, чтобы добавить.Тип, укажите имя типа, заполните описание типа, установите время действия кеша в соответствии с фактической ситуацией типа и какие приложения привязаны к Songxiaocai. Затем для добавленного типа можно добавить в него поля, указав имя, тип, описание, время действия кеша и фиктивные данные поля.

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

При написании оператора запроса среда IDE автоматически запрашивает нас в соответствии с созданной нами схемой, точно так же, как при использовании обычной настольной среды разработки, и каждый тип документа можно увидеть во всплывающем окне справа. GPM делит IDE на IDE для формальных служб и тестовых служб, формальные IDE используются для запроса онлайн-данных. После того, как мы протестировали новые добавленные или измененные типы, мы можем развернуть официальную среду без повторной публикации GPM.

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

Мы также сделали некоторые дополнительные функции на GPM, потому что большинство микросервисов, предоставляемых нашим бэкендом, вызываются с использованием RSETful, поэтому мы специально сделали трассировку для запросов RSETful, здесь вы можете увидеть каждый в случае доступа RSETful.

Самое главное — отслеживать каждый запрос GraphQL. Видно, что когда мы выполняем такой оператор запроса, можно увидеть полученные результаты данных, время выполнения и детали этого оператора запроса, и в то же время мы также можем увидеть скорость запроса каждого поля. Для другого примера, такого как этот интерфейс, он связывает две службы, одна служба — это служба заказов на складирование, а другая — служба информации о поставщиках, так что вы можете видеть каждое поле запроса и отслеживать выполнение. Как насчет эффективности, вы можете скажите сторонним студентам оптимизировать в соответствии с результатом запроса.

И некоторые из наших пользовательских макетов, так выглядит весь GPM. Из-за нехватки времени я лишь кратко расскажу о том, как мы реализуем онлайн-редактирование и развертывание GraphQL.

Как реализовать онлайн-редактирование схемы

GPM построен с помощью Nodejs, поэтому это решение предназначено для nodejs. Решения на других языках необходимо изучить самостоятельно. Для достижения этой функции есть следующие ключевые моменты.

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

Второй ключевой момент — как модифицировать уже используемую схему: мы делим схему GraphQL на две части: одна — определение типа, а другая — преобразователь. Как упоминалось ранее, под каждым типом есть поля, и под каждым полем привязаны распознаватели.Фактически, мы можем отделить определение типа от распознавателя и в то же время выполнить соответствующее расслоение распознавателя. Иерархическая структура GPM такая, но это наша собственная наслоенность, на самом деле есть и другие решения, о которых лектор расскажет позже. Затем мы определяем преобразователь и тип и связываем их с некоторыми инструментами разработки для создания такой схемы GraphQL.

Суть typeDefs заключается в String, ключевой гордости и в том, как динамически генерировать Resolver.

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

Для достижения этой работы поколения необходимы следующие ключевые связи:

заменить схему
Абстрагируйте typeDefs и преобразователи в модели данных
Полноценно используйте контекст, упростите преобразователь и упростите динамическую генерацию.
выполнить извлечение параметров

Объединяя приведенный выше рисунок, нам сначала нужно упростить распознаватель.Сам распознаватель имеет фиксированную форму.Сигнатура функции на самом деле такая.Имя поля ниже типа имеет четыре параметра ниже имени поля, а затем возвращает результат:

Первый параметр — это результат запроса родительского типа, мы можем использовать некоторые данные запроса под его типом.
Второй - указанный параметр запроса
Третий — контекст выполнения (Context), о котором мы только что упоминали, мы можем вызывать различные связанные службы в контексте выполнения (Context).

Это общая форма распознавателя в GPM.Первым шагом является сборка параметров, а вторым шагом является использование контекста выполнения для вызова службы, чтобы данные можно было получить динамически, чтобы распознаватель мог быть динамически сгенерировано.

Проблемы с агрегацией данных с помощью GraphQL

Когда мы используем GraphQL, есть некоторые неизбежные проблемы, которые необходимо решить. Вот две проблемы, которых нельзя избежать:

Первое — это безопасность
Вторая — проблема медленного запроса

Для медленных запросов уже есть много решений, решающих эту проблему с кешированием в терминале, таких как apollo и relay. В сервисе GraphQL также есть кеш.Это механизм apollo, предоставляемый apollo, но его можно использовать только через стену, поэтому его можно использовать только в качестве эталона. Есть еще одно решение, которое Song Xiaocai использует в GPM: рационально использовать директивы, предоставляемые GraphQL, для замены распознавателей, чтобы кэшировать данные службы GQ. Существует также использование загрузчиков данных для пакетной обработки нескольких повторяющихся запросов.

Как сделать сбор данных

Наконец, есть гаджет, который бросается в глаза.Есть сбор данных при выполнении GraphQL.В экосистеме GQ есть GraphQL-расширение,которое очень просто использовать.Мы можем сослаться на него,чтобы сделать собственное расширение для отслеживать запросы GraphQL.Выполнение операторов, мы также можем использовать сторонние инструменты, такие как трассировка аполлона.

Наконец, давайте откроем наши умы вместе:

Сам GraphQL на самом деле является стандартом. Нам не нужно использовать официально предоставленный движок GraphQL. Мы можем реализовать свой собственный GraphQL в соответствии с нашей реальной ситуацией и вернуться к процессу выполнения GraphQL. Когда мы реализуем свой собственный движок GraphQL, следующее оптимизацию можно сделать:

Один и тот же запрос каждый раз нуждается в Vlidate?
Тот же запрос, не нужно ли их поля повторять, собирать
Есть ли еще место для оптимизации в execteFields?

На самом деле нет необходимости каждый раз проверять один и тот же оператор запроса, что может сэкономить немного времени запроса. Поскольку это один и тот же оператор запроса, нет необходимости собирать такую коллекцию полей, и можно использовать более простые способы, чтобы избежать повторного сбора полей. Существует также пункт повышения производительности.Официальный graphql-js выполняет распознаватель каждого поля циклическим и последовательным образом.Возможно ли выполнять распознаватель параллельно в соответствии с реальной ситуацией?

резюме

Наконец, подведем итог: когда Сун Сяокай использует GraphQL, чтобы попытаться оптимизировать эффективность внешнего и внутреннего интерфейса, он имеет следующие шесть характеристик:

Единая запись, односторонняя запись удобна для внешнего управления проектом, позволяя избежать громоздкого управления версиями API в бэкэнде.
Документ, этот документ может в определенной степени решить проблему синхронизации документов и чтения переднего плана.
Избыточность данных более удобна, поскольку снижает затраты на внешние и внутренние коммуникации.
Агрегация данных. GraphQL изначально поддерживает агрегацию данных. Поскольку каждый тип привязан к распознавателю, если вы определяете разные распознаватели, вы можете получать данные из разных служб и собирать данные из разных типов источников данных.
MOCK, должным образом передайте ответственность за MOCK интерфейсу или поддерживайте интерфейс и серверную часть вместе, и это относительно просто поддерживать. Так что MOCK нам удобен для разработки
Динамическое редактирование обеспечивает развертывание в реальном времени и гибкую разработку. Развертывание в режиме реального времени быстро реагирует на онлайн-данные

Для внешнего и внутреннего рабочего процесса сотрудничества Song Xiaocai вы можете интуитивно увидеть эти изменения:

От ссылки на дизайн интерфейса внешний интерфейс переходит к ссылке обзора структуры библиотечной таблицы в дизайне серверной системы.В это время вы можете не только понять распределение полей и бизнес-значение библиотечной таблицы, но и сделать некоторые предложения по дизайну библиотечной таблицы, чтобы помочь Сервер выводит более удобные типы и структуры полей для внешнего интерфейса, такие как точность и размерность.Хранятся ли эти два отдельно или разделены запятыми и хранятся как строка, это другое .
Сторона сервера экономит Mock, экономит дизайн и поддержку связующего API, экономит Mock, а сэкономленное время может быть сосредоточено на разделении базовой бизнес-системы, предоставлении более стабильных услуг данных и создании более надежной и надежной системы. совместимая базовая архитектура
Перед просмотром интерфейса интерфейс может абстрагировать большинство полей на пользовательском типе Mock of GraphQL (как только серверная сторона определит структуру таблицы библиотеки, возможность последующих изменений будет очень мала), в это время DOM может После того, как страница реализована, большинство полей-заполнителей заполнены. В окончательной структуре обе стороны проверят и отрегулируют специфику интерфейса в процессе проверки интерфейса.
Поскольку внешний интерфейс поддерживается границей домена сервера, он может инкапсулировать более гибкие компоненты для определенных доменов и комбинаций доменов. Масштабируемость компонентов может определяться конфигурацией, а не API.

По третьему пункту надо постоянно бегать по фронтенду и бэкенду.По четвертому пункту мы еще изучаем и пробуем, и напоследок хотим высказать некоторые мысли о том, чем занимается наша фронтенд команда.Я лично считаю это очень важно, особенно для начинающих команд. В коллективе кому бы вещи вроде бы ни принадлежали, в конце концов, вещи должны принадлежать компании.На кого бы продвижение технологий не повлияло или расшатывало интересы так называемой исходной позиции, лишь бы это было выгодно Эффективность команды R & D компании, это выгодно для технологии.Эволюция способствует ускорению бизнеса, поэтому мы должны решительно стараться. В конечном счете, за все наши действия платит компания, но, в конечном счете, это все еще мы.

Это то, чем мы поделились на GraphQLParty в июне 2018. Сегодня мы все еще применяем это во многих бизнес-сценариях, но мы также столкнулись с практическими трудностями.Самая большая трудность — это нехватка командного персонала, что мешает нам углубиться в оптимизацию. и реорганизуйте его, поэтому его ценность не была максимальной, но мы всегда были готовы продолжать делать это. это направление.

Наконец, в качестве статьи для разогрева, эта статья направлена на то, чтобы вывести следующие темы для всех: Соберите команды от 0 до 1 для автоматизации операций Процесс роста обобщается и выводится сообществу, помогая большему количеству небольших команд избегать обходных путей. В количественном выражении путаница, осадки и методический путь внешнего интерфейса Xiaocai собраны, что приносит команде больше творческих достижений. Взгляните на процесс управления командой/технологической эволюции/личностного роста с разных точек зрения и обсудите максимизацию ценности команды инженеров. Если вам интересно, наша фронтенд-команда Xiaocai вместе соберет коллективный разум, напишет и запустит буклет о фронтенд-карьере, техническом росте и росте команды и вернет его всем.Не забывайте оставлять комментарии и пожелания после статьи. О, и не забудьте добавить WeChat Ha Скотта: codingdream.

За последние два года, будь то на собеседованиях или в автономном и онлайн-режиме, Скотт познакомился со многими передовыми студентами.По причинам команды, личным причинам, карьерному росту, техническому направлению и даже семье и т. д. между идеальной страной и реальность, между отказом и настойчивостью, постоянно качаясь, грустно и тяжело, вы можете найти меня, чтобы поболтать о юге и севере, лучше понять судьбу инженеров, увидеть и услышать больше, Скотт WeChat: codingdreamer , тоже можно прийти