Я долго искал аналитику для своих пет-проектов. Мне нужно было решение, не использующее данные моих поситителей в своих целях, желательно опен-сорсное, с небольшим клиентским трекером или без него, не завязывающее меня на себе (например, с удобным экспортом или возможностью хостить бекенд самому).

Найти такую аналитику оказалось не просто, но в итоге я остановился на https://plausible.io/

Во-первых, они удовлетворяют всем моим требованиям.

Во-вторых, у них есть ряд приятных бонусов, о которых я даже не думал: возможность не ставить GDPR-баннер для Европы, классные имейл-дайджесты и сорцы на Elixir.

А в-третих, меня дико вдохновила история — это стартап из двух людей, которые делают заебись и зарабатывают на этом деньги. Недавно они достигли ревенью в 10 тысяч долларов в месяц.

Если вам понадобится простая и классная аналитика — возьмите эту.

#рекомендации

Субботний мини-анонс! Мы с Лешей Войцеховским (@crazymidnight) запустили твиттер-аккаунт с новостями фронтенда. Есть один нюанс — все твиты написаны нейросетью 🌚

Подписывайтесь, ставьте лайки, кекайте с удовольствием — https://twitter.com/neurofront

Из-за декабрьского факапа с подкастом у меня совсем пропало желание его дальше делать.

А когда нет драйва — очень сложно вернуться к проекту. Поэтому, вместо серьезного номерного выпсука я решил сделать коротенький спешиал на отвлеченную тему.

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

​​Сто лет не делал дайджест, а вот сейчас решил сделать 🌴

+ Как Netflix ведет разработку продукта. Обзор на книжку, обзор хороший, книжку не читал.

+ System Design для самых маленьких. Хорошая вводная статья, там в блоге есть еще небольшие заметки по более узким темам, тоже классные.

+ Introducing Zero-Bundle-Size React Server Components. Некоторые говорят, что это будушее фронтенд-разработки, почитайте пост в блоге.

+ Очарованные циферками. Интересные мысли про дата-дривен-что-угодно.

Наслаждайтесь!

#дайджест

Больше года назад мы в Самокате сделали прекрасную систему передачи параметров во фронтенд приложение во время деплоя. Я тогда написал черновик статьи про это, а потом целый год не мог его довести до нормальной статьи.

В эти выходные я его дописал, а сегодня утром опубликовал.

https://habr.com/ru/post/541314/

#фронтенд #удобство_разработки

JetBrains Academy ищет автора статей про Unix Shell (Bash)

Ребята ищут человека, который возьмёт на себя раздел Bash. Это классная парт-тайм ремоут работка, с большой творческой свободой и классной командой.

👉 Подробности

Масштабируемость

Готовность приложения к решению проблем возникающих при росте нагрузки.

Чтобы говорить о масштабируемости системы, нужно выделить ключевые параметры нагрузки (например, число запросов в секунду, отношение операций записи к операциям чтения, etc.)

После описания нагрузки, нужно выяснить: как повлияет на систему увеличение нагрузки? насколько нужно увеличить аппаратные мощности чтобы справиться с нагрузкой?

Для веб-сервисов самые важные метрики производительности — время ожидания и время отклика. Часто смотрят на медиану, 95-й перцентиль, 99-перцентиль и 99.9-й перцентиль.

> Измерять время отклика внутри приложения не стоит, это даёт недостоверные результаты. Лучше замерять на клиенте.

Масштабировать приложение можно вертикально — перейти на более мощный сервер. А можно горизонтально — распределить нагрузку на несколько менее мощных серверов. Для горизонтального масштабирования необходимо строить архитектуру, не предусматривающую разделения ресурсов. На практике часто совмещают два подхода и используют много очень мощных серверов.

> Некоторые системы могут адаптироваться автоматически — поднимать новые копии приложения при возрастании нагрузки, другие требуют участия людей.

Архитектура масштабируемого приложения сильно зависит от конкретного приложения, но обычно создаётся на основе универсальных блоков и паттернов, которые рассмотрены в этой книге.

#dia

Удобство сопровождения

Это в первую очередь возможность эффективной работы всех специалистов (разработчиков, админов, вот эвер) с системой.

Стоимость программы по большей части состоит из расходов на эксплуатацию и поддержку. Поэтому нужно проектировать системы так, чтобы снизить головную боль при сопровождении. Три ключевые характеристики, помогающие контролировать это:

+ удобство эксплуатации (мониторинг, автоматизация, документация, разумные дефолты, возможность самовосстановления, принцип наименьшего удивления, независимость от среды исполнения);

+ простота понимания (хорошие абстракции, явные зависимости, низкое сцепление модулей);

+ возможность развития на уровне всей системы.

#dia

Сегодня в 18 МСК буду в Клабхаусе, залейтайте.

https://www.joinclubhouse.com/event/P9g8oRjA

Мы в эфире, заходите 🤗

Штош, было забавно. Клабхаус я так и не распробовал, странная штука.

