GraphQL та мікросервісна архітектура

Я намагаюся зрозуміти, де саме GraphQL найкраще використовувати в архітектурі мікросервісу.

Існує певна дискусія щодо наявності лише однієї схеми GraphQL, яка працює як шлюз API, який надає запит цільовим мікросервісам та примушує їх відповідати. Мікросервіси все ще використовуватимуть протокол REST / Thrift для комунікаційної думки.

Інший підхід полягає в тому, щоб мати кілька схем GraphQL по одній на мікросервіс. Маючи менший сервер шлюзу API, який спрямовує запит до цільової мікросервісу з усією інформацією запиту + запит GraphQL.

1-й підхід

Маючи 1 схему GraphQL як шлюз API, буде мати зворотний бік, коли кожен раз, коли ви змінюєте вхід / висновок контракту мікросервісу, ми повинні змінювати схему GraphQL відповідно на стороні шлюзу API.

2-й підхід

Якщо ви використовуєте декілька схем GraphQL для мікросервісів, це має сенс, оскільки GraphQL виконує визначення схеми, і споживачеві потрібно буде дотримуватися введення / виводу, що надається з мікросервісу.

Запитання

• Чи вважаєте ви, що GraphQL підходить для розробки архітектури мікросервісів?

• Як би ви створили шлюз API з можливою реалізацією GraphQL?

Однозначно підхід №1.

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

Маючи спільну архітектуру нічого, це може здатися розумним з точки зору мікросервісів, але для вашого клієнтського коду це абсолютний кошмар, тому що кожного разу, коли ви змінюєте одну із своїх мікросервісів, вам доведеться оновлювати всіх своїх клієнтів. Ви обов'язково пошкодуєте про це.

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

Якщо ви не хочете використовувати REST для своїх мікросервісів, ви, звичайно, можете мати кожен з них GraphQL API, але у вас все ж повинен бути шлюз API. Причина, по якій люди використовують шлюзи API, полягає в тому, щоб зробити її більш керованою для виклику мікросервісів із клієнтських додатків, а не тому, що вона добре вписується в шаблон мікропослуг.

Дивіться статтю тут , де сказано, як і чому підхід №1 працює краще. Також подивіться на зображення нижче, взятого згаданої статті:

Однією з головних переваг наявності всього за однією кінцевою точкою є те, що дані можуть бути маршрутизовані ефективніше, ніж якби кожен запит мав власну послугу. Хоча це значення GraphQL, яке часто рекламується, зменшення складності та повзучість сервісу, отримана структура даних також дозволяє чітко визначити та чітко окреслити право власності на дані.

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

Наступна стаття дуже добре пояснює ці дві переваги разом з іншими: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Для підходу №2 насправді саме так я обираю, адже це набагато простіше, ніж підтримувати надокучливий шлюз API вручну. Таким чином ви можете самостійно розвивати свої послуги. Зробити життя набагато простіше: P

Існує кілька чудових інструментів для комбінування схем в одну, наприклад, graphql-ткач та графічний інструмент Apollo , який я використовую graphql-weaver, він простий у використанні та чудово працює.

Станом на середину 2019 року рішення для 1-го підходу тепер має назву " Федерація схем ", яку придумали люди Аполлона (раніше це часто називали зшиванням GraphQL). Вони також пропонують модулі @apollo/federationі @apollo/gatewayдля цього.

ДОДАТИ: Зверніть увагу, що за допомогою Федерації схем ви не можете змінювати схему на рівні шлюзу. Тож для кожного біта, який вам потрібен у вашій схемі, потрібно мати окремий сервіс.

Станом на 2019 рік найкращим способом є написання мікросервісів, які реалізують специфікацію шлюзу apollo, а потім склеїти ці сервіси за допомогою шлюзу, дотримуючись підходу №1. Найшвидший спосіб побудувати шлюз - це зображення докера на зразок цього. Потім використовуйте docker-compose для одночасного запуску всіх служб:

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

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

Недоліком є ​​тісний зв'язок між API-даними даних та службою оркестрування. Випуски вже не можуть бути атомними. Якщо ви утримаєтесь від введення зворотних порушень змін у своїх API даних, то це може спричинити складність лише під час скасування випуску. Наприклад, якщо ви збираєтеся випустити нові версії двох API-файлів даних із відповідними змінами в сервісі оркестрації, і вам потрібно буде повернути один з цих випусків назад, а не інший, то все-таки ви змушені будете повернути всі три.

У цьому порівнянні GraphQL та REST ви побачите, що GraphQL не настільки ефективний, як API RESTful, тому я б не рекомендував замінювати REST на GraphQL для API даних.

