Андрей Марченко Dev заметки

Сегодня я наткнулся на дискуссию вокруг Effector https://habr.com/ru/companies/vk/articles/839632/, когда одна из команд VK опубликовала пост с критикой и объяснением, почему они отказываются от этой библиотеки. Я следил за Effector с 2019 года и всегда считал, что он сложен и делает слишком большой акцент на управлении состоянием.

Мой прошлый подход

Мне больше нравился подход с минимальным использованием глобального состояния и применением библиотек типа react-query, SWR, Apollo или Relay, которые берут на себя работу с загрузкой и обновлением данных. В этом случае менеджеры состояния используются только для хранения общих, глобальных данных, которых обычно не так много в большинстве приложений.

Этот подход повлиял на разработку фреймворка Tramvai, над которым я работал. Вот что было внутри:

- Простой менеджер состояния https://tramvai.dev/docs/features/child-app/state-management/ , похожий на Redux, но без глобальных обновлений при каждом изменении.
- React Query для загрузки данных https://tramvai.dev/docs/features/data-fetching/react-query , который полностью отвечал за это, причем данные с API не хранились в менеджере состояния.
- Для SSR использовались глобальные экшены https://tramvai.dev/docs/features/data-fetching/action : для каждой страницы регистрировался набор промисов с действиями, которые нужно было выполнить перед рендерингом страницы.

На этот момент я думал, что это оптимальный подход в React. Но в свое время я не учитывал особенности React, так как React Suspense были чем-то новым на это время и я просто не думал в таких категориях.

Новый взгляд

После перехода в новую компанию я увидел иной подход, основанный на Relay, который активно использует возможности React и при этом значительно упрощает схему, использованную в Tramvai. Relay — это клиент для GraphQL, позволяющий декларативно описывать необходимые данные для компонентов и связывать их между родительскими и дочерними элементами.

Ключевые улучшения:
- Замена глобальных экшенов: Вместо ручного прописывания экшенов используется useFragment https://relay.dev/docs/api-reference/use-fragment/ , который описывает набор данных, необходимых для текущего компонента. При подключении компонента родителем нужно связать необходимость загрузки этих данных https://relay.dev/docs/guided-tour/rendering/fragments/#composing-fragments , что повторяется на всех уровнях, формируя полную цепочку необходимых данных для страницы.
- Использование React Suspense: Этот подход позволяет улучшить визуальную производительность, загружая только необходимые данные. Появляется возможность пометить данные как необязательные для блокирующей загрузки, используя React.Suspense для отображения скелетонов на месте еще не загруженных компонентов.

Как это можно применить к Tramvai

Применяя эти концепции к Tramvai, можно было бы:
- Позволить каждому компоненту описывать необходимые данные для рендеринга. При этом без использования GraphQL, а как необходимые react-query которые необходимы для отрисовки компоненты, дальше это можно дедублицировать
- Связывать эти данные по цепочке к определению роута, просто лист промисов/query
- При переходе на страницу выполнять список промисов/query, которые нужно выполнить для страницы. При этом ожидая только блокирующие данные
- Использовать React Suspense для компонентов, данные которых еще не загружены. Все это автоматически, на основе информации, был ли выполнен query ранее


Преимущества нового подхода:
- Улучшенная производительность: Пользователь видит плавный переход между страницами, где новая страница уже отрендерена с данными для первого экрана, а остальное догружается в фоне.
- Упрощение организации кода: Разработчику не нужно думать о связи с SSR и последующей загрузке. Он просто определяет необходимые компоненту данные, а остальное происходит автоматически.


В итоге, я считаю, что этот способ оптимален для SSR React-приложений, обеспечивая баланс между производительностью и удобством разработки, а так-же открывает дверь к Server components. А так-же убирает большую часть сложности с State manager для большинства сайтов.

Всем привет, возвращаюсь с новой статьей: Edge Computing Demystified - From ISP Architecture to Global Content Delivery.

Недавно читал в новостях, что выходит из строя оборудование Google, и из-за этого YouTube будет хуже работать в России. И тут я вспомнил, что сам работал 10 лет назад в мелком интернет-провайдере, который уже тогда имел оборудование от Google для кэширования статичных данных. По сути, это и есть Edge-технологии, которые стали популярны в реализациях Edge Computing/Functions/Workers. То есть Google, как обычно, придумал крутые технологии задолго до всех. Получается, что Edge — это не что-то хайповое, а уже давно проверенные технологии, которые работают внутри большинства крупных CDN-сервисов.

