Как стать тимлидом фронтендеров и как жить после этого — расшифровка эфира

15 июня в нашем инстаграм-аккаунте прошел прямой эфир с Ильей, руководителем фронтенд-разработки в Яндекс.Деньги. Выкладываем запись эфира и расшифровку.

Меня зовут Илья, я работаю в компании Яндекс.Деньги и руковожу фронтендом. До этого был бэкенд-разработчиком, писал на C#, около 5 лет назад перешел во фронтенд. Чуть больше года руковожу. Вот такой путь развития. Еще активно участвую в Burning Lead – это сообщество для ведущих разработчиков, тимлидов, людей, которые так или иначе пересекаются с задачами управления; надеюсь, ребята из сообщества слушают стрим.

Про Node.js и его использование

Сначала скажу, как она у нас появилась и почему мы ею пользуемся. Исторически сложилось так, что у нас в Деньгах есть полноценный Java-бэкенд, в котором Java-разработчики работают с базами данных, с основной бизнес-логикой. Фронтендеры с бизнес-логикой не работают, мы подготавливаем для себя нужный формат данных и отправляем его на фронтенд, а там уже рисуем их на каком-либо фреймворке. Изначально у нас был Xscript-сервер, который ребята в Яндексе сделали еще в 2000-х годах – это наше legacy. Часть логики – серверный рендеринг – мы писали на XML, XSL/XML преобразования. Так продолжалось очень долго. Потом, когда мы осознали, что разработчиков на XSL/XML стало тяжело искать, мы стали выбирать новый сервер, в который можно было бы писать на бэкенде и потом использовать на фронтенде. Оказалось, что есть целая платформа Node.js.

Тогда Node.js была очень молодой платформой, версия 0.10, наверно. Решено было использовать ее по нескольким причинам: язык Javascript набирал популярность, разработчиков было много; кроме того, серверную и клиентскую логику мог писать один разработчик без суперспецифичных знаний. О своем выборе мы не жалеем: платформа все еще активно развивается, оптимизируется, становится быстрее, получает полезные фичи, имеет активное сообщество.

Поговорим про архитектуру фронтенда и о том, чего мы хотели бы достичь в архитектуре Яндекс.Денег в целом. Так как мы используем Node.js, у нас уже долгое время основой серверного фреймворка служит Express. Он хорошо справляется со своей задачей – обрабатывает запросы пользователя и дает ответы, больше от него ничего не нужно. Для него написано множество плагинов. Есть SSR для React-приложений, например; так как основной стек на клиенте – это React, SSR не проблема прикрутить. Есть много реализаций; можно даже не писать код: разворачиваешь из NPM, он сам все делает.

Что касается архитектуры – мы порядка 4-5 лет живем на Express, и из-за этого возникают некоторые проблемы. У нас довольно много разработчиков – в отделе сейчас человек 50 – и нам нужно писать понятный для всех код; разработчики могут менять интересы, переходить из команды в команду, и нам нужно, чтобы код был примерно одинаковым, чтобы разработчик в новой команде не тратил по месяцу на акклиматизацию к новому коду. Express – довольно низкоуровневый фреймворк, и с ним живется довольно тяжело: каждая команда использует свое видение того, как писать обработчики запросов или бизнес-логику, ходить в бэкенд. Первая попытка наладить архитектуру сервера была совершена, когда мы сделали ProcessFlow. Я на эту тему выступал с докладами – рассказывал, как на основе IDEF0 можно построить систему, которая позволит организовать бизнес-логику, задать правила ее написания, сделать поддержку, визуализацию связей между сущностями. Попытка была вполне успешной: в некоторых местах у нас были серьезные проблемы с пониманием кода, и ProcessFlow помогла их решить. Она работает и сейчас, и вполне нас устраивает.

Сейчас у нас идет переезд на NestJS. Это довольно современный серверный фреймворк, позволяет писать контроллеры в парадигме Model-View-Controller, организовывать бизнес-логику; его философия пришла из Angular. Его сильная сторона – это правила, они уже на уровне фреймворка определяют написание контроллеров и бизнес-логики. Бесконтрольная среда бывает губительна, когда вас много и все пишут по-разному; лучше иметь свод правил, к которому всегда можно обратиться – такой путь мы выбираем. Про NestJS активно рассказывает мой коллега Андрей Мелехов, ведущий подкаст devSchacht; он сейчас описывает процесс переезда на NestJS, обсуждает проблемы.

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

Про клиентскую часть

Она состоит из двух больших стеков. Первый – это легаси-стек с использованием методологии BEM Naming (определенные названия CSS-стилей, позволяющие избегать пересечений), на основе которой в Яндексе создали фреймворк. Мы использовали его довольно долго, так как мы используем технологический стек Яндекса. Он классный, и в нем работа с компонентами организована примерно так же, как в современных фреймворках: в виде отдельно лежащих блоков, которые удобно поддерживать. Однако он уже устарел, поскольку основан на GQL и не отвечает современным требованиям по UI; на нем очень сложно делать анимации и приложения на клиенте. Мы постепенно переходим на React уже несколько лет (переход продвигается тогда, когда меняется дизайн или функциональность: то есть, все переписывания бизнес-процессов происходят на новой технологии). Он показался нам довольно мейнстримовым — то есть, разработчиков на нем много. React — основной фреймворк на клиенте, в качестве стейт-менеджера используется Redux; с ним же мы используем Redux-Thunk для асинхронных действий и запросов к бэкенду. В нескольких проектах использовали hooks.

Почему не Angular?

Когда мы выбирали стек, Angular был приблизительно версии 1.5. Он показался нам сомнительным, и мы выбрали другое решение. К последним версиям Angular я не имею претензий, но отказываться от React мы не хотим.

Как я стал тимлидом, почему я выбрал этот путь, какие плюсы и минусы

На самом деле, в каждой компании будут собственные требования к тимлиду или руководителю отдела, но, как мне кажется, есть и определенный план того, что нужно знать и делать, чтобы развиваться в направлении менеджмента. Есть такой подкаст – PodlodkaPodcast, они публиковали такой план (роадмап). Крутая штука; там написано, что следует читать для развития нужных softskills — на них нужно делать упор. Конечно, у хорошего тимлида должны быть и отличные hardskills: он – не просто формальный лидер команды (допустим, 5 человек), он должен доказать свое лидерство, он должен учить свою команду, его люди должны желать научиться программировать так же, как может он. Но важны и softskill: коммуникативные навыки для общения в пределах команды и вне их, для отстаивания мнения команды, для поиска компромиссов. В работе тимлида очень много коммуникаций. Кроме того, нужно уметь проявлять эмпатию: при общении с разработчиками важно устанавливать понимание на уровне чувств, понимать настроение каждого собеседника, определять, чего он хочет. Напрямую это не говорится, но очень хорошо, когда тимлид владеет этим. Здорово, когда к hardskills также прилагается умение наставничества: за таким тимлидом потянутся люди, он будет в состоянии четко формулировать и ставить задачи.

У меня все произошло приблизительно по этому плану. Я учился коммуникации, помогал ребятам – даже в тех случаях, когда я сам изначально не понимаю, в чем проблема, полезно вместе сесть и разобраться с проблемой. Ко мне стали чаще обращаться люди; руководство это заметило, и меня повысили до старшего разработчика, а через год – до ведущего. В нашей компании это – тот разработчик, который непосредственно отвечает за развитие и рост команды. Я готовил много различных воркшопов по тестам, нагрузочному тестированию. В общем, я смотрел, какие темы в отделе в данный момент «больные», и старался сделать что-то полезное для команды, чтобы улучшить положение – с помощью воркшопов, выступлений, просто личной помощи; и, когда наш руководитель ушел, он порекомендовал меня на его место.

Когда я стал тимлидом, проблемы только начались. Можно подумать, что на этом месте всё должно быть хорошо: разработчики работают, лид командует, и всё — но это не так. Когда я был разработчиком, я делал понятную задачу и радовался своему достижению – но у руководителя, как оказалось, задачи часто сильно размыты. Нужно «улучшить что-нибудь». Например, надо ускорить время код-ревью: человек заходит, просматривает код и нажимает кнопку, что тут можно улучшать? Второй важный момент, который на тебя давит, состоит в том, что руководитель не решает прикладных задач своими руками. И тут происходит «синдром самозванца»: может казаться, что ты просто тратишь время, пока разработчики пишут код, и ты иногда чувствуешь себя бесполезным. Нужно понимать и знать свою ценность: коммуникации – это тоже важная задача. Хороший руководитель помогает снять ненужные коммуникационные барьеры в ходе проекта; разработчики могут не коммуницировать, потому что им это некомфортно, но руководитель – обязан.

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