До питання 1, Intuit визнав потужність GraphQL кілька років тому, коли оголосив про перехід до однієї екосистеми API Intuit ( https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations -quickbooks-підключити-2017 ). Intuit вирішив піти з підходом 1. Недолік, про який ви згадуєте, насправді заважає розробникам вводити порушені зміни схеми, які потенційно можуть порушити клієнтські програми.

GraphQL допомогло підвищити продуктивність розробників різними способами.

1. Розробляючи нову мікросервіс для домену, інженери (бекенд / frontend / зацікавлені сторони) узгоджують схему для суб'єктів домену. Після схвалення схеми вона об'єднується з основною доменною схемою (універсальною) і розгортається на Gateway.Front кінцеві інженери можуть почати кодування клієнтських додатків за допомогою цієї схеми, тоді як інженери-сервери реалізують цю функціональність. Наявність однієї універсальної схеми означає, що немає двох мікросервісів із зайвою функціональністю.

2. GraphQL допоміг клієнтським програмам стати простішими та швидшими. Хочете отримати дані з / оновити дані в декілька мікросервісів? Всі клієнтські програми повинні зробити один запит GraphQL, і рівень абстракції шлюзу API подбає про отримання та збір даних із різних джерел (мікросервісів). Рамки з відкритим кодом на зразок Apollo ( https://www.apollographql.com/ ) прискорили темпи прийняття GraphQL.

3. Оскільки мобільний телефон є першим вибором для сучасних додатків, важливо розробити для менших вимог пропускної здатності даних від нуля землі. GraphQL допомагає, дозволяючи клієнтським програмам запитувати лише конкретні поля.

До питання 2: Ми створили спеціальний рівень абстракції на шлюзі API, який знає, якою частиною схеми володіє, яка служба (постачальник). Коли надходить запит, рівень абстракції передає запит відповідній службі. Після того як базовий сервіс повертає відповідь, рівень абстракції відповідає за повернення запитуваних полів.

Однак сьогодні існує кілька платформ (сервер Apollo, graphql-yoga тощо), які дозволяють побудувати шар абстракції GraphQL за короткий час.

Я працював з GraphQL та мікросервісами

Виходячи з мого досвіду, для мене працює комбінація обох підходів, залежно від функціональності / використання, я ніколи не матиму єдиного шлюзу, як у підході 1 ..., але я створюю графік для кожної мікросервіси як підхід 2.

Наприклад, грунтуючись на зображенні відповіді від Енаят, я б робив у цьому випадку, щоб мати 3-х графічні шлюзи (не 5, як на зображенні)

• Додаток (продукт, кошик, доставка, інвентар, необхідні / пов'язані з іншими послугами)

• Оплата

• Користувач

Таким чином, вам потрібно приділити додаткову увагу дизайну необхідних / пов’язаних мінімальних даних, що підлягають впливу залежних служб, таких як маркер аутентифікації, userid, paymentid, статус платежу

Наприклад, у моєму досвіді у мене є шлюз "Користувач", у цьому GraphQL у мене є запити / мутації користувачів, увійдіть, увійдіть, вийдіть, змініть пароль, відновіть електронну пошту, підтвердіть електронну пошту, видаліть акаунт, редагуйте профіль, завантажте зображення і т.д. ... цей графік сам по собі досить великий !, він відокремлений, оскільки в кінці інших служб / шлюзів піклується лише про отриману інформацію, наприклад, userid, ім'я чи маркер.

Цей спосіб простіше ...

• Масштабування / вимкнення різних вузлів шлюзів залежно від їх використання. (наприклад, люди не завжди можуть редагувати свій профіль або платити ..., але пошук продуктів може використовуватися частіше).

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

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

ОНОВЛЕННЯ:

У мене в Інтернеті є кластер Kubernetes, який використовує той самий підхід, який я описую тут з усіма перехідними програмами за допомогою GraphQL, усі відкриті джерела, ось головне сховище: https://github.com/vicjicaman/microservice-realm

Це оновлення моєї відповіді, тому що я вважаю, що краще, якщо відповідь / підхід буде резервним кодом, який працює, і з ним можна звернутися / переглянути, я сподіваюся, що це допоможе.

Оскільки архітектура мікросервісу не має належного визначення, то для цього стилю немає конкретної моделі, але більшість з них матиме мало помітних характеристик. У випадку архітектури мікросервісів кожна служба може бути розбита на окремі невеликі компоненти, які можуть бути індивідуально налаштовано та розгорнуто, не впливаючи на цілісність програми. Це означає, що ви можете просто змінити декілька сервісів, не переходячи на перерозподіл додатків за допомогою розробки спеціальних програм мікросервісів .

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