Однако чем сложнее становятся наши приложения, тем острее становится вопрос о подходящей для них архитектуре.
Вместе с Виктором Грицко Грищенко, создатель swarm.js ( https://x.com/gritzko ), мы рассмотрим современные подходы к построению архитектуры JS-приложений как на сервере, так и на клиенте.
– Когда мы говорим о монолитных веб-приложениях, мы обычно имеем в виду уже ставшую классической архитектуру.
Так называемый слоистый монолит хорошо прижился во многих корпоративных решениях.
Расскажите, с какими недостатками этой архитектуры вам приходилось бороться в реальных проектах? 
– Впервые с такой классической архитектурой я столкнулся еще в 2000 году в Банке России.
Более того, оно возникло само собой, в процессе экстренной реализации.
Получился совершенно обычный Java-кошмар предприятия, когда систему можно было запустить только целиком и только на сервере, с полной базой данных.
С получившимся монолитом уже было сложно что-то сделать; все зависело от всего.
Позже я увидел такой же факапи в Яндексе.
Это неизбежный этап, если приложение перерастает свою архитектуру.
– Как понять, что пришло время разбить монолитный проект на сервисы? Есть ли характерные признаки? — «Пора делить» — это из серии «пора ампутировать».
Разделение большой проблемы на небольшие ортогональные подзадачи необходимо производить еще на этапе проектирования.
— Node.js очень активно развивается, статьи и руководства быстро устаревают. Есть ли передовой опыт, достойный подражания сегодня? Возможно, есть эталонные решения для построения микросервисной архитектуры? Лично мне кажется, что микросервисы на базе REST — это те же миньоны, только в профиле.
Так или иначе, асинхронная связь между подсистемами необходима.
В классике это очереди сообщений; они используются везде и всегда использовались везде.
Сейчас есть модные вещи – Кафка, Акка.
— Для монолитного приложения обычно достаточно балансировщика нагрузки и необходимого количества копий.
Но с микросервисами также необходимо понимать, какой компонент системы следует масштабировать.
— Балансировщик как таковой решает проблему только для очень простых, в идеале stateless приложений.
В противном случае начинаются проблемы с синхронизацией и конкурентным доступом к данным, в подвале открывается портал и из него вылазят демоны.
А компонент с одной понятной функцией однозначно легче масштабировать.
Специализация и экономия на масштабе — вторая половина XVIII века, Адам Смит. В целом доклад не о микросервисах.
Я применяю идеи «неизменяемой инфраструктуры» непосредственно к интерфейсу, к тому, что работает в браузере.
- Хорошо, давайте обсудим код на клиенте.
Какие проблемы актуальны сейчас? — Например, при использовании модных фреймворков типичный размер клиентского бандла уже составляет мегабайты JavaScript. Это неприятно, особенно по телефону.
Процесс сборки передней части – это уже целое дело.
Вытягивание данных клиенту идет полным ходом — сначала вытащили код, появился SPA, теперь постепенно вытаскиваем данные, хотим офлайн-первый, быстрое время отклика и прочие вкусности.
При этом, когда вы начинаете говорить, что UI-компоненты должны быть чистыми функциями, это не считается странным.
То есть народ готов.
– Действительно, размер среднего веб-приложения только увеличивается.
Есть ли у вас предложения, как можно улучшить ситуацию? — Моя идея — строго разделить все, что происходит на фронтенде, на (А) данные и (Б) все остальное (компоненты, код).
Более того, все, что не является данными, является функцией.
А функции — это тоже данные, если вдуматься.
Когда мы помещаем код в систему контроля версий, он становится данными.
То есть у нас есть версионированные данные и версионные функции, которые мы одинаково доставляем клиенту, одинаково кэшируем и обновляем.
– А как насчет чуть подробнее? – Я объясню на примере.
Мы отправляем пользователю страницу с сотней кнопок.
Мы не кладем код сотни кнопок в один большой бандл и не скачиваем всю базу данных, а отправляем только то, что нужно для рендеринга — часть данных и часть компонентов.
Если пользователь начинает везде ковыряться, мы подтягиваем больше данных, больше компонентов.
При этом то, что уже доставлено клиенту, кэшируется навсегда.
Обновляется по мере необходимости.
Это отчасти похоже на микросервисы — своего рода разделение большого количества кода на неизменяемые/версионные компоненты.
Кстати, лично я предпочитаю называть это версионированием, а не неизменяемостью.
Версия, будь то данные или код, по определению неизменяема, и в этом вся хитрость.
В конечном счете, фундаментальная проблема здесь одна и та же — и код, и данные должны работать на нескольких устройствах одновременно.
Мы строим распределенные системы просто потому, что процессоры уже повсюду.
Телефон – компьютер, книга – компьютер, телевизор – компьютер.
Клиент-серверное мышление уйдет в прошлое, как только уйдут мэйнфреймы.
Что придет ему на смену – интересный вопрос.
— Звучит интересно, но насколько это совместимо с существующими библиотеками и фреймворками? Даже частичная работа приложения потребует больших зависимостей ядра (AngularJS, jQuery,.
).
— Ну преакт как-то умещается в 3КБ.
В таком контексте нет необходимости использовать Angular. – Эта концепция уже сформировалась в отдельный проект? Где я могу узнать более подробную информацию? - Упаковка.
Сейчас это скорее эксперимент. К декабрю Я вам скажу , что случилось.
Кроме отчет Виктора на Конференция HolyJS (11 декабря, Москва, Рэдиссон «Славянская»), рекомендуем обратить внимание на следующие отчеты:
- ECMAScript: последние и предстоящие функции
- Создание интерактивных модулей командной строки npm
- Лебедь-рак и щука: как технологии тянут фронтенд на дно
- 3Л3М3НТ5
- Как подойти к современным веб-приложениям
- Отладка проблем производительности Node.js в рабочей среде
- WebVR — следующий рубеж
- Немного ближе к Frontend Bliss с Elm
- Профилирование производительности для V8
- Инструменты дистанционного управления своими руками (разработки)
- Расширенное редактирование текста с помощью Draft.js
- Офлайн — это новый черный
- Обмен файлами и данными с друзьями с помощью общей папки P2P на базе JavaScript.
-
Подкаст «Я Сказал На Каннада» (№ 17)
19 Oct, 24 -
Рбк Открывает Картографический Сервис
19 Oct, 24