О процессах управления людьми в нашем отделе

Процесс разработки подразумевает общение разработчиков между собой, и у нас есть несколько точек пересечения. Задача на разработку поступает в одну из команд; обычно команда — это Java-разработчики, фронтенд-разработчики, менеджер, продукт, обязательно тестировщики. Такая единица, сидит где-то отдельно. Существование других команд для нее особенного значения не имеет само по себе – но нам необходимо, чтоб все команды писал приблизительно единообразный код. Для этого нужно общаться, и здесь есть несколько подходов. Во-первых, это происходящие время от времени встречи всего отдела; сейчас мы все собираемся в zoom, но это, конечно, не то. На встречах мы делимся новостями, ребята рассказывают, что они делают у себя в командах: какие у них проекты, какие будут в дальнейшем, что и как они делают. Это помогает строить представление о том, что происходит во фронтенде: он большой, просто так его рассмотреть не выйдет. Еще мы организуем tech talks, разные по масштабам: на всю компанию или на наш отдел, и там представляются технические приемы: например, на одном из них рассказывали, как используются hooks в React, как они влияют на форму, как выглядит код для них, какие плюсы и минусы. Такие доклады интересно слушать, и они помогают распространять по компании знания.Непосредственно в разработке есть процессы, которые позволяют нам общаться так, чтобы писать код, который потом не встретит непонимания на кодревью из-за используемых приемов, компонентов и библиотек – то есть, мы стараемся нивелировать плохие последствия от изолированного принятия решений. Этот процесс, который мы называем Logic Review, позволяет нам узнавать мнения экспертов, ведущих разработчиков, старших разработчиков после того, как мы понимаем, как делать определенную задачу – то есть, сверить наше видение реализации проекта с видением тех, кто определяет дальнейшее развитие всего отдела. Он позволяет нам обмениваться знаниями, технологиями, и контролировать однородность и архитектуру стека. Конечно, успеть везде и избежать всех проблем на кодревью невозможно, но такая сверка перед началом разработки позволяет уменьшить их количество.

Можно ли обмануть Review 360?

Напомню, что Review 360 – это когда все (разработчики, тестировщики, менеджеры), с кем работал человек, которого нужно оценить, опрашиваются «по кругу» с помощью опросника. Я об этом процессе рассказывал на Burning Lead. Если команда небольшая, как у нас обычно – человек 5-10 – то этот процесс, собственно, не нужен: тимлид может сам пообщаться с каждым членом команды. Собственно, он и должен общаться с каждым разработчиком раз в 1-2 недели, чтобы понимать, чего хочет разработчик, какое у него настроение, доволен ли он задачами, как он работает, как проходит его рост. Но, когда команда большая – например, у меня сейчас больше 50 фронтендеров – то на такое личное общение уже не будет хватать времени. У тимлида есть и другие обязанности и проекты, он обязан развивать отдел, он не может тратить все рабочее время только на общение, которое впоследствии нужно будет еще и проанализировать. Поэтому приходится использовать менее точные подходы – например, Review 360.

Можно ли его обмануть – я думаю, имеется ввиду то, могут ли разработчики договориться между собой и поставить себе высокие оценки? Наверно, могут, но с менеджером и product owner так не договоришься: эти люди преследуют несколько другие интересы, и это будет легко вычислено. То есть – можно, но ненадолго. Со временем станет понятно, что разработчик не делает свои задачи. Если product owner говорит, что разработчик не справляется, а другие разработчики ставят ему высшие оценки, то мы ясно понимаем, что существует проблема: либо product owner на него точит зуб, либо другие разработчики чего-то не замечают (или они договорились).

В целом, я думаю, что 360 Review – довольно объективная вещь, и мы их проводим с определенным промежутком времени. Опыта по ним накопили еще не слишком много, но мы постепенно двигаемся вперед и совершенствуем методы подсчета статистики и наборы вопросов.

Расскажите про менеджер зависимости, composer и Laravel

Я знаю, что Laravel – хороший PHP-фреймворк, и у нас на нем пишут, но сам с этими технологиями почти не работал.

У вас есть разделение на верстальщиков и JS-разработчиков, или разработчик делает все?

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

Что нужно знать джуниор-фронтенд-разработчику для работы в компании?

К сожалению, сейчас у нас нет открытых вакансий для джунов, но они бывают. Мы требуем знания теории языка Javascript. Это может показаться абсурдным, потому что теория JS в повседневных задачах вроде бы не нужна; однако мы знаем, что человек, изучивший теорию, умеет работать с информацией и воспринимать её. Кроме того, у него есть мотивация: он сел и разобрался с тем, как язык работает; когда он сталкивается с проблемой или сложным местом, он знает, как искать нужную для решения информацию (даже гуглить надо уметь).

Расскажите про архитектуру клиентской части. Есть ли у вас библиотека компонентов, и как она шарится? Сколько независимых приложений, все ли они в одном стеке?

Про архитектуру я уже немного рассказывал. Библиотека компонентов у нас есть, их несколько. Есть та, которую мы получаем от Яндекса, чтобы визуальный стиль был одинаковым. Есть дизайн-система, которая говорит, какие сетки, цвета, типографику (и т.д.) мы используем на фронтенде – то есть, эта система полностью диктует расположение и цветовую схему. Наконец, библиотека общих между приложениями компонентов, которые мы используем. Приложений у нас больше 20 (26?), и во всех она используется; иногда мы довольно сильно ползем по версиям – получаются разные версии в разных приложениях, из-за чего может страдать визуальная часть. Это одна из больших проблем устройства микросервисов с общей библиотекой, но мы стараемся.

Какой размер вашей команды?

У меня две роли в компании: я руковожу отделом порядка 50 человек и одновременно являюсь product owner нашей платформенной команды, там 8 человек.

React Native или Flutter?

У нас были эксперименты с React Native, Flutter тогда был очень новым; мы решили, что выберем React Native.

Яндекс хочет свой фрейм запускать?

Нет, BEM – это очень старый фреймворк, он устарел, мы вместо него используем React. Никто не хочет запускать новый фреймворк.
Вопрос: на бэкенде только JS, или есть какие-то legacy-части?
Я рассказывал, что у нас есть сервер с Xscript с XML/XSL. Это как раз и есть наше legacy, мы его активно выпиливаем и хотим как можно скорее прекратить его использовать. В основном – в 96% случаев – у нас используется JS.

Redux-Thunk или Redux-Saga?

Мы использует Thunk. К Saga был подход; может быть, у нас тогда просто не было ребят, которые достаточно хорошо в ней разбираются, но преимуществ над Thunk мы не увидели. Сейчас уже есть подход с hooks, но пока Thunk очень активно используется.

Вы внутри компании или команды ставите задачи по Smart?

Когда мы делаем проекты, цели ставятся по Smart. То есть, мы должны четко представлять, что мы будем делать и к чему прийти. Новичкам тоже задачи ставятся по Smart. Но я не могу сказать, чтобы уже в процессе разработки всегда были четко прописанные задачи: часто, когда ребята в команде создают задачи, они могут быть совершенно по-разному описаны, но для новичков всегда всё описывается так, чтобы было ясно, как идти и к чему. То есть, не все 100% задач ставятся по Smart, но мы активно используем эту методологию.

Насчет микросервисов – сейчас выкатили Module Federation Pack 5, можно ли в эту сторону посмотреть?

Да, но это уже, наверно, не микросервис, а микрофронтенд? Нужно будет анализировать, что можно вытащить из этого; просто в лоб микросервисные задачи на фронтенде не очень хорошо решаются.

В чем разница в управлении 5, 10 и 50 людьми?

Во внимании, уделяемом разработчикам. Когда разработчиков 5-10, я могу с каждым из них пообщаться, выслушать проблемы, понять, чего они хотят и как развиваются. Когда их 50, это невозможно; конечно, это ухудшает ощущения от роли руководителя, потому что кажется, что я отделен от разработчиков, но сделать с этим ничего нельзя. Это основная разница. Кроме того, 5-10 человек – это одна команда, которая вместе работает, но 50 человек не могут быть одной командой; такое количество разработчиков нужно разбивать по отдельным управляемым группам, иначе не получится держать фокус.