В статье я разобрал, как схематично устроены интернет-провайдеры изнутри, почему Edge-оборудование — это спасение для них и youtube начнет тормозить, после выхода из строя их оборудования, как работает Edge-технология, как клиенты находят ближайшие серверы и какие плюсы Edge дает для всех.

Статью можете почитать тут: https://amarchenko.dev/blog/2024-07-22-edge-netwook/

Всем привет, в статье про FAANG компании я обещал рассказать куда в итоге прошел. И вот результат - в этот понедельник был первый день в Meta в Калифорнии. Буду работать на позиции senior full stack разработчика в Oculus команде.

Всем привет! Написал очередную статью с разбором Technology Radar 30 от ThoughtWorks. ThoughtWorks — это консалтинговая организация, в которой работают крутые инженеры, такие как Martin Fowler и Neal Ford. Каждые полгода компания ThoughtWorks выпускает список технологий, в которые они верят и которые начинают использовать. Последние семь лет я активно слежу за этим списком, так как он помогает мне понимать, куда движется IT-сфера и какие технологии я мог пропустить, находясь в своем информационном пузыре.

В этом выпуске делается акцент на AI/ML/LLM инструментах и новых сервисах, построенных на их основе, а также на решениях, которые помогают создавать подобные приложения. А также Infrastructure as Code для описания инфраструктуры проекта на языках по типу TypeScript.

В моем блоге вы можете найти разбор списка технологий по категориям с небольшим расбором, зачем все это нужно: https://amarchenko.dev/blog/2024-05-08-technology-radar-30/

Собрал для вас в одну папку авторов, ведущих блоги по фронтенду, веб-разработке и вокруг неё.

🔗 https://t.me/addlist/Z6Efi4jXwe9lODcy

Специально отобрал именно ламповые авторские блоги, а не перепосты ссылок, документации или тексты не про код.

Для меня это хороший способ следить за реакциями о событиях индустрии. Например, конференции проходят не так часто, и контент с них становится общедоступным не сразу. Кроме того, там обычно рассказывают о чём-то эпичном, не сиюминутном, так как формат обязывает. А вот в авторских бложиках (и комментариях к постам) можно собрать цельную картинку происходящего в рутине, и не просто факты, а именно авторскую интерпретацию и комментарии.

Надеюсь, будет полезно ✌️

@web_platform | Поддержать канал 🤝

Привет всем! Опубликовал новую статью в своем блоге о NewSQL. Последние три месяца я много изучал то, как работают базы данных внутри: прочел несколько книг, прошел несколько курсов (кстати, у MIT прям отличный курс на эту тему), а также изучил ряд papers. В итоге, на основании всего изученного, получилась эта статья.

Меня давно интересовал вопрос, как устроены новые типы баз данных NewSQL. Если с работой PostgreSQL и в общих чертах с Cassandra было понятно, то оставались вопросы относительно таких систем, как Google Spanner или FaunaDB, предлагающих высокую консистентность и масштабируемость. Как они могут решить все сложности и почему они еще не стали универсальным решением и не сместили предыдущие поколения?

В статье вы найдете разбор SQL и NoSQL баз данных, подробный разбор NewSQL на примере FaunaDB, а также обзор Consensus протоколов, таких как Raft и Multi-Paxos, лежащих в основе множества распределенных систем. Также рассмотрены Two-phase commits и Calvin для распределенных транзакций.

Полный текст статьи доступен в моем блоге: https://amarchenko.dev/blog/2024-03-13-new-sql/

Всем привет! Возвращаюсь с новым постом. За последние три года я трижды пытался пройти собеседование в FAANG, и этот процесс занял у меня почти три года. За это время я ознакомился с огромным количеством материалов, связанных с прохождением интервью: просмотрел десятки часов видеоматериалов, изучил множество статей и историй других кандидатов.

В итоге я выделил пачку ключевых моментов, на которые стоит обратить внимание при собеседовании, особенно в Big Tech и FAANG компаниях, где достаточно сложные интервью, отличные от того, к чему я привык. Когда требуется специальная подготовка и формат ответов.

