Ти не Google, тобі не потрібен React або сучасний карго-культ в IT.

Розмовляв з другом. Робить мікрофронтенди на React. Бідолаха. Вся задача – пару сторінок і кілька кнопок, але React і мікрофронтенди. Памʼятаю іншого знайомого, робив стартап. Клієнтів - нуль, проте є Kubernetes кластер. Бачив інший приклад, стартап, пишуть десятки сторінок технічних документів як у Amazon коли могли б вирішити свої проблеми простим малюнком на дошці.

Про пошесть мікросервісів я взагалі мовчу….

Вам не потрібне все це барахло!!!

Panic mode?

Не варто.

Давайте розберемось для чого і для кого розроблявся всі ті бібліотеки та процеси.

Facebook React

React розробляється в надрах Facebook, бо їм складно розробляти сайт.  Ви його бачили? Зайдіть на свою сторінку у Facebook і порахуйте кількість різнорідних елементів, не здивуюсь якщо їх там сотні і все це треба динамічно оновлювати, ходити в різні мікросервіси, і так далі. Думаєте у вас дійсно такий складний додаток? Я сумніваюсь.

Всі переваги про які говорить Facebook рекламуючи React не мають нічого спільного з тим, що більшість з нас робить. Scalability в їх розумінні це коли 1000 людей можуть парцювати над однією сторінкою уявіть які там дедлоки. Ваші 5, 10 та хай навіть 20 розробників ніколи, буквально ніколи, не будуть настільки заблоковані, щоб вам було потрібно запроваджувати React.

Для абсолютної більшості задач вистачить  jQuery.

Все ще не вірите, що без React не можна побудувати нічого хорошого та сучасного?

Дивіться, навіть поштовий клієнт для Hey написаний без всього цього барахла і працює швидше і краще за "best-practice" конкурентів.

HEY is running No Build JavaScript for the main app. Contrast the Lighthouse scores and the inbox vs imbox loads with Gmail. I think we're doing pretty alright with No Build, import maps, and a some ~100 individual JS files! We send 500kb of JS uncompressed vs Gmail's 10mb! 😄 pic.twitter.com/yElhMrgWTi

— DHH (@dhh) October 12, 2023

GFS and Kubenretes

Не думаю, що багато хто з вас навіть чув про Google File System, але у white-paper з її описом є ключове речення про те, як саме великі компанії розробляють свої продукти.

However, its design has been driven by key observations of our application work- loads and technological environment, both current and an- ticipated, that reflect a marked departure from some earlier file system design assumptions.

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

Великим корпораціям наплювати на стартап Васі Пупкіна, вони вирішують свою проблему.

Думаєте з Kubenretes це не так? Ось вам цитата з white-paper який описує систему Borg, яка лягла в основу Kubernetes.

Borg provides three main benefits: it (1) hides the details of resource management and failure handling so its users can focus on application development instead; (2) operates with very high reliability and availability, and supports applications that do the same; and (3) lets us run workloads across tens of thousands of machines effectively. Borg is not the first system to address these issues, but it’s one of the few operating at this scale, with this degree of resiliency and completeness.

Kubenretes створений для масштаба Google, не для вас.

Мікросервіси проти моноліта

Нещодавно вийшла стаття про те як Amazon мігрував одну зі своїх моніторингових систем з мікросервісів в моноліт і зекономив 90% витрат.

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

Фреймворки

Завжди коли вам корить використати якийсь популярний фреймворк, написаний компанією, памʼятайте, що його писали під потреби і задачі компанії, а не ваші. Так це розповсюджується і на open-source фреймворки.

Візьмемо наприклад GWT, цікаво чи хтось про нього ще памʼятає, але це був досить популярний Java фреймворк для створення фронтенда для веб-додатків. Він почав своє існування в додатку Gmail, там він власне і згинув.

Ще одни приклад це Ruby on Rails(RoR), неймовірно популярний фреймворк для розробки веб-додатків. Нещодавно DHH(програміст написавший  RoR) абсолютно наплювавши на думку спільноти розробників, авторитарним рішенням видалив з фреймворка Typescript чим спричинив неаби яку драму.

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

Ще щось?

Нажаль, наведені приклади абсолютно не вичерпні. Вас змушують розвертати бінарне дерево на співбесіді – привіт FAANG. Вимагають сотні сторінок документаціі заради документації – привіт FAANG. Будь яка інша дебільна "best practice" – привіт FAANG.

Вам самим це не набридло?

Про карго культ

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

По перше, FAANG компанії настільки великі, що навіть самі не роблять все те, про що вони говорять.

По друге, вони вирішують виключно свої проблеми і заточують свої процеси та рішення під свої, виключно свої потреби. Не заради вас чи, щоб вирішити ваші проблеми.

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