Будет ли массовый переход на NestJS?

Сложно сказать. Может, завтра появится новый фронтенд-фреймворк, превосходящий NestJS, и мы все будем на него переходить. Я думаю, что сейчас NestJS хорошо проработан, но нужно исходить из задачи. Для многих задач, которые мы решаем на Node, не нужен такой серьезный фреймворк – например, для лямбда-функций, которые кто-то будет вызывать; но, когда на фронтенде есть развесистая логика, кажется, что подошел бы лучше Nest. Он сейчас хорошо проработан, есть и бэкенд-фреймворк (хотя он был довольно сырым, когда мы смотрели его). Nest развивается и, может быть, станет более популярным, но я не думаю, что будет массовый переход на него, как на Express.

Чем отличаются собеседования на джуна и миддла? Что оценивается во втором случае?

Когда мы собеседуем джуна, мы проверяем мотивацию человека, базовые знания JS, смотрим на коммуникативность и желание развиваться. С миддлом все интереснее: ведь миддлы – это люди, которые пишут основную часть кода наших проектов; у них мало встреч, они большую часть времени именно разрабатывают. Мы должны хорошо проверить его hardskills (задачами), узнать, как он рассуждает, поговорить про архитектуру, спросить, как он организует проекты, рассмотреть его стиль написания кода. У самого миддла уже есть сформированные ожидания относительно компании – то есть, с нашей стороны нужно донести, чего мы ждем от него и что можем предложить.

Есть ли какая-то боль в твоей команде, которую хотелось бы решить? С чем это связано, и какое может быть решение?

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

Как строите процесс по управлению таким количеством человек? Сколько лидов? Тяжело ставить цели?

Непросто. Очень много коммуникаций. Вместо официальных лидов у нас в каждой команде роль лидера выполняет самый опытный разработчик, который непосредственно работает и общается с людьми, проводит ревью, декомпозирует и нарезает задачи. С каждым таким лидом мы коммуницируем, пересекаемся на ревью. Есть еще более крупные направления (B2B, B2C), и у каждого направления есть человек, который за него отвечает. Он выстраивает работу в своем направлении, в том числе работу с людьми. Я стараюсь общаться как со старшими разработчиками, так и с ведущими разработчиками направления, как можно чаще; еще у нас есть общие встречи старших разработчиков, где мы обсуждаем новости, проблемы команд и процессов, думаем, что делать. Я думаю, старшие разработчики должны ощущать себя некоторой командой, с которой можно свернуть любые горы – сделать процессы такими, как нужно, вместо того, чтобы смиряться с неудобствами.

Проводите 1 на 1? Как часто? Лайфхаки?

Собственно, у нас в компании ревью как раз называется «1 на 1». Сейчас я провожу со всеми старшими разработчиками ревью раз в месяц (это реже, чем рекомендуется – лучше проводить раз в пару недель). Зачастую нам есть, что обсуждать. Лайфхаков особых нет – в литературе достаточно подробно расписано про 1 на 1. Важно давать разработчику говорить – он должен говорить примерно 80% времени; в этом суть: задача руководителя – создать на ревью дружественную и безопасную атмосферу, чтобы разработчик мог ему рассказать все, что его беспокоит. Это довольно тяжело и не всегда получается, но круто, если 1 на 1 есть, и на них есть, что обсуждать. Их лучше проводить в неформальной обстановке – например, можно в парке. Создание комфортной атмосферы может быть разным – это не только переговорка в офисе.

Какие вакансии у вас открыты?

В каком направлении? У нас довольно много в разных направлениях. По фронтенду мы ищем нескольких миддл-разработчиков (по-моему, 2), можно и senior.

Какие сложные задачи возникают у руководителя?

Сложно говорить о сложности задач, когда ты их решаешь. Допустим, отказ от легаси – это сложная задача. Есть бизнес, который хочет развиваться; есть ты, руководитель, который хочет, чтобы легаси не стало. Нужно находить общий язык с бизнесом и добиваться внесения в бизнес-план задач по отказу от легаси, что нетривиально. Это требует хороших коммуникативных навыков, хорошего фокуса – нужно постоянно держать на пульсе руку; задача бизнеса – зарабатывать деньги, он не любит отказываться от работающих легаси-систем.
Сложная задача – придумывать задачи по улучшению работы в отделе. Нужно анализировать, с какими проблемами сталкиваются разработчики, не забывать улучшать dev-experience. Выявлять проблемы – это тоже нетривиально.

Рассматриваете фронтов на удаленке?

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

Что делать, если тимлид слабоват и явно не должен оставаться на позиции?

Нужно использовать механизм подачи обратной связи. Это мощный и классный механизм, но, конечно, нужно делать это аккуратно, чтобы человек не обиделся. Нужно уметь проявлять эмпатию, понимать чувства человека, давать в правильном направлении обратную связь. Он может либо принять, либо не принять ее; если он стал тимлидом, он должен уметь работать над собой и принимать обратную связь. Важно не просто дуться на него из-за того, что он «не дотягивает», а сказать ему конструктивно, что, на ваш взгляд, делается плохо, и узнать его мнение. Я сам не мастер подачи обратной связи, мне еще предстоит этому научиться, но я знаю главное правило: говорить про действие, а не про личность. Если рассказать лиду, какие вещи в команде проседают – может быть, все починится.

А что дальше?

30 июня в 20:00 в нашем инстаграм-аккаунте будет выступать Влада Рау — Senior Digital Analyst в лондонском офисе McKinsey Digital Labs. Сейчас Влада занимается product/data engineering. До своего переезда в Лондон она дважды стажировалась в Google в Дублине, а также училась в ВШМ СПбГУ и IE Business School в Мадриде.

Задать ей вопрос можно в комментариях к этому посту.

Что было ранее

1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
5. Ашот Оганесян, технический директор и основатель DeviceLock — кто ворует и зарабатывает на ваших персональных данных.

о чем это мы? / Блог компании Райффайзенбанк / Хабр

Все эти годы вы, frontend-разработчик, писали монолиты, хотя и понимали, что это дурная привычка. Вы делили свой код на компоненты, использовали require или import и определяли npm-пакеты в package.json или плодили гит-репозитории в вашем проекте, но все равно писали монолит.
Пришло время изменить положение.

Почему ваш код можно считать монолитом?

По своей природе все frontend-приложения монолитны – кроме приложений, реализующих микро-фронтенды. Причина в том, что вы разрабатываете с использованием библиотеки React, и работу ведут две команды. Обе должны использовать одну версию React и держать друг друга в курсе обновлений, а значит, неизменно решать конфликты при мерже кода. Они не полностью независимы друг от друга в кодовой базе. Вероятно, они вообще пользуются одним репозиторием и одной системой сборки. Микросервисы могут спасти от монолитности приложения! Но как же так? Ведь они для бэкенда! *неимоверное удивление*

Что же такое микросервисы?

Говоря простым языком, микросервисы — это техника разработки, которая позволяет разработчикам делать независимые поставки функционала (релизы) для разных частей платформы, и при этом релизы не ломают друг друга. Независимые поставки позволяют им собирать изолированные или слабосвязанные сервисы. Есть несколько правил, делающих такую архитектуру устойчивее. Вкратце их можно определить так: каждый сервис должен быть маленьким и выполнять лишь одну задачу. Следовательно, работающая над ним команда тоже должна быть маленькой. Насколько крупными могут быть проект и команда, объясняют Джеймс Льюис и Мартин Фаулер:

Разработчики, взаимодействующие с микросервисами, называют разные размеры. Самые крупные из них отвечают стратегии Amazon о «команде на две пиццы» — не более 10-12 человек. Обратный полюс – команды из 5-6 человек, где каждый поддерживает один сервис.

Вот схема, объясняющая отличие монолита от микросервисов:

Из схемы видно, что каждый сервис в системе микросервисов является отдельным приложением, кроме UI — он остался единым целым! Когда все сервисы поддерживаются одной командой, велик риск, что по мере роста компании frontend-команда перестанет за UI успевать. В этом состоит уязвимость данной архитектуры.