В итоге написал статью в которой рассказываю о:
- Различных типах компаний;
- Нужен ли хороший английский на интервью?
- Моём подходе к Coding/System Design/Behavioral интервью
- Количестве задач, которые я решил, и моих рекомендациях по подготовке

Саму статью можете почитать в моем блоге https://amarchenko.dev/blog/2024-01-17-interview-experience/ и удачного вам прохождения интервью

Всем привет, давно я не писал новых статей, так как активно готовился к собеседованиям к FAANG компаниям. Пока жду результатов. Делюсь новой интересной статьей не под моим авторством, но содержащую интересную информацию про базы данных, основные проблемы и подходы:
- CAP-теорему
- LSM Tree – это популярный дизайн баз данных, наподобие Cassandra
- Bloom filters, позволяющие, не расходуя большой объем памяти, понять, обрабатывал ли ты ранее элемент
- Consistent Hashing – алгоритм распределения данных между хостами

Статья https://tontinton.com/posts/database-fundementals/ . В общем, советую почитать. Особенно если вы – full-stack или бэкенд-разработчик, так как все это необходимо знать для успешного прохождения system-design собеседований.

Также одна из интересных для меня тем – это реализация небольшого прототипа системы. Я подумываю написать на Node.js простую базу данных, которая внутри использует LSM Tree и при этом запускается как часть Node.js процесса. То есть сам Node.js будет выступать в роли бэкенда и базы данных. Такой дизайн используют, например, в Одноклассниках, только у них Java и Cassandra. Это помогает убрать задержки между бэкендом и базой данных и улучшить SLA. Но пока это только в планах.

Всем привет. Написал очередную статью. На этот раз про архитектуру и фреймворки. Ранее мне часто попадался новый фреймворк Service Weaver от Google для Golang, так как инженеры Google активно участвует в конференциях и рассказывают про этот фреймворк.

Первая мысль: "Очередной фреймворк, ничего интересного". Но на деле этот фреймворк реализует интересную модель, когда во время деплоя можно выбрать, как именно проект будет задеплоен - как множество микросервисов? Как модульный монолит? Или как множество модульных монолитов?

И это определенно необычный подход, который позволяет решить ряд проблем микросервисов. В статье подробнее разбираю, как работает эта "магия" внутри, на основе каких компонентов построен Service Weaver и как это можно реализовать в Node.js.

Статья доступна на английском: https://amarchenko.dev/blog/2023-10-19-service-weaver/

В своей статье я использовал расширение deoptexplorer-vscode https://marketplace.visualstudio.com/items?itemName=rbuckton.deoptexplorer-vscode для сбора профайл информации V8 и последующего удобного просмотра. На удивление все это легко можно запустить, расширение имеет хороший UI. А значит это:
- Рабочий инструмент для создания оптимизированных библиотек
- Позволяет понять на примерах механизмы работы V8, включая концепции, такие как hidden-classes, turbofan, Monomorphic, Polymorphic, Megamorphic, PACKED_SMI_ELEMENTS и прочее.

Привет всем! Опубликовал новую статью на тему Memory Cache. Тема кэширования меня всегда привлекала своей вариативностью и отсутствием универсального решения. В прошлом, я уже реализовывал простые версии LRU cache, в том числе и на собеседованиях. Недавно наткнулся на исследование нового алгоритма кэширования — S3-FIFO. Он ещё не был реализован для JS, и это меня заинтересовало. S3-FIFO отличается простотой, но при этом по обещаниям обеспечивает отличную производительность и высокий hit rate.

В статье найдете:

- Зачем нужен Кэш и почему важен hit rate?
- Разновидности алгоритмов кэширования: 2Q, LRU cache, S3-FIFO.
- Возможные угрозы: как атака на кэш может нарушить работу приложения.
- Детальное рассмотрение и реализация S3-FIFO.
- Результаты тестирования в плане производительности и cache hit.
- Бонус: профилирование кода в V8 и поиск мест деоптимизации.

Статья доступна на английском: https://amarchenko.dev/blog/2023-10-12-memory-cache/
А так-же ссылка на самому библиотеку: https://github.com/Tom910/effective-cache

Channel name was changed to «Андрей Марченко Dev заметки»

Подъехала новая статья: "Сетевая инфраструктура - от основ до Дата Центров".

