Картофельные лонгриды

Назад, к списку

Туман FrontOps-войны

Привет! Долго думал, с чего всё-таки начать цикл статей про магию, которая поддерживает фронтенд, поэтому давайте сначала поговорим о том, что из себя эта ✨ магия ✨ представляет.

Ребята, которые такой магией владеют, обычно называют её FrontOps. Откуда взялось Front ясно, но Ops кто таков? На слуху есть ещё один подобный термин — DevOps (Development and operations). В слово «operations» вкладывают обслуживание и автоматизацию всего, с чем взаимодействует наш код, то есть DevOps практики сосредоточены вокруг разработчиков и автоматизации их рутины, например:

и ещё куча разных вещей. Оно, так-то и во фронтенде нужно, и вот из девопса выкинули разработку, добавили фронтенд и получился FrontOps, хе-хе.

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

Бекенд был куда сложнее, и разработчикам надо было так или иначе понимать, как работает сеть, по которой летают запросы между сервисами, кто и как запускает приложения. Масштабирование, контейнеризация, другие страшные слова... Это всё нужно было научиться держать под контролем и автоматизировать. Что нужно было понимать фронтендеру помимо языков, с которыми он работал? Ничего.

Времена поменялись и появилась куча инструментов: от CSS-препроцессоров, которые избавляют нас от дублирования лишнего кода, до «frontender-friendly» поставки типа Vercel, которая позволяет парой кликов автоматически где-то разворачивать код. Проблема в том, что огромная часть инструментов, которые у нас появились, под капотом делают много неясных вещей, но пользоваться ими слишком просто: совсем не нужно разбираться с тем, как они устроены.

У фронтендера практически ничего не поменялось, он как просто писал код, так и пишет. В рабочем процессе типичного разработчика появились разве что npm i и npm start для того, чтобы под капотом непонятным образом куча js-файликов собралась в что-то, что переварит браузер.

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

Так и появилось отдельное течение, которое умные люди прозвали FrontOps. По сути своей, оно призвано подружить DevOps-практики в мир фронтенда, помня о его специфике.

В отличии от бекенда, которому нужен фронтенд для существования, фронтенд может существовать отдельно! Взять хотя бы бесполезные, но забавные сайты из The Useless Web. Каждый из них можно назвать отдельным продуктом, а огромная часть из них существует без бекенда. Любой фронтендер может превратить в продукт почти любую свою идею! Жаль, что не каждый знает, как доставить её до пользователя. В интернетах много статей по отдельным местам, которые чаще всего ломаются, но составить общую FrontOps карту приходится самому.

Все FrontOps-технологии, кажется, не покрыть никогда: как только начнешь погружаться в одну технологию, найдешь ещё пять, которые с ней связаны. Почему-то в моей голове укрепилась аналогия с «туманом войны» из игр: исследуешь территорию, а на ней дорожки в другие. Но в случае с FrontOps даже не ясно, откуда начинать исследовать...

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