Бэкэнд и фронтэнд: Чем отличаются фронтенд, бэкенд и фулстек — Блог HTML Academy

Чем отличаются фронтенд, бэкенд и фулстек — Блог HTML Academy

Все они делают сайты. Но есть нюанс.

Фронтенд-разработчик

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

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

В реальной работе верстальщики делают не только страницы — иногда нужно сверстать макет для WordPress или Drupal или подготовить вёрстку, которую будут использовать React-разработчики.

Фронтенд-разработчики верстают на HTML, CSS, пишут код на JavaScript и умеют работать с макетами в графических редакторах.

Как начать:

Тренажёры по вёрстке (бесплатно)

Старт в Figma для верстальщика

Профессия «Фронтенд-разработчик» (год обучения)

React-разработчик

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

React-разработчик должен хорошо понимать и уметь всё, что умеет верстальщик, но часто ему не обязательно верстать самому. Такие разработчики чаще пишут код приложений на React, но для этого им нужно отлично знать «ванильный» JavaScript — просто чистый язык без примесей, на котором тоже можно много всего сделать.

Учить React без знания JavaScript можно, но это как строить пятый этаж дома, не построив первые четыре. Скорее всего, придётся ставить подпорки, а потом всё развалится.

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

Бэкенд-разработчик

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

Бэкенд может быть «тяжёлым» — его пишут на PHP, Python или Ruby, или «лёгким» — его пишут на JavaScript с помощью Node.js. Язык нужно выбирать в зависимости от того, что нужно в конкретной компании или на конкретном проекте. И неудивительно, почему многие бэкендеры выбирают PHP.

Зачем нужен PHP

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

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

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

Фулстек-разработчик

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

Как стать веб-разработчиком, если вы сомневаетесь

И если с фронтендом всё примерно понятно — там вёрстка и JavaScript — то по бэкенд-части есть разнообразие. И здесь тоже можно учить Python и PHP, а можно отлично выучить JavaScript, разобраться в Node.js и стать фулстеком только с одним языком. Это звучит как минус, но на самом деле и для таких специалистов есть работа.

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

На профессии «Фулстек-разработчик» в HTML Academy мы готовим как раз специалистов по JavaScript, которые могут и сайт оживить, и бэкенд написать, и всё это на JavaScript — с помощью React и Node.js.

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

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

Всё ещё непонятно?

Давайте мы перезвоним и ответим на все вопросы насчёт обучения на профессиях в HTML Academy.

А давайте

Чем отличаются фронтенд- и бэкенд-разработка

Хочешь проверить свои знания по JS?

Подпишись на наш канал с тестами по JS в Telegram!

Решать задачи

×

Перевод статьи «Front End Developer vs Back End Developer – Definition and Meaning In Practice».

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

Многослойность разработки

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

Линия разграничения между ними может быть довольно размытой, особенно с учетом роста популярности JavaScript и бессерверных технологий. Когда инструментарий фронтенда и бэкенда становится общим, мы порой можем задуматься, а не относимся ли мы к full stack разработчикам. Спойлер: не относимся. По крайней мере, не все.

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

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

В чем разница между фронтенд- и бэкенд-разработкой?

Даже если вы full stack разработчик, это не означает, что при работе над проектом у вас не будет разделения труда.

Что из себя представляют обе части разработки?

Что такое фронтенд-разработка?

Фронтенд приложения обычно охватывает слой пользовательского интерфейса (UI). А UI бывает и на статических сайтах, и на полнофункциональных React-приложениях.

Как выглядела фронтенд-разработка раньше?

В настоящее время миром фронтенда правит JavaScript, но так было не всегда. Раньше этот язык использовали для добавления некоторой интерактивности на сайте, но вообще фронтенд рендерился благодаря использованию языков бэкенда, таких как PHP и Perl.

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

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

К наиболее традиционным инструментам фронтенда можно отнести следующие:

Но со временем JavaScript «повзрослел», да и браузеры стали более мощными. В результате этого мы пришли к идее, что можно передать часть работы браузерам и таким образом обеспечить более быструю и интерактивную работу продуктов.

Что собой представляет фронтенд-разработка в настоящее время?

Сейчас на сайтах и в приложениях интенсивно используется JavaScript, а создаются они при помощи UI-фреймворков, таких как React, Vue и Angular. Эти инструменты позволяют разработчикам строить сложные пользовательские интерфейсы из компонентов, пригодных для многократного использования.

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

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

Сегодня широко используются следующие инструменты фронтенд-разработки:

• UI-фреймворки вроде React или Vue,
• веб-фреймворки, такие как Gatsby,
• компиляторы (Babel),
• сборщики (Webpack),
• CSS-инструменты, например Sass.

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

Что такое бэкенд-разработка?

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

Как бэкенд-разработка выглядела раньше?

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

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

К традиционным инструментам бэкенда можно отнести следующие:

• локально или удаленно управляемые серверы, например Rackspace,
• HTTP-серверы, использующие Apache,
• базы данных, например MySQL,
• серверные языки (PHP или Perl),
• фреймворки приложений, такие как Ruby on Rails.

Что собой представляет бэкенд-разработка сейчас?

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

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

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

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

Сегодня распространены следующие инструменты бэкенда:

• облачные серверы вроде AWS EC2,
• бессерверные сервисы, такие как AWS Lambda,
• базы данных NoSQL (MongoDB),
• такие языки как Python или JavaScript (последний — с применением NodeJS),
• фреймворки веб-приложений, например Serverless Framework.

Сумеречная зона

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

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

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

Фронтенд или бэкенд

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

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

Учебные ресурсы

Фронтенд

Бэкенд

Для обоих направлений

когда простого API не хватает / Хабр

Технология Backend-for-Frontend упрощает разработку сервисов, с которыми одновременно работают множество разных клиентов: компьютеры, смартфоны и планшеты со всеми возможными ОС.

Подход Backend-for-Frontend (BFF) разработали в компании SoundCloud. Pуководитель департамента разработки SoundCloud Фил Калсадо (Phil Calçado) ещё в 2015 году описывал BFF как закономерный этап эволюции, которую прошли современные ИТ-продукты.

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

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

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

