You have a MACH! Розбираємось в архітектурних принципах

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

TLDR; MACH is yefa for Microservices-based, API-first, Cloud-native, and Headless principles for designing software applications.

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

Всім відомий REST, який по суті не є протоколом чи стандартом, а просто певною групою правил, яка при повному їх виконанні гарантує очікуваний результат, до якого всі звикли. Достатньо сказати «в мене комунікація по принципам REST» і ти вже розумієш, як усе побудовано (токени, свагер, ендпоїнти ...) Цих акронімів в IT вагони — MERN, SOLID, MVP і ось додається ще один :)

Що таке MACH

Тож MACH — це група архітектурних принципів, які при застосуванні разом забезпечують побудову системи, яка відповідатиме сучасним вимогам до програмного продукту.

Що ж то за вимоги такі? Ну, можна накопіпастити стандартих *-ilty (maintainability, scalability, deployability, saleability), але все зводиться до звичайного «щоб було легше, а не складніше».

Розшифровуємо принципи

Наразі всі ці принципи давно відомі і навіть трохи дивно їх описувати, бо це ж очевидно як день, але може якомусь джуну це буде корисним.

Microservices-based — ні, не треба все зразу писати на нано мікро-сервісах, просто треба проєктувати систему так, щоб бізнеслогіка була відділена одна від одної, наскільки це можливо (Aggregations form DDD). Писати код, намагаючись зробити гіпотетичне відокремлення цього функціоналу у незалежний сервіс легшим і з меншим впливом на загальний продукт.

API-first — функціонал, відкритий до користування через публічні контракти, які затверджуються до початку розробки, і змінюються тільки після ґрунтовного обдумування. Бо коли розумієш, чого очікують, то реалізується це легше.

Cloud-native — не забувати про акронім IaC та користуватись залізом від Andy Jassy \ Sundar Pichai \ Satya Nadella на вибір. І бажано не просто залізом, а інтегруватись з усією доступною кількістю сервісів та автоматизовувати усі доступні процеси. Погодесь, коли все автоматизовано, навіть деплой стає простіший за натискання однієї кнопки merge.

Headless — намагитсь не привязуватись до фреймвоків (фреймворки змінюються а for-цикли назавжди). Про побудову бекенду агностичного до фронтенду, це і так ясно. Але якшо експресовский req-res не протікає в контролери, то замінити його на фастіфай буде легше.

Може, в коментарях напишете, який принцип варто додати до стеку.

Тож що дає нам виконання всіх принципів MACH?

• Гнучке, але без хаосу у контрактах, рішення. Коли продакт-овнер затверджує зміну у контракті, а бізнес-логіка розділена та концентрована, можна забути про хаотичні рипання і естімейти овер 9000 для додання одної фічі.
• Коли їдеш на хмарі, то важко загрузнути у болоті старих технологій. Cloud-провайдер сам спонукає користуватись їх новими сервісами та не костяніти в технологіях, заодно хайрити розрабів буде легше.
• Скейлити мікро-сервіси в хмарі, це далеко не те саме, що адмінити 10 ящиків за балансувальником.
• Коли фреймворк — це плагін, то повідомлення про зупинку його підтримки не призведе до облисіння техліда.
• Автономна бізнес-логіка з автоматичними деплоями зробить щасливим будь якого скрам-майстра, спринти крутятся функціонал релізиться.

Може MACH щось забирає?

Як будь-який звід правил, він обмежує та змушує.

• Як мінімум, він змушує думати кожен раз, як комітиш чи не порушується якесь з правил. А змушення зайвий раз подумати — це вже хороший привід не користуватись ним.
• Headless-принцип обмежує архітектуру, змушує будувати додаткові механізми забезпечення меж між функціоналом (абстракції, DTO etc). А будь-які зусилля, витрачені не на реалізацію бізнес логіки, марні в очах продакт-овнера (і не тільки).
• Api-first — змінює процеси розробки, змушує нетехнічний персонал узгоджувати контракти API, забороняє девелоперу додати якусь потрібну йому властивість до респонзу.
• Глибока інтеграція з клаудом вимагає часу та зусиль на опанування його сервісів, знання доцільні лише для конкретного провайдеру і непотрібні для іншого.
• Суттєві інвестиції на старті у побудову автоматизованої інфраструктури CI\CD ще до початку побудови MVP йде врозріз з модерновою парадигмою коли після першого спринта вже треба віддавати продукт на апробацію для отримання зворотного зв’язку.

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

В умовах аутсорсу швидкість завжди важливіша за якість і простоту, але Езоп і Дядька Боб казали — шо go slow is faster, хз вірити їм чи ні.