Бэкенда – принципы и отличия — статьи на Skillbox

Как разделить фронтенд и бэкенд, сохранив взаимопонимание / ISPsystem corporate blog / Habr

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

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

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

Предыстория

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

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

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

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

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

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

Для какого-то абстрактного нового проекта этого будет достаточно, но у нас уже было написанное приложение, а объёмы планируемых работ и сроки их реализации явно указывали, что одной командой обойтись не получится. В баскетбольной команде пять человек, в футбольной — 11, а у нас было около 30. Под идеальную скрам-команду из пяти — девяти человек это никак не подходило. Надо было разделиться, но как при этом сохранить связность? Чтобы сдвинуться с места, нужно было решить архитектурную и организационную проблемы.

«Всё сделаем в одном проекте, так будет удобнее» — говорили они…

Архитектура

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

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

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

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

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

Повысили устойчивость, разделив зоны ответственности.

Коммуникации

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

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

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

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

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

API

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

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

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

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

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

Другим распространённым решением является GraphQL. Он тоже не идеален, но в отличие от REST, GraphQL API — это не просто описательная модель, а настоящие правила.

Выше я говорил про систему, которая должна была согласовывать работу фронтенда и бэкенда. Прослойка (interlayer) — это именно тот промежуточный уровень. Рассмотрев возможные варианты работы с сервером, мы остановились на GraphQL в качестве API для фронтенда. Но, так как бэкенд написан на C++, то реализация GraphQL-сервера оказалась нетривиальной задачей. Не буду здесь описывать все возникшие сложности и ухищрения, на которые мы шли, чтобы их преодолеть, реального результата это не принесло. Посмотрели на проблему с другой стороны и решили, что простота — залог успеха. Поэтому остановились на проверенных решениях: отдельный Node.js сервер с Express.js и Apollo Server.

Далее нужно было решить, как обращаться к API бэкенда. Сначала смотрели в сторону поднятия REST API, потом пробовали использовать аддоны на C++ для Node.js. В итоге поняли, что это всё нам не подходит, и после подробного анализа для бэкенда выбрали API на базе gRPC-сервисов.

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

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

Общая схема работы после изменения архитектуры

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

Результат

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

1. За отображение отвечает фронтенд, а за данные — бэкенд.
2. На фронтенде сохранилась гибкость в плане запросов и получения данных. Интерфейс знает, что можно попросить у сервера и какие ответы должны быть.
3. На бэкенде появилась возможность менять код с уверенностью, что интерфейс у пользователя продолжит работать. Стал возможным переход на микросервисную архитектуру без необходимости переделывать весь фронтенд.
4. Появилась возможность использования mock-данных для фронтенда, когда ещё не готов бэкенд.
5. Создание схем совместной работы исключило проблемы взаимодействия, когда команды понимали одну и ту же задачу по-разному. Сократилось количество итераций по переделке форматов данных: действуем по принципу «семь раз отмерь, один раз отрежь».
6. Появилась возможность планировать работы на спринт параллельно.
7. Для реализации отдельных микросервисов теперь можно набирать разработчиков, не знакомых с C++.

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

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

Здесь я поверхностно затронул вопросы командной и межкомандной работы над одним продуктом, выбор технологи API (REST vs GraphQL), связь Node.js приложения с C++ и т. д. Каждая из этих тем тянет на отдельную статью, и если вам будет интересно, то мы их обязательно напишем.

habr.com

13 инструментов крутого backend-разработчика — подборки на Skillbox

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

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

Как выглядят Frontend и Backend на самом деле. Источник

Минимум, который должен знать и уметь разработчик:

1. Владеть языком программирования, например PHP.
2. Работать с базой данных, например MySQL.

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

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

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

По сути это виртуальная машина с широкими возможностями. Физически Vagrant находится на компьютере, но воспринимается не как локальный сервер. Разработчик подключается к нему не по localhost, а по другому IP, который он сам прописывает. Vagrant не зависит от системы: можно взять эту сборку, перенести на другую машину, и всё будет работать в том же режиме. Это более гибкое и удобное решение для организации веб-сервера.

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

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

Теоретически код можно писать где угодно, даже в блокноте. Однако для удобства давно придуманы системы, где работает автоподстановка, можно заниматься дебагом (подсказка: Процесс отладки кода) и использовать массу иных возможностей. Такая программа называется IDE — интегрированная среда разработки, или редактор кода.

