Front end back end: Фронтенд и бэкенд: о самом главном

Фронтенд и бэкенд: о самом главном

Frontend и backend: об иерархии разработки веб-приложения, точках соприкосновения, сходствах и различиях двух столпов веба, а также сферах их ответственности.

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

Сложная и многоуровневая структура современных веб-приложений требует иерархического разделения процесса их разработки. Исторически этот процесс разделяется на две части: front-end (клиентская) и back-end (серверная). Взглянем поближе на каждую из них, поговорим об их различиях, точках соприкосновения и зонах ответственности

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

Задачей фронтенд-разработчика является сделать все возможное, дабы предупредить подобное развитие событий. Сфера его ответственности охватывает создание пользовательского интерфейса, что в свою очередь подразумевает некоторую иерархию. Это дизайн макета, верстка, адаптация. Важной частью разработки веб-приложения является UI/UX дизайн — то, что в наибольшей степени влияет на первое впечатление пользователя.

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

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

Библиотека jQuery позволяет легко реализовывать эффективное взаимодействие JavaScript и HTML. Язык TypeScript, компилируемый в js-код, дает возможность использования классов, модулей, шаблонов, являясь, таким образом, полноценным объектно-ориентированным языком. Программная платформа Node.js превращает JavaScript из узкоспециализированного языка в язык общего назначения, «выпуская» его из браузерной песочницы. На клиентской стороне реализуется отправка запросов и обработка ответов сервера, парсинг данных, динамическое изменение отображаемого контента.

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

Помимо серверной логики в сферу ответственности бэкендера входит отладка и прототипирование с использованием клиентской части приложения. Это влечет за собой необходимость понимания работы стека протоколов TCP/IP, HTTP, REST/SOAP, принципов взаимодействия браузера с веб-приложением.

Несмотря на то, что сфера фронтенда традиционно считается самой богатой и разнообразной в плане технологий, бэкенд также имеет широкий спектр инструментов разработки. Помимо каноничного PHP, несправедливо многими поругаемого, прочные ниши заняли Python с фреймворком Django, Java и Node.js, Ruby, а также набирающий популярность Go.

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

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

Фронтенд и бэкенд — вовсе не взаимоисключающие параграфы. Для тех, кто одинаково свободно чувствует себя на обоих поприщах, существует такое понятие, как full stack. “Фулл стэк” -разработчик занимается и клиентской, и серверной частями приложения. Освоение такой профессии — непростое дело. На этому тернистом пути путеводной звездой может послужить онлайн-программа по веб-разработке от Нетологии. В ней в оптимальной пропорции совмещаются теория и практика. В процессе обучения вы освоите два языка программирования, пополните свое портфолио пятью проектами, прокачаете коммуникационные навыки и работу с системой контроля версий git.

И напоследок приятный бонус для наших читателей — промокод proglib со скидкой 7000Р.

Старт программы — 21.07.

Успейте подать заявку

Простыми словами: бэкенд, фронтенд и их взаимодействие

Веб-разработчик и путь его развития в 2018 году

Front-end и Back-end разработка — отличия и проф.стандарты

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

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

Особенности Front-end и Back-end разработки

Front-end разработка – это клиентская составляющая процесса создания веб-ресурсов, предусматривающая формирование макета сайта, шаблонов, интерфейса и скриптов, которые отвечают за визуализацию. На этом этапе разработки также выполняется CSS-верстка.

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

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

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

Front-end vs. Back-end разработка

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

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

Front-end разработчики в основном используют 3 языка – CSS, HTML и Javascript. А вот бек-энд разработчики в своей деятельности используют Python, Ruby,.NET, Postgre SQL, MySQL и MongoDB.

Среда разработки

Фронтенд разработка предусматривает применение внешнего интерфейса для разработки дизайна. В обязанности Front-end разработчиков входит не только изменения дизайна, но и изучение поведения пользователей.

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

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

Цели

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

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

Теги:

Разница между Front end, Back end, Full stack разработчиками

