Реактивное программирование очень мощная штука. Томас Бурлесон (ex-Google) написал хорошую статью о том, как оно помогает в разработке приложений — "Push-based Architectures with RxJS" .
В статье рассматривается одно приложение, написанное с использованием двух подходов — pull-based и push-based. Pull-based — это традиционный подход, в котором view инициирует обращение к внешним API. В push-based подходе view реагирует на изменение данных в некотором источнике-стриме. Pull-based приложение без дополнительного тюнинга получилось очень топорным и не очень интуитивным. С push-based — приложение стало интуитивным и приятным в использовании. Код тоже стал более организован.
Томас ничего не написал про недостатки. По-моему опыту работа со стримами требует большего планирования, чем при обычном императивном программировании. Также rxjs требует время, чтобы в него погрузиться (но это того стоит).
Как бы то ни было очень советую посмотреть статью. Хотя примеры там и используют Angular, push-based подход можно применить в React, во Vue и в других фреймворках/библиотеках.
#angular #rxjs #architecture
https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
В статье рассматривается одно приложение, написанное с использованием двух подходов — pull-based и push-based. Pull-based — это традиционный подход, в котором view инициирует обращение к внешним API. В push-based подходе view реагирует на изменение данных в некотором источнике-стриме. Pull-based приложение без дополнительного тюнинга получилось очень топорным и не очень интуитивным. С push-based — приложение стало интуитивным и приятным в использовании. Код тоже стал более организован.
Томас ничего не написал про недостатки. По-моему опыту работа со стримами требует большего планирования, чем при обычном императивном программировании. Также rxjs требует время, чтобы в него погрузиться (но это того стоит).
Как бы то ни было очень советую посмотреть статью. Хотя примеры там и используют Angular, push-based подход можно применить в React, во Vue и в других фреймворках/библиотеках.
#angular #rxjs #architecture
https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
Medium
Push-based Architectures with RxJS
You have been coding wrong!
Евгений Бондаренко в статье "9 лет в монолите на Node.JS" поделился опытом перевода Node.js монолита OneTwoTrip на микросервисы.
Ребята начали разрабатывать приложение в 2010 году. За это время у них накопился большой опыт. В разделе про недостатки монолита описываются проблемы, которые связаны с масштабированием большого проекта, от сложности обновления зависимостей до поиска новых людей в команду. Из плюсов — простота развёртывания, нет оверхеда на передачу данных, простота отката на предыдущие версии.
Преимущества микросервисов: частые релизы, проще делать независимые тесты, использование разных технологий для наиболее оптимального решения задач. Минусы: необходимость в шине передачи данных и хорошем логировании, у разработчиков появляется слишком много свободы, необходима команда DevOps для управления всеми этими делами.
Автор пишет, что микросервисы не являются серебряной пулей и что погоня за хайпом может быть чревата проблемами. В общем, советую почитать статью, если эта тема вам интересна.
#nodejs #architecture
https://habr.com/ru/post/459206/
Ребята начали разрабатывать приложение в 2010 году. За это время у них накопился большой опыт. В разделе про недостатки монолита описываются проблемы, которые связаны с масштабированием большого проекта, от сложности обновления зависимостей до поиска новых людей в команду. Из плюсов — простота развёртывания, нет оверхеда на передачу данных, простота отката на предыдущие версии.
Преимущества микросервисов: частые релизы, проще делать независимые тесты, использование разных технологий для наиболее оптимального решения задач. Минусы: необходимость в шине передачи данных и хорошем логировании, у разработчиков появляется слишком много свободы, необходима команда DevOps для управления всеми этими делами.
Автор пишет, что микросервисы не являются серебряной пулей и что погоня за хайпом может быть чревата проблемами. В общем, советую почитать статью, если эта тема вам интересна.
#nodejs #architecture
https://habr.com/ru/post/459206/
Хабр
9 лет в монолите на Node.JS
Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные п...
Недавно инженеры Slack в статье "When a rewrite isn’t: rebuilding Slack on the desktop" поделились опытом обновления своего приложения.
Старая архитектура Slack содержала три основных проблемы: ручное управление DOM, жадную загрузку данных и отдельные процессы для каждого workspace. С первыми двумя проблемами можно было справиться постепенно: для работы с DOM был выбран React, для работы с данными — Redux. Но последняя проблема требовала фундаментального изменения дизайна приложения. Был выработан план: продолжать работать со старой кодовой базой, постепенно её обновляя и используя строгий интерфейс взаимодействия современной и старой части приложения. При этом весь новый код постепенно переносился в современное приложение из старого. Таким образом получилось добиться баланса между доставкой новых фич пользователям и переписыванием приложения. В результате обновлённое приложение стало работать быстрее и потреблять меньше памяти.
Статья очень интересная. Определённо, стоит почитать.
#electron #performance #architecture
https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4
Старая архитектура Slack содержала три основных проблемы: ручное управление DOM, жадную загрузку данных и отдельные процессы для каждого workspace. С первыми двумя проблемами можно было справиться постепенно: для работы с DOM был выбран React, для работы с данными — Redux. Но последняя проблема требовала фундаментального изменения дизайна приложения. Был выработан план: продолжать работать со старой кодовой базой, постепенно её обновляя и используя строгий интерфейс взаимодействия современной и старой части приложения. При этом весь новый код постепенно переносился в современное приложение из старого. Таким образом получилось добиться баланса между доставкой новых фич пользователям и переписыванием приложения. В результате обновлённое приложение стало работать быстрее и потреблять меньше памяти.
Статья очень интересная. Определённо, стоит почитать.
#electron #performance #architecture
https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4
Slack Engineering
When a rewrite isn’t: rebuilding Slack on the desktop - Slack Engineering
Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. Time spent rewriting something that already works is time that won’t be spent making our customers working lives simpler, more pleasant, and more productive.…
Майк Ритмюллер несколько недель назад поделился своими мыслями про управление стилями в современных приложениях — "CSS Architecture for Modern JavaScript Applications".
Майк пишет про то, что использование современных подходов для управления стилями без планирования может вызвать проблемы в будущем. Например, переиспользование компонентов может стать невозможным, если не использовать принципы абсолютно независимых блоков. Недостаточно поделить макет на прямоугольники — нужно спланировать раскладку и то как с ней будут взаимодействовать презентационные компоненты. Для управления состоянием предлагает использовать переосмысленные типы состояний, позаимствованные из SMACSS. В статье есть пример этого подхода, но он мне показался сложным для восприятия. Имхо, для описания сложных состояний компонентов хорошо подходит старый-добрый БЭМ.
Статья большая. Советую почитать, если работаете над проектами, в которых переиспользуется большое количество компонентов.
#css #musings #architecture
https://www.madebymike.com.au/writing/css-architecture-for-modern-web-applications/
Майк пишет про то, что использование современных подходов для управления стилями без планирования может вызвать проблемы в будущем. Например, переиспользование компонентов может стать невозможным, если не использовать принципы абсолютно независимых блоков. Недостаточно поделить макет на прямоугольники — нужно спланировать раскладку и то как с ней будут взаимодействовать презентационные компоненты. Для управления состоянием предлагает использовать переосмысленные типы состояний, позаимствованные из SMACSS. В статье есть пример этого подхода, но он мне показался сложным для восприятия. Имхо, для описания сложных состояний компонентов хорошо подходит старый-добрый БЭМ.
Статья большая. Советую почитать, если работаете над проектами, в которых переиспользуется большое количество компонентов.
#css #musings #architecture
https://www.madebymike.com.au/writing/css-architecture-for-modern-web-applications/
MadeByMike
CSS Architecture for Modern JavaScript Applications - MadeByMike
My attempt to modernise some learnings from CSS architecture and apply them in the context of modern JavaScript applications.
Крис Льюис и Брендан Дин из UberEats рассказали, почему они пошли по пути переписывания основного сайта проекта и какие плоды это им принесло.
Проблема с предыдущей версией сайта имела накопительный эффект. Это было React-Redux приложение, которое плохо поддавалось разделению на бандлы и имело сложности с поддержкой из-за усложнённого подхода к работе с данными и смешиванию кода для разных платформ (desktop/mobile). В новой версии они перешли на фреймворк fusion.js, созданный Uber на базе React (аналог Next.js). Благодаря ему они получили server side rendering и хорошую поддержку code splitting. Для слоя данных оставили Redux, но только как хранилище данных, которое может быть использовано разными роутами приложения. Для всего остального состояния используется локальное состояние компонентов. Благодаря работающему code splitting решили проблему со смешиванием кода разных платформ.
Очень большая и толковая статья. Рекомендую почитать.
#react #performance #architecture
https://eng.uber.com/uber-eats-com-web-app-rewrite/
Проблема с предыдущей версией сайта имела накопительный эффект. Это было React-Redux приложение, которое плохо поддавалось разделению на бандлы и имело сложности с поддержкой из-за усложнённого подхода к работе с данными и смешиванию кода для разных платформ (desktop/mobile). В новой версии они перешли на фреймворк fusion.js, созданный Uber на базе React (аналог Next.js). Благодаря ему они получили server side rendering и хорошую поддержку code splitting. Для слоя данных оставили Redux, но только как хранилище данных, которое может быть использовано разными роутами приложения. Для всего остального состояния используется локальное состояние компонентов. Благодаря работающему code splitting решили проблему со смешиванием кода разных платформ.
Очень большая и толковая статья. Рекомендую почитать.
#react #performance #architecture
https://eng.uber.com/uber-eats-com-web-app-rewrite/
Флориан Раппл рассказал про текущее состояние микрофронтендов — "The State of Micro Frontends".
Микрофронтенды — это подход к организации приложения, когда команды в рамках одного продукта могут делать фичи, используя разные технологии, и релизить их независимо друг от друга. Микрофронтенды могут быть реализованы по-разному, поэтому существуют разные фреймворки для построения микрофронтендов, покрывающие специфические требования: qiankun, piral, mosaic, micromono и т.п.
Микрофронтенд — это не серебряная пуля, которая может решить все известные проблемы. Но в определённых случаях он может быть полезен. Такой подход для своих продуктов используют IKEA, Microsoft, SAP, Spotify и другие компании.
#architecture
https://blog.bitsrc.io/state-of-micro-frontends-9c0c604ed13a
Микрофронтенды — это подход к организации приложения, когда команды в рамках одного продукта могут делать фичи, используя разные технологии, и релизить их независимо друг от друга. Микрофронтенды могут быть реализованы по-разному, поэтому существуют разные фреймворки для построения микрофронтендов, покрывающие специфические требования: qiankun, piral, mosaic, micromono и т.п.
Микрофронтенд — это не серебряная пуля, которая может решить все известные проблемы. Но в определённых случаях он может быть полезен. Такой подход для своих продуктов используют IKEA, Microsoft, SAP, Spotify и другие компании.
#architecture
https://blog.bitsrc.io/state-of-micro-frontends-9c0c604ed13a
Medium
The State of Micro Frontends
One of the more controversial topics in frontend web dev is microfrontends. Are they worth it? Should you really split up your application?
Станислав Черенков написал статью про использование роутинга в современных SPA-приложениях — "Your SPA doesn’t need a router".
Станислав пишет про то, что использование готовых библиотек роутинга это не самое оптимальное решение, так как разработчики роутеров не могут предусмотреть всех возможных требований. Большинство роутеров не могут работать вне уровня представления, например, react-router использует jsx. В серьёзных приложениях с таким подходом могут проблемы, если при переходе на новый роут нужно выполнить какие-то проверки, загрузить данные или дополнительные скрипты.
В статье предлагается альтернативный подход с отделением представления от логики роутинга и использованием только самых необходимых библиотек, например, для сериализации url страницы в объект.
Полезная статья. В первую очередь рекомендую почитать всем, кто разрабатывает сложные SPA.
#musings #architecture
https://forweb.dev/en/blog/drop-the-router/
Станислав пишет про то, что использование готовых библиотек роутинга это не самое оптимальное решение, так как разработчики роутеров не могут предусмотреть всех возможных требований. Большинство роутеров не могут работать вне уровня представления, например, react-router использует jsx. В серьёзных приложениях с таким подходом могут проблемы, если при переходе на новый роут нужно выполнить какие-то проверки, загрузить данные или дополнительные скрипты.
В статье предлагается альтернативный подход с отделением представления от логики роутинга и использованием только самых необходимых библиотек, например, для сериализации url страницы в объект.
Полезная статья. В первую очередь рекомендую почитать всем, кто разрабатывает сложные SPA.
#musings #architecture
https://forweb.dev/en/blog/drop-the-router/
For Web
Your SPA doesn’t need a router
So you are building a client-side web app for that next big project and wondering: “Which router should I use?”. Here is the thing: you don’t need any at all.
Андрей Мелихов опубликовал на хабре статью "Архитектура современных корпоративных Node.js-приложений".
Фронтенд-разработка в больших проектах давно вышла за границы работы с представлением. Фронтендеры должны поддерживать сервер-сайд рендеринг и жонглировать ответами от разных бэкендов. В статье рассказывается про подход с организацией логики уровня приложения с помощью BFF (Backend For Frontend). Разбираются плюсы и минусы нескольких подходов разделения приложения на слои. В качестве примера реализации используется фреймворк Nest, по ходу дела разбираются его ограничения.
Очень хорошая статья. Рекомендую почитать всем, кто хочет узнать больше про разработку серьёзных web-приложений на Node.js.
#architecture #nodejs
https://habr.com/ru/company/yandex/blog/514550/
Фронтенд-разработка в больших проектах давно вышла за границы работы с представлением. Фронтендеры должны поддерживать сервер-сайд рендеринг и жонглировать ответами от разных бэкендов. В статье рассказывается про подход с организацией логики уровня приложения с помощью BFF (Backend For Frontend). Разбираются плюсы и минусы нескольких подходов разделения приложения на слои. В качестве примера реализации используется фреймворк Nest, по ходу дела разбираются его ограничения.
Очень хорошая статья. Рекомендую почитать всем, кто хочет узнать больше про разработку серьёзных web-приложений на Node.js.
#architecture #nodejs
https://habr.com/ru/company/yandex/blog/514550/
Хабр
Архитектура современных корпоративных Node.js-приложений
Ох, не зря в названии намёк на нетленку Фаулера. И когда фронтенд-приложения успели стать настолько сложными, что мы начали рассуждать о высоких материях? Node.j...
В Китае очень популярны суперприложения — приложения, с помощью которых можно получить доступ к разным сервисам (заказ такси, бронирование столиков в ресторане и т.п.) Они состоят из нативной оболочки и миниприложений конкретных сервисов, которые создаются с помощью web-технологий. Томас Штайнер из Google разобрался с разными видами миниприложений и подготовил доклад для TPAC 2020 — "Learning From Mini Apps".
Из интересного. Все суперприложения используют разные диалекты HTML и CSS для описания представлений миниприложений — Wxml/WXSS (WeChat), AXML/ACSS (Alipay), Swan Element/CSS (Baidu), TTML/TTSS (ByteDance). Для описания логики используется подмножество JavaScript — WXS (WeChat), SJS (Alipay, ByteDance), Baidu (JS). Для доступа к функциям операционной системы используется специальный мост (bridge). Для связи представления и состояния используется паттерн model-view-viewmodel (MVVM). Все суперприложения предоставляют специальные среды разработки.
Томас предлагает использовать идеи миниприложений для создания многостраничных приложений (multi-page single-page apps — MPSPA) на базе легковесных компонентных фрейморков или custom elements.
#architecture
https://docs.google.com/presentation/d/e/2PACX-1vREwN7H71zfjPP8lwYgyc-iXam7_PMFCxiZy2dQNZ-XpbiKk1aRSj67vxfcegkHogcO0q3BFHxPf6S5/pub
Из интересного. Все суперприложения используют разные диалекты HTML и CSS для описания представлений миниприложений — Wxml/WXSS (WeChat), AXML/ACSS (Alipay), Swan Element/CSS (Baidu), TTML/TTSS (ByteDance). Для описания логики используется подмножество JavaScript — WXS (WeChat), SJS (Alipay, ByteDance), Baidu (JS). Для доступа к функциям операционной системы используется специальный мост (bridge). Для связи представления и состояния используется паттерн model-view-viewmodel (MVVM). Все суперприложения предоставляют специальные среды разработки.
Томас предлагает использовать идеи миниприложений для создания многостраничных приложений (multi-page single-page apps — MPSPA) на базе легковесных компонентных фрейморков или custom elements.
#architecture
https://docs.google.com/presentation/d/e/2PACX-1vREwN7H71zfjPP8lwYgyc-iXam7_PMFCxiZy2dQNZ-XpbiKk1aRSj67vxfcegkHogcO0q3BFHxPf6S5/pub
Райан Карниато — автор библиотеки Solid.js — написал статью о общих принципах работы точечной реактивности — "A Hands-on Introduction to Fine-Grained Reactivity".
Точечная реактивность (fine-grained reactivity) используется в MobX, Vue, Svelte, Knockout и Solid. Если объяснять совсем просто, то её суть сводится к выполнению реакций при изменении наблюдаемых значений. Точно также как меняется результат выполнения формулы в Excel при изменении ячеек, которые используются формулой. Если продолжать аналогию, то эти "ячейки" в разных библиотеках называются по-разному: Signals, Observables, Atoms, Subjects, Refs, — а "формулы": Reactions, Effects, Autoruns, Watches, Computeds.
В статье нет каких-либо деталей реализации, но её можно рекомендовать как хорошее введение в тему точечной реактивности.
#jsframeworks #reactivity #architecture
https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf
Точечная реактивность (fine-grained reactivity) используется в MobX, Vue, Svelte, Knockout и Solid. Если объяснять совсем просто, то её суть сводится к выполнению реакций при изменении наблюдаемых значений. Точно также как меняется результат выполнения формулы в Excel при изменении ячеек, которые используются формулой. Если продолжать аналогию, то эти "ячейки" в разных библиотеках называются по-разному: Signals, Observables, Atoms, Subjects, Refs, — а "формулы": Reactions, Effects, Autoruns, Watches, Computeds.
В статье нет каких-либо деталей реализации, но её можно рекомендовать как хорошее введение в тему точечной реактивности.
#jsframeworks #reactivity #architecture
https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf
DEV Community
A Hands-on Introduction to Fine-Grained Reactivity
Reactive Programming has existed for decades but it seems to come in and out of fashion. In...
Гал Шлёзингер поделился подходом для создания лёгкого встраиваемого виджета — "HTML over the wire with Preact".
Галу надо было сделать интерактивный виджет, который можно встроить на любой сайт. Он хотел как можно сильнее уменьшить размер js-бандла виджета, поэтому вместо React выбрал Preact. Для работы с GrahpQL на стороне клиента была выбрана библиотека urlq, но её размер тоже был очень большим. В итоге вместо отправки JSON стал отправлять на клиент уже готовую разметку HTML (проект это позволял). Так как
В общем, довольно интересный подход, его также можно использовать в React.
#preact #architecture
https://gal.hagever.com/posts/hotwire-in-preact-apps/
Галу надо было сделать интерактивный виджет, который можно встроить на любой сайт. Он хотел как можно сильнее уменьшить размер js-бандла виджета, поэтому вместо React выбрал Preact. Для работы с GrahpQL на стороне клиента была выбрана библиотека urlq, но её размер тоже был очень большим. В итоге вместо отправки JSON стал отправлять на клиент уже готовую разметку HTML (проект это позволял). Так как
dangerouslySetInnerHTML ломал доступность (пропадал фокус и DOM-состояние при замене разметки), он воспользовался библиотекой preact-markup для преобразования полученной HTML-размеки в Preact-элементы, чтобы работал diff виртуального DOM при замене элементов.В общем, довольно интересный подход, его также можно использовать в React.
#preact #architecture
https://gal.hagever.com/posts/hotwire-in-preact-apps/
Hagever
HTML over the wire with Preact
Communicating using HTML like it isn't 2021
Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".
После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.
У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.
Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.
#architecture #announcement #google #a11y
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)
После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.
У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.
Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.
#architecture #announcement #google #a11y
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)