Архитектура может принести и организационные проблемы. Предположим, что компания выросла и взяла на вооружение гибкие методологии разработки (это я про Agile). Они требуют небольших кросс-функциональных команд. Конечно, в нашем абстрактном примере руководители начнут разделять задачи frontend’а и backend’а, и кросс-функциональные команды не будут по-настоящему кросс-функциональны. И все усилия будут тщетными: команда может выглядеть гибкой, но на деле будет сильно разделена. Управление подобной командой не для слабонервных. На каждой планерке будет вставать вопрос: достаточно ли frontend-задач, достаточно ли backend-задач в спринте? Для решения этих и многих других проблем пару лет назад возникла идея микрофронтедов, быстро завоевавшая популярность.

Решение проблемы: микрофронтенды

Решение выглядит довольно очевидно, ведь аналогичные принципы давно и успешно применялись в работе над backend-сервисами: разделить монолитный фронтенд на небольшие UI-фрагменты. Однако UI не совсем похож на сервисы – это интерфейс между конечным пользователем и продуктом, он должен быть продуманным и системным. Более того, в эпоху одностраничных приложений, целые приложения запускаются через браузер на клиентской стороне. Это уже не простые HTML-файлы, это сложные компоненты, которые могут заключать в себе различную UI и бизнес-логику. Теперь, пожалуй, необходимо дать определение микрофронтендам.

Принцип микрофронтендов: представление вебсайта или веб-приложения как набор функций, за которые отвечают независимые команды. У каждой из команд есть своя миссия, свое поле работы, на котором она специализируется. Команда кросс-функциональна и разрабатывает
весь цикл – от базы данных до пользовательского интерфейса (micro-fontend.org).

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

Общая структура и еще немного терминологии

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

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

Проблемы, которые нужно решить

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

Проблема №1: добиться цельного и согласованного поведения от UI, когда у нас несколько абсолютно автономных микроприложений

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

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

Либо же мы можем сделать SASS-переменные и примеси общими для всех команд. Среди минусов данного подхода будут повторяющаяся реализация UI-элементов и необходимость постоянной проверки дизайна сходных элементов во всех микроприложениях.

Проблема №2: убедиться, что одна команда не переписывает CSS другой команды

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

Во-вторых, можно заставить каждое микроприложение стать кастомным веб-компонентом. Преимущество такого подхода в том, что ограничением занимается браузер. Однако у всего есть цена: с Shadow DOM почти невозможно проводить рендеринг на стороне сервера. К тому же кастомные элементы не поддерживаются браузерами на 100% — тем более, если вам нужна поддержка IE.

Проблема №3: сделать глобальную информацию общей для разных микроприложений

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

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

Также вам может помочь реализация pub-sub или T39. Если вам нужен более тонкий обработчик глобальных состояний, можно реализовать небольшой общий Redux – таким образом получается более реактивная архитектура.

Проблема №4: если все микроприложения автономны, как проводить маршрутизацию на стороне клиента?

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

Мой прагматический подход заключается в создании общего клиентского маршрутизатора, ответственного только за маршруты верхнего уровня, а остальное отдано на откуп соответствующим микроприложениям. Допустим, у нас есть определение маршрута /content/:id. Общий маршрутизатор решит часть c /content, и решенный маршрут будет передан ContentMicroApp. ContentMicroApp – автономный сервер, который будет вызываться только с /:id.

Проблема №5: а точно ли нам нужна SSR (server-side rendering), возможна ли она при использовании микрофронтендов?

Рендер на стороне сервера – дело непростое. Если вы хотите связать микроприложения с помощью iframes, забудьте о рендеринге на стороне сервера. Аналогично, веб-компоненты для связывания не сильнее iframes. Однако если каждое из микроприложений способно рендерить контент на стороне сервера, то связующий слой будет отвечать только за объединение HTML-фрагментов на стороне сервера.

Проблема №6: «Интеграция с имеющимся окружением нужна как воздух! Как ее произвести?»

Для интеграции с имеющимся системами, я хочу описать свое видение, которое я называю “постепенным внедрением”.

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

Следующая ступень – постепенное внедрение. Мы возьмем небольшой кусочек LegacyMicroApp, удалив главную навигацию, заменив ее зависимостью. Эта зависимость – микроприложение, реализованное с помощью новенькой блестящей технологии, NavigationMicroApp.

Теперь LegacyMicroApp будет перехватывать все роуты через зависимость NavigationMicroApp и обрабатывать уже внутри себя.

Затем аналогичным способом мы переделаем футер.

Так мы будем продолжать откусывать от LegacyMicroApp по кусочку, пока от него ничего не останется.

Проблема №7: оркестровать сторону клиента, чтобы не приходилось каждый раз перезагружать страницу

Связующий слой решает проблемы на стороне клиента, но не на стороне сервера. На стороне клиента мы, загрузив единый HTML, не можем загружать при смене URL отдельные части. Следовательно, нам нужен механизм, который загружает фрагменты асинхронно. Проблема в том, что у этих фрагментов могут быть зависимости, и эти зависимости нужно уметь разрешать на стороне клиента. Это означает, что микрофронтенд-решение должно предлагать механизм загрузки микроприложений и внедрения зависимостей (dependency injection).

Перечисленные выше проблемы можно объединить в следующие темы:

Сторона клиента

• Оркестрация
• Маршрутизация
• Изоляция микроприложений
• Взаимодействие приложений
• Единство UI микроприложений

Сторона сервера

• Серверный рендеринг
• Маршрутизация
• Управление зависимостями

Гибкая и мощная, но простая архитектура

Ради этого стоило перетерпеть начало статьи! Основные элементы и требования микрофронтенд-архитектуры наконец-то начали вырисовываться 😉

Руководствуясь обозначенными требованиями и вызывающими беспокойство вопросами, я начал разрабатывать решение под названием microfe. *предвосхищение фидбека*

Здесь я в общих чертах опишу архитектуру проекта, описав вкратце его основные компоненты.

Легче всего начать со стороны клиента, которая обладает тремя отдельными основными структурами: AppsManager, Loader, Router, а также одной дополнительной, MicroAppStore.

AppsManager

AppsManager – ядро оркестрации микро-приложений на стороне клиента. Основная задача AppsManager – создание дерева зависимостей. Как только все зависимости разрешены, AppsManager запускает микроприложение.

Loader

Еще одна важнейшая часть оркестровки клиентской стороны – Loader. Он отвечает за загрузки приложений для клиентской стороны.

Router