Опытного IT рекрутера точно нельзя испугать модными словечками или техническими выражениями, а вот начинающему стоит разобраться во всех тонкостях IT сферы. Узнайте, чем занимаются «front end», «back end», «full stack» разработчики, чтобы быть уверенными в том, что вы с твердыми знаниями подходите к выполняемой роли специалиста. Какие-то различия — существенные, какие-то несут в себе большое количество тонкостей, но все они позволят вам понять текущие потребности IT-индустрии.

На сегодняшний день создается все больше и больше различных веб-инструментов, программ и сервисов. Спрос на разработчиков растет с каждым днем с такой же прогрессией. В связи с этим выросла потребность в IT рекрутерах.
Сегодня мы поможем вам понять, кто такие «front end», «back end», «full stack» разработчики.

Front End разработчик

Когда вы видите наполненный жизнью сайт с привлекательным интерфейсом, вам становится интересно, кто же этот волшебник, который так профессионально с ним поработал. Именно в эту минуту вы думаете о front end разработчике, даже об этом не зная. Любое визуальное отображение, с которым вы работаете, производится потом, кровью и слезами front end разработчика. GUI или «Графический пользовательский интерфейс» — это визуальный фронт, на котором отображается экран, позволяющий клиентам взаимодействовать с программным обеспечением. Любое из сегодняшних устройств с прилагательным «умный», будет иметь интерфейс, который запускает приложения, предоставляет доступ к веб-сайтам, и все это создается разработчиком front end.

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

Дизайнер UX ссылается на конструктор «User Experience», в котором описывается путь, который пользователь использует, и его общая эффективность. Front end разработчики также должны думать над общим удобством использования, полезностью и опытом, которые пользователь имеет при взаимодействии с программным обеспечением и этот конкретный сегмент требует, безусловно, самых «гибких навыков» программиста. Тем не менее, эта работа может выполняться также не программистами.

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

Традиционно разработчиком front end является человек, которому удобно работать как с дизайном, так и с кодированием. Другими словами, тот, кому комфортно работать с использованием простых инструментов проектирования и умеет писать структуру веб-сайта в HTML и стилизовать его с помощью CSS-кода. На данный момент самой большой проблей для front end разработчиков является то, что веб-сайт, построенный только с использованием HTML и CSS, будет полностью статическим. Если вы думаете о stickman на пустой странице в качестве веб-сайта. HTML будет достаточно, чтобы нарисовать его форму и CSS будет использоваться для его стилизации (сгустить, покрасить его, добавить одежду и т.д.). Но чтобы заставить stickman двигаться и реагировать, front end разработчику как следствие потребуется что-то еще.

По мере усложнения и совершенствования веб-приложений спрос на полный язык программирования Turing в интерфейсе растет с большой скоростью, поэтому для анимации программистов — stickman используют Java Script, который является языком программирования на стороне браузера.

Back End разработчик

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

Весь процесс прочно закреплен в логике, сети процессов и запросов, разрешаемых за считанные секунды, чтобы дать вам, как пользователю, определенный желаемый результат. Выберите рейс из Нью-Йорка в Гонконг и вы находитесь в зоне front end, нажмите клавишу поиска и вы перемещается в back end, чтобы правильно вернуть вам лучший, самый короткий, самый дешевый рейс в мгновение ока. Как только результаты будут отображаться для вас, вы снова будете во front end. Если поисковый запрос выдал вам своевременный и полезный результат, и вы не представляете, благодаря чему это произошло, спасибо разработчику за завершение поиска, а также бесчисленное множество других вещей, упрощающих вашу жизнь.

У back end разработчика может быть множество обязанностей. От создания базы данных и интеграции до обеспечения безопасности, а также технологий резервного копирования и восстановления, также back end разработчики создают мозг приложения.

Back end разработчики используют различные технологии для кодирования основной вычислительной логики информационных систем, конкретного программного обеспечения или веб-сайтов. Они могут включать Java, C#, Python и языки баз данных, такие как SQL и многие другие. Back end отличаются от разработчиков front end тем, что работа back end разработчика полностью лишена какого-либо визуального дизайна и основывается на логике и архитектуре программного обеспечения, целью которой является предоставление определенного результата. Иногда возникают проблемы с объединением back end и front end, что приводит нас к человеку, который может обработать обе части.

Разработчик Full Stack.

