Из фронтенда в бэкенд / QIWI corporate blog / Habr
К переходам внутри департаментов иногда относятся по-разному. Кому-то просто привычнее видеть любые карьерные изменения внутри одной компании через призму роста должностей. Кто-то не считает возможным сменить сферу деятельности, даже если она смежная с текущей. Третьи же в принципе уверены, что переход из департамента в департамент означает, что человек занимает позицию “ни рыба, ни мясо”, и вряд ли добьётся чего-то значимого.
При этом некоторые работодатели всячески это приветствуют и считают чем-то вроде предохранителя от выгорания – человек сменит фокус внимания, сменит департамент или отдел, но не сменит саму работу в целом.
Меня зовут Костя, и я работаю в QIWI почти 4 года. Сегодня расскажу вам, как успешно перешел из frontend-разработки в backend.
Frontend
В QIWI я с конца 2014 года, начинал работать как разработчик iOS–приложений, и, в принципе, пару лет занимался разработкой QIWI-кошелька. При этом не могу сказать, что было скучно – задачи были довольно разные и в рамках одного приложения: мы занимались интеграцией кошелька с другими нашими сервисами, чинили баги, подтягивали анимацию. Кроме этого, был занятный опыт по созданию приложения для Apple Watch. Потом немного расширил фокус и поработал еще и над iOS-приложением для «Совести».
И вот примерно тогда я начал потихоньку переходить в бэк. В плане гибкой методологии это даже удобно – я переключался, в первом спринте мог делать какие-то задачки по бэкенду, а во втором проводить интеграцию API, которое я же и написал.
Но в бэкенде на то время было слишком мало разработчиков и слишком здоровенный бэклог, так что в итоге я все же переключился на бэкенд полностью. То, что я делаю сейчас, это классические задачи бэкендера – пишу код в наших микросервисах, чиню баги, занимаюсь рефакторингом, постигаю Kotlin. Есть возможность работать и над свежим продуктом компании – QIWI Инвестор.
Кстати, не могу сказать, что за эти два года получилось как-то закостенеть во фронте, я отчетливо осознавал, что там тоже есть, куда развиваться. К примеру, я вижу, что сейчас происходит в команде мобильной разработки, и понимаю, что, останься я там, продолжил бы расти дальше вместе с ребятами.
Так что тут сложилась win-win ситуация – я хотел помочь команде и продукту (перевес в разработке был сильно не в сторону бэкендеров) и набраться новых знаний. Тимлиды все поняли и отпустили меня без каких-то претензий, продакт тоже.
Кроме этого, знания хотелось именно диверсифицировать, чтобы не привязываться к одной платформе (Android мне немного не по душе, но и Apple все же сдает позиции). Ну и было желание в случае чего уметь взять и сделать себе приложение самому (и фронт, и бэк), если вдруг появится какая-то клевая идея. Пока вот не пригодилось, правда.
Backend
Само собой, сама первая проблема, с которой сталкиваешься при таком переходе, это пробелы в матчасти. В моем случае это были некоторые тонкости работы с базами данных, но здесь помогла как способность к самообучению, так и команда – ребята отзывчивые и всегда готовы прийти на помощь и что-то подробно объяснить. В QIWI в принципе с обучением на любых этапах все хорошо, будь ты хоть джуниором в самом начале работы, хоть вот так реши и смени сферу пару лет спустя.
Никого не раздражало, что первое время я явно работал не так эффективно, потому что во многое надо было въезжать (но в долгосрочной перспективе команда-то все равно в выигрыше).
Конечно, у меня и до этого был небольшой опыт в разных сферах – мобильные игры и веб, но это все были, скорее, попытки нащупать что-то свое, нежели именно набивание практического серьезного опыта.
Впечатления от бэкенда после фронтенда
Нет работы с UI. Вообще. Раньше приходилось убивать время на исправление багов в UI, сейчас – нет. Минусы такого положения – конечный пользователь не видит результатов конкретно моей работы, как это было с фронтом. Я пытался определить, что же сложнее – бэк или фронт, и понял, что (лично для меня) тяжелее всегда было работать с многопоточностью и сетевым стеком. И тут уже не так важно – за фронт ты или за бэк. На фронте я просто столкнулся с такими задачами впервые, без подготовки, а на бэкенде уже с каким-никаким опытом.
Набраться опыта и делать что-то крутое можно в любой области, было бы желание и усидчивость, здесь практики сходятся – сделать что-то (и сделать хорошо), и чтобы это работало надежно и легко поддерживалось. Причем для бэкендера не столь критично наличие или отсутствие опыта во фронте. Если разраб учитывает все мелочи, сам продумывает корнер-кейсы и в целом понимает, как будут использовать его API, то он и без фронт-знаний сделает все, как надо.
Мне проще обнаруживать возможные проблемы как раз потому, что я знаю особенности реализации наших мобильных приложений. Но это не какая-то сверхспособность – это набор знаний, которыми так или иначе обрастает любой бэкендер, который часто работает с фронтами.
Что в итоге
Backend-разработка стала для меня еще одним хорошим опытом – я научился писать код и проводить ревью, продумывать архитектуру. Это на самом деле интересно.
Но при этом, попробовав вживую что фронт, что бэк, я не скажу, что в случае чего сразу выбрал бы бэкенд в самом начале карьеры. Для меня все же важно видеть и понимать, как мой продукт воспринимают пользователи. С бэкендом это все довольно призрачно.
Скорее всего, выбирая сферу сейчас, я бы пошел в геймдев или веб-фронтенд. Веб все еще остается хорошей платформой для запуска новых продуктов, и при этом перестал быть жутким и сложным для понимания. Все эти туториалы из спагетти-кода и callback-hell остались далеко позади, к счастью.
Как же все таки совместить front-end и back-end? — Хабр Q&A
Привет.
В планах написать полностью некоммерческий проект — фотохостинг. Ну просто хочется и все.
Знаю, что их много, но:
1) Сейчас я на 3 курсе в техникуме, а препод увидел, что я занимаюсь вебом и сказал, что могу приступать делать проект сейчас, чтобы не ждать 4-го курса.
2) Мне хочется создать что-то вроде «своего детища». И повторюсь — не с целью навариться. Просто хочется поработать с данными, с картинками, создать логику, API и все такое. Даже нашел НН, которая определяет, является ли фотография 18+, чтобы ее не публиковать.
Сейчас же имею только верстку. Верстаю немного, в свободное от работы и учебы время, но дал себе условный дедлайн — сделать за месяц. Нет, не потому, что для меня это сверхсложно, а потому что занимаюсь этим в свое удовольствие в свободное время. Меня никто не гонит.
Так вот, извиняюсь за такое водное вступление. Собственно, вопрос.
Как же лучше совместить бекенд и фронт?
1) Лучше писать PHP код прямо в HTML разметке?
Первый вариант мне не особо симпатизирует, потому что ну не хочется встраивать логику по факту в статику. Но со вторым вариантом тоже не все так просто — увеличится время загрузки контента, не смотря на асинхронность. Лучше, как мне кажется, отдавать сразу готовую HTML страницу, но эта идея противоречит предложению выше.
Вот такие дела, сижу сам с собой размышляю. Не понимаю, что делать.
P.S. Хочу сделать все на чистом HTML, CSS, есть также уже фреймворк, в котором я отредактировал стили под себя. Не хотелось бы делать на Vue, Angular’e, потому что я не занимаюсь так фронтом, как бекендом. Верстаю на UIKit и меня все устраивает, это как собирать конструктор. А если писать на том же Vue, то это уже не принесет такого удовольствия.
- Вопрос задан
- 200 просмотров
бэкенд, фронтенд и их взаимодействие
Взгляд на расширяющиеся границы веб-разработки. Изначально этот пост был ответом на 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 для взаимодействия бэкенда и фронтенда.
Standalone фронтенд
По мере развития веб-приложений, они все меньше и меньше зависят от подключения к сети.
Прогрессивные веб-приложения запускаются один раз и работают непрерывно. Вы можете иметь базу данных в своем браузере. В некоторых случаях приложению нужно соединение с интернетом только при первом запуске и затем лишь для обновления/синхронизации данных. Такой уровень независимости требует того, чтобы большая часть логики была реализована на стороне клиента.
Легковесный бэкенд
Параллельно бэкенд становится все более и более легким. Такие технологии как хранилища документов и графовые базы данных подразумевают довольно вялую активность повторной агрегации данных на стороне сервера. Ответственность за определение, какие данные требуются (графовые БД) и как вытащить все необходимые их фрагменты (REST API) ложится на клиентскую сторону.
Сегодня создаются бэкенд-серверы, которые даже запущены не все время, а только тогда, когда в этом возникает необходимость, спасибо таким бессерверным архитектурам, как AWS Lambda.
Сложность связки фронтенд-бэкенд все возрастает. Сегодня разработчик может выбирать, в зависимости от типа приложения, возложить ли основную ответственность на клиент, или же на сервер.
Каждый вариант имеет свои достоинства и недостатки. Сервер более привычен и стабилен, но требует постоянного подключения к интернету. Некоторые пользователи имеют новейшие браузеры, и для них удобнее клиентно-ориентированное приложение, которое делает всю основную работу в пользовательском интерфейсе, однако встречаются и индивидуумы, которые используют последние браузеры вместе с оптоволоконным интернет-кабелем.
Оригинал
Фронтенд и бэкенд: о самом главном
Освоить основы фронтенда за 12 часов: большая видеоподборка
Как соединить front-end и back-end? — Хабр Q&A
Всем привет, меня зовут Григорий и вот уже полгода я никак не могу понять как правильно готовить Web! Очень нужна помощь знающих людей.Гуглить я умею довольно не плохо, занимался этим долго и упорно, прочитал огромную кучу разнообразных статей, на себе попробовал различные инструменты, но мозаика в моей голове все никак не сложится, и мозг уже кипит из-за всей этой информации, которую я никак не могу структурировать.
1. Есть фронт-энд, который выполняется на стороне клиента
2. Есть бэк-энд, который выполняется на стороне сервера
Для того чтобы готовить фронт-энд есть огромная куча инструментов: Grunt и RequireJS, Gulp и Browserify, Webpack…
Давайте пока не будем трогать MVC фреймворки типа Backbone, ReactJS, AngularJS, я хочу разобраться с основами.
Предположим в данный момент я использую 2 инструмента для фронт-энда: Gulp и Webpack.
Мне нужно сверстать 2 страницы, полностью идентичные, но на которых в меню были бы выделены 2 разных пункта, в зависимости от того, какая страница открыта. И так же присутствует динамическая информация — кнопка, если пользователь залогинен то показывается надпись «профиль», если нет то «вход».
Во первых, я хочу оптимизировать процесс верстки HTML страниц, то есть я не хочу верстать одинаковые элементы по нескольку раз, и было бы не плохо такие повторяющиеся элементы вынести в модули. Но казалось бы такую элементарную операцию сделать крайне трудно. Есть огромное количество JS шаблонизаторов типа Handlebars, Mustache, Underscore… но все они работают через JavaScript, а я хочу собрать нормальную HTML страницу, которая будет готова сразу без необходимости грузить скрипты. Еле-еле нашел такой инструмент для Gulp’a как «gulp-file-include». Но это явно какие-то костыли, и писать серьезное web-приложение на его основе стремно, должен быть какой-то другой путь, вопрос какой?
Во вторых, предположим я сверстал такие страницы, все ок, но как мне проверить залогинен пользователь или нет? На помощь к нам приходит бэк-энд. Каким образом нам получить данные? Мы можем собирать страницы на сервере и возвращать уже готовые либо с кнопкой «профиль» или с кнопкой «вход». На мой взгляд это не совсем верный путь, потому что, во первых, зачем нам Gulp и Webpack если сборка будет происходить на сервере, во вторых, сервер по-хорошему не должен заниматься такими задачами как сборка страниц для пользователя. На мой взгляд сервер должен возвращать мою сверстанную страницу из прошлого пункта и что-то типа JSON’а с данными, которые я при рендеринге смогу вставить в нужные места, например проверю залогин ли пользователь и покажу правильную кнопку. Но как это сделать я тоже не понимаю, этого можно добиться только если после загрузки страницы в скрипте посылать AJAX запрос на необходимые данные и потом уже изменять страницу, но это тоже явно не верный путь, потому что нам требуется дополнительный запрос к серверу, что плохо, и в то время пока мы будем ждать ответа нам не известно что показывать на странице.
Так каким образом мне получить страницу с правильными данными?
Моя голова скоро лопнет от отсутствия решения этих вопросов, люди добрые, срочно нужна помощь!!!
Как разделить фронтенд и бэкенд, сохранив взаимопонимание / ISPsystem corporate blog / Habr
Как изменить архитектуру монолитного продукта, чтобы ускорить его развитие, и как поделить одну команду на несколько, сохранив согласованность работы? Для нас ответом на эти вопросы стало создание нового API. Под катом вас ждёт обстоятельная история о пути к такому решению и обзор выбранных технологий, но для начала — небольшое лирическое отступление.
Несколько лет назад я прочёл в научной статье, что для полноценного обучения нужно всё больше и больше времени, а в недалёком будущем на получение знаний будет уходить восемьдесят лет жизни. Видимо, в IT это будущее уже наступило.
Мне посчастливилось начать программировать в те годы, когда не было разделения на бэкенд и фронтенд-программистов, когда не звучали слова «прототип», «продуктолог», «UX» и «QA». Мир был проще, деревья выше и зеленее, воздух чище и во дворах играли дети, а не парковались автомобили. Как бы мне ни хотелось вернуться в то время, нужно признать, что всё это не замысел суперзлодея, а эволюционное развитие общества. Да, общество могло развиваться иначе, но, как известно, история не терпит сослагательного наклонения.
Предыстория
BILLmanager появился как раз в те времена, когда не было жёсткого разделения по направлениям. Он имел согласованную архитектуру, умел управлять поведением пользователя и его даже можно было расширять плагинами. Шло время, команда развивала продукт, и вроде всё было хорошо, но стали наблюдаться странные явления. К примеру, когда программист занимался бизнес-логикой, он начинал плохо верстать формы, делал их неудобными и сложными для восприятия. Или добавление, казалось бы, простой функциональности отнимало несколько недель: архитектурно модули были жёстко связаны, поэтому при изменении одного приходилось корректировать другой.
Про удобство, эргономику и глобальное развитие продукта вообще можно было забыть, когда приложение падало с неизвестной ошибкой. Если раньше программист успевал делать работу в разных направлениях, то с ростом продукта и требований к нему это стало невозможно. Разработчик видел картину в целом и понимал, что если функция не будет правильно и стабильно работать, то формочки, кнопочки, тесты и продвижение не помогут. Поэтому откладывал всё и садился за исправление злосчастной ошибки. Совершал свой маленький подвиг, который оставался никем не оценённым (сил на правильную подачу клиенту уже просто не было), но функция начинала работать. Собственно, чтобы эти маленькие подвиги доходили до клиентов, в команде и появились люди, ответственные за разные направления: фронтенд и бэкенд, тестирование, дизайн, поддержку, продвижение.
Но это было только первым шагом. Команда изменилась, а архитектура продукта осталась технически сильно связанной. Из-за этого не получалось развивать приложение требуемыми темпами, при изменении интерфейса приходилось менять логику бэкенда, хотя структура самих данных часто оставалась неизменной. Со всем этим надо было что-то делать.
Фронтенд и бэкенд
Стать профессионалом во всём — долго и дорого, поэтому современный мир прикладных программистов делится, в основной своей массе, на фронтенд и бэкенд.
Здесь вроде всё понятно: набираем фронтенд-программистов, они будут отвечать за пользовательский интерфейс, а бэкенд наконец-то сможет сфокусироваться на бизнес-логике, моделях данных и других подкапотных вещах. При этом бэкенд, фронтенд, тестировщики и дизайнеры останутся в одной команде (ведь они делают общий продукт, просто фокусируются на разных его частях). Быть в одной команде — значит иметь одно информационное и, желательно, территориальное пространство; вместе обсуждать новые фичи и разбирать законченные; согласовывать работу над большой задачей.
Для какого-то абстрактного нового проекта этого будет достаточно, но у нас уже было написанное приложение, а объёмы планируемых работ и сроки их реализации явно указывали, что одной командой обойтись не получится. В баскетбольной команде пять человек, в футбольной — 11, а у нас было около 30. Под идеальную скрам-команду из пяти — девяти человек это никак не подходило. Надо было разделиться, но как при этом сохранить связность? Чтобы сдвинуться с места, нужно было решить архитектурную и организационную проблемы.
«Всё сделаем в одном проекте, так будет удобнее» — говорили они…
Архитектура
Когда продукт устарел, кажется логичным отказаться от него и писать новый. Это хорошее решение, если можно спрогнозировать время и оно всех устроит. Но в нашем случае даже при идеальных условиях разработка нового продукта заняла бы годы. Помимо этого, специфика приложения такова, что перейти со старого на новое при полном их различии было бы крайне сложно. Нашим клиентам очень важна обратная совместимость, и если её не будет, они откажутся переходить на новую версию. Целесообразность разработки с нуля в таком случае сомнительна. Поэтому мы решили модернизировать архитектуру существующего продукта с сохранением максимальной обратной совместимости.
Наше приложение — это монолит, интерфейс которого строился на стороне сервера. Фронтенд только реализовывал полученные от него инструкции. Иными словами, за интерфейс пользователя отвечал не фронтенд, а бэкенд. Архитектурно фронтенд и бэкенд работали как одно целое, поэтому изменяя одно, мы были вынуждены менять другое. И это не самое страшное, что гораздо хуже — нельзя было разрабатывать пользовательский интерфейс без глубокого знания происходящего на сервере.
Нужно было разделять фронтенд и бэкенд, делать отдельные программные приложения: только так можно было начать развивать их требуемыми темпами и объёмами. Но как делать два проекта параллельно, менять их структуру, если они сильно зависят друг от друга?
Решением стала дополнительная система — прослойка. Идея прослойки крайне проста: она должна согласовать работу бэкенда и фронтенда и взять на себя все дополнительные издержки. К примеру, чтобы при декомпозиции функции оплаты на стороне бэкенда прослойка комбинировала данные, а на стороне фронтенда ничего не нужно было менять; или чтобы для вывода на дашборд всех заказанных пользователем услуг мы не делали дополнительную функцию на бэкенде, а агрегировали данные в прослойке.
Помимо этого прослойка должна была добавить определённости в том, что можно позвать у сервера и что в итоге вернётся. Хотелось, чтобы запрос операций можно было делать без знания внутреннего устройства функций, которые их исполняют.
Повысили устойчивость, разделив зоны ответственности.
Коммуникации
Из-за сильной зависимости между фронтендом и бэкендом делать работу параллельно было невозможно, что тормозило обе части команды. Программно разделив один большой проект на несколько, мы получали свободу действий в каждом, но при этом нам нужно было сохранить согласованность в работе.
Кто-то скажет, что согласованность достигают с помощью повышения софт-скиллов. Да, их нужно развивать, но это не панацея. Посмотрите на дорожное движение, там тоже важно, чтобы водители были вежливы, умели объезжать случайные препятствия и помогали друг другу в сложных ситуациях. Но! Без правил дорожного движения мы даже при наилучших коммуникациях получили бы аварии на каждом перекрёстке и риск не доехать до места вовремя.
Нам нужны были правила, которые было бы сложно нарушить. Как говорится, чтобы их было проще соблюдать, чем нарушать. Но внедрение любых законов несёт не только плюсы, но и накладные расходы, а нам очень не хотелось тормозить основную работу, втягивая в процесс всех. Поэтому мы создали координационную группу, а потом и команду, целью которой стало создание условий для успешной разработки разных частей продукта. Она настроила интерфейсы, которые позволили разным проектам работать как одно целое — те самые правила, которые проще соблюдать, чем нарушать.
Мы называем эту команду «API», хотя техническая реализация нового API — это только малая часть её задач. Как общие участки кода выносят в отдельную функцию, так и команда API разбирает общие вопросы продуктовых команд. Именно здесь происходит соединение нашего фронтенда и бэкенда, поэтому участники этой команды должны понимать специфику каждого направления.
Возможно, «API» — не самое подходящее название для команды, больше подошло бы что-то про архитектуру или масштабное видение, но, думаю, это мелочь и сути не меняет.
API
Интерфейс доступа к функциям на сервере существовал и в нашем начальном приложении, но для потребителя выглядел хаотично. При разделении фронтенда и бэкенда нужно было больше определённости.
Цели для нового API сформировались из ежедневных трудностей в реализации новых продуктовых и дизайнерских идей. Нам были нужны:
- Слабая связанность компонентов системы, чтобы бэкенд и фронтенд можно было развивать параллельно.
- Высокая масштабируемость, чтобы новый API не мешал наращивать функциональность.
- Стабильность и согласованность.
Поиск решения для 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 станет больше.
Результат
Мы пошли эволюционным путём развития продукта и команды. Достигли успеха или затея обернулась провалом, наверное, судить рано, но можно подвести промежуточные итоги. Что имеем сейчас:
- За отображение отвечает фронтенд, а за данные — бэкенд.
- На фронтенде сохранилась гибкость в плане запросов и получения данных. Интерфейс знает, что можно попросить у сервера и какие ответы должны быть.
- На бэкенде появилась возможность менять код с уверенностью, что интерфейс у пользователя продолжит работать. Стал возможным переход на микросервисную архитектуру без необходимости переделывать весь фронтенд.
- Появилась возможность использования mock-данных для фронтенда, когда ещё не готов бэкенд.
- Создание схем совместной работы исключило проблемы взаимодействия, когда команды понимали одну и ту же задачу по-разному. Сократилось количество итераций по переделке форматов данных: действуем по принципу «семь раз отмерь, один раз отрежь».
- Появилась возможность планировать работы на спринт параллельно.
- Для реализации отдельных микросервисов теперь можно набирать разработчиков, не знакомых с C++.
Из всего этого главным достижением я бы назвал возможность осознанно развивать команду и проект. Думаю, нам удалось создать условия, в которых каждый участник может более целенаправленно повышать свои компетенции, фокусироваться на задачах и не распылять внимание. От каждого требуется работа только на своём участке, и теперь она возможна с высокой вовлечённостью и без постоянных переключений. Стать профессионалом во всём невозможно, но для нас это теперь и не нужно.
Статья получилась обзорной и очень общей. Её целью было показать путь и результаты сложной исследовательской работы на тему, как с технической точки зрения поменять архитектуру для продолжения развития продукта, а также продемонстрировать организационные сложности деления команды на согласованные части.
Здесь я поверхностно затронул вопросы командной и межкомандной работы над одним продуктом, выбор технологи API (REST vs GraphQL), связь Node.js приложения с C++ и т. д. Каждая из этих тем тянет на отдельную статью, и если вам будет интересно, то мы их обязательно напишем.
Бэкенд для фронтенда, или Как в Яндекс.Маркете создают 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,
}Какие еще плюсы мы получаем?
- Фильтрация. Клиент получает только то, что ему нужно, ни больше ни меньше.
- Агрегация. Не нужно тратить клиентскую сеть и батарею, чтобы делать множественные аякс-запросы. Заметный выигрыш по скорости за счет того, что открытие соединения — это дорогая операция.
- Кэширование. Ваш повторный агрегированный вызов не будет лишний раз никого дергать, а просто вернет 304 Not Modified.
- Сокрытие данных. Например, у вас могут быть токены, которые нужны между бэкендами и не должны попадать на клиент. У клиента может не быть прав даже знать о существовании этих токенов, не говоря уже об их содержимом.
- Микросервисы. Если у вас на бэке монолит, то BFF — это первый шаг к микросервисам.
Теперь о минусах.
- Повышение сложности. Любая абстракция — это еще один слой, который необходимо кодить, деплоить, поддерживать. Еще одна движущаяся часть механизма, которая может сбоить.
- Дублирование ручек. Например, несколько ендпойнтов могут выполнять один и тот же тип агрегаций.
- 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, валидировать ответы бэкендов и в случае расхождений репортить тестировщикам, самим бэкендерам и т. д.
Допустим, тестировщик находит на сайте какой-то баг, например при клике на кнопку ничего не происходит. Что делает тестировщик? Ставит тикет на фронтендера: «это ведь ваша кнопка, вот она не нажимается, чините».
Если между вами и бэком стоит валидатор, то тестировщик будет знать, что кнопка на самом деле нажимается, просто бэкенд присылает неправильный ответ. Неправильный — это такой ответ, который фронт не ожидает, т. е. не соответствующий «контракту». И тут уже надо или чинить бэк или менять контракт.
Выводы
- Принимаем активное участие в проектировании API. Проектируем API так, чтобы им было удобно пользоваться через 17 лет.
- Требуем Swagger-документацию. Нет документации — работа бэка не выполнена.
- Есть документация — публикуем ее в git, при этом любые изменения в интерфейсе API должны апрувиться представителем фронт-команды.
- Поднимаем фейковый сервер и начинаем работать над фронтом не дожидаясь реального API.
- Кладем ноду под фронтенд и валидируем все ответы. Плюс получаем возможность агрегировать, нормализовать и кэшировать данные.
См. также
→ Как построить REST-like API в крупном проекте
→ Backend In the Frontend
→ Using GraphQL as BFF Pattern Implementation
Разница между Front end, Back end, Full stack разработчиками.
Опытного IT рекрутера точно нельзя испугать модными словечками или техническими выражениями, а вот начинающему стоит разобраться во всех тонкостях IT сферы. Узнайте, чем занимаются «front end», «back end», «full stack» разработчики, чтобы быть уверенными в том, что вы с твердыми знаниями подходите к выполняемой роли специалиста. Какие-то различия — существенные, какие-то несут в себе большое количество тонкостей, но все они позволят вам понять текущие потребности IT-индустрии.
На сегодняшний день создается все больше и больше
различных веб-инструментов, программ и сервисов. Спрос на разработчиков
растет с каждым днем с такой же прогрессией. В связи с этим выросла
потребность в IT рекрутерах.
Сегодня мы поможем вам понять, кто такие «front end», «back end», «full stack» разработчики.
Front End разработчик
Когда вы видите наполненный жизнью сайт с привлекательным интерфейсом, вам становится интересно, кто же этот волшебник, который так профессионально с ним поработал. Именно в эту минуту вы думаете о front end разработчике, даже об этом не зная. Любое визуальное отображение, с которым вы работаете, производится потом, кровью и слезами front end разработчика. GUI или «Графический пользовательский интерфейс» — это визуальный фронт, на котором отображается экран, позволяющий клиентам взаимодействовать с программным обеспечением. Любое из сегодняшних устройств с прилагательным «умный», будет иметь интерфейс, который запускает приложения, предоставляет доступ к веб-сайтам, и все это создается разработчиком front end.
UI дизайнер или дизайнер «Пользовательского интерфейса» создает пространство, в котором происходит взаимодействие между человеком и машиной. С точки зрения мастерства, данный процесс требует от программиста сочетания навыков программирования и дизайна, и часто этот человек вовсе не должен быть программистом.
Дизайнер UX ссылается на конструктор «User Experience», в котором описывается путь, который пользователь использует, и его общая эффективность. Front end разработчики также должны думать над общим удобством использования, полезностью и опытом, которые пользователь имеет при взаимодействии с программным обеспечением и этот конкретный сегмент требует, безусловно, самых «гибких навыков» программиста. Тем не менее, эта работа может выполняться также не программистами.
Responsive design — очень трудная работа. Она относится к процессу адаптации дизайна интерфейса к любому экрану, от широкоэкранных настольных компьютеров и ноутбуков до мобильных устройств, таких как планшеты и смартфоны.
Традиционно разработчиком front end является человек, которому удобно работать как с дизайном, так и с кодированием. Другими словами, тот, кому комфортно работать с использованием простых инструментов проектирования и умеет писать структуру веб-сайта в HTML и стилизовать его с помощью CSS-кода. На данный момент самой большой проблей для front end разработчиков является то, что веб-сайт, построенный только с использованием HTML и CSS, будет полностью статическим. Если вы думаете о stickman на пустой странице в качестве веб-сайта. HTML будет достаточно, чтобы нарисовать его форму и CSS будет использоваться для его стилизации (сгустить, покрасить его, добавить одежду и т.д.). Но чтобы заставить stickman двигаться и реагировать, front end разработчику как следствие потребуется что-то еще.
По мере усложнения и совершенствования веб-приложений спрос на полный язык программирования Turing в интерфейсе растет с большой скоростью, поэтому для анимации программистов — stickman используют Java Script, который является языком программирования на стороне браузера.
Back End разработчик
В прошлом back end состоял из физического компьютера и программного обеспечения, предназначенного для запуска запросов через него. Сегодня этот процесс стал куда более сложным: облачные серверы являются более распространенными, трудоемкие базы данных и приложения микросервиса, но в принципе back end по-прежнему остается процессом объединения сервера, приложения и базы данных для решения проблемы.
Весь процесс прочно закреплен в логике, сети процессов и запросов, разрешаемых за считанные секунды, чтобы дать вам, как пользователю, определенный желаемый результат. Выберите рейс из Нью-Йорка в Гонконг и вы находитесь в зоне front end, нажмите клавишу поиска и вы перемещается в back end, чтобы правильно вернуть вам лучший, самый короткий, самый дешевый рейс в мгновение ока. Как только результаты будут отображаться для вас, вы снова будете во front end. Если поисковый запрос выдал вам своевременный и полезный результат, и вы не представляете, благодаря чему это произошло, спасибо разработчику за завершение поиска, а также бесчисленное множество других вещей, упрощающих вашу жизнь.
У back end разработчика может быть множество обязанностей. От создания базы данных и интеграции до обеспечения безопасности, а также технологий резервного копирования и восстановления, также back end разработчики создают мозг приложения.
Back end разработчики используют различные технологии для кодирования основной вычислительной логики информационных систем, конкретного программного обеспечения или веб-сайтов. Они могут включать Java, C#, Python и языки баз данных, такие как SQL и многие другие. Back end отличаются от разработчиков front end тем, что работа back end разработчика полностью лишена какого-либо визуального дизайна и основывается на логике и архитектуре программного обеспечения, целью которой является предоставление определенного результата. Иногда возникают проблемы с объединением back end и front end, что приводит нас к человеку, который может обработать обе части.
Разработчик Full Stack.
Разработчик full stack — это тот, кто хорошо работает как с бэкэнд, так и с фронтэнд. «Чтобы быть более конкретным, это означает, что разработчик может работать с базами данных, PHP, HTML, CSS, JavaScript и всем, что находится между ними, также принимая во внимание преобразование проектов Photoshop в интерфейсный код», — говорит Sitepoint.
Для разработчиков full stack необходимо общее знание технологий из каждой части процесса разработки. Это, конечно, означает, что они не будут экспертом в какой-либо конкретной области, но скорее могут предложить лучший обзор возможностей применения и возможности преодоления разрыва между тем, как функционирует система и как она выглядит и ощущается для пользователя. Возможно, это не требование дляработы, но разработчик full stack обычно также понимает бизнес-логику, пределы дизайна и пользовательский интерфейс. На ранних этапах развития бизнеса может возникнуть большая потребность в разработчиках full stack, поскольку их универсальность может быть полезна при разработке продукта, но по мере созревания компании разработчикам требуется все больше и больше конкретных навыков.
Full stack разработчик также может быть отличным техническим специалистом. Он имеет широкое понимание технологий и может предвидеть, какие будущие усилия по набору персонала должны быть или какие технологии должны быть реализованы в дальнейшем.