Для выполнения маршрутизации на стороне клиента я внедрил Router в microfe. В отличие от обычных маршрутизаторов стороны клиента, маршрутизатор microfe обладает ограниченным функционалом. Он обрабатывает не страницы, а микроприложения. Допустим, у нас есть URL /content/detail/13 и ContentMicroApp. В таком случае маршрутизатор microfe обработает URL до /content/* и вызовет часть ContentMicroApp /detail/13.

MicroAppStore

Для решения клиентского взаимодействия между микроприложениями я внедрил в microfe MicroAppStore. Он обладает сходным функционалом, что и библиотека Redux, но с одним нюансом: он более гибкий в отношении асинхронного изменения данных и объявления reducer’a.

***

Сторона сервера, возможно, немного более сложна в реализации, но имеет более простую структуру. Она состоит из двух основных частей – StitchingServer и MicroAppServer.

MicroAppServer

Минимально возможный функционал MicroAppServer можно выразить так: init и serve.

Когда MicroAppServer загружается, первое что он должен делать — это вызвать SticthingServer и зарегистрировать эндпоинт с объявленным микро-приложением. Оно определяет зависмости, типы и URL схемы MicroAppServer Думаю, что о serve рассказывать излишне – здесь ничего интересного.

StitchingServer

StitchingServer позволяет зарегистрировать endpoint в MicroAppServers. Когда MicroAppServer регистрируется в StichingServer, StichingServer записывает объявление MicroAppServer.

Позже StitchingServer использует объявление для разрешения MicroAppServices от требуемого URL.

Разрешив MicroAppServer и все его зависимости, в названиях всех соответствующих путей в CSS, JS и HTML появится соответствующий публичный URL. Дополнительный шаг – добавление к CSS-селекторам уникального префикса MicroAppServer для предотвращения конфликта между микроприложениями на стороне клиента.

Затем на сцену выходит главная задача StitchingServer: компоновка всех полученных частей и возврат цельной HTML-страницы.

Пара слов о других реализациях

Еще до того, как в 2016 году появился термин микрофронтенд, многие крупные компании пытались решать схожие проблемы – например, Facebook с его BigPipe.

Сейчас идея набирает обороты. Компании самого разного масштаба интересуются этой темой, инвестируя в нее время и деньги. Например, Zalando предоставила открытый код своего решения Project Mosaic. Могу сказать, что microfe и Project Mosaic следуют аналогичным подходам, но с некоторыми кардинальными отличиями. Если microfe прибегает к полностью децентрализованной маршрутизации для большей независимости каждого микроприложения, Project Mosaic предпочитает централизованную маршрутизацию и определение шаблона для каждого маршрута. Кстати говоря, Project Mosaic позволяет легко проводить АB-тестирование и динамическую генерацию шаблона прямо на лету.

Есть и другие подходы, в частности, использование ifram’ов в качестве связующего слоя – очевидно, не на стороне сервера, а на стороне клиента. Это очень простое решение, которое не требует особой серверной структуры и привлечения DevOps. Оно может быть реализовано фронтенд-командой самостоятельно, а значит, создает меньше организационных проблем для компании и стоит дешевле.

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

Заключение (и ссылки)

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

micro fe app registry server
micro front end infrastructure

Что фронтенд разработчики должны знать о бэкенде? / Хабр

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

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

Ниже представлен краткий список того, о чем должен знать разработчик интерфейсов.

Частота запросов

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

Как мы можем измерить насколько запрос затратный?

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

Давайте рассмотрим пример того когда это становится критичным: предположим мы разрабатываем google docs.

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

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

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

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

Время простоя (downtime)

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

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

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

В любом случае, хороший фронтэнд должен всегда отлавливать ошибки в запросах с помощью try catch и иметь заготовленные ошибки для пользователя. В javascript нет встроенной функции(recovery panic), которая позволяет продолжить выполнение кода после ошибки, поэтому при её возникновении ваше приложение упадет.

HTTP

Бэкэнд и фронтенд должны использовать соответствующие HTTP статусы (в определенной степени). Надеюсь, ваш бэкэнд не воспринимает каждую ошибку как 400.

Интерфейс должен знать каждый статус, который бэкэнд планирует вернуть.

Не парсите сообщения об ошибках, чтобы определить, то что авторизация не удалась, код ошибки 401 подходит для этого больше.

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

Другие свойства HTTP запросов которые желательно знать:

• HTTP запросы могут быть закрыты сервером если они занимаются слишком много времени прежде чем завершатся. Если вы думаете что некоторая задача займет больше времени чем лимит на запрос (как правило около 20 секунд), вам следует выбрать вместо единичного запрос-ответа, запрос с последующим опросом результата. Или воспользоваться другими механизмами, например веб-сокетами.
• Если вы отправляете большое количество данных на сервер(например видео), вы должны использовать составной HTTP запрос(multipart/form-data), который делит данные на части перед отправкой.
• Иногда неожиданно возникает то, что существует ограничение размера URL. Некоторые веб-интерфейсы передают данные обратно на сервер с query параметрами, но если они длиннее 2048 символов, вам придется изменить такой способ на передачу параметров в теле HTTP запроса.

Делегирование бизнес логики

Если какая-то бизнес логика вашего функционала может быть реализована и на бэкенде и на фронтенде, где лучше её реализовать?

В основном лучше делать это на бекенде. Причины:

1. Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
2. Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
3. Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для pro пользователей. Если ограничение будет сделано на фронтенде, то кто-либо потенциально может провести реверс-инжиниринг и получить доступ к функционалу.

Кросс-доменные запросы

В качестве протокола безопасности, если запрос к бэкэнду поступает из другого домена, он будет отклонен из-за того что он является кросс-доменным запросом. Такое поведение обусловлено политикой одного источника(Same-Origin Policy). Данная политика запутывает людей в процессе разработки, поскольку порты тоже считаются частью домена.

Зачастую используется сервер npm/yarn для фронтенда и бэкенда на другом порту, что делает каждый запрос кросс-доменным.

Решения:

• Указание одного домена в hosts файле и разграничивание фронтенда и бекенда с помощью nginx*.
• Включить кроcс-доменные запросы на сервере в зависимости от переменной среды, если production то false, если development то true.
• Включить домен с которого ведется разработка в белый список исключений.

Межсайтовая подделка запросов(CSRF) — так называется атака, которая делает несанкционированный запрос от пользователя инициированный с другого сайта.

Например: вы нажимаете кнопку на каком-либо сайте и он выполняет javascript код, который попытается выполнить запрос на сайт вашего банка.(подробнее)

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

Очистка кэша

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

Веб-приложение загружается быстрее чем в первый раз, поскольку браузер кэширует ресурсы, такие как favouritewebsite.com/static/script.js.

Что если вы хотите внести изменения в script.js? Вы меняете имя файла. Допустим, вы меняете script.js на script.js?v=2, на который ссылается index.html.

Закэшированный script.js становится неактуальным, поскольку к нему никогда не будет другого запроса (если сам index.html не будет закэширован! Запрос к index.html должен быть инвалидирован на бэкэнде).

Современные конвейерные сборки включают в себя очистку кэша для каждой сборки, поэтому большинство javascript файлов выглядят как script.4e885f13.js. Обычно это применяется только к css стилям и скриптам, но вы также можете применить их к изображениям и другим ресурсам.

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

*Примечание переводчика:

В оригинале было так:

Map your server domains to some hostname in your dev environment’s host config.

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

Чем отличается верстальщик от front-end developer? — Хабр Q&A

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется «толстый клиент»), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

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

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

————

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front…

FrontFest.Kvartirniki — говорим о будущем JavaScript и судьбе фронтенд-разработчика

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

Каждый квартирник проходит на определенную тему, которую задают и разгоняют наши эксперты. Первый квартирник — о будущем JavaScript глазами Владимира Дашукевича и Евгения Гусева. На втором обсуждаем с Владиславом Козулей профессию фронтендера с разных сторон. И на финал рефлексируем на тему происходящего в мире фронтенд-разработки с Никитой Прокоповым и Виктором Грищенко. Квартирники переходят в виски-энд, где дискуссии идут еще в более неформальной плоскости.

Рассказываем в статье, почему эти темы важнее других и чем хороши эксперты.

§ Кто такой фронтенд-разработчик

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

Не все придерживаются такого мнения.

Разберемся в этом вместе с Владиславом Козулей — фронтендером, дизайнером, мемологом, ведущим слегка смешного твиттера.

На квартирнике «Почему никто не воспринимает фронтендеров всерьёз» посмотрим на фронтендера с разных сторон:

• С точки зрения бекендера — фронтендер не умеет программировать и не видит общей картины.
• С точки зрения бизнеса — всем всё равно, интерфейс не нужен.
• С точки зрения фронтендера — кругом плохой код! Инструменты не работают!

А вот видео-приглашение от Владислава

§ Будущее JavaScript

Год за два — так развиваются веб-технологии:

• Каждый год JavaScript получает больше новых операторов и синтаксического сахара.
• Каждый месяц выходят версии браузеров, а с ними огромное количество новых API.
• Мы можем писать почти на любом языке программирования в браузере с кросс-компиляцией в WebAssembly код.

Помечтаем на квартирнике «Туманное будущее JavaScript или куда мы все идем» с экспертами: Владимиром Дашукевичем и Евгением Гусевым.

Владимир — фронтендер c 7-летним опытом, экспериментатор и страстный поклонник кофе, теории графов, типизированных языков программирования и философии Канта.

Евгений — фронтенд тимлид из компании Wrike. Занимается разработкой высоконагруженного SAAS приложения на Dart (он живой!) и Angular 2.0

Обсудим будущее профессии фронтенд-разработчика. На что повлияет WebAssembly в браузере, какую работу можно будет отдать C/С++ программистам. Обсудим возможность запуска кода Java или C# в браузере. Поговорим о параллельно исполняющемся JavaScript коде и атомарных операциях в нем. Погрузимся в типизацию на примере TypeScript, Flow, PureScript, Reason и обсудим последние предложения по типизации самого JavaScript.

§ Немножечко рефлексии

Подслушали в Твиттере

Никита Прокопов

— Очень хочется конференции, где люди тупо рефлексируют о том, что в программировании происходит, а не докладывают радостно о достижениях НТП научно-технического прогресса.

Андрей Ситник

— Мы пробовали рефлексировать в JS и это ни к чему не привело. Рефлексия быстро скатывается к нытью. Нужно искать причины и их исправлять. А рассуждения «у всех проблемы с вебпаком» как раз блокируют исправления — формирует выученную беспомощность.

Никита Прокопов

— Не. Отсутствие рефлексии приводит к тому, что люди просто делают фигню и не задумываются, почему и зачем.

Владимир Грищенко

— Может на квартирнике FrontFest раздуть тему?

А давайте раздуем, подумали мы и вот результат — квартирник «Тренды и фронтенды»

Кто все эти люди?

Никита Прокопов, Cognician. Пишет бэкенды, фронтенды и распределенные системы на Clojure, ведет блог о программировании и человеко-компьютерном взаимодействии, рисует шрифт Fira Code. Автор DataScript, Rum, AnyBar.

Виктор Грищенко, Врачи без границ. Сеньор-помидор. Распределённые системы, синхронизация данных. ЦБ РФ, Яндекс, TU Delft, своя компания, realm.io

На квартирнике Никита, Виктор и участники слегка порефлексируют о распределенных системах, синхронизации данных, архитектуре приложений, и бегстве из JS.

Тизер:

• Всё плохо. Нормального инструмента синхронизации нет. Либо плохие и приготовить нормально нельзя, либо плохие и приготовить нормально очень сложно.
• Никто даже не понимает, как всё плохо с синхронизацией. Никто не бьет тревогу. Просто берут и пользуются. А там дыры! Конфликты! Оно чуть ли не разваливается.
• Почему ни у кого ничего не получилось до сих пор? Разъясните, почему все дураки. Надо ли оно вообще? Можно ли вообще?
• Почему Dahl и Holowaychuk убежали в Go?
• Почему Прокопов пишет на Clojure?
• Где Попп и что такое OCaml?
• Кто сказал «Reason»?
• Что? Typescript?

FrontFest прекрасен не только аутентичными квартирниками, но и программой, например: JAVASCRIPT, VYORSTKA, MIX, два кинота и поток воркшопов. И это точно.

Регистрируйтесь, осталось 16 дней.

Frontend-дизайн / Блог компании OTUS. Онлайн-образование / Хабр

Всем привет!

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

Поехали.

Где-то между дизайном — миром персон, пикселей и полировки — и инжинирингом — миром логики, циклов и линукса — лежит frontend-дизайн. Frontend-дизайн включает в себя работу с HTML, CSS и презентационным кодом JavaScript для создания пользовательского интерфейса.

Frontend-дизайнеры (которые также могут называться UI-разработчиками, client-side разработчиками, дизайн-инженерами, frontend-архитекторами, дизайнерами/разработчиками, прототипистами, единорогами или Бо Джексонами) живут в своего рода чистилище между мирами:

• Они понимают принципы и лучшие практики UX, но не тратят время на проведение исследований, создание флоу и планирование сценариев;
• Они обладают эстетическим вкусом, но не тратят время на поиски комбинаций шрифтов, сравнение цветовых палитр, создание иллюстраций и иконок;
• Они пишут на JavaScript, но не тратят время на написание кода прикладного уровня, подключение middleware и отладку;
• Они понимают важность backend-разработки, но не тратят время на написание backend-логики, запуск серверов, нагрузочное тестирование и тд.

Конечно, у всех по-разному. Некоторые занимаются frontend-дизайном в дополнении к своей основной должности. Официально они могут считаться разработчиками (что делает их “full-stuck разработчиками”, как сейчас принято говорить), а могут быть и дизайнерами (что делаем их “full-stuck дизайнерами”, наверное?). Иногда, особенно когда компании начинают разрастаться, frontend-дизайном занимаются люди, которые неловко застряли в том или ином департаменте.

Про свой собственный опыт я рассказываю в книге:

Когда прошлый работодатель узнал, что я пишу на HTML, CSS и презентационном JavaScript, меня пересадили поближе к инженерам и back-end разработчикам. Прошло совсем немного времени, как меня начали спрашивать: “Эй, Брэд, как долго будет собираться связующее ПО?”, и: “Можешь нормализовать эту базу данных по-быстрому?”

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

Существует глобальное заблуждение, что кодинг — ультра-гиковское программирование, но это не так. HTML — не язык программирования. CSS — не язык программирования. Но, так как и HTML, и CSS, чисто технически, являются кодом, frontend-разработку часто кладут в корзину к Python, Java, PHP, Ruby, C++ и другим языкам программирования. И это недопонимание ведет к кризису идентичности многих frontend-разработчиков, меня в том числе.

Такое отношение к frontend UI-коду и “настоящему программированию” влияет на организационную структуру:

В организационном плане, часто бывает большой разрыв между дизайнерами и разработчиками (или “маркетингом” и “IT”, или “креативом” и “инжинирингом”, или какими-то иными разделяющими ярлыками). Дизайнеры и разработчики часто сидят на разных этажах, или вообще в разных зданиях, в разных городах, на разных континентах. Частично это можно оправдать, но такое четкое разделение дизайнеров и frontend-разработчиков абсолютно ужасная идея.

Суть в том, что HTML, CSS и презентационный JavaScript служат для создания пользовательских интерфейсов, тех же самых, что дизайнеры создают с помощью инструментов вроде Photoshop или Sketch. Для того, чтобы команда могла успешно создавать системы пользовательских интерфейсов, очень важно считать frontend-разработку важной частью дизайн-процесса.

Поэтому меня вдохновляют истории компаний (например, Optimizely), которые смогли организовать структуру своих команд таким образом, чтобы frontend-работа считалась частью дизайн-процесса. Джонатан Снук (Jonathan Snook) поделился блестящими идеями по этой теме, основываясь на своем опыте в Shopify. Я с радостью смотрю на распространение этой идеи, и призываю организации считать frontend-дизайн ключевой частью дизайн-процесса.

Я считаю, что люди, обладающие опытом в frontend-дизайне, находятся в отличном положении, чтобы помочь преодолеть барьер между мирами дизайна и разработки. Они — связующий элемент, который скрепляет кирпичики. Жизнь в чистилище между мирами звучит не очень привлекательно, но так не должно продолжаться! Примите неопределенность, вдохновляйте frontend-разработчиков существовать между мирами, да здравствует сотрудничество и отличная работа!

THE END

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

Log in или Log on? Front-end или Frontend? Продолжаем разбираться / Хабр

В прошлый раз мы говорили о разнице между login и log in. В продолжение темы — ещё несколько нюансов, о которых вы просили рассказать в комментариях.

Log in и Log on

Log in и Log on — это синонимы. Log in употребляется чаще (иначе бы мы не логинились, а логонились):

В Microsoft традиционно пишут Log on, а в Apple и UNIX — Log in. Всё зависит от руководства по стилю (стайл гайда).

Совет. Пишите Log in, если это не противоречит руководству по стилю.

Источник: techterms.com, dictionary.cambridge.org

Front-end, front end и frontend

• Front-end — прилагательное;
• front end — существительное.

Примеры:

• Я работаю front-end разработчиком.
• Front end — это абстракция, которая предоставляет пользовательский интерфейс.

Что же касается слитного написания, то здесь такая же ситуация, что и со словами email и plugin. Язык меняется и некоторые слова, которые раньше писались через дефис, сегодня всё чаще сливаются воедино.

Аналогично — back-end, back end и backend.

Совет. Если сомневаетесь, пишите слитно. Это не будет серьезной ошибкой.

Источники: english.stakexchange.com, dzone.com

Sign in и Sign up

• Sign in — авторизация существующего пользователя;
• Sign up — регистрация нового пользователя.

Совет. Эти две конструкции часто путают друг с другом, слишком уж они похожи. Чтобы исправить ситуацию, замените sign up на что-нибудь другое:

• register;
• join;
• create account;
• get started.

Источник: uxmovement.com

«Наверх» и «на верх»

• Наверх — направление;
• На верх — указание на верхнюю часть чего-либо.

Примеры:

• Поднимись наверх, я буду ждать тебя там.
• Лезь на верх вон той горы!

Совет. Попробуйте вместо слова «наверх» написать «на самый верх». Если смысл не изменился, то пишите «на верх».

• Поднимись на самый верх, я буду ждать тебя там — было абстрактное направление на верхний этаж, а стало указание подняться на крышу.
• Лезь на самый верх вон той горы! — как была вершина горы, так и осталась.

Название кнопки «Наверх» пишется слитно, если нет уточнений вроде «на верх страницы».

Источник: gramota.ru

А какие трудности возникают у вас?

Backend vs Frontend Web Development — Изучение обеих сторон

Автор Cody Arsenault

Опубликовано 23 февраля 2017 г.

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

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

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

Что нужно знать разработчикам интерфейсов?

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

В результате Facebook стал одним из наиболее посещаемых веб-сайтов в Интернете, а MySpace ушел в безвестность. Независимо от того, насколько плавно работает веб-сайт или сколько ценного контента он может предложить, пользовательский опыт играет важную роль в определении успеха веб-сайта.

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

HTML

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

CSS

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

К счастью, прекомпиляторы CSS, такие как Sass и Less, могут значительно упростить процесс написания кода для веб-разработчиков.

JavaScript

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

Хотя последнее обновление HTML, HTML5, поддерживает некоторые из этих функций, начинающие разработчики окажут себе медвежью услугу, упустив из виду JavaScript. Такие фреймворки, как Backbone, React, Angular и Ember, позволяют ускорить разработку JavaScript. Если во время исследования JavaScript вы также столкнулись с Java, просто обратите внимание, что эти два языка не связаны друг с другом. Узнайте больше о разнице между Java и JavaScript.

Адаптивный дизайн

Согласно исследованию, проведенному компанией Similar Web в 2015 году, 56% трафика , ведущего на ведущие веб-сайты США, поступает с мобильных устройств, таких как смартфоны и планшеты, а не с традиционных настольных компьютеров.Эта тенденция создала проблемы для разработчиков, которые так стараются, чтобы все посетители имели одинаковый опыт при посещении их веб-сайтов, поэтому адаптивный дизайн или оптимизация веб-сайтов для адаптации к разным размерам экрана важны как никогда.

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

Воспринимаемая производительность

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

Что нужно знать backend-разработчикам?

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

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

Хотя внутренняя разработка — это очень техническая область, она все же требует степени творческих способностей и человеческого взгляда .Frontend-разработчики полагаются на своих бэкэнд-коллег в создании кода, который легко понять и манипулировать, поэтому бэкэнд-специалисты должны ознакомиться со стандартизованными стилевыми рекомендациями и идиомами, которые существуют для таких языков программирования, как PHP, Ruby, Python и т. Д.

Начинающие бэкэнд-разработчики следует сосредоточиться на отработке следующих навыков:

Язык программирования

Источник: Appflower

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

• PHP — чрезвычайно популярный язык программирования, который подходит как для начинающих, так и для опытных программистов. Первоначально он был создан в 1994 году и с тех пор значительно вырос, поэтому существует очень большого сообщества разработчиков .Кроме того, многие популярные фреймворки и системы управления контентом основаны на PHP, включая WordPress, Drupal, CakePHP и т. Д.
• Ruby легко читать и понимать людям, не имеющим предварительного знания языка. Ruby полезен для кодирования бизнес-логики, расчета данных и распределения серверов для обеспечения оптимальной производительности. Ruby on Rails, фреймворк для создания веб-приложений, особенно популярен среди малых предприятий и стартапов, и некоторые крупные компании, включая Twitter и Hulu, все еще используют его сегодня.
• Python также имеет репутацию простого читателя для некодеров. Django, популярный фреймворк для разработки веб-приложений, является эквивалентом Python для Ruby on Rails. Reddit и Dropbox — это примеры крупных веб-сайтов, построенных на Python.

Backend-разработчики также могут извлечь большую пользу из изучения других языков, таких как C #, Java, C ++ и т. Д.

Базы данных

Поскольку универсальный язык запросов к базам данных, SQL или язык структурированных запросов, необходим для каждого веб-приложения, которое необходимо хранить информацию .Независимо от того, используете ли вы Django, Ruby on Rails, WordPress или любую другую структуру для создания своего веб-сайта, вы также должны использовать SQL для взаимодействия с базами данных, которые являются частью каждого серверного приложения. Несколько популярных вариантов баз данных включают Postgres, MySQL и MongoDB.

API

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

Веб-службы

Большинство веб-страниц и приложений сегодня интегрированы с другими системами, включая платежные системы и социальные сети. Веб-службы позволяют легко взаимодействовать между интерфейсными и серверными технологиями. Две веб-службы, с которыми должны быть знакомы все серверные разработчики, — это SOAP, или протокол простого доступа к объектам, и REST, или передача репрезентативного состояния.

Что должны знать разработчики внешнего и внутреннего интерфейса?

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

Системы контроля версий (VCS)

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

Источник: GitHub

На схеме выше показан базовый рабочий процесс GitHub (системная служба контроля версий).Еще один надежный провайдер VCS, который вы можете использовать, — Bitbucket.

Тестирование и отладка

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

Разработка полного стека

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

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

Backend vs frontend — выбор стороны

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

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

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

.

Я не говорю на вашем языке: интерфейс и серверная часть

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

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

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

Бесплатная пробная версия Treehouse: Хотите узнать больше о серверной и интерфейсной веб-разработке? Подпишитесь на бесплатную пробную версию Treehouse.

Различия между дизайном и разработкой на самом деле приводят к большему количеству дискуссий вокруг веб-интерфейса и внутреннего интерфейса. Что такое бэкэнд? А что такое фронтенд? Начнем с внешнего интерфейса…

Что такое интерфейс?

Когда мы обсуждаем «интерфейс» сети, на самом деле мы говорим о той части сети, которую вы можете видеть и с которой вы можете взаимодействовать. Интерфейс обычно состоит из двух частей: веб-дизайна и интерфейсной веб-разработки.

Раньше, когда кто-то обсуждал разработку, это обычно относилось к бэкэнду, но в последние годы возникла реальная необходимость различать дизайнеров, которые работали строго в Photoshop, и тех, кто мог кодировать HTML и CSS.Дело пошло еще дальше, когда дизайнеры перешли границы и начали работать с JavaScript и jQuery.

Итак, теперь, когда мы обсуждаем термин «веб-дизайн», мы действительно говорим о тех, которые работают с Photoshop и Fireworks, и тех, которые кодируют с использованием HTML, CSS, JavaScript или jQuery (здесь может быть важно указать, что jQuery — это скомпилированная библиотека Javascript).

Все, что вы видите при использовании Интернета, представляет собой комбинацию HTML, CSS и JavaScript, которые контролируются браузером вашего компьютера.К ним относятся шрифты, раскрывающиеся меню, кнопки, переходы, ползунки, контактные формы и т. Д.

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

Что такое бэкэнд?

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

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

Мы вызываем человека, который создает всю эту технологию, для совместной работы backend-разработчика .Бэкэнд-технологии обычно состоят из таких языков, как PHP, Ruby, Python и т. Д. Чтобы сделать их еще проще в использовании, они обычно расширяются такими фреймворками, как Ruby on Rails, Cake PHP и Code Igniter, которые делают разработку быстрее и упрощают совместную работу. .

Многие веб-профессионалы, которые только начинают работать в этой области, возможно, слышали, как многие люди говорят о WordPress. WordPress является хорошим примером совместной работы внешнего интерфейса и внутреннего интерфейса, поскольку WordPress — это платформа с открытым исходным кодом, построенная на PHP, которую вам необходимо установить на свой сервер с базой данных.Затем дизайнеры настраивают внешний вид и функциональность сайтов WordPress с помощью CSS, jQuery и JavaScript.

Заключение

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

Границы между дизайном и разработкой кажутся с каждым днем ​​все более и более размытыми, но в основном они все еще очень разные.

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

Что вы думаете о дизайне и разработке, а также о интерфейсе по сравнению с серверной частью? Пожалуйста, присоединяйтесь к беседе, оставив комментарий ниже. Ура!

Разработчиком может быть любой.

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

.

Как интерфейс взаимодействует с серверной частью? · Vsupalov.com

Как связать фронтенд и бэкэнд?

Как они общаются?

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

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

Начнем с основ.

Почему вообще существуют фронтенд и бэкэнд?

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

• Пользователь указывает в своем браузере на один из URL вашего веб-сайта
  • Это заставляет браузер отправлять один или несколько запросов на ваш сервер.
  • Браузер ожидает ответа от вашего сервера
  • Каждый ответ используется для рендеринга части сайта
• Пользователь ждет, пока браузер отобразит страницу
• Пользователь видит полезную и полезную страницу
• Пользователь взаимодействует со страницей
  • Вызывает отправку большего количества запросов, получение дополнительных данных и отображение новой информации и т. Д.

Все дело в пользователе.

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

Прежде чем погрузиться глубже, мы должны убедиться, что мы говорим о
те же вещи.

Определения

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

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

Backend — часть вашего веб-приложения, которая не видна пользователю напрямую. Он принимает запросы и
подготавливает данные, которые передаются обратно в браузер пользователя. Бэкэнд-код создан для работы на сервере и никогда не запускается на компьютере пользователя.

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

Браузер — приложение, работающее на устройстве пользователя. Он отправляет HTTP-запросы, получает ответы,
обрабатывает полученные данные и использует их для отображения страницы, доступной для просмотра.Все сообщения со стороны пользователя проходят через его браузер.

Когда браузер взаимодействует с серверной частью?

HTTP-запросов поступают от браузера на серверной части.
Эти запросы могут содержать данные в заголовках HTTP или теле запроса.
Целью может быть запрос новых данных или передача данных, созданных пользователем, на серверную часть.

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

Что должно произойти, чтобы браузер отправил запрос?
Те запросы, которые запускаются, потому что пользователь щелкнул ссылку или запущен JS-код.
на заднем фоне. Но есть еще триггеры:

• Пользователь вводит URL-адрес, который заставляет браузер переходить и запрашивать его.
• Браузер считывает входящий HTML-код и замечает, что есть ресурс, который необходимо загрузить, например файл JS, изображение или файл CSS.Он идет вперед и запрашивает каждый с одним новым HTTP-запросом. Обычно это происходит при загрузке сайта. (Эти запросы не обязательно должны поступать в один и тот же сервер, вы можете загрузить JS с другого сайта. Людям нравится использовать для этого CDN, поскольку это довольно быстро и удобно.)
• Пользователь нажимает на обычную ссылку, веб-страница загружается и отображается. Браузер знает, что им нужно перейти на новую страницу, и запрашивает соответствующий URL.
• JavaScript выполняется на сайте и хочет, чтобы некоторые данные загружались в фоновом режиме.Запросы поступают, но браузер делает это в фоновом режиме. Это не перезагружает всю страницу. Это AJAX. Javascript может запускаться при нажатии пользователем чего-либо, и он может сообщить браузеру, что этот щелчок не был предназначен для перехода на новую страницу. Это может сбивать с толку.

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

Что они посылают друг другу?

Этот может отличаться! Но есть один очень популярный способ, который используется чаще всего.Это хороший способ сделать что-то для 99% всех сценариев взаимодействия интерфейс-серверная часть.

Магия заключается в полезной нагрузке HTTP-запроса / ответа.
Серверная часть обычно отвечает определенным содержимым тела HTTP:

• HTML-ответы
• другие статические файлы (CSS, JS, изображения,…)
• Данные в формате JSON
• Никакого тела. Просто код состояния и поля заголовка.

Интерфейс отправляет:

• Простые HTTP-запросы без тела
• Данные формы
• Данные в формате JSON

Давайте посмотрим на примеры

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

Я надеюсь, что эти примеры помогут вам увидеть, как все вписывается.
И понять, как взаимодействуют серверная часть и фронтенд.

Сценарий: только статическое содержимое

Если браузер запрашивает что-то вроде http://example.com/style.css , это обычно обрабатывается веб-сервером (например, Nginx) бэкэнда.Запрос является GET для этого
ресурс, и серверная часть отвечает ответом, содержащим содержимое файла.

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

Vanilla Django с использованием шаблонов Django

Следующий случай касается запроса динамического содержимого .Со стороны браузера
это выглядит так же, как запрос статического контента — есть запрос
который запускается по URL-адресу типа http://example.com/cute-puppies .
Браузеру не важно, какая часть серверной части будет обрабатывать запрос, он просто хочет получить ответы. (СЕЙЧАС.)

Запросы поступают на сервер, передаются на веб-сервер (например, Nginx),
и веб-сервер передает запрос серверу приложений (Django обрабатывается Gunicorn). Веб-сервер просто делает то, для чего он настроен.Здесь нет ничего волшебного.

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

Подробнее: Ваше приложение Django реагирует на запрос. Запрошенный URL интерпретируется с использованием ваших конфигураций urls.py. Для обработки запроса выбрано правильное представление. Код представления может использовать модель для получения данных из базы данных и визуализировать шаблон, передавая ему данные в объекте контекста. Фух.
Вот что такое «классический» проект Django.Вы получаете это из коробки, и это очень хороший способ начать практически любой веб-проект.

Полученный HTML-код упаковывается в ответ.
Ответ содержит HTML-страницу внутри тела HTTP.

Браузер получает ответ и отображает DOM из HTML.
Оттуда браузер, вероятно, сделает больше запросов для загрузки этих
изображения щенка и немного CSS, чтобы он мог стилизовать страницу. Эти ресурсы статичны и должны обрабатываться так же, как в первом примере.

Добавлен интерактивность с помощью jQuery, Vue.js или vanilla JS

Теперь все становится немного сложнее: JavaScript входит в картинку во внешнем интерфейсе.

Представьте, что динамическая страница загружается из серверной части, как описано в предыдущем примере. Возвращенный HTML-код содержит
Код JS внутри тега script .

Браузер отобразит страницу и начнет выполнение JS-кода.

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

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

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

Интегрированный фреймворк: Vue.js, например

Теперь мы переходим на территорию JS framework.
Этот случай такой же, как и выше, но шаблон, возвращаемый серверной частью, не обязательно является полным. В исходном HTML-ответе отсутствуют фрагменты последней страницы.

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

Эффект состоит в том, что конечный HTML-код, который отображается пользователю, не тот
который покидает сервер.

Браузер выполняет JS-код по прибытии страницы, который, в свою очередь, создает остальную часть страницы.
Вы можете сделать это с помощью Vue.js — подробнее здесь.

Одностраничное приложение (SPA) — данные извлекаются позже

При архитектуре одностраничного приложения статическая страница
загружен с кучей JS в нем.Ваш бэкэнд-код не
используется для этого первоначального запроса. В этом нет ничего динамичного
в конце концов — это просто загрузка очень простого HTML и получение JS в
начало.

Веб-сервер предоставляет их.
Django обычно участвует в обслуживании статических ресурсов в этом случае — веб-сервер или другой сервис, такой как AWS S3, заботится о них.

Как только HTML и JS поступают в браузер, JS выполняется и запускается.
делать запросы к серверу для DATA .Это то, что предоставляет внутренний код — обычно в форме ответов JSON.

Код JavaScript внутри статической страницы заботится о загрузке данных из вашего бэкэнда, и DOM строится динамически на основе этих данных, начиная с
с пустой страницей. Элементы DOM, которые динамически собираются JS, показаны пользователю. Ваш внутренний код не знает, как выглядит эта страница,
и наплевать. Он заботится только об ответах на запросы данных с помощью ответов JSON.

Рендеринг на стороне сервера

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

Как оказалось, это то, что не нравится поисковым системам.
Они думают, что эти изначально пустые страницы скучны, и это вызывает
им меньше думать о вашем сайте.

Они бы предпочли красивый, полный сайт.

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

По сути, это часть
бэкэнд, который на время притворяется браузером! Это делает
запрашивает ваш бэкэнд-код и создает HTML
site, выполнив JS-часть кода внешнего интерфейса.

Когда это будет сделано,
браузер получает ответ HTML, который был
производится с помощью кода JS. Сервер Django
используется для предоставления данных JSON для этого шага отрисовки.

«Зачем столько хлопот?» вы можете спросить.
Что ж, это то, что вам нужно сделать, если вы хотите иметь архитектуру SPA,
но все равно дружите с поисковиками.

В основном, SSR используется для SEO.
Он используется для устранения проблем
которые вызваны в первую очередь доставкой пустых (или просто неполных) HTML-ответов, которые еще не были собраны с помощью JS.Могут быть положительные стороны производительности и кеширования, но обычно они не имеют большого значения.

Заключение

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

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

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

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

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

Если у вас есть предложения, комментарии или вопросы — напишите мне на почту @ vsupalov.com. Всегда рад тебя слышать 🙂

.