Разработчик full stack — это тот, кто хорошо работает как с бэкэнд, так и с фронтэнд. «Чтобы быть более конкретным, это означает, что разработчик может работать с базами данных, PHP, HTML, CSS, JavaScript и всем, что находится между ними, также принимая во внимание преобразование проектов Photoshop в интерфейсный код», — говорит Sitepoint.

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

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

Backend для Frontend-разработчика и наоборот: осваиваем новое

Фронтендеру не помешает знать, как работает Backend, и наоборот. Сразу определитесь, чего хотите: полного перехода или простого знакомства?

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

Мы не будем говорить о полном переходе на Frontend или Backend: просто дадим несколько дельных советов, которые поспособствуют всестороннему развитию.

Начнем с определения самого понятия «Backend». Это программно-аппаратная часть сервиса, все процессы, происходящие непосредственно на сервере, в том числе работа с базами данных. В контексте клиент-серверного ПО это сервер, клиент – Frontend, а между ними HTTP – система запросов от браузера и ответов сервера HTML-страницей.

Иными словами, уровня всего три: интерфейс, средний уровень (точки соприкосновения) и сервер.

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

• Изучите разработку API.
• Особое внимание стоит уделить REST и, возможно, GraphQL.
• Поймите разницу между ошибками 422 и 401, а также GET/POST/PATCH/PUT, etc.

Если же этого недостаточно, и вы действительно заинтересованы в бекенде, то:

• Изучите аппаратные ограничения.
• Освойте Linux.
• Узнайте о шинах сообщений (message bus), очередности и межпроцессных коммуникациях.
• Узнайте об обнаружении сервисов (service discovery) и различиях между Eventually Consistent и Strongly Consistent.
• Изучите информацию о контейнеризации.
• Поймите, как работает система.
• Изучите алгоритмы, включая графовые алгоритмы и определение алгоритмической сложности.

Полезно в обоих случаях:

• Освойте SQL.
• Познакомьтесь с несколькими СУБД, такими как NoSQL, MongoDB, Elastic Search, Redis и т. д.
• Узнайте о безопасности.

Не беспокойтесь о конкретных языках: данные концепции подходят для любого.

Пришло время взяться за изучение трех столпов фронтенда:

1. HTML
2. CSS
3. JavaScript

Это главное. Существуют различные библиотеки и фреймворки, которые также используются во Frontend-разработке. Среди них Bootstrap, jQuery, AngularJS и многие другие. Но в первое время даже не думайте о дополнительных инструментах. Все они основаны на HTML, CSS и JavaScript. Изучите основы, и у вас не будет проблем с переходом к библиотекам и фреймворкам.

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

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

Фронтенд, бэкенд и фулстек: что это такое простыми словами?

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

ПО ТЕМЕ: Основы программирования: 15 лучших бесплатных браузерных игр для обучения программированию.

Что такое «фронтенд» и «бэкенд»?

С фронтендом (front end) любой из нас сталкивается постоянно. Ведь это все то, что браузер может выводить на экран и запускать: сама страница, таблицы на ней, кнопки, стрелки, поля, баннеры и прочее.

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

Бэкенд (back end) – это «подводная часть айсберга», сторона, работающая не в браузере, а на удаленном сервере (серверная часть).

Фактически, это компьютер, который обрабатывает посланные ему запросы и посылает обратно некую информацию. Для этого используется какой-либо из универсальных языков программирования: Python, Ruby, Java, PHP, C#, Swift и т.д., а также системы управления базами данных MySQL, PostgreSQL и т.д. Спектр инструментов тут тоже довольно широк. Бэкенд-разработчик отвечает за производительность серверного кода, его масштабируемость, рациональность и безопасность. Для этого необходимо понимать сетевые протоколы и принципы взаимодействия браузера с веб-приложением.

ПО ТЕМЕ: Human Resource Machine для iPhone и iPad – увлекательный симулятор программирования.

Что такое фулстек?

Фронтенд и бэкенд вовсе не являются взаимоисключающими областями. Разработчики должны хотя бы в общих чертах представлять, что происходит на противоположной стороне. Но есть действительно уникальные специалисты, которые одинаково хорошо себя чувствуют в обоих направлениях: фулстеки (full-stack). Такие разработчики занимаются и клиентской частью приложения, и серверной.