Для работы с PHP рекомендуем две IDE:

Основное преимущество — это бесплатная система. Однако NetBeans съедает много памяти во время работы и не такой прогрессивный, как редактор ниже.

Очень удобный интеллектуальный редактор от компании JetBrains. Обладает отличной автоподстановкой и продвинутой системой семантического анализа. Программист допустил опечатку — анализатор тут же показывает, где именно. Незаменимый инструмент для веб-разработчика на PHP.

Краткое, но исчерпывающее введение в PhpStorm от официального разработчика.

Недостаток PhpStorm только в том, что он платный: можно оформить подписку за $199 на год. Через12 месяцев последняя версия остается у вас навсегда, но обновить ее без оплаты нового периода использования не получится.

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

Советуем два варианта, превосходящие MyAdmin по характеристикам:

1. SQLyog.
2. Navicat.

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

Советуем программу Postman, где можно протестировать их в удобном интерфейсе. Нужно просто вбить url и параметры, чтобы разработчику вернулся ответ в трех форматах: как запрос выглядит на сайте, в JSONJavaScript Object NotationТекстовый формат обмена данными на JavaScript. и в текстовом виде. Postman невероятно удобен и очень облегчает разработку API.

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

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

Для этого рекомендуем две системы:

 1. GitKraken — платная программа. Предназначена для операционных систем Ubuntu, macOS.

Источник

 2. Tortoise — удобная программа для Windows, правая рука backend-разработчика.

Еще один вариант кроссплатформенного версионизатора — решение от Atlassian. Компания предлагает нескольких передовых и надежных продуктов для разработки, поддержки, управления кодом и рабочими задачами — не только техническими. Конкретно для работы с Git есть бесплатный клиент Sourcetree. Его можно использовать, если по каким-либо причинам GitKraken и Tortoise не подходят.

Интерфейс клиента Sourcetree от Atlassian

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

Предлагаем три лучших репозитория на выбор:

1. Bitbucket — можно использовать бесплатно командой до пяти разработчиков. Для растущих и больших компаний предлагает варианты по2 и 5 долларов в месяц за одного пользователя соответственно.
2. GitLab — доступен бесплатно с ограниченным функционалом. Платные тарифы начинаются от4 долларов за пользователя ежемесячно.
3. GitHub — пожалуй, самый крупный и известный сервис для совместной разработки. Бесплатен для проектов с открытым исходным кодом и предлагает платные тарифы для корпоративных команд.

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

Курс «PHP-разработчик»

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

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

skillbox.ru

Бэкенд для фронтенда, или Как в Яндекс.Маркете создают API без костылей

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

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

Симптомы проблемы

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

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

Вы смотрите на документацию и видите это:

№   |  Имя параметра
----------------------
53  |  feed_shoffed_id
54  |  fesh
55  |  filter-currency
56  |  showVendors

Не замечаете ничего странного? Camel, Snake и Kebab Case в рамках одной ручки. Я уже не говорю про параметр fesh. Что вообще такое fesh? Такого слова даже не существует. Попробуйте догадаться до того, как раскроете спойлер.

Спойлер

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

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

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

result: [
   {id: 1, name: 'IPhone 8'},
   {id: 2, name: 'IPhone 8 Plus'},
   {id: 3, name: 'IPhone X'},
]

result: {id: 1, name: 'IPhone 8'}

result: null

Если товары найдены — получаем массив. Если найден один товар, то получаем объект с этим товаром. Если ничего не найдено, то в лучшем случае получаем null. В худшем случае бэкенд отвечает 404 или вообще 400 (Bad Request).

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

Итак, какие могут быть пути решения этой проблемы? Что мы как фронтендеры можем сделать на своей стороне, чтобы работать с API приемлемого качества?

Бэкенд для фронтенда

Мы в партнерском интерфейсе используем на клиенте React/Redux. Под клиентом лежит Node.js, который делает много вспомогательных вещей, например прокидывает на страницу InitialState для Редакса. Если у вас сервер-сайд рендеринг, не важно с каким клиентским фреймворком, скорее всего, он рендерится нодой. А что, если пойти на шаг дальше и не обращаться с клиента напрямую в бэкенд, а сделать свое проксирующее API на ноде, максимально заточенное под клиентские нужды?
Эту технику принято называть BFF (Backend For Frontend). Впервые этот термин ввел SoundCloud в 2015 году, и схематично идею можно изобразить в таком виде:

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