Мы в программном комитете Frontend Crew придумали пять тем для предстоящей конференции ☺️

Помогите выбрать лучшие. Среди проголосовавших разыграем пару билетов 💙

https://forms.gle/BbVx4PhssjdWrJ5aA

Ищем в Авиасейлс специалиста по информационной безопасности!

https://www.aviasales.ru/about/vacancies/2606969

Лучшая в мире компания, крутейший продукт, ремоут (или релокация).

Страховка, спорт, обучение, психотерапия и куча всего ещё — просто лучшие условия.

​​Новый выпуск подкаста!

Дима @ZeroBias сделал супер-крутой Effector — современный менеджер состояния для фронтенд приложений. Поговорили про фуллтайм опенсорс, спонсорство от компаний, проблемы современных UI-библиотек и недооцененных фронтендеров.

+ Патреон Димы — https://www.patreon.com/zero_bias
+ Новости экосистемы Effector — @effector_tips_ru
+ Процесс размышлений о реализации визуализации — @lines_of_code
+ Личный канал Димы — @leadingedge

Вот тут можно написать фидбек и мне будет радостно👇

Вжух, снова ищу пару неопытных фронтенд-инженеров. Пишите, расскажу подробнее.

Набраны ☺️

​​В эти выходные участвовал в хакатоне EBASH48. На мой взгляд, одна из главных ценностей хакатонов — попробовать новые подходы и технологии в реальном проекте. Одна из опробованных технологий поразила меня так сильно, что, возможно, мы затащим ее в большой продакшн.

Linaria — это CSS-in-JS библиотека с нулевым рантаймом и шикарным API, почти полностью повторяющий styled-components. Я сравнивал ее с SASS (потому что мы используем его в боевых проектах) и вот почему Linaria выигрывает:
+ Обычный CSS, без миксинов, сасс-переменных и прочего дерьма;
+ Шикарные динамические стили через CSS-переменные;
+ Удобный скоупинг всего — от класснеймов до кастомных переменных и кейфремов.

Linaria — лучшее решение для написания CSS в React-приложениях, что я встречал, просто кайф 😍

Реляционная модель vs документноориентированная модель

Большая часть приложений работает с объектами, которые не очень хорошо ложатся на реляционную модель — это называют рассогласованием (impedance mismatch). Часто это проблема решает через ORM, но фигово.

С другой стороны, если структура данных представляет собой независимый документ, то ее удобно сохранить в документноориентированную БД (MongoDB, RethinkDB, CouchDB, Espresso) в виде JSON.

Такой подход упрощает создание связей «один-ко-многим», все «многие» хранятся просто внутри «одного». В итоге весь документ можно извлечь одним запросом. Но связи «многие-к-одному» и «многие-ко-многим» плохо вписываются в концепцию документноориентированных БД. А поддержка ссылок в таких базах обычно слабее чем в реляционных, часто приходится решать эту проблему на уровне приложения.

> По мере развития приложения, количество связей внутри модели данных обычно увеличивается.

В документноориентированных БД используется schema-on-read — схема данных неявная и их интерпретация происходит при чтении. В реляционных — schema-on-write, то есть схема данных проверяется при записи и все данные в базе гарантированно ей соответсвуют.

> Если в одной коллекции может храниться много разных типов объектов, или структура данных определяется внешним поставщиком — обычно удобнее использовать неявную схему.

Основные доводы в пользу документной модели данных — гибкость схемы, лучшая производительность вследствие локальности и большая близость к применяемым структурам данных (для некоторых приложений). Реляционная модель отвечает на это лучшей поддержкой соединений, а также связей «многие-к-одному» и «многие-ко-многим».

Похоже, что реляционные и документноориентированные БД становятся все более схожими и в итоге их модели дополняют друг друга. Вероятно, будущее за гибридными моделями.

#dia

Закончу историю про цели нашего фронтенд-департамента 🤓

В Авиасейлс у нас много маленьких продуктовых команд. То есть, в каждой команде есть свои фронтендеры, бекендеры, QA, мобильные разработчики, аналитики, вот эвер. Соотвественно, получается много разных команд, которые взаимодействуют между собой через общую кодовую базу.

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

Каждый виджет — это просто компонент, который через пропсы получает шину событий и может слушать и передавать только ограниченное множество своих событий. А чтобы связать два разных виджета, необходимо создать отношение — это такая прослойка, которая превращает события одного виджета, в события другого. Так мы гарантируем, что виджеты остаются независимыми.

Может показаться, что мы придумали микрофронтенды, но это не совсем так. Дело в том, что сейчас вся эта система имеет две особенности:
+ все отношения определяются статически, еще при сборке бандлов известно какие виджеты присутствуют на странице и как они связаны между собой;
+ все виджеты и отношения деплоятся одновременно и приезжают на клиент в одном бандле.

Вероятно, в будущем мы будем развивать эту систему и придём к более трушным микрофронтендам 🤷‍♂️

#кейс