Существует несколько вариантов взаимодействия бэкенда и фронтенда. Это могут быть серверные приложения, в которых HTTP-запросы идут напрямую на сервер, а тот отвечает HTML страницей. Возможна связь с использованием AJAX, в которой запрос генерируется внутри страницы Javascript, а в ответ приходит информация в формате XML или JSON. Клиентские или одностраничные приложения дают возможность с помощью AJAX загружать данные без обновления страницы с помощью специальных фреймворков.

Границы фронтенда и бэкенда статичными не являются. Оба направления постоянно развиваются и заимствуют черты друг друга. Так, появился автономный фронтенд, который позволяет хранит логику приложения и данные в самом клиенте. Легкий бэкенд направлен на сокращение числа обращений к данным за счет бессерверной архитектуры, новых технологий.

Смотрите также:

“Front-end” и “back-end” Разработка

Разработка сайтов по системе front-end и back-end подразумевает иерархическое разделение процесса создания ресурса на две части, на разработку пользовательского интерфеса –(фронтэнда) и его программно-административной части (бэкэнда).

Front-end разработка – это работа по созданию публичной части сайта, с которой непосредственно контактирует пользователь и функционала который обычно обыгрывается на клиентской стороне (в браузере).

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

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

При создании пользовательской стороны сайта и формировании html страницы мы учитываем следующие моменты:

• Грамотное использование тегов h2, h3 и т.д. в порядке очерёдности.
• Грамотное использование тега lang.
• Реальное заполнение атрибута alt для картинок. Если на картинке изображен логотип, то “Логотип компании”, если человек, то имя человеке. Для значков на английском языке “Twitter Icon” и т.д. (не относиться к динамическим изображениям, например, фото новости).
• Не забываем про метатеги.
• Не забываем про фавиконку (favicon).
• Там где предполагается ссылка, должна быть прописана ссылка.
• Для контактов использовать атрибуты skype, tel и mailto.
• Ссылки на внешние страницы должны открываться в новом окне.
• Каждая ссылка имеет атрибут title.
• Код хорошо прокомментирован.
• Оптимизация изображений для Интернета.
• Использование мобильных версий картинок, там где это необходимо.
• HTML, CSS и JS файлы должны иметь параллельно с основной (рабочей) и сжатую версию для последующего запуска сайта на хостинге.
• Все стили и скрипты вынесенны в отдельные файлы.
• Размеры всех картинок заданы средствами CSS.
• Использовать слайдеры, карусели и галереи адаптированны для мобильных устройств.
• Всплывающие окна адаптированны для мобильных устройств.
• Переименование файлов в случае использования кеширования.
• Подсветка (hover, active, visited) для ссылок.
• Подсветка (hover, active) для кнопок и полей в формах.
• Прижатый подвал при малом кол-ве контента на странице.
• Отсутствие outline у кнопок.

Back-end разработка

Бэкэнд development – это процесс программирования сайта и наполнения его функционалом. Создание ядра сайта, разработка платформы сайта, наполнение его основным функционалом и создание административной зоны – это и есть бэкэнд разработка.

Бэкэнд производит обработку пользовательской информации полученной из front-офиса, и возвращает front-end’у результат в понятной ему форме.

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

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

Front-End и Back-End разработчик: что такое…

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

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

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

Что такое Front-End разработка?

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

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

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

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

Что такое внутренняя разработка?

С другой стороны,

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

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

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

Разница между Front-End и Back-End разработкой

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

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

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

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

Front-end vs. Back-end: необходимые навыки

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

Навыки переднего плана

Основными языками интерфейса являются HTML, CSS и JavaScript.Чтобы начать обучение, зарегистрируйтесь на онлайн-курс Fullstack Academy «Введение в программирование».

