Насколько глубоко фронтенд- и бэкенд-программисты должны знать смежный стек — отвечают эксперты

Глубина изучения сильно зависит:

• от продукта — насколько в нём разделён фронт и бэк;
• от команды — есть ли в ней явные фронтендеры и бэкендеры или все фуллстек-разработчики.

По опыту скажу, что в команде с фуллстеками фронтенд-разработчику будет сложновато. 🙂

Изучать смежные технологии нужно постоянно — в этих знаниях нет предела. В результате можно настолько изучить бэкенд, что однажды проснуться фуллстек-разработчиком. 🙂

Если говорить о конкретном минимуме знаний бэкенда для фронтендера, то вот он:

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

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

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

• знать о реализациях авторизации и аутентификации — современных и не очень (basic, oauth, ntlm, …);
• сконфигурировать хотя бы один Web Static Server, Web API Server, Proxy Server;
• написать сервис с несколькими API, а затем изменить требования — после обеспечить обратную совместимость и удобное версионирование API;
• интересоваться архитектурой решения в целом, интересоваться средствами мониторинга и не пренебрегать самостоятельным поиском проблем между микросервисами до похода к бэкенд-команде.

Для бэкенд-разработчика написать своё маленькое фронтенд-приложение будет полезно, чтобы лучше понимать желания фронтенд-разработчиков:

• когда лучше предоставить несколько отдельных API-методов и вернуть данные в нормализированном виде, а когда их лучше предварительно агрегировать и вернуть более сложные сущности;
• когда фронтенд-разработчики хотят в ответ массив, а когда объект с id в роли ключей;
• когда стоит помещать тексты ошибок в 5xx/4xx ответы, а когда стоит отдать эту ответственность фронтенду.

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

Разработчикам бэкенда я бы посоветовал понять модель многопоточности браузеров, возможности по хранению (LocalStorage, IndexedDB), обязательно необходимо погрузиться в модель безопасности (атаки XSS, CSRF и т. д.).

Разработчикам фронтенда полезно знать о том, как бэкенд работает с данными (SQL, ORM), как масштабируются приложения, каковы принципы интеграции (очереди сообщений, синхронное взаимодействие). И, конечно же, стоит погрузиться в особенности фреймворка, который используют коллеги — какие сообщения об ошибках выдаёт система, когда ломается.

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

Также в обоих случаях нужно знать «транспорт» для взаимодействия между фронтом и бэкендом. Например, отсутствие подробного знакомства с CSS, React и прочими фреймворками не мешает делать бэкенд при наличии специфицированного API.

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

Также сейчас разработка фронтовой части идёт на NodeJS, а это уже минимальная фуллстек-разработка. Для создания простейшего интерфейса необходимо развернуть стартовое окружение и написать сервер для раздачи самого веб-приложения по URL. Если необходима оптимизация под SEO, требуется Server Side Rendering — это уже изоморфные приложения (приложения, где и фронт- и бэкенд написаны на 90 % на одном языке, обычно на JS). По сути это уже standalone-приложения. Также стоит учитывать, что более 70 % приложений пишут фронтовую часть на React, а это компонентный подход. Часто его пытаются притянуть за уши к MVC, но на мой взгляд, он прямо проецируется из дизайн-мышления.

Что же тогда делают бэкенд-разработчики? Сейчас это больше построение микросервисной архитектуры, работа с большим количеством данных, построение удобного API для получения этих данных (REST, GraphQL), инфраструктура и архитектура, оптимизация и нагрузка, часто DevOps-история (выбрать между контейнеризацией Docker/Kubernetes/Swarm или же виртуализацией). Также не стоит забывать про BigData, машинное обучение и нейросети.

Резюмирую: чтобы понять, насколько глубоко нужно знать смежную область, необходимо определить, куда человеку интереснее развиваться. Фронтендеру нужно быть хорошим специалистом в своей области, а также, повторюсь, понимать серверную часть, структуры данных, протоколы и технологии общения (HTTP, WebSocket). Бэкендеру, по большей части, нужно знать, какие данные он получает от фронта и какие отдаёт, протоколы общения. Изучение остальных технологий уже зависит от энтузиазма и мышления разработчика.

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

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

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

Взаимодействие frontend и backend происходит по кругу: frontend отправляет пользовательскую информацию в backend, там она обрабатывается и возвращается обратно, приняв понятную форму.

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

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

• принципы работы сетевых протоколов, особенно HTTP (формат запросов/ответов, коды ответов и т. д.);
• форматы передачи данных XML и JSON;
• особенности архитектурных стилей, протоколов и стандартов REST, RPC, SOAP, WebSocket и Long-Polling.