Так и родилась концепция Backend-for-Frontend – легковесного сервиса, который лежит ближе к фронтенду, чем к бэку.

Возможности BFF

Ключевое слово – «легковесный», список возможностей у BFF гораздо меньше, чем у API:

• Работать с микросервисами продукта и получать от них данные.

• Форматировать эти данные, чтобы они корректно обрабатывались на фронтенде.

• Отправлять данные фронтенду.

Компания может параллельно поддерживать несколько BFF: для пользователей на ПК, для Android, для iOS и т.д. А с точки зрения разработчиков главные преимущества – это избавление от многих технических ограничений бэкенда и ускорение выпуска фич:

• Можно строить бэкенд и API от выстроенного клиентского пути и продукта, а не наоборот.

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

• Становится проще управлять доступом мобильного приложения к бэкенду.

Сейчас BFF в своей практике используют многие крупнейшие технологические компании – например, Netflix и Flickr. Его рекомендуют Microsoft и IBM. Мы поделимся своим опытом из одного из недавних проектов True Engineering.

Как мы используем BFF

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

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

Такая архитектура ускоряет обновление данных в нашем продукте, которые периодически возникали при работе через API. Раньше наш продукт получал данные из собственной БД интернет-магазина, и при работе напрямую с Rabbit просто так обновить данные было невозможно. С внедрением BFF мы запустили новый модуль Data Provider, которая позволяет не ходить в ИМ за обновлениями информации. 

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

О чём нужно помнить, создавая BFF

BFF-сервис должен быть лёгким – в этом его главное отличие от API. Не надо прописывать в коде сложную бизнес-логику, строить БД и т.д. Приоритетом должен быть простой обмен данными.

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

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

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

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.

Самые Полюбившиеся Статьи

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

Различные Сферы Влияния: Фронтенд и Бэкенд

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

Итак, frontend backend разработчики и их обязанности, давайте начинать!

Для начала давайте сравним то, чем Фронтенд и Бэкенд разработчики занимаются. Это не очень сложная тема, так как отличия весьма разительные, несмотря на одну сферу деятельности.

Как Работают Сайты?

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

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

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

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

Какую часть делал Фронтенд и Бэкенд разработчик в этом случае?

Всё, что вы видите на сайте Amazon было создано фронтенд разработчиками. Кнопки, список товаров, страница товаров, страница оплаты, практически всё.

Но.

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

Если вы хотите создать сайт, то это не front end vs back end. Это front end и back end вместе.

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

День Из Жизни Фронтенд Разработчика

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

Давайте представим, что вы фронтенд разработчик в компании X, которая имеет свой собственный интернет-магазин скейтбордов.

Эта компания имеет команды UI/UX дизайнеров, фронтенд и бэкенд разработчиков, а также системных администраторов.

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

Если идея будет принята, то вам придётся переделать 60% фронтенд сайта. Так как эта идея имеет новый дизайн, то с этого момент начнётся ваша работа.

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

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

День Из Жизни Бэкенд Разработчика

Теперь, давайте решим спор “front end vs. back end”, взглянув на него с другой стороны. Ваш день начинается почти так же, и вы отправляетесь на встречу с техническим директором вашей компании.

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

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

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

Технологии, Которые Вам Нужно Будет Знать

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

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

Набор Инструментов Front End

Давайте определим frontend backend инструменты. Хлебом и маслом фронтенд разработчиков являются HTML, CSS и JavaScript. HTML — это гипертекстовый язык разметки, который используется для создания основы сайта. CSS — это способ сказать браузеру, как всё должно выглядеть, стилизуя контент. JavaScript используется для добавления анимаций, переходов и функций для элементов.

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

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

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

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

Учитывая сказанное, интернет-магазин компании X будет иметь невероятный дизайн, но он может потребовать скриптов, которые должны работать слаженно. В качестве опытного фронтенд разработчика вы должны ценить своё время и использовать библиотеки, вроде React.js и фреймворки, вроде Angular.js только в подходящих случаях.

Набор Инструментов Back End

Итак, давайте приступим к следующей части изучения Фронтенд и Бэкенд инструментов. Инструменты фронтенд разработчика обычно довольно популярны. Однако в случае с бэкенд разработчиком всё совсем не так.

Языки программирования серверной части

Выбор языков программирования зависит от предпочтений, нужд проекта и ваших знаний. Существует несколько популярных языков программирования серверной части, вроде PHP, JavaScript (используемых в среде Node.js с фреймворком Express), Python, Ruby, C#, Java и другие.

Используемые технологии также могут определить язык, которые вы собираетесь использовать. Например, если ваш сайт создан на Symfony или Laravel, то вам придётся использовать PHP. Для фреймворка Django более предпочтительным станет Python, тогда как работа с фреймворком Express потребует от вас знаний Node.js.

База данных

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

Существует несколько популярных систем баз данных, вроде MongoDB, MySQL, Oracle, Redis и другие.

Итак, front end и back end инструменты мы рассмотрели, давайте перейдём к следующей теме.

Разная Специализация Для Различных Интересов

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

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

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

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

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

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

Однако это вовсе не так. Эти две специализации равны, хотя требует различных наборов навыков и знаний.

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

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

Какая Зарплата у Веб-Разработчика?

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

Давайте взглянем на цифры и подведём некий итог в споре “front end vs back end”, что позволит вам принять взвешенное решение. Эти данные будут представлены в качестве сравнения.

Зарплата Фронтенд

По данным glassdoor.com средняя зарплата фронтенд разработчика в городе Нью Йорк равна $111,728, что на 20% выше чем национальный уровень по стране. Это может быть объяснено тем, что крупные города имеют высокие расходы на проживания и более развитую экосистему бизнеса.

В Лондоне, Великобритания, средняя годовая зарплата для фронтенд разработчика составляет около $52,000, что 22% выше национального среднего уровня, по данным glassdoor.com. Как вы заметили, зарплата серьёзно отличается, но общий уровень относительно других зарплат в стране остаётся практически таким же.

В Индии среднегодовая зарплата для фронтенд разработчика составляет порядка $5,000. Это может показаться очень низким уровнем по сравнению с другими данными, но вы должны учитывать общий уровень жизни и зарплат в стране!

Зарплата Бэкенд

В Нью Йорке средняя зарплата бэкенд разработчика будет равна $133,182, что на 17% выше национального среднего уровня зарплат. Как вы наверное заметили, то разнится с другими странами и города также высока.

В Лондоне средняя зарплата бэкенд разработчика является уже более высокой и равна $74,000, на 32% выше средней. В Индии фронтенд и бэкенд разработчики получают одинаковую заработную плату.

Самые Популярные Статьи

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

Вердикт

Если дело касается зарплаты, то front end и back end разработчики не сильно разнятся, но бэкенд специалист может рассчитывать на большее.

Почему?

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

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

Заключение

Надеемся, что теперь у вас есть более ясное представление о фронтенд и бэкенд разработке.

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

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

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

Фронтенд и Бэкенд. Выбор за вами?

Оставьте ваше честное мнение

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

“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.  На самом деле многие используют фронтэнд и бекэнд в своем бизнесе по двух шаговой системе продаж, но не знают, что это так называется.

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

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

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

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

Главный доход, компании получают от продажи бекэнда.

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

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

Дешевые принтеры – и дорогие картриджи к ним.

Дешевые билеты в кино – это фронтэнд, а сопутствующие товары типа  напитков, попкорна и др. – это бекэнд, от продажи которого идет основная прибыль.

В консалтинге фронтэндом может служить бесплатная консультация.

Что такое фронтэнд и бекэнд в инфобизнесе

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

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

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

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

Ваши бэк-эндовые продукты всегда будут в итоге переходить в разряд фронт-энда.

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

Что делать в таком случае?

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

Это не удержит «сползания» продукта в массовость, но позволит хоть как-то еще использовать его потенциал.

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

И когда мы создаем новый продукт, то цену на него увеличиваем постепенно.

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

Пишите комментарии и ставьте  лайки.

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

С уважением и верой в Ваш успех Татьяна Рахлецова

10 лучших интерфейсных и серверных фреймворков, которые следует изучить в 2021 году | автор: javinpaul | Javarevisited

Эти лучшие интерфейсы и бэкэнд-фреймворки и библиотеки, которые разработчики Java, Python, Ruby и JavaScript могут изучить в 2021 году.

Здравствуйте, ребята, если вы хотите стать full-stack разработчиком , тогда у вас есть много вариантов между интерфейсной и бэкэнд-фреймворками. В то время как в интерфейсных фреймворках преобладает JavaScript, на бэкэнде есть множество опций для создания серверных приложений, таких как Java, Python, Ruby и даже JavaScript.

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

Многие из нас попадают в мир программирования и веб-разработки, зная всего лишь одну или две технологии, такие как Java, C ++ или JavaScript, но это больше не поможет.

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

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

Если вы посмотрите описание должности инженера-программиста полного стека в интернет-компаниях, вы обнаружите, что от инженера-программиста полного стека ожидается знание таких интерфейсных технологий, как ES-next, Babel, React, Redux, Bootstrap, LESS и т. Д.и внутренние навыки, такие как Python, Django, Graphene (GraphQL), REST, MySQL, DynamoDB, Redis, Docker и т.д. просто зная HTML, CSS и немного JavaScript, но не больше, и поэтому важно быть знакомым с другим набором технологий, даже если вы в них не разбираетесь.

Если вы инженер-программист полного цикла или кто-то, кто стремится стать инженером-программистом полного цикла, то вы должны быть знакомы с парой интерфейсных и серверных веб-фреймворков, таких как React и Node, но также зависит от вашего опыта, например, от того, являетесь ли вы в основном из Python или Java / JavaScript.

Лучше изучить фреймворк, который совместим с вашими основными навыками, например, разработчик Python должен получить больше пользы от изучения Django, чем от изучения Angular. Точно так же разработчик JavaScript должен научиться React и Node JS, а не изучать Django и Node JS.

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

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

1. React.js [Frontend + JavaScript]

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

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

Если вы в первую очередь разработчик JavaScript, то React JS должен быть вашим первым выбором для интерфейсной разработки. Если вы ищете рекомендации, лучше всего начать с The React Complete Guide от Max.

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

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

Front End разработка и Back End разработка отвечает за Интернет, с которым вы взаимодействуете — весь день, каждый день. Front End разработка использует языки программирования front end для создания того, что пользователь видит в браузере; Внутренняя разработка использует языки программирования серверной части для выполнения этих запросов на стороне сервера. В совокупности это создает беспроблемный опыт для пользователя.

Погружаясь глубже, эта страница была создана с использованием трех языков интерфейса.Слова, которые вы читаете, представлены в формате HTML. Расстояние и цвета определяются CSS. Интерактивная графика является результатом JavaScript. Языки серверной части, работающие в фоновом режиме, включают Ruby, Python и PHP.

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

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

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

Это означает охват языков программирования полного стека и навыков, необходимых для Front End или Back End разработчика. Мы также рассмотрим новейшие тенденции в области веб-разработки и трудоустройства для Front End и Back End разработчиков, в том числе возможности заработной платы и трудоустройства. Мы также рассмотрим появление Full Stack Development. Это очень важно, но мы здесь, чтобы помочь.

Итак, что такое Front End и Back End?

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

• Языки Front End разработки и программирования Front End создают то, с чем взаимодействует пользователь

• HTML, CSS и JavaScript — это три языка Front End

• Каждый язык имеет определенную функцию

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

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

Вскоре фронтенд-разработка будет процветать с появлением JavaScript в 1995 году и Flash в 1996 году. К 1998 году были созданы каскадные таблицы стилей (CSS), и все инструменты, которые потребуются фронтенд-разработчику, теперь доступны для создания современных сайтов.

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

За последние 20 лет то, что было началом разработки Front End, вышло далеко за рамки HTML, JavaScript и CSS. Популярность Flash-разработки уступила место HTML5. Хотя JavaScript привнес в Интернет интерактивность, разработчики разработали фреймворки для оптимизации этого процесса. Фреймворки JavaScript, такие как React, теперь используются для быстрой и эффективной разработки пользовательских интерфейсов. Redux — это еще одна среда JavaScript, обычно используемая с React или Angular, которая позволяет разработчикам создавать предсказуемые и легко тестируемые приложения.Есть еще больше фреймворков JavaScript, которые устраняют избыточные задачи кодирования.

Ключевые выводы → Языки фронтенд-разработки и фронтенд-программирования привели к созданию динамичного и интерактивного Интернета, который мы используем ежедневно. Front End-разработка сочетает в себе три языка программирования, фреймворки JavaScript и навыки дизайна для создания веб-сайта на основе определенного набора потребностей.

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

• Помогает создать пользовательский интерфейс в браузере

• Требуются творческие, технические и коммуникативные навыки

• Прогнозы занятости и заработной платы многообещающие

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

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

TL; DR: Что такое фронтенд-разработчик? Front End-разработчик использует HTML, CSS и JavaScript для создания того, что пользователь испытывает в браузере.

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

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

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

Front End Dev должны обладать как техническими, так и творческими навыками в рамках своей повседневной работы. Им нужно иметь воображение, чтобы понять, как будет выглядеть веб-сайт, и при этом иметь техническую возможность воплотить мечту в реальность.Это также должно происходить совершенно незаметно и интуитивно понятно для пользователя. Разработчикам также необходимо учитывать скорость отклика сайта, поскольку мир становится все более мобильным. Медленный или плохой опыт будет наказан как Google, так и пользователями.

Помимо жестких навыков, Front End разработчикам необходимы мягкие навыки для общения между несколькими командами. Это означает, что нужно научиться сообщать о потребностях дизайнерам, разработчикам серверной части и членам команды, которые могут не обладать большими техническими знаниями. Одно дело писать код, а совсем другое — объяснять кодирование.

В связи с растущим спросом на цифровые технологии фронтенд-разработчики пользуются большим спросом. По прогнозам Бюро статистики труда Министерства труда США, количество вакансий веб-разработчиков, в том числе разработчиков Front End и Back End, вырастет на 15% в период с 2016 по 2026 год.

Хотя медианные зарплаты могут сильно различаться, даже самые консервативные оценки для Front End разработчика намного выше, чем медианная зарплата для всех профессий. По данным Бюро статистики труда, средняя зарплата веб-разработчика составляет 67 990 долларов по сравнению со средней зарплатой в 37 690 долларов для всех профессий.

Средняя зарплата Front End разработчиков выше на таких сайтах, как Glassdoor и Indeed. Средняя годовая зарплата Front End разработчика на Glassdoor составляет 92 783 доллара. Средняя зарплата на Indeed составляет 108 303 доллара в год. Средняя зарплата младших разработчиков Front End ниже — 60 425 долларов на Indeed и 79 511 долларов на Glassdoor. По данным Glassdoor, старшие разработчики Front End зарабатывают в среднем 120 000 долларов.

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

Ключевые выводы → Интерфейсный разработчик жизненно важен для взаимодействия с пользователем в Интернете. Они работают как часть более крупной команды, чтобы создать то, что пользователь видит и с чем взаимодействует в браузере. Для этого разработчики Front End используют HTML5, CSS, JavaScript, JavaScript-фреймворки и библиотеки кода.

Языки переднего плана

• HTML5, CSS и JavaScript являются основой разработки переднего плана

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

• Разработчики используют фреймворки и библиотеки кода для повышения эффективности

• Также известные как языки интерфейса или языки интерфейса

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

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

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

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

Теперь разработчики Front End могут манипулировать веб-элементами, не дожидаясь загрузки сайта (представьте, что вы ждете обновления Twitter каждый раз, когда вы обновляете свой канал). Разработчики также используют инфраструктуры Front End для улучшения или упрощения задач JavaScript. Например, фреймворк AngularJS позволяет разработчикам эффективно создавать одностраничные веб-приложения. jQuery упрощает задачи, а AJAX добавляет в JavaScript XML, язык разметки, чтобы сайты могли обновляться без обновления.

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

Ключевые выводы → HTML, CSS и JavaScript лежат в основе разработки Front End.Эти три языка относительно просты в изучении и предлагают большую гибкость и творческий подход. Если вы хотите стать Front End разработчиком, вам необходимо изучить эти три языка и фреймворки JavaScript.

Что такое Back End разработчик?

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

TL; DR: A Что такое Back End разработчик? Back End разработчик использует Ruby, Python, PHP, SQL и другие языки программирования Back End для разработки и поддержки логики Back End веб-сайта.

Back End разработчики могут быть более технически организованными и организованными, но они по-прежнему являются частью более крупной команды. Хотя им нужно знать, как создать логику, которая эффективно извлекает данные для выполнения запроса, им также необходимо сообщить о своих потребностях и потенциальных ограничениях во Front End-разработчика.Они также несут ответственность за поддержание этой логической системы. Разработчики Back End работают с базами данных, серверами, интерфейсом прикладного программирования (API), который создает структуру для взаимодействия компонентов и интеграции всех этих процессов.

Back End разработчики используют языки программирования Back End, такие как Ruby, Python, PHP, Java, платформу Microsoft .Net, и инструменты управления данными, такие как SQL и MySQL, для удовлетворения запросов пользователей. В предыдущем примере с Amazon запрос пользователя запускает цепочку как видимых, так и невидимых событий.Пользователь вводит поисковый запрос, который затем приводит к тысячам результатов менее чем за секунду. Пользователь испытывает все, что создал Front End-разработчик, одновременно пользуясь преимуществами быстрого извлечения информации с использованием логики, созданной Back End-разработчиком. Если пользователь нажимает кнопку, чтобы перейти на новую страницу, или если на веб-сайте есть функция бесконечной прокрутки, Back End dev отвечает за то, чтобы пользователь попал на нужную страницу.

Back End разработчики пользуются большим спросом из-за технического характера роли.Это не так привлекательно, как Front End разработка, но Back End разработка очень важна. Средняя годовая зарплата Back End разработчика составляет 114 255 долларов на Glassdoor и 126 601 доллар на Indeed. Заработная плата может отличаться в зависимости от местоположения, отрасли и опыта.

Ключевые выводы → Back End разработчик разрабатывает и поддерживает серверную логику веб-сайта. Они используют несколько языков Back End, включая Ruby, Python и PHP, а также инструменты управления базами данных, такие как SQL и .Net.

Back End языки

• Ruby, Python и PHP являются популярными Back End языками

• Back End языки используются для выполнения запросов, созданных пользователем

• Back End языков извлекают информацию из базы данных, хранящейся в сервер, который затем обрабатывается через приложение

• Также известные и серверные языки или серверные языки

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

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

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

Ruby — это объектно-ориентированный язык программирования общего назначения.Это означает, что он широко используется и рассматривает все как объект. Философия Ruby, которая подчеркивает человечность и способствует выразительности, сделала его невероятно популярным среди разработчиков и стартапов. Ruby on Rails — невероятно популярный фреймворк, используемый для помощи в разработке веб-сайтов и приложений путем оптимизации процесса разработки. Ави Фломбаум, наш соучредитель и декан, много писал о Ruby и о том, почему ему нравится этот язык программирования.

В то время как веб-разработка Back End является более технической, чем разработка Front End, разработчики Back End работают рука об руку с разработчиками Front End.

Python — еще один объектно-ориентированный язык программирования общего назначения. Python используется для кодирования серверной логики, и многие популярные веб-сайты, включая Reddit и Instagram, построены на Python. Язык легко масштабируется с помощью таких фреймворков, как Django. Python становится все более популярным благодаря своим приложениям в машинном обучении и науке о данных.

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

SQL, или язык структурированных запросов, используется для управления данными, найденными в базе данных. MySQL — это система управления данными с открытым исходным кодом, которая широко используется в серверной разработке. Существуют и другие серверные языки, такие как Java или ASP.NET, которые используются в разных отраслях.

Ключевые выводы → Back End языков и Back End разработки используются для выполнения запросов, сделанных языками Front End. Они взаимодействуют с базами данных, серверами и приложениями и также известны как серверные языки.

Фронтенд и бэкэнд

Front End и Back End можно резюмировать по-разному. Они используют разные языки программирования и имеют разные обязанности. Но разработчики Front End и Back End работают над достижением одной цели. В конечном итоге они работают вместе, чтобы удовлетворить потребности пользователя.

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

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

Key takeaway → Front End и Back End — две стороны одной медали.Они работают вместе, чтобы выполнить запрос пользователя и удовлетворить более крупные потребности компании.

Что такое полный стек?

Что происходит, когда компания слишком мала или не может позволить себе команду разработчиков? Вот где может пригодиться разработчик Full Stack. Они не обязательно являются экспертами как во Front End, так и в Back End, но более чем способны решить большинство потребностей веб-разработки.

• Разработка Full Stack охватывает весь спектр веб-разработки

• Разработчики Full Stack не являются экспертами как в Front End, так и в Back End разработке

• Стартапы и небольшие компании популяризировали роль

апокрифическая история о том, что Facebook нанимал только разработчиков Full Stack.Было ли это правдой, причиной такого решения было нанять более универсальных разработчиков, которые не были исключительно «Front End» или «Back End». У вас может быть команда разработчиков, которая сможет справиться со всем спектром веб-разработки и будет знать потребности других членов команды. Коммуникация будет улучшена, а для компании — более упорядоченная команда.

Растущий стартап мог бы хорошо использовать разработчика Full Stack. Этот человек будет знать достаточно, чтобы умело создать веб-сайт, а также решить некоторые проблемы на Back End.Разработчик Full Stack знает немного HTML, CSS, JavaScript, Python и PHP, а также библиотеки кода и фреймворки, которые помогают автоматизировать некоторые процессы. Они не являются экспертами во всех языках, но понимают достаточно и знают, куда обратиться за помощью, если что-то пойдет не так.

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

По данным Glassdoor, благодаря широкому набору навыков разработчики Full Stack могут получать среднюю годовую зарплату в размере 115 960 долларов. Заявленные зарплаты варьируются от 76 000 до 157 000 долларов США с обычными оговорками, что различия связаны с местоположением, отраслью и опытом. Средняя годовая зарплата разработчика Full Stack на Indeed составляет 113 575 долларов. А как насчет Front End и Back End? Разработчики Full Stack обычно зарабатывают больше, чем оба.

Ключевые выводы → Разработчик Full Stack понимает как Front End, так и Back End разработку.Они не являются экспертами в обоих направлениях, и эта роль стала популярной, поскольку стартапам нужны разносторонние технические таланты.

Front End vs. Back End vs. Full Stack

• Три очень популярных роли разработчика

• Front End и Back End являются специализированными, а Full Stack — обобщенными

• Full Stack использует программирование Front End и Back End languages ​​

Как мы уже говорили, разница между Front End и Back End связана с пользователем.В то время как Front End разработчик использует код для создания того, что пользователь видит в браузере, Back End разработчик использует код, чтобы сделать все это возможным на стороне сервера. И хотя Back End разработка более техническая, чем Front End разработка, Back End разработчики работают рука об руку с Front End разработчиками.

Совсем недавно появился новый тип разработчиков, поскольку стартапы и небольшие компании стремятся удовлетворить свои потребности как во Front End, так и Back End. Разработчики Full Stack обладают навыками Front End разработки и Back End разработки.Они не обязательно должны быть экспертами, , но имеют общее представление обо всех потребностях как на стороне пользователя, так и на стороне сервера. Разработчики Full Stack могут работать в гибридной роли от этапа проектирования до завершения.

Все три роли востребованы, и есть вероятность, что разработчики будут иметь некоторое знание разных языков программирования. В зависимости от размера компании разработчик Front End или Back End может по необходимости стать разработчиком Full Stack. Все зависит от ваших предпочтений.Если вам не нравится работать с визуальными элементами или вам больше не нравится организация, то, скорее всего, вы собираетесь стать Back End разработчиком.

Ключевые выводы → Не существует «лучшего» разработчика. Определите, что вам нравится, и посмотрите, соответствует ли это трем распространенным типам разработчиков.

Как стать разработчиком

Судя по всему, что вы читали до сих пор, почти все вакансии Front End разработчика требуют HTML, JavaScript и CSS. Знание фреймворка, включая JSON и jQuery, также необходимо для любых работ по веб-разработке.В описании должностей старшего Front End может содержаться указание на опыт работы с PHP или фреймворками с серверными шаблонами.

Задания Back End разработчиков немного отличаются в зависимости от отрасли. Ruby, Python и PHP — популярные языки программирования, а SQL и MySQL — популярные инструменты управления базами данных. Некоторые отрасли могут предпочесть опыт работы с Java или Microsoft .Net framework. Наши собственные данные о результатах работы выпускников показывают, какие языки студенты используют в своей карьере.

Для работы веб-разработчиками ученая степень не требуется.Большинство вакансий в Glassdoor предполагает получение практического опыта, а не продвинутого образования. Согласно Статистическому бюро Министерства труда США, степень младшего специалиста — это типичный уровень образования для фронтенд-разработчиков начального уровня.

Если вы хотите стать разработчиком, теперь вы знаете, что означает Back End и Front End, вам нужно изучить код. Начните развивать технические навыки и определите, что вам нравится в технической карьере. Веб-разработка — это всего лишь популярная отправная точка в карьере программиста, которая отличается от мобильной разработки.Вы можете дополнительно специализироваться, разрабатывая приложения для Android или iOS. Все зависит от ваших интересов и от того, чем вы хотите заниматься! Вам также стоит пройти наш курс по разработке программного обеспечения!

Полное руководство по работе с токенами | Curity

Обзор

В этом руководстве и видео объясняется, как запустить пример сквозного кода для одностраничного приложения (SPA), которое реализует OpenID Connect через шаблон обработчика токенов . Это обеспечивает Backend для Frontend (BFF) для SPA, а также обеспечивает очень четкое разделение проблем, связанных с вебом и API.Однако есть несколько движущихся частей, которые необходимо понять.

Традиционные одностраничные приложения

В последние годы стало обычным делом реализовывать OpenID Connect для SPA исключительно на Javascript. Это больше не рекомендуется, как описано в спецификации OAuth для приложений на основе браузера, по двум основным причинам:

• Использование токенов доступа в браузере имеет больше рисков для безопасности, чем использование безопасных файлов cookie, поэтому SPA должны вместо этого использовать файлы cookie с недавними улучшениями SameSite.
• Недавние изменения браузера для предотвращения отслеживания могут привести к отбрасыванию сторонних файлов cookie SSO во время традиционных потоков SPA, что приводит к блокированию проблем с удобством использования

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

Поведение SPA

В примере SPA будет использоваться обработчик маркеров Curity, который предоставляет дополнительные конечные точки REST API, для вызова сервера авторизации от имени SPA. Обработчик токена будет выпускать безопасные файлы cookie уровня приложения, которые можно использовать с сайта веб-источника SPA. Все полезные функции SPA будут поддерживаться и в сочетании с безопасностью браузера, эквивалентной безопасности веб-приложений:

• Рекомендуемая безопасность браузера
• Современный пользовательский интерфейс
• Простой код SPA
• Развернуть где угодно

Компоненты

Комплексное решение для SPA теперь включает пару дополнительных компонентов, показанных ниже:

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

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

Компоненты API Curity

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

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

Выполнить комплексное решение

Предварительные требования для установки

Сначала убедитесь, что у вас установлены и NodeJS, и Docker Desktop, поскольку эти компоненты будут использоваться для сборки и развертывания кода браузера и API.

Настройка доменов

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

Использование

Эти домены должны быть сначала добавлены в ваш файл / etc / hosts следующим образом:

  127.0. 0.1 localhost www.example.com api.example.com login.example.com
: 1 localhost  

Хостинг обработчика токенов

Для работы файлов cookie SameSite компоненты обработчика токенов должны размещаться в том же родительском домене, что и веб-источник SPA, а в примере кода используется значение `example.com`.

Получите код

Клонируйте репозиторий с помощью следующих команд:

  git clone https://github.com/curityio/web-oauth-via-bff
cd web-oauth-via-bff  

Затем просмотрите компоненты кода и обратите внимание, что все они требуют только простого кода. В статье Code Example описывается, как реализована работа OAuth для SPA.

Сборка кода

Затем запустите сценарий сборки, который компилирует код для всех компонентов и развертывает его в образы Docker:

Обратите внимание, что он также загружает и создает API обработчика токенов (агента OAuth) в коде , и вы можете изучить его код или при необходимости адаптировать его:

Предоставьте файл лицензии Curity Identity Server

Перед развертыванием системы вам понадобится файл лицензии для Curity Identity Server.Если у вас его нет, вы можете получить бесплатную лицензию сообщества на портале разработчиков Curity, войдя в свою учетную запись GitHub.

Компоненты Docker

Папка развертывания содержит всего следующие компоненты:

Все они развертываются на компьютере разработчика через файл Docker Compose :

Развертывание системы

Вся система может быть развернута с помощью следующих команд:

  cd deployment
./deploy.sh  

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

Перейдите к SPA

Затем вы можете перейти на http://www.example.com, чтобы запустить SPA, который первоначально будет представлять неаутентифицированный вид:

Затем вы можете войти в систему с помощью тестового пользователя demouser , используя пароль Password1 , после чего отобразится аутентифицированный вид.Затем SPA может загрузить информацию о пользователе из конечной точки userInfo обработчика токенов, а также может безопасно вызвать Пример API:

Просмотр с несколькими вкладками

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

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

Просмотр журналов

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

При устранении неполадок он может быть полезно для просмотра вывода журнала только определенного компонента в собственном окне терминала.Для этого можно использовать следующие стандартные команды Docker:

  export BFF_API_CONTAINER_ID = $ (docker container ls | grep bff-api | awk '{print $ 1}')
журналы докеров -f $ BFF_API_CONTAINER_ID  

  экспорт KONG_CONTAINER_ID = $ (docker container ls | grep reverse-proxy | awk '{print $ 1}')
docker logs -f $ KONG_CONTAINER_ID  

Обзор безопасности браузера

Поток OAuth веб-сайта

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

• Code Flow + PKCE, наряду с использованием секрета клиента
• Использование последних улучшений файлов cookie SameSite

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

Developer Setup

Веб-разработчикам необходимо запустить обработчик токенов на своей рабочей станции, и предпочтительный способ сделать это — использовать контейнер Docker. В будущем Curity ожидает предоставить разработчикам дополнительные возможности, такие как интеграция с Webpack Dev Server.

Сообщения OAuth

Обработчик токена возвращает поток кода авторизации + URL-адрес запроса PKCE в SPA со следующими параметрами:

  GET / oauth / v2 / oauth-authorize
    ? client_id = спа-клиент
    & redirect_uri = http% 3A% 2F% 2Fwww.example.com% 2F
    & response_type = код
    & code_challenge = k2XFDLJ_mIVEt25-phu4_3O4Jqrd8QqTGGbeEsql3Rc
    & code_challenge_method = S256
    & state = NlAoISfdL1DxPdNGFBljlVuB1GDjgGARmqDcxtHhV8iKNYu6ECS2KOavDHpI3eLN
    & scope = openid% 20profile  

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

  POST / oauth / v2 / oauth-token

grant_type = код_ авторизации &
client_id = спа-клиент &
client_secret = Password1 &
authorization_code = bMYnHhHHRFRnT7sbuPmqIzHpb8RFfqtg &
redirect_uri = http: // www.example.com/  

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

  POST / oauth / v2 / oauth-token

grant_type = refresh_token &
client_id = спа-клиент &
client_secret = Password1 &
refresh_token = 76fd951484a3d4cc31f869bb8fc93df ...  

Эти сообщения повышают безопасность более старых решений SPA, поскольку можно использовать секрет клиента и поскольку в браузере не используются токены.

Выдано безопасных файлов cookie

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

903 69

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

Обратите внимание, что источником SPA является www.example.com , но эти файлы cookie необходимо отправить только в домен API по адресу api.example.com , который находится на том же сайте . SPA не должен отправлять файлы cookie во время веб-запросов, поэтому рекомендуется ограничить объем cookie запросами API. Если у вас есть особые требования, домен cookie можно расширить до .example.com , а также отправлять во время веб-запросов. Однако обратите внимание, что это увеличивает потенциал для этого типа проблем с удобством использования:

• Пользователь подписывается в
• Пользователь переходит по электронной почте обратно в свой аутентифицированный сеанс
• Файл cookie удаляется, потому что это SameSite = strict
• Пользователь перенаправлен для повторной аутентификации снова

Параметры клиента OAuth

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

• https: // localhost: 6749 / admin
• Пользователь : admin
• Пароль: Password1

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

  
     спа-клиент 
     спа-клиент 
     SPA, использующий шаблон обработчика токенов 
     Секрет1 
     http: // www.example.com/ 
     openid 
     профиль 
    <аутентификация пользователя>
         http://www.example.com/ 
    
    <возможности>
        <код>
        
    
    
         спа-клиент 
    
     истина 
  

Безопасная разработка

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

Обзор безопасности API

Маршрутизация запросов API

После завершения аутентификации SPA выполнит вызовы API для доступа к данным, как описано в статье Пример кода . Ваши API-интерфейсы будут ожидать получения JWT, и обычный способ управления этим — через шаблон Phantom Token Pattern .

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

Поведение обратного прокси

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

  - name: business-api
  url: http: // apiserver: 3002
  маршруты:
  - имя: business-api-route
    пути:
    - / api

  плагины:

  - имя: bff-token
    config:
      encryption_key: NF65meV> Ls
      cookie_name_prefix: пример
      verify_csrf: true
      trust_web_origins:
      - http: // www.example.com
  
  - имя: фантом-токен
    config:
      точка_интроспекции: http: // curityserver: 8443 / oauth / v2 / oauth-introspect
      client_id: API-шлюз-клиент
      client_secret: Пароль1
      token_cache_seconds: 900
      trust_web_origins:
      - http://www.example.com  

Компоненты подключаемого модуля реализованы на облегченном языке сценариев LUA и запускаются в следующей последовательности:

Плагин прокси-сервера OAuth

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

Сквозной доступ к данным

Пример API, включенный в пример кода, требует действительного JWT для каждого запроса API и возвращает ошибку 401, если это не так. Приведенная ниже кнопка Get Data позволяет полностью протестировать вызовы API, и вы можете просмотреть журналы обратного прокси-сервера, чтобы увидеть используемые плагины:

Варианты развертывания

Настройка развертывания для примера кода состоит только из путь bff и единственный путь api , чтобы объяснить механизм маршрутизации.Реальные системы часто имеют дело с несколькими веб-доменами, несколькими типами клиентов или альтернативными техническими настройками.

Фирменные веб-домены

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

Выбор технологии обработчика токенов

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

• API на основе контейнера
• Бессерверная лямбда
• Плагин обратного прокси
• Расширение веб-хоста

Мы рекомендовали внедрять прокси OAuth в обратном прокси-сервере или шлюзе API, а не в собственном коде вашего API, поскольку эти компоненты имеют проверенную маршрутизацию и высокая пропускная способность.

Несколько типов клиентов

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

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

  - name: orders- api
  url: http: // apiserver: 3002
  маршруты:

  - имя: по умолчанию
    пути:
    - / api / orders
    плагины:
      - имя: фантом-токен

  - название: сеть
    пути:
    - / api / web / orders
    плагины:
      - имя: bff-token
      - имя: фантом-токен

  - имя: взаимное-tls
    пути:
    - / api / b2b / orders
    плагины:
      - имя: взаимное-tls
      - name: phantom-token  

Видео

Следующее видео наглядно показывает, как развернуть пример кода, затем использует развернутую систему и объясняет некоторые дополнительные детали:

Заключение

Мы продемонстрировали сквозное решение, где основные компоненты, которые разрабатывает компания, могут по-прежнему реализовываться простым и стандартным способом:

• Веб-приложения отправляют простые запросы REST к обработчику токенов для выполнения своей работы OAuth в манере, управляемой API
• Микросервисы продолжают проверять JWT в стандартный способ и не нужно иметь дело с куки-файлами

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

Давайте оставаться на связи!

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

Будьте в курсе наших последних статей и инструкций по RSS-каналам.

Внешняя и внутренняя веб-разработка

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

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

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

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

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

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

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

Front-end разработчикам необходимо знать:

• HTML5
• CSS
• JavaScript
• Ajax

Back-end разработчики должны знать:

• JavaScript
• SQL
• Ява
• C #
• Python

филиппинских песо

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

Интерфейсный веб-разработчик

Описание : интерфейсный веб-разработчик (иногда называемый веб-дизайнером) ориентирован на архитектуру веб-приложений, ориентированных на клиента.

Обязанности:

• Разработка новых пользовательских функций в веб-браузерах
• Разработка и реализация интерфейса для веб-сайтов сложных веб-приложений с использованием современных JS- и CSS-фреймворков Создание повторно используемого кода и библиотек для будущего использования
• Оптимизация клиентских приложений для максимальной скорости и масштабируемости
• Код для современных передовых практик REST или GraphQL

Заработная плата:

Навыки:

• Владеет HTML, CSS и JavaScript.
• Понимает клиентские сценарии и JavaScript-фреймворки, такие как jQuery

.

• Понимает принципы веб-дизайна
• Имеет базовые знания в области программного обеспечения графического редактора, такого как Photoshop

.

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

Описание: внутренний разработчик ориентирован на серверную архитектуру веб-приложений.

Обязанности:

• Разработка и реализация серверной веб-архитектуры, такой как серверы, базы данных, операционные системы и API
• Интеграция элементов, обращенных к пользователю, с логикой на стороне сервера
• Создание повторно используемого кода и библиотек для будущего использования
• Оптимизация серверных приложений для максимальной скорости и масштабируемости
• Внедрить решения для защиты данных

Заработная плата:

Навыки

• Владеет такими языками, как JavaScript (NodeJS), Ruby, Java, SQL и C #

.

• Имеет практические знания PHP, Ruby, Python и.Нетто
• Имеет практические знания серверных препроцессоров CSS, таких как LESS и SASS

.

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

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

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

[cta vid = «0»]

Все, что вам нужно знать

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

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

Интерфейс против серверной части: быстрый и грязный

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

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

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

Что такое CMS?

Инструмент, называемый системой управления контентом (CMS), преобразует языки веб-разработки в удобный интерфейс. WordPress, Drupal, Wix и Squarespace — самые популярные CMS на рынке в настоящее время.

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

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

Расширение на интерфейсе:

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

Подумайте о веб-сайте как о ресторане: HTML — это обеденные столы, столовое серебро и стулья; CSS — это атмосфера, декорации, музыка и краски; и Javascript — это официант.

Расширение на сервере:

Самыми популярными языками для серверной части являются PHP, Ruby, Python, SQL и Java.Эти языки предназначены для взаимодействия с базой данных веб-сайтов. Эти языки предназначены для хранения, извлечения и изменения конкретной информации, хранящейся в файлах данных.

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

Сколько нужно знать администратору?

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

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

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

Заключительные мысли

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

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

Введение

С появлением и успехом Интернета де-факто способ доставки пользовательских интерфейсов сместился с приложений для толстых клиентов на интерфейсы, доставляемые через Интернет. Эта тенденция также способствовала развитию решений на основе 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-интерфейсу, и многие команды используют их не только для мобильной разработки, но и для других целей. Простое ограничение количества поддерживаемых ими потребителей значительно упрощает работу с ними и их изменения, а также помогает командам, разрабатывающим ориентированные на клиентов приложения, сохранять большую автономию.

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

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

Front-End и Back-End Производительность

Когда посетитель попадает на ваш сайт — прежде чем контент волшебным образом появится в его браузере — он должен пройти через несколько
прикладные слои. Иногда мы вольно определяем эти уровни как «интерфейс» и «бэкэнд». Интерфейс
состоит из HTML, CSS, JS, изображений и т. д. Серверная часть — это инфраструктура и, в некоторых случаях, базы данных и
логика приложения, отвечающая за предоставление данных пользователю.

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

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

«Правило 80/20 веб-производительности»

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

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

Соотношение может выглядеть примерно так:

Пример соотношения

Это, кажется, подтверждает «Правило 80/20 веб-производительности», поскольку большая часть времени тратится на выборку, анализ,
и рендеринг внешних ресурсов.

Но подождите … производительность серверной части не постоянна!

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

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

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

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

Давайте посмотрим, что может произойти с общим временем отклика при увеличении пользовательской нагрузки (трафика):

Пример отношения

По мере того, как все больше одновременных пользователей начинают посещать сайт, серверная часть начинает замедляться.В этом примере при умеренной нагрузке соотношение больше не 80/20… больше похоже на 60/40.

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

Таким образом, соотношение времени, затрачиваемого на интерфейсную и внутреннюю части, может меняться в зависимости от нагрузки на сайт.

Снижение производительности серверной части даже не линейно!

Вопрос: Если вашему бэкэнду требуется 400 мс для возврата страницы, когда на сайте одновременно находятся 100 пользователей, как долго
потребуется ли это, когда на сайте одновременно будет 200 пользователей?

• А.400 мс
• Б. 800мс
• C. понятия не имеем

Правильный ответ — C. Может возникнуть соблазн сказать, что серверная часть займет одни и те же 400 мс независимо от нагрузки.
Или можно предположить, что это займет 800 мс (в два раза дольше при двойной нагрузке). Но правда в том, что никто не знает впереди
времени, сколько времени это займет, потому что взаимосвязь между параллелизмом и временем отклика сложна и
нелинейный.

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

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

Пример соотношения

После того, как узкое место в серверной части устранено, такие обобщения, как «Правило 80/20 веб-производительности», больше не
подать заявление.

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

Как подготовить свой сайт к событию с высокой посещаемостью?

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

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

Моделирование события с интенсивным движением

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

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