• HTML: язык разметки, используемый для описания структуры и содержимого веб-страницы. Теги являются основной единицей HTML: они записываются в угловых скобках <> и предоставляют семантическую информацию о тексте, который они окружают. Одним из распространенных способов использования является обозначение заголовка и заголовков страницы. Сам HTML невидим для конечного пользователя, а его команды — нет.
• CSS: язык таблиц стилей, который работает вместе с HTML для описания дизайна и внешнего вида веб-страницы.Например, файл CSS может определять, что любой текст, окруженный тегом HTML , который используется для гиперссылок, будет зеленым и полужирным. Ни файл CSS, ни HTML, как уже упоминалось, не могут быть просмотрены пользователем; все, что они увидят, — это жирная зеленая ссылка.
• JavaScript: язык программирования, используемый для создания интерактивного и динамического контента на веб-страницах, и в центре внимания учебной программы Fullstack Academy. JavaScript может делать все: от отображения текущей даты и времени до проверки введенных пользователем данных формы и добавления анимации.Как и все языки программирования, JavaScript не виден конечному пользователю, но его влияние на объекты, с которыми он действует — формы, изображения и т. Д. — видны.

Наряду с этими тремя столпами интерфейсной разработки многие программисты будут использовать различные фреймворки и библиотеки, чтобы упростить написание и организацию своего внешнего кода. Эти надстройки к HTML, CSS и JavaScript призваны сделать разработку более быстрой и более структурированной.

Некоторые из самых популярных интерфейсных фреймворков и библиотек включают Bootstrap, jQuery, AngularJS и React (для JavaScript), а также Sass и LESS (для CSS).Разработчики интерфейсов также должны использовать дизайн, ориентированный на мобильные устройства, или адаптивный дизайн, чтобы веб-страницы хорошо отображались на разных устройствах.

Внутренние навыки

Дорожная карта для внутренней разработки немного менее ясна. Программное обеспечение, работающее на серверной части, может быть написано на сотнях различных языков программирования, поэтому внутренние разработчики обычно сужают круг вопросов до нескольких языков, которые лучше всего подходят для их нужд. JavaScript, хотя изначально был языком интерфейса, все чаще используется в серверной части благодаря популярной серверной структуре Node.js. Другие распространенные серверные языки включают Scala, Python, Ruby и Go.

Как и разработчики интерфейсов, внутренние разработчики также используют фреймворки и библиотеки для заботы о технических деталях низкого уровня, поэтому разработчики сами могут сосредоточиться на текущих задачах более высокого уровня. (Это похоже на использование функции «СУММ» в Excel для более быстрого выполнения бюджета отдела вместо того, чтобы складывать все самостоятельно.) Внутренние фреймворки и библиотеки включают Rails для языка программирования Ruby и Django для Python.

Почти каждый веб-сайт, который позволяет пользователям делать запросы, будет иметь базу данных на сервере. Помимо знания языков программирования, внутренние разработчики должны иметь некоторый опыт работы с такими технологиями баз данных, как Oracle, Microsoft SQL Server и MySQL. Эти знания используются для написания бизнес-логики или набора правил во внутреннем коде. Разработчики используют эти правила, чтобы диктовать, как создавать модели баз данных, как писать в базу данных и как запрашивать у нее соответствующую информацию.

Почему важно знать навыки работы с клиентской частью и серверной частью

Даже если в вашей карьере вам, вероятно, придется выбирать между внешним или внутренним интерфейсом, наличие обоих наборов навыков дает множество преимуществ. На начальном этапе как полной, так и частичной иммерсивной программы Fullstack студенты начинают осваивать HTML5, расширенный CSS и современные технологии, такие как React во внешнем интерфейсе и Node.js и API во внутреннем интерфейсе. Поскольку Fullstack фокусируется на одном языке — JavaScript, а не на нескольких, его программы уникальным образом подготавливают студентов к беспрепятственной работе в обеих сферах.

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

Наверх Далее: выбор программы или учебного курса

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

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

Посмотрите, как интерфейсные и внутренние навыки вплетены в учебную программу. в Fullstack Academy и программе Grace Hopper, или познакомьтесь с командой инструкторов .

.

Front-end разработка и Back-end разработка. Какой из них вам подходит?

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

Стоит ли начинать учиться, чтобы стать фронтенд-разработчиком?

Внутренний разработчик?

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

Что вообще означают эти термины?

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

Начнем с аналогии с обычным магазином.