Изучите производительность браузеров и мощности серверов: это поможет адекватно оценить технические возможности каждой стороны.

Знайте принципы и средства (Cookie, JSON Web Token) построения аутентификации в веб-приложениях.

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

А ещё есть fullstack-разработчики, которые разбираются и в серверной, и в клиентской части одинаково хорошо.

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

Бэкендеру для работы пригодится база фронтенда: HTML и CSS, понимание, как работает технология, которая используется на фронте (jQuery, Vue, Angular, React, etc). Кроме плюсов, перечисленных выше, база даст возможность брать на себя несложные задачи фронт-части в случае их высокой загрузки.

И наоборот, фронтендеру в работе пригодится база бэкенда — принцип работы веб-сервера, основы ЯП бэка и фреймворка. Это позволит, например, сделать что-то несложное самостоятельно и не тратить время на ожидание решения от бэкенд-разработчиков. А бэкэнду не придётся переключаться на эту мелкую задачу. Как известно, переключение между задачами — это зло. 🙂

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

С одной стороны — нет смысла забивать себе голову этими штуками, ибо сейчас уже существует огромный стек технологий. Но, разумеется, если, например, бэкенд написан на Node.js — тут всем надо знать JavaScript.

С другой стороны — обе стороны разработки должны понимать принципы работы как «обратной стороны медали», так и продукта в целом. Например, фронтенд-разработчики должны понимать (в случае медленной работы приложения), где проблемы — на стороне сервера или на фронте, либо же это их продукт на Vue.js тормозит. А бэкенд-разработчики должны понимать, что будут делать фронтендеры с их данными, как выводить и т. д. — соответственно, очень часто запросы по тому, как должен работать бэкенд, приходят от фронтенда, и бэкендерам приходится проектировать API.

Соответственно, общим стеком знаний можно назвать: принципы работы HTTP, Rest, GraphQL, JSON, HTML, WebSockets (а то бывает напрограммируют «такое», а ведь можно было на сокетах сделать, и все были бы счастливы), принципы авторизации (JWT например).

Бэкендерам про фронт желательно знать: принцип работы современных фреймворков, Shadow DOM, виртуальные DOM.

Фронтендерам про бэк желательно знать: основы работы с БД, принципы работы веб-/аппликейшн-серверов.

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

Уровень взаимодействия backend- и frontend-разработчиков зависит от масштабов разрабатываемой системы. В маленьких проектах, стартапах, при разработке MVP (Minimal Viable Product) и т. п. обычно привлекаются fullstack-разработчики, отвечающие и за frontend, и за backend. По мере роста проекта и сложности системы, всё больше прослеживается разделение между командами backend- и frontend-разработки, а в очень больших проектах они могут быть изолированы друг от друга, в этом случае роль «коммуникаторов» выполняют архитекторы системы. Безусловно, можно долгие годы работать именно в таких проектах и взаимодействовать друг с другом лишь на уровне API, не углубляясь в технологические стеки друг друга, но полагаться на это не стоит, ведь никогда не знаешь, какие проекты и задачи встанут перед тобой в будущем, и всегда ли ты сможешь реализовать себя в узкой специализации.

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

Квалифицированные бэкенд- и фронтенд-разработчики должны говорить на одном языке, с полуслова понимать друг друга, иметь возможность решать все рабочие вопросы самостоятельно. Для меня, например, оптимальный уровень погружения в смежный стек такой: нужно уметь читать и понимать программный код друг друга и, в случае необходимости, уметь вносить в него изменения. Но при этом, кстати, ты не становишься fullstack-разработчиком, точно так же, как ты не становишься разработчиком, научившись читать чужой код. 🙂

Я считаю, что разработчику в любом случае полезно иметь общее представление о том, как устроен продукт, над которым он работает. В контексте web-разработки важно понимать принципы и механизмы взаимодействия клиентской и серверной частей приложения. Это позволяет упростить коммуникацию между разработчиками разных направлений и взаимодействовать более эффективно. Далее всё зависит от личных предпочтений, а также от предъявляемых разработчику требований.

Всё ещё существует большое число компаний, использующих монолитную архитектуру, в которых frontend-разработчику то и дело приходится дорабатывать серверную логику, а backend-разработчику править верстку. В таких условиях, что немаловажно, глубокие знания смежного стека позволят более качественно выполнять широкий спектр задач и зарекомендовать себя как грамотного fullstack-специалиста.

Ещё больше команд сегодня используют распределённую клиент-серверную архитектуру, жёстко разделяя frontend и backend. В таких случаях backend-разработчик реализует определённый интерфейс взаимодействия в виде API, а frontend-разработчик работает с этим API как с чёрным ящиком. При этом нет никакой необходимости в обширных познаниях соседней области. Достаточно знать, как пользоваться ящиком: формат передаваемых данных, формат и типы ответа, возможные ошибки.

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

