If all you have is a hammer -
everything around looks like a nail.
Здається, перший технічний пост в блозі. Просто думки, які приходять в голову останнім часом. Всі вони апріорі суб’єктивні, і жодним чином не претендують на істинність.
Думка перша. Про JavaScript
Ви ж пам’ятаєте часи, коли ця прекрасна мова використовувалась для встановлення фокусів на елементах? Ви помітили, як Яваскрипт потихеньку став центром всесвіту у веб-програмуванні? Останні роки центр мас змістився в rich frontend, і на яваскрипті почало писатись буквально все. Швидко з’явились спочатку зручні ліби, а потім і охуєнні mvc-фреймворки, які допомагають писати все, аж до бекенду. Писати на мові, що взагалі-то не призначена для писання всього, а призначена скоріше для встановлення фокусів на елементах пейджа.
Це, звісно, гіпербола, але в цьому явно є велика доля правди. Непристосованість JS до серйозного програмування помітна неозброєним оком будь-кому, хто на ньому хоч щось хоч колись писав. Але альтернативи немає, бо SPA - тренд, який не зупинити, і який виглядає цілком логічно і слушно. Потреба в коді є, а інструменту, що відповідав би цим потребам - нема. В результаті програмування виглядає як ходіння п’яним по тонкому льоду з зарядженою рушницею в руках.
Останнім часом з’явився цілий клас фронтенд-погромістів, що займаються добуванням золота палкою-копалкою, обвішуючи її різноманітними аксесуарами і саморобними подєлками, що так-сяк допомагають використовувати цей застарілий і непристосований для видобування золота інструмент. В результаті палка перетворюється на монстра, а в копачів всі руки і душі вкриті ранами. Скільки це буде тривати - невідомо, бо хайпу на цю тему я наразі ніде не бачив. Можливо я просто помиляюсь, і все на фронтенді ок.
Думка друга. Про REST
На іншому кінці дроту, нажаль, все теж виглядає досить підозріло. З входженням світу в еру мікросервісів і SPA/rich_frontend з’явилась гостра потреба в концепції, яка б допомогла розробляти більш-менш схожий і уніфікований АРІ. SOAP занадто складний, XML-RPC занадто недорозвинений. І тут на сцену вийшов вуйко, і сказав:
Ось же є HTTP, я його робив - хороша штука. Давайте його юзати. Там все просто. Що вам ще треба, хлопці??
Але з часом в людей починає виникати все більше питань і все більше різновидів розуміння РЕСТу. Тепер він вже ніфіга не простий і ніфіга не однозначний. В нього тепер навіть є рівні, які, ясна річ, також ніде і нічим не стандартизовані, а просто начертані на скрижалях в апокрифі від Мартіна Фаулера. Поки що люди в основному схильні закривати очі на той факт, що РЕСТ постійно ковбасить, і по ньому немає жодного стандарту. Ми думаємо, що це є наслідком молодості ідеї, і ось-ось все утрясеться, і програмісти заживуть щасливим безтурботним життям. Не буде більше холіворів на тему правильного дизайну АРІ, і правильного розуміння абревіатури РЕСТ. Все буде стандартизовано і зрозуміло.
Або все буде інакше. Чи в правильному взагалі напрямку рухається спільнота, намагаючись стабілізувати і стандартизувати РЕСТ? В мене є підозра, що одна з первинних причин цієї ситуації полягає в тому, що адепт HTTP дещо штучно "натягнув" його на потреби програмістів. Як і JavaScript, HTTP ніколи не розроблявся для того, для чого його використовують зараз. І тому, ймовірно, він просто не може виконувати цю роль без постійних компромісів.
Природня для HTTP передача ресурсів-сторінок - це все ж таки не те саме, що віддалені виклики в розподілених системах. І тому CRUD в РЕСТфул АРІ, якщо придивитись, виглядає досить таки штучно. Наразі цю штучність намагаються прикрити для себе люди, яких нудить від поганого дизайну, але ці спроби дедалі менш вдалі.
Схоже, що ці конфлікти мають корені в самій ідеї використовувати модель HTTP взаємодії для побудови API. Навіть розшифровки центральних абревіатур підходу - HTTP та REST звучать не надто співзвучно до їх використання - побудови API. Доречі, Java*Script* у випадку вище теж трохи натякає, що це не зовсім той інструмент, на чому пишуться великі системи і фреймворки. Це ніби смішний аргумент, але програмісти знають, що якщо ім’я змінної не відповідає її функції - це дзвіночок, що з кодом щось не так.
Думка третя. Про мікросервіси.
Мабуть мікросервіси - це те, що можна назвати одним з основоположних елементів сучасної розробки. Ідея дуже проста, але мені здається, що очікуване багатьма спрощення системи розбиттям її на мікросервіси не досягнути. Складність при цьому просто розмазується по горизонталі, і частково переноситься на рівень взаємодії, але аж ніяк не зникає, і навіть навряд чи суттєво зменшується. Краще масштабується - однозначно, легше деплоїти маленькі шматочки, ніж велику монолітну байду - можливо. Але складність...
Вам давно доводилось вносити зміни, що залежать від інших компонентів, в систему з мікросервісною архітектурою? Це іноді неслабо виносить мозок через необхідність внести зміни в десяти різних компонентах, окремо їх всі зарелізити, бампнути всі версії, і так далі. Це ніфіга не просто. Виникає відчуття, що складність не сильно і залежить від таких речей, як розтягування системи по горизонталі.
No comments:
Post a Comment