Подумайте о среднем магазине. Почти все они имеют интерфейсную и внутреннюю части.

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

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

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

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

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

То же самое и с веб-приложениями.

Что такое Front-end разработчик?

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

Вот некоторые технологии, которые часто используют фронтенд-разработчики:

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

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

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

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

Лучшие практики фронтенд-разработчиков

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

Препроцессоры CSS

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

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

Языки Less и Saas являются наиболее часто используемыми языками препроцессора. Вот чем они отличаются:

• Less — это совсем другой язык, чем CSS.Обычный CSS работает в Sass, но он также поддерживает дополнительные функции.

Веб-сайт

• Sass называет sass «CSS со сверхспособностями».

Как только вы освоите обычный CSS, Sass и Less довольно легко освоить.

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

Расширенные шаблоны CSS

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

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

Фреймворки JavaScript

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

Сейчас есть три основных фреймворка:

• Angular был разработан Google и используется многими веб-приложениями. Следующее поколение Angular — это Angular 2, и между ними есть некоторые существенные различия.
• Ember — это интерфейсный фреймворк, созданный Apple. Apple создала фреймворк под названием SproutCore , который позже был переименован в Ember.
• React — это интерфейсный фреймворк, созданный инженерами Facebook. Экосистема React быстро развивается, но начинает стабилизироваться. React-Fiber — это полностью переписанный фреймворк, призванный быть быстрее, но при этом поддерживать совместимость со старым кодом React.

Другие известные фреймворки — это Backbone и VueJS.

Прямо сейчас не существует «правильной» структуры для использования. Разные компании используют разные фреймворки.

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

Транспилеры JavaScript

Все браузеры

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

Вот некоторые распространенные транспилеры:

• ES6 — это следующая версия JavaScript. Он обратно совместим со старыми версиями JavaScript, но имеет дополнительные функции. Инструмент преобразования, который используется для преобразования ES6 в обычный код JavaScript, называется babel . ES6 довольно новый, но я с оптимизмом смотрю на его будущее.
• CoffeeScript — это рубиновый язык программирования, который преобразуется в JavaScript.По умолчанию он встроен в структуру rails и используется многими разработчиками.
• TypeScript использует радикальный подход к фундаментальному изменению JavaScript с динамически типизированного языка на статически типизированный. Значит, это принципиально другой язык. TypeScript — это инициатива Microsoft. Его успех во многом зависит от скорости внедрения Angular 2.

Итоги фронтенд-разработки

Вещи развиваются очень быстро.Это потрясающе. Это также пугает.

Термин JavaScript Fatigue используется для описания тенденции JavaScript-сообщества двигаться к новым и ярким объектам.

Не беспокойтесь, если вы не используете новейшие технологии.

Что такое внутренний разработчик?

Front-end разработчики сосредоточены на работе с инструментами, технологиями и языками программирования, которые работают внутри веб-браузеров. Back-end разработчики сосредоточены на…. все остальное.

Так что это на самом деле влечет? Давайте немного уменьшим масштаб.

Давайте поговорим о том, как на самом деле работают веб-приложения.

• Для начала веб-браузер обращается к Интернету и выполняет так называемый HTTP-запрос GET для посещенного URL.
• Волшебство происходит по трубам в Интернете
• В конце концов, он достигнет сервера (компьютера), который вы, как веб-разработчик, контролируете.

Ваша работа как back-end разработчика — «сделать волшебство» и дать пользователю то, что он ожидает увидеть.

Итак, давайте поговорим о том, что вовлечено в , заставляя совершить волшебство .

Базы данных

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

Базы данных позволяют легко добавлять, удалять, изменять и получать доступ к таким объектам, как данные, созданные пользователями. Почти все веб-приложения используют базы данных , и есть два основных разных типа баз данных: SQL и NoSQL.

Большинство веб-приложений используют базы данных SQL. Принято создавать веб-приложения, которые позволяют создавать строки, читать их, обновлять и уничтожать. Это сокращенно называется « CRUD ».

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

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

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

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

Контроллер — это связующее звено между различными другими частями веб-приложения.