Это касается не только примитивных get-запросов, а вообще всех запросов, в том числе с multipart/form-data. Например, магазин через форму на сайте загружает .xls-файл со своим каталогом. Так вот, в этой реализации каталог загружается не напрямую в API, а в вашу нодовскую ручку, которая проксирует stream в настоящий бэкенд.

Помните тот пример с result-ом, когда бэкенд возвращал null, массив или объект? Теперь мы можем привести его к нормальному виду — чему-нибудь вроде такого:

function getItems (response) {
   if (isNull(response)) return []
   if (isObject(response)) return [response]
   return response
}

Этот код выглядит ужасно. Потому что он ужасен. Но нам все равно нужно это сделать. У нас выбор: делать это на сервере или на клиенте. Я выбираю сервер.

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

query: {
   'feed_shoffer_id': 'feedShofferId',
   'pi-from': 'piFrom',
   'show-urls': ({showUrls = 'offercard'}) => showUrls,
}

Какие еще плюсы мы получаем?

1. Фильтрация. Клиент получает только то, что ему нужно, ни больше ни меньше.
2. Агрегация. Не нужно тратить клиентскую сеть и батарею, чтобы делать множественные аякс-запросы. Заметный выигрыш по скорости за счет того, что открытие соединения — это дорогая операция.
3. Кэширование. Ваш повторный агрегированный вызов не будет лишний раз никого дергать, а просто вернет 304 Not Modified.
4. Сокрытие данных. Например, у вас могут быть токены, которые нужны между бэкендами и не должны попадать на клиент. У клиента может не быть прав даже знать о существовании этих токенов, не говоря уже об их содержимом.
5. Микросервисы. Если у вас на бэке монолит, то BFF — это первый шаг к микросервисам.

Теперь о минусах.

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

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

GraphQL

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

При этом GraphQL может работать поверх REST, т. е. источником данных служит не база, а рестовое API. За счет декларативности GraphQL, за счет того, что все это дружит с Реактом и Редаксом, ваш клиент становится проще.

На самом деле, GraphQL мне видится реализацией BFF со своим протоколом и строгим языком запросов.

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

Best Friends Forever

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

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

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

Обратите внимание на дату коммита. Получается совсем недавно fesh отметил свое семнадцатилетие.

Видите какие-то странные идентификаторы слева? Это SVN, просто потому что в 2001 году гита не было. Не гитхаба как сервиса, а именно гита как системы управления версиями. Он появился только в 2005 году.

Документация

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

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

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

Swagger

Хороший вариант для документации API — формат Swagger, сейчас он называется OpenAPI. Лучше использовать Swagger в YAML-формате, т. к., в отличие от JSON, он лучше читается человеком, а для машины разницы нет.

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

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

Итак, вы собрались, написали Swagger, таким образом фактически подписали контракт. С этого момента вы как фронтендер можете начинать свою работу, не дожидаясь создания реального API. Ведь в чем был смысл разделения на клиент и сервер, если мы не можем работать параллельно и клиентским разработчикам приходится ждать серверных разработчиков? Если у нас есть «контракт», то мы можем спокойно параллелить это дело.

Faker.js

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

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

Валидация

Swagger можно сконвертировать в json-схему, и с помощью таких инструментов как ajv вы можете прямо в рантайме, в своем BFF, валидировать ответы бэкендов и в случае расхождений репортить тестировщикам, самим бэкендерам и т. д.

Допустим, тестировщик находит на сайте какой-то баг, например при клике на кнопку ничего не происходит. Что делает тестировщик? Ставит тикет на фронтендера: «это ведь ваша кнопка, вот она не нажимается, чините».

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

Выводы

1. Принимаем активное участие в проектировании API. Проектируем API так, чтобы им было удобно пользоваться через 17 лет.
2. Требуем Swagger-документацию. Нет документации — работа бэка не выполнена.
3. Есть документация — публикуем ее в git, при этом любые изменения в интерфейсе API должны апрувиться представителем фронт-команды.
4. Поднимаем фейковый сервер и начинаем работать над фронтом не дожидаясь реального API.
5. Кладем ноду под фронтенд и валидируем все ответы. Плюс получаем возможность агрегировать, нормализовать и кэшировать данные.