За 10 лет работы инженером у меня накопилось много вопросов о сети, часть из которых я либо не знал, либо не понимал. Сеть эффективно скрывает от нас всю свою сложность, делая нашу жизнь проще. Но иногда эти пробелы в знаниях сказывались, например:
- Когда меня спросили на собеседовании про Level 3 и Level 4 балансеры.
- Когда я стал лидить проект, связанный с инфраструктурой (создание Cassandra as a Service)
- Так и при проектировании высоконагруженных систем, когда требуется глубокое понимание сети для оптимизации и правильного дизайна.

Именно поэтому я решил погрузиться в изучение сети и разобраться в основных вопросах. Этот материал будет особенно полезен разработчикам, так как фокус сделан на их специфические задачи и проблемы.

В статье вы узнаете:
- Что такое OSI Level?
- Как функционируют TCP/UDP/QUIC? Что такое пакет, фрагмент, датаграм?
- Как устроена сеть между клиентом и сервером. Что такое ISP, BGP, Anycast?
- Что представляют из себя Edge networks?
- И в заключение — как устроена сеть в дата-центре компании Meta.

Статья довольно объемная. Приходите в комментарии, если вы нашли неточности или у вас есть вопросы.

На русском: https://amarchenko.dev/translate/2023-10-02-network/
На английском: https://amarchenko.dev/blog/2023-10-02-network/

Привет всем!

Опубликовал свежую статью на тему версионирования библиотек в монорепозитории. Если изучить популярные библиотеки, такие как react, angular, next.js, tramvai и nx, то можно заметить общий подход к версионированию NPM библиотек. Почему они пришли к схожему способу?

В статье я разбираюсь, почему многие из них следуют одинаковой стратегии и какие трудности могут возникнуть, если каждая библиотека в монорепозитории будет иметь свою версию. Это особенно актуально для разработчиков библиотек и тем, кто хочет понять как это все работает и почему стоит использовать команды вроде "nx migrate".

На английском можно прочитать здесь - https://amarchenko.dev/blog/2023-09-26-versioning/
На русском можно прочитать здесь - https://telegra.ph/Luchshih-praktik-versionirovaniya-bibliotek-v-monorepozitorii-09-26

Заодно опробовал утилиту tsup https://github.com/egoist/tsup для сборки NPM пакета https://github.com/Tom910/rate-limit-guard . До этого натыкался на нее как в других библиотеках, так и в twitter, но не доходили руки самому проверить

По первым ощущениям это отличная библиотека, которая решает основные кейсы node.js библиотек:
- Простая настройка. Из коробки работает TypeScript и ESM
- Бандлинг всех зависимостей. tsup собирает все внешние зависимости и они будут включены в npm пакет. Помогает снизить количество внешних зависимостей библиотеки и поставлять библиотеку с работающем кодом
- Сборка всех необходимых типов. Так-же как и с кодом, собирает все внешние типы
- Решает головную боль с commonjs и ESM импортами
- Удаление не экспортируемого кода
- Возможность сборки для браузера и node.js
- Возможность задать множество entry points

Все это работает из коробки. Когда-то я также участвовал в разработке схожей утилиты, и сделать так, чтобы везде все работало - нетривиальная задача

Первая запись посвящена Rate limit на основе статьи, опубликованной на https://amarchenko.dev/blog/2023-09-23-rate-limiting/. Работая в крупной компании, я часто сталкивался с различными ситуациями, связанными с большим трафиком в приложении. Это могли быть DDOS-атаки, проведение акций или сбой API, когда пользователи начинают постоянно обновлять страницу, что приводит к увеличению трафика. В таких ситуациях сервис обычно не выдерживает нагрузку.

Попытки ограничить количество запросов на уровне инфраструктуры (nginx) не привели к успеху, поскольку nginx оказался слишком простым для этого. В итоге я пришел к идее, описанной в статье, которая предполагает контроль количества запросов на уровне каждого приложения.

Заодно написал опенсорсную библиотеку https://github.com/Tom910/rate-limit-guard которая реализует все это и работает с express, fastify и nestjs

Всем привет (хотя здесь еще никого нет). Завел свой канал, в который буду дублировать сообщения из моего блога https://amarchenko.dev/ , а также закидывать свои заметки/мысли на актуальные мне темы - web, backend, infra, процессы и так далее

Channel photo updated

Channel created