RESTful Архитектура. REST — это концепция размышлений о том, что на самом деле представляют собой HTTP-запросы. Back-end разработчики могут продумать, какие HTTP-запросы ожидает увидеть веб-приложение, и знать, как подключить его к своему приложению (в частности, к их контроллерам), используя так называемую маршрутизацию .

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

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

Итог с внутренней разработкой

Back-end разработчики работают с серверами и базами данных.Они также помогают преобразовывать HTTP-запросы в реальные ответы из Интернета.

Вот почему лучше всего быть разработчиком полного стека

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

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

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

Это означает, что если вы…

• Работа в компании добавление функции
• Создание идеи для побочного проекта
• Исправление ошибки в существующем приложении

… вы сможете работать со всеми аспектами кода.

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

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

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

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

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

То же самое и в разработке.

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

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

.

Сэм Ньюман — Бэкенды для внешних интерфейсов

Введение

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

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

Бэкэнд API общего назначения

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

Бэкэнд API общего назначения

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

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

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

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

Общие командные структуры при использовании общего API

Введение в бэкэнд для внешнего интерфейса

Одно из решений этой проблемы, которое я видел при использовании как в REA, так и в SoundCloud, заключается в том, что вместо универсального бэкэнда API у вас есть один бэкэнд для каждого пользователя — или, как (бывший SoundClouder) Фил Кальсадо назвал его Бэкэнд для Frontend (BFF).Концептуально вы должны рассматривать приложение, обращенное к пользователю, как два компонента — клиентское приложение, живущее за пределами вашего периметра, и серверный компонент (BFF) внутри вашего периметра.

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

Использование одного серверного BFF для каждого пользовательского интерфейса

BFF сосредоточен на одном пользовательском интерфейсе, и только на нем. Это позволяет сфокусировать его и, следовательно, будет меньше.

Сколько лучших друзей?

Когда дело доходит до предоставления одного и того же (или аналогичного) взаимодействия с пользователем на разных платформах, я видел два разных подхода. Модель, которую я предпочитаю, состоит в том, чтобы строго иметь одного BFF для каждого типа клиентов — это модель, которую я видел в REA:

.

Другая мобильная платформа, другой BFF, используемый в REA

Другая модель, которую я видел в использовании в SoundCloud, использует один BFF для каждого типа пользовательского интерфейса.Таким образом, обе версии собственного приложения слушателя для Android и iOS используют один и тот же BFF:

.

Наличие одного BFF для разных мобильных бэкэндов, как это используется в SoundCloud

. Меня больше всего беспокоит вторая модель: чем больше типов клиентов у вас будет с одним BFF, тем больше у него может возникнуть соблазн раздуться из-за решения нескольких проблем. . Однако важно понять, что даже при совместном использовании BFF он предназначен для одного и того же класса пользовательского интерфейса — поэтому, хотя собственные приложения SoundCloud для слушателей для iOS и Android используют один и тот же BFF, другие собственные приложения будут использовать разные BFF (для Например, новое приложение Creator Pulse использует другой BFF).Я также более спокойно отношусь к использованию этой модели, если одна и та же команда владеет приложениями для Android и iOS, а также владеет BFF — если эти приложения обслуживаются разными командами, я более склонен рекомендовать более строгую модель. Таким образом, вы можете рассматривать свою организационную структуру как один из основных факторов, определяющих наиболее целесообразную модель (закон Конвея снова побеждает). Стоит отметить, что инженеры SoundCloud, с которыми я разговаривал, предположили, что наличие одного BFF для приложений прослушивания Android и iOS — это то, что они могли бы пересмотреть, если снова примет решение сегодня.

Мне очень нравится рекомендация Стюарта Глидоу (который, в свою очередь, упомянул Фила Кальсадо и Мустафу Сезгина): «Один опыт, одна лучшая подруга». Так что, если опыт работы с iOS и Android очень похож, то легче оправдать наличие одного BFF. Однако если они сильно расходятся, то иметь отдельные BFF имеет больше смысла.