Резюмируем: требуемым минимумом является ясное понимание взаимодействия двух направлений — frontend и backend, по мере роста ваших компетенций также приветствуется расширение знаний в смежном стеке. Глубина этих знаний зависит от ваших индивидуальных предпочтений и внешних условий.

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

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

Активно я работал с фронтендом, когда учился в университете. Поначалу тяжело давалась идеология React и Vue — приходилось читать «туториалы», задавать вопросы. Сейчас найти время на «пощупать» технологии руками и вовсе сложно. Я полагаю, фронтенд- и бэкенд-команды могут эффективно работать на уровне API-контрактов — договорённостей, как и в каком формате будут общаться клиент и сервер: OpenAPI, API Blueprint. Знать совсем мелкие детали реализации необязательно. Но мне интересно наблюдать за трендами во фронтенде со стороны: у нас, бэкендеров, мир меняется не так быстро.

Радует, что за последние десять лет фронтенд- и бэкенд-разработчики значительно сблизились по стилю мышления и подходам в работе. Почему? Граница разделения ответственности между клиентом и сервером сместилась: сейчас не встретишь PHP-скриптов с намешанным в одном файле HTML и SQL. И серверные HTML-шаблонизаторы используются всё реже — сервер становится «тоньше» и отвечает только за данные, а не их представление. На стороне клиента, напротив, появляется дополнительная логика, которая требует новых подходов к построению веб-приложений: SPA, переиспользуемые веб-компоненты, модули, слои абстракции, «реактивные» данные, статическая проверка типов и т. п.

Популярность приобретают новые технологии, которые работают на стыке клиента и сервера. Сегодня, как минимум, стоит обратить на них внимание, так как не исключено, что в следующем проекте вы с ними столкнётесь. Например «реактивное» программирование и GraphQL. Последний — отличный вариант для проектирования единого API под разные потребности.

В реальной жизни я вижу, что уже появились люди, которые пишут только бэкенд или только фронтенд. Они вообще не знают, что происходит по другую сторону баррикад, и иногда это приводит к плачевным результатам. Например, фронтендер просит данные, а бэкенд их предоставляет, но разделёнными по разным ресурсам. Проект усложняется и рождаются не самые оптимальные решения. А всё можно было бы оптимизировать — объединить запросы в один, так как клиент у приложения один, и потратить на разработку и тестирование в N раз меньше времени.

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

Мне сложно представить себя в ситуации, когда я полностью не понимаю, что происходит на бэкенде. Я часто заглядываю в код «под капот» и нахожу, что мне нужно для работы. Так получается в разы быстрее, чем если бы я подключил к поиску коллег из команды бэкенда. Это про эффективность команды и про мою ценность как специалиста.

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

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

Если перед разработчиком или маленькой командой стоит задача сделать своими силами небольшое приложение или прототип, то придётся достаточно широко освоить технологии и фронтенда, и бэкенда, но при этом пожертвовать глубиной. Этот подход обычно называется «fullstack-разработка». Исторически он ближе к бэкенду, когда приложения «многостраничные», а фронтенд не очень сложный. Однако сегодня проект может иметь уклон в сторону фронтенда: сложный клиент и сервер с простыми функциями (например тонкого хранилища).

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

• создать общее представление о предметной области продукта и границах каждой его части;
• продумать и разделить ответственности на границах (кто потребитель интерфейсов, кто поставщик);
• создать среду непрерывной интеграции для быстрого прототипирования и тестирования изменений в разных частях продукта.

Хороший программист должен знать фронтенд на уровне, достаточном для самостоятельной верстки. Сейчас с развитием JavaScript-фреймворков хорошим плюсом будет понимание их работы (например ReactJS). Что касается фронтенд-разработчиков, необходимо иметь понимание устройства движка (CMS), на котором идёт работа, чтобы избежать неприятных ситуаций, таких как правки в ядре и т. п. Желательно также понимать, как реализовывать простейшие условия на бэкенде, уметь пользоваться системой контроля версий.

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

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

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

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

На мой взгляд подобное разделение в корне неправильное. Разработчиков не нужно делить на когорты и потом изолировать их друг от друга.

Почему?