См. также

→ Как построить REST-like API в крупном проекте
→ Backend In the Frontend
→ Using GraphQL as BFF Pattern Implementation

habr.com

где учиться, зарплата, плюсы и минусы

Профессия Бэк-энд разработчик: где учиться, зарплата, плюсы и минусы

• Выбор профессии

  8, 9, 10, 11 класс

  • Всесторонний анализ личности и способностей ребёнка
  • Точный выбор подходящей жизнеспособной профессии
  • Подбор вуза или колледжа в России и за рубежом
  • Пис

www.profguide.io

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. HTML
2. CSS
3. JavaScript

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

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

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

proglib.io

Пишем backend для мобильного приложения за несколько минут / Habr

Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.

За исходные данные были приняты: знание что такое HTTP, REST, JSON и начальный уровень разработки на Python (Django).
И вот на днях, на глаза попался небольшой проект, на котором можно было провести полевые испытания. Суть проекта — приложение для одного мероприятия. Нужно отображать спикеров и их доклады.
После непродолжительных поисков, за основу были взяты следующие инструменты: Python (как основной язык разработки), Django (как базовая платформа) и фреймворк Tastypie (представленный как фреймворк для создания API веб-сервисов). Итак, приступим.
Создаем шаблон приложения Django:

python django-admin.py startproject EventApp

В настройках файла settings.py прописываем необходимые настройки для базы данных, локализацию, время. Устанавливаем пакет tastypie:

pip install django-tastypie

Обратите внимание, что требуется Python2.6+ и Django 1.5+. Из-за незнания этого факта пришлось потратить немного больше времени, т.к. фреймворк отказывался работать. Кроме того, нужно установить аналогичным образом пакет python-mimeparse.
Далее, в файле settings.py, прописываем:

INSTALLED_APPS += ['tastypie']

или добавляем уже в существующий список приложение ‘tastypie’.
Теперь пропишем модели нашей предметной области:

# -*- coding: utf-8 -*-
from django.db import models


class Speaker(models.Model):
    name = models.CharField(max_length=32)
    company = models.CharField(max_length=32)
    photo = models.ImageField(upload_to='photos', blank=True, null=True)

    def __unicode__(self):
        return self.name + ' (' + self.company + ')'


class Event(models.Model):
    title = models.CharField(max_length=64)
    speaker = models.ForeignKey(Speaker, blank=False, null=False)
    start_time = models.TimeField()
    end_time = models.TimeField()

    def __unicode__(self):
        return self.title + ' (' + self.speaker.name + ')'

Мы написали модель докладчика (Speaker) и модель выступления (Event). У каждого выступления обязательно есть докладчик. Теперь, сделаем так, чтобы мы могли полноценно работать с нашими моделями как с ресурсами через REST протокол.
Создаем в нашем приложении пакет api и файлом resources.py (или можно его создать в основном пакете).

from tastypie.resources import ModelResource
from EventApp.models import Speaker, Event


class SpeakerResource(ModelResource):
    class Meta:
        queryset = Speaker.objects.all()
        resource_name = 'speaker'


class EventResource(ModelResource):
    speaker = fields.ForeignKey(SpeakerResources, 'speaker', blank=True, null=True)
    class Meta:
        queryset = Event.objects.all()
        resource_name = 'event'

В этом файле мы создали классы, так называемых ресурсов, основных объектов в нашем REST сервисе. Это как раз те ресурсы, к которым мы будем обращаться. Каждый класс содержит ссылку на ту модель, которую он представляет. Поле queryset возвращает нам набор объектов получаемых из базы при обращении к даному ресурсу. Поле resource_name необязательно, и позволяет нам указать дополнительно наименование ресурса, по которому он будет доступен нам.
Еще один момент, в классе EventResources мы указали отдельное поле speaker, которое указывает что ресурс события ссылается на ресурс спикера.
Теперь осталось только прописать в файле urls.py обращения к нашему сервису. Это делает очень просто.

from django.conf.urls.defaults import *
from tastypie.api import Api
from api.resources import EventResource, SpeakerResource