Пит Ходжсон заметил, что лучшие лучшие друзья работают лучше всего, когда они выстраиваются вокруг границ команды, поэтому структура команды должна определять количество ваших лучших друзей. Так что если у вас одна мобильная команда, у вас должен быть один лучший друг, но если у вас есть отдельные команды iOS и Android, у вас будут разные лучшие друзья.Меня беспокоит то, что командные структуры обычно более подвижны, чем дизайн нашей системы. Итак, если у вас есть один BFF для мобильных устройств, а затем разделите команду на специализации iOS и Android, вам также придется разделить BFF? Если бы BFF уже были разделены, то разделение команды было бы проще, поскольку вы могли бы передать право собственности на уже независимый актив. Тем не менее, взаимодействие BFF и структуры команды важно, и мы это рассмотрим позже.

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

И несколько нисходящих сервисов (микросервисы!)

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

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

Выполнение нескольких нисходящих вызовов для создания представления списка желаний

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

Режимы отказа становятся важными для понимания. В нашем примере выше мы могли бы настоять на том, чтобы все нисходящие вызовы возвращались, чтобы мы могли вернуть полезную нагрузку нашему клиенту.Однако разумно ли это? Очевидно, что мы ничего не сможем сделать, если служба Wishlist не работает, но если бы была отключена только служба Inventory, не лучше ли было бы просто ухудшить функциональность, которую мы передаем обратно клиенту, возможно, просто удалив индикатор уровня запасов? Эти проблемы должны решаться самим BFF в первую очередь, но мы также должны убедиться, что клиент, выполняющий вызов BFF, может интерпретировать частичный ответ и правильно его отобразить.

Повторное использование и BFF

Одна из проблем, связанных с наличием одного BFF для каждого пользовательского интерфейса, заключается в том, что вы можете столкнуться с большим количеством дублирования между самими BFF.Например, они могут в конечном итоге выполнять одни и те же типы агрегации, иметь одинаковый или похожий код для взаимодействия с подчиненными службами и т. Д. Некоторые люди реагируют на это, желая объединить их вместе, и поэтому имеют универсальную агрегирующую службу Edge API. . Эта модель снова и снова доказывала, что приводит к сильно раздутому коду, в котором объединяются несколько проблем.

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

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

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

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

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

Несколько BFF выполняют одни и те же задачи

Вместо этого мы могли бы изменить сервис Wishlist, чтобы он выполнял нисходящие вызовы за нас, тем самым упростив работу для вызывающих:

Дальнейшее продвижение функций агрегации вниз по потоку для удаления дублирования в BFF

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

BFF для настольных компьютеров и выше

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

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

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

Предоставление API-интерфейсов третьим сторонам с помощью BFF

Этот подход может быть особенно эффективным, поскольку третьи стороны часто ограничиваются отсутствием возможности (или желания) использовать или изменять выполняемые ими вызовы API.С бэкэндом API общего назначения вам, возможно, придется хранить старые версии API, чтобы удовлетворить небольшую часть ваших внешних сторон, неспособных внести изменения — с BFF эта проблема значительно уменьшается.

и автономность

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

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

Пример границ владения командой при использовании BFF

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

Общие проблемы периметра

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

Использование сетевого устройства для реализации общих проблем периметра

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

Когда использовать

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

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

Дальнейшее чтение (и просмотр)

• С тех пор, как я написал эту статью, Лукаш Плотницки из ThoughtWorks опубликовал отличную статью об использовании SoundCloud паттерна BFF
• Лукаш дает интервью о шаблоне (и других вещах) в недавнем выпуске подкаста «Разработка программного обеспечения».
• Bora Tunca из SoundCloud также более подробно рассказывает во время выступления на microxchg 2016.

Заключение

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

Спасибо Матиасу Кепплеру, Майклу Ингланд, Филу Кальсадо, Лукашу Плотницки, Джону Ивсу, Стюарту Глидоу и Кристофу Адрианссенсу за их помощь в исследовании этой статьи, а также Джайлзу Александру, Кену Маккормаку, Шрираму Вишванатану, Корнелису Ситсма, Хани Элемэри, Мартину Фаулеру , Владимиру Снеблицу и Питу Ходжсону за общие отзывы.Буду очень признателен за любые дальнейшие отзывы, так что не стесняйтесь оставлять комментарии ниже!

Посмотреть другие образцы.

.