1. Кросс-функциональные команды дают результат быстрее. Людям проще и быстрее работать в рамках одной логической задачи, чем разбивать одну задачу на несколько связанных исключительно по технологии.
2. Сейчас понятие фронтенд и бэкенд начинает размываться. SSR — бэкенд или ещё фронтенд? Serverless-функции, которые выполняются как бы прямо из фронта, — считаются бэкендом? Phoenix LiveView, N2O, Korolev — что они? Новые технологии работают на стыке зон ответственности. Инженеры должны адаптироваться.
3. В разделении мало смысла с точки зрения «роста». Мне нравится концепция Т-образных людей с широким кругозором и глубокой компетенцией в какой-то области. Штука в том, что чем бы человек ни занимался — ему нужно быть самодостаточным и понимать, как работает проект в целом.

Знать обе части нужно на уровне middle+, а какую-то одну из них необходимо знать на очень глубоком уровне. Желательно следить за основными трендами, создавать собственные инструменты и библиотеки. Не стоит забывать про аналитику, документацию, Ops и тестирование. Кто будет заниматься данными вещами?

Очень важно помнить, что у нас есть фундаментальная база, которая едина для всех языков, подходов и платформ. Вкладываясь в изучение фундаментальных вещей, нам будет намного проще учить конкретные реализации в виде разных инструментов. Что есть?

• Операционные системы;
• сети;
• алгоритмы и структуры данных;
• логика;
• теория категорий.

Мне очень нравится проект, который подробно показывает карту всех более-менее важных вопросов, которые нужно покрыть во фронте и бэке (а ещё и в Ops-части). Новичкам будет очень полезно.

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

Как правило, бэкендщики не воспринимают фронтенд как хардовое направление: порог вхождения во фронтенд ниже, чем в бэк, необязательно знать алгоритмы, Design Patterns, архитектурные паттерны, уметь моделировать БД. Поговорите с любым бэкендщиком, он скажет, что фронт — это jQuery. Но это было верно недавно, а сегодня положение дел изменилось. jQuery отошёл на второй план. Сейчас пришло время JS-фреймворков, борьбы за скорость загрузки сайтов, борьбы за уменьшение размера скриптов, оптимизации первичной загрузки, lazy load и прочих непонятных бэкендщику слов.

Так что же нужно знать бэкенд-разработчику из новинок фронтенда, чтобы получить в итоге отличный программный продукт? Основной инструмент веба — это браузер. Всё, что делает бэкендщик, в итоге будет видно в браузере, поэтому важно знать, как работают современные браузеры. И речь идёт не о том, чтобы изучать исходный код браузера — для дальнейшей оптимизации на фронтенде как минимум необходимо знать браузерный API, API работы с документом, DOM-модель, с чего начинается загрузка сайта, чем заканчивается, когда происходит загрузка всех ассетов и скриптов. Но и это не всё. Базово необходимо знать API, принимающие данные от сервера, AJAX-запросы, API хранения данных на клиенте, файлы cookie, local и session storage, HTML, CSS и основы JS.

Отдельно хочется остановиться на JS. Если бэкенд в виде Rest API, то без JavaScript не получится адекватно общаться с фронтендщиком. Как минимум надо знать типы данных, основные методы работы с ними, основы ES6 и выше. Также важно знать всё про JSON, потому что фронтендщику предстоит с ним работать.

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

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

Фронтендщику очень важно понимать, как работает сервер, хотя бы поверхностно знать, что такое Nginx и Apache, как выдаётся статика, какие типы запросов бывают, что отдаёт сервер, какие бывают статусы, типы протоколов, HTTP, HTTPS и другие.

Не менее важно поработать в нескольких шаблонизаторах и понимать, для чего они нужны. Со временем пригодится умение работать в Unix-системах, знание основных команд Bash-скрипта. Также пригодятся знание СУБД, не только NoSQL. Ещё нужно понимать, как строятся запросы к БД, насколько они могут быть тяжёлыми — это позволит лучше разбираться в важности кэширования данных.

Почти каждый фронтендщик рано или поздно столкнётся с докером, поэтому с ним тоже лучше познакомиться заранее.
Знание алгоритмов и Design Patterns, умение оценивать сложность алгоритмов актуальны и во фронтенде, как и знание ООП, от которого никуда не деться. Есть сферы, с которыми столкнётся любой разработчик, но есть и дополнительные навыки, которые зависят от конкретного проекта. И здесь нужно смотреть по ситуации и по задачам, поставленным перед разработчиком.

Если нужен масштабируемый, поддерживаемый проект, нужно уважать обе стороны, понимать, с какой болью и сложностью может столкнуться твой коллега. Всегда важен поиск оптимальных решений в конкретной ситуации, в конкретном проекте, поэтому желательно быть немножко фуллстеком. Как говорил Козьма Прутков: «Ограниченный специалист подобен флюсу, полнота его односторонняя». Для всех направлений необходимо знать общепринятые практики создания качественного продукта, принципы SOLID, KISS и DRY.