v1_api = Api(api_name='v1')
v1_api.register(SpeakerResource())
v1_api.register(EventResource())

urlpatterns = patterns('',
    (r'^api/', include(v1_api.urls)),
)

Теперь запускаем наш проект

python manage.py runserver

Теперь, если сервер успешно запустился, открыв в браузере страницу по адресу http://localhost:8000/api/entry/?format=json, увидим там что фреймворк видит все наши ресурсы и отобразил нам схему нашего сервиса:

{
  "events": 
  {
    "list_endpoint": "/api/v1/events/"
    , "schema": "/api/v1/events/schema/"
  }
  ,"speakers": 
  {
    "list_endpoint": "/api/v1/speakers/"
    ,"schema": "/api/v1/speakers/schema/"
  }
}

Параметр format принудительно указывает в каком формате мы хотим получить данные, но вместо него можно в запросе указать заголовок Content-type: application/json. Кроме JSON поддерживаются xml, yaml, bplist.
По адресу schema можно посмотреть описание структуры модели (поля, типы и описание), а по адресу list_endpoint можно уже получить наши ресурсы, которые мы предварительно записали в базу.
Теперь, открыв адрес http://localhost:8000/api/v1/events/?format=json мы увидим там что-то вроде этого:

{
  "meta": 
  {
    "limit": 20
    ,"next": null
    ,"offset": 0
    ,"previous": null
    ,"total_count": 4
  }
  ,"objects": [
  {
    "id": 3
    ,"speaker": "/api/v1/speakers/2/"
    ,"start_time": "08:39:25"
    ,"end_time": "18:39:29"
    ,"title": "Ранее что нибудь"
    ,"description": "описание"
  }
  ]
}

Как видим — ничего сложного. В разделе meta выводится основная информация о ресурсе: количество записей, размер выдачи и тд. Одновременно мы можем обратиться к конкретному событию, обратившись к ресурсу по его id — http://localhost:8000/api/v1/events/1/
Можем создать запись выполнив POST запрос и передав в него объект в JSON формате, обновить запись PUT запросом и удалить с помощью DELETE.
Так же, в tastypie у класса ModelResource есть большой набор переопределяемых полей и методов, с помощью которых мы можем полностью изменить структуру выдаваемых данных. Например, мы хотим вместо ссылки на спикера, сразу получать его имя, чтобы не делать лишний запрос. В классе EventResource переопределяем метод dehydrate:

    def dehydrate(self, bundle):
        try:
            speaker = Speaker.objects.filter(id=bundle.obj.speaker.id)
            bundle.data['speaker_name'] = speaker[0].name
        except Speaker.DoesNotExist:
            pass
        return bundle

В нем, мы находим спикера в базе и подставляем его в объект bundle, который представляет из себя словарь который отдается ресурсом. Теперь, ответ на запрос будет выглядеть так (напишу только основную часть):

{
  "id": 3
  ,"speaker": "/api/v1/speakers/2/"
  ,"speaker_name": "Василий"
  ,"start_time": "08:39:25"
  ,"end_time": "18:39:29"
  ,"title": "Ранее что нибудь"
  ,"description": "описание"
}

Что нам и требовалось! Кроме того, запрос к ресурсу можно сделать с параметрами для фильтрации.
Например, нам надо выбрать все события для одного докладчика. Логичен был бы следующий запрос:
http://localhost:8000/api/v1/events/?speaker=1 который вернет нам события, спикерами которых является спикер с id = 1. Необходимо только прописать в meta класс ресурса еще одно поле:

        filtering = {
            'speaker': ALL_WITH_RELATIONS
        }

Заключение

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

habr.com

Что такое современная backend разработка

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

О бэкенде подробнее

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

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

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

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

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

Кто же такой бэкэндер?

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

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

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

• Умеет писать код без каких-либо затруднений
• Знает такие фреймворки, как Django, Flask, Spring, а возможно, какие-либо другие
• Может организовать удобную систему хранения данных
• Оптимизирует потоки поступающей информации
• Знает современные паттерны, парадигмы и матрицы программирования
• Четко представляет устройство веб-сайтов, веб-сервисов и т.п.
• Владеет английским языком свободно, т.к. это пригождается при кодировании и чтении технической документации и прочих рабочих моментах

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

webshake.ru