Что лучше рекламировать – фронтенд или бэкенд?

Содержание

Простыми словами о «фронтенде» и «бэкенде»: что это такое и как они взаимодействуют

Рассказывает Хьюго Ди Францеско, веб-разработчик

Вы наверняка уже слышали эти модные в сфере программирования слова «фронтенд» и «бэкенд», но что за ними стоит? Предлагаю в этом разобраться.<\p>

Давайте начнем с определений.

Фронтенд — все, что браузер может читать, выводить на экран и / или запускать. То есть это HTML, CSS и JavaScript.

HTML (HyperText Markup Language) говорит браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка».

CSS (Cascading Style Sheets) говорит браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana».

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

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

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

Это означает, что вы можете использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript / Node, bash.

Это также означает, что вы можете использовать системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Структура взаимодействия бэкенда и фронтенда

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

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).

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

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML).

Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ.

Сейчас для ответов также можно использовать формат JSON.

Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения

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

Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения

Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.

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

Вне фронтенда и бэкенда

Автономный фронтенд

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

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

Легкий бэкенд

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

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

Размытые границы

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

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

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

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

Перевод статьи «In simple terms: backend code, frontend code and how they interact»

Мая Устинова, мастер клавиатуры

Источник: https://tproger.ru/translations/frontend-backend-interaction/

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

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

Давайте начнем с определений.

Фронтенд

Все, что браузер способен воспринять, отобразить и/или запустить. То есть HTML, CSS и JavaScript.

HTML (Hypertext Markup Language, язык разметки гипертекста) говорит браузеру, что он должен отобразить, например, заголовок, абзац, список, элемент списка и так далее.

CSS (Cascading Style Sheets, каскадные таблицы стилей) отвечают за то, как выглядят элементы: «отступ после первого абзаца равен 20 пикселям», «весь текст в body должен быть темно-серым».

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

Бэкенд

Все, что происходит на сервере (другими словами «не в браузере» или «на компьютере, подключенном к сети, как правило, к Интернет, и отвечающем на запросы пользователей»).

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

Можно воспользоваться любым языком программирования общего назначения, таким как Ruby, PHP, Python, Java, JavaScript/Node, bash.

Также у вас есть возможность развернуть сервер баз данных, например, MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Точки соприкосновения

Система прямых HTTP-запросов к server-rendered приложению заключается в том, что браузер отправляет HTTP-запрос, а сервер отвечает HTML-страницей.

Между получением запроса и ответом на него, сервер обычно обращается к базе данных и генерирует страницу с помощью шаблонизатора (ERB, Blade, EJS, Handlebars). В открытой браузером странице HTML отвечает за то, что в ней содержится, CSS за то, как это выглядит, а JS — за взаимодействие пользователя с контентом.

Коммуникация с использованием AJAX

Аббревиатура AJAX расшифровывается как Asynchronous JavaScript and XML (асинхронный JavaScript и XML). Эта технология основывается на отправке HTTP-запросов JavaScript-кодом со страницы. Исторически ответ поступал в XML, сегодня же он преобразился в более удобный JSON.

AJAX подразумевает, что ваш сервер имеет некую конечную точку, отвечающую на запросы XML или JSON-ами. Два примера отвечающих за это протоколов — REST и SOAP.

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

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

Универсальные/изоморфные приложения

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

Между фронтендом и бэкендом

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

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

Легковесный бэкенд

Параллельно бэкенд становится все более и более легким. Такие технологии как хранилища документов и графовые базы данных подразумевают довольно вялую активность повторной агрегации данных на стороне сервера. Ответственность за определение, какие данные требуются (графовые БД) и как вытащить все необходимые их фрагменты (REST API) ложится на клиентскую сторону.

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

Стирание границ

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

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

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

Оригинал

Другие статьи по теме

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

Освоить основы фронтенда за 12 часов: большая видеоподборка

Источник: https://proglib.io/p/frontend-backend-in-simple-words/

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

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

Для меня: backend — серверная часть (работа с БД, обработка данных, и т.д.), вообщем все, чего клиент не видит.

frontend — все что видит клиент (верстка, JS скрипты, флеш и т.д.)

Очень часто я вижу сообщения с очередными «велосипедами» как разделить фронтенд часть от бекенд части (мухи отдельно, котлеты отдельно).

Не так давно в одной из статей на Хабре предлагали фронтенд делать XSLT файлами (аля как в Java), еще раньше все ударились в MVC архитектуру. Но мне это все не нравится и я сейчас объясню почему.

1. Мне _не_ нравится что вьюхи лежат в проекте (да, я плохой backend dev и редко хочу копаться в вьюхах). 2. Мне _не_ нравится что я преобразовываю корректные данные чтоб они «красиво легли в вьюху».

3. Мне _не_ нравится что вообще связан фронтенд и бекенд.

Вам тоже это не нравится? Тогда вам подкат.

Начало

Года 4 назад я впервые увидел MVC архитектуру и не мог нарадоваться. Как же хорошо что все было разбросано по разным папкам и теперь понятно куда и зачем смотреть. Радость длилась недолго.

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

А все что преобразовывает данные для вьюх — в либы. Удивился, но вроде они умнее и я начал писать как они. И мне это надоело.

Я начал искать аналоги MVC прекрастно понимая что это не silver bullet, и явно кто-то придумывал что-то еще. Скажу сразу, все что я нашел меня всеравно не устроило на 100%, но об этом ниже.

MVC? XSLT ?

Чем мне не понравился MVC: 1. Если у вас больше 1000 вьюх — вы застрелитесь их поддерживать. 2. Вьюхи лежат в проекте 3. С выходом новых и новых шаблонизаторов возникнет желание с ними «поиграться» 4. Любой рефакторинг в модели/контролере может привести к тому, что вьюха не получит каких-то данных.

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

Да, XSLT немного более «жестко» позводяет держать под контролем ситуацию и не создавать код вида:

Я думаю Вы такое видели очень часто в своих вьюхах.

И тут возникает вопрос — «А что делать ?».

Ответ оказался не такой и сложный, благо его используют повсеместно уже лет 5, а может и больше — AJAX.

AJAX? Silver bullet ?

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

Нет, это не silver bullet и я объясню дальше почему, но для начала давайте просто посмотрим что нам дает отказ от MVC в строну аякс-приложения.

1. Вся фронтенд часть может спокойно лежать отдельно (другая репа, другой сервер, да что угодно).
2. Рефакторить все еще сложно (хотя есть решения с версионностью, если будет интересно я о них расскажу в следующих раз). Но если в методе в ***Doc блоке писать что мы передаем то рефакторить уже проще.

/**
* @return array(
'id' – int ID of item
'title' – string title of item
'link' – string link of item
)
*/
function test(){
// something
return $data;
}

3. Разделенный бекенд и фронтенд.
4. Возможность добавить еще варианты выдачи информации (ниже я покажу как).

JSON? XML? Да не проблема

На самом деле для AJAX все мы сейчас в 90% используем JSON. Это очень хорошо и им приятно пользоваться (спасибо создателям).

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

И мы начинаем писать много кода и вьюх чтоб выдавать XML для этого приложения (Я ж надеюсь Вы согласны с тем, что нужен именно XML который будем парсить SAX парсерами а не JSON ?).

Давайте рассмотрим как можно сделать простенький контролер который будет выдавать данные в любом формате

class Controller{ /** */ public function test(){ /** Да, я не сторонник создавать объекты в методах и считаю что в 99% можно отлично использовать фабрику с Service Layer. Это мое мнение, извините. */ $model = SL::get('Model'); $data = $model->getData(); $this->_view($data); } /** Собственно это и есть основная функция. Она и отдает контент в тех видах, которые нам нужны. */ private function view($data){ $format = $_SERVER[“CONTENT_TYPE”]; switch($format){ case “XML”: SL::get('ViewRepresentation')->asXML($data); break; case “JSONP”: SL::get('ViewRepresentation')->asJSONP($data); break; default: SL::get('ViewRepresentation')->asJSON($data); break; } }
}

Как только у нас появятся еще 10/20/30/… и т.д. разных форматов добавить их будет не проблема.
Таким образом все данные на выходе это XML/JSONP/JSON. Никаких проблем при работе с ними быть не должно. И если завтра прийдет клиент и захочет SOAP — ну добавите еще один тип данных на выходе.

Проблемы

Да, как же без них.

Версионность

Вам нужна будет верисонность. Ёё можно придумать самому или почитать материалы о том, как создавать версионные API (возможно напишу об этом в следующей статье)

SEO

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

Не дадут по одной причине — поисковые гиганты не хотят платить деньги и писать JavaScript эмуляторы для своих пауков.

И если ничего меняться не будет — мы так и будем сидеть с тем, чтоб отдавать паукам уже полностью готовые странички (ну да, паукам же легче жить с этим …)

CMS/CMF

Никогда ниодна CMS/CMF система не перейдет на AJAX. Просто потому что это потребует переписать больше половины кода и еще огромное количество времени пересматривать архитектуру.

Итог

Как итог могу сказать одно. Варианты как разграничить frontend и backend есть. Многие фирмы их используют (ФБ, ВК передает JS скрипты, еще часть сайтов — JSONP, для мобильных клиентов делают отдельный вход с XML форматом).

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

Updated

Почему нужно разграничивать frontend и backend ?

Сразу отвечу. Если например завтра вы увидите что 1 страница из ваших 8000 страниц стала отдаваться медленно и захотите переписать какойто блок этой страницы например на Java / C# / etc. то Вам не нужно будет разбираться с тем, как не поломать всю оставшуюся страницу. Она просто будет получать тотже JSON только уже с другого ЯП, что по моему мнению очень правильно.

Gron

Источник: http://www.pvsm.ru/php-2/10110

Backend vs Frontend

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

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

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

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

В веб-приложениях условно считается, что front-end — это всё, что пришло с веб-сервера в браузер (ещё называют «клиентская сторона»), а то, что работает на сервере, считается back-end. Могу сказать, что деление это очень условное, потому что и на стороне сервера, и в браузере может быть как front-end, так и back-end.

Примеры:

Gmail пытается восстановить связь и отправить мои письма

Исходный код страницы вКонтакте

1. Онлайн-клиент электронной почты Gmail. Если написать письмо и нажать «Отправить» во время сбоя подключения к Интернет, то письмо не отправится, но и не потеряется. Оно пропадёт с экрана, но где-то внутри программного кода, который сейчас загружен в бразер, есть невидимая часть, которая раз за разом пытается отправить письмо, пока это не удастся. Получается, клиентская часть содержит back-end для фоновой отправки запросов на сервер.
2. Популярный сервис .com. Страницы сформированы на сервере. И там разделение на две части, одна из которых нашла запись в базе данных, а другая сделала из этой записи фрагмент HTML, то есть создала фрагмент будущего интерфейса пользователя, который позже отобразится в браузере. На сервере тоже может быть front-end, который формирует данные для непосредственного отображения пользователю после передачи в браузер и back-end, который, например, работает с базой данных.

Такое деление делает веб-разработку проще и быстрее. Двумя частями могут заниматься два программиста. Пример на диаграмме Гантта и доске Канбан.

Параллельная работа двух программистов на частями back-end и front-end

Разделив две задачи на четыре (Задача 1.1 + Задача 1.2, Задача 2.1 + Задача 2.2), можно делать их так, что части фронтенд и бакенд будут реализованы последовательно в рамках одной задачи (сначала Задача 1.1, потом 1.2, потом 2.1, потом 2.2), но параллельно для двух разных задач (Задача 1.2 и Задача 2.1).

Кроме разделения работы по времени важно также разделение разработчиков по специализациям. Когда-то за весь сайт мог отвечать один человек. Он и страницы в Dreamweaver набросает, и тексты с картинками на сайт выложит и хостингом займётся.

А сейчас в веб-технологиях настолько большое разнообразие, что одному человеку стало очень трудно знать всё. Поэтому появились разработчики для front-end и разработчики для back-end. Универсалов, которые знают обе части, называют «комбайны» или «full-stack developer«.

Замечу, что фронтенд разработка тоже может быть разделена: на вёрстку и непосредственно программирование.

Разделение кода приложения на базе фреймворка Yii на админку и фронт

И есть ещё одно деление на front/back в веб-разработке.

Если веб-проект подразумевает разный интерфейс для разных типов пользователей, то front — это всё что доступно обычным пользователям, а back — это то, что доступно администраторам, модераторам и службе поддержки (условно называется «админка» или «панель администратора»). Вот, к примеру, старый, но наглядный пример создания приложения на базе фреймворка Yii с делением на панель администратора и панель пользователя: Способ разделения front-end/back-end-частей в Yii.

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

  • панель клиента
    • серверное программирование: node.js, RabbitMQ, memcached, PHP, Python, Ruby, база данных и другое
    • клиентское программирование: JavaScript Ruch Client Application на базе Angular, LESS, SCSS и других технологий
  • панель администора
    • серверное программирование: ещё больше, чем в панели клиента
    • клиентское программирование: значительно более простой, чем в панели клиента, например HTML + CSS + jQuery UI

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

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

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

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

Источник: https://copist.ru/ru/blog/2015/08/26/backend-vs-frontend/

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

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.