Что фронтенд разработчики должны знать о бэкенде? / Habr
Подавляющее большинство вещей, которые должны делать фронтенд разработчики, можно сделать не зная ничего о бэкенде кроме API.
Однако если вы достаточно долго работаете с разного рода задачами, вероятней всего вы столкнетесь с чем-то, что требует некоторых знаний в области бэкенда.
Ниже представлен краткий список того, о чем должен знать разработчик интерфейсов.
Частота запросов
Бэкенд имеет ограниченные ресурсы, он может обрабатывать запросы лишь с определенной частотой. В общем случае вы не должны об этом думать — фронтенд должен делать все что необходимо для предоставления качественного пользовательского опыта, бэкенд же в свою очередь можно оптимизировать и масштабировать. Тем не менее сетевые запросы к бэкенду не бесплатны и имеют разную цену (в терминологии используемых ресурсов)
Как мы можем измерить насколько запрос затратный?
Одно из практических правил говорит нам о том запись всегда дороже чтения, поэтому чем больше данных записывается — тем дороже становятся запросы.
Давайте рассмотрим пример того когда это становится критичным: предположим мы разрабатываем google docs.
Мы хотим чтобы пользователь не потерял написанное если он вдруг покинет приложение, поэтому мы чаще сохраняем данные. Можем ли мы сохранять каждый новый символ или его удаление?
Ваш бэкенд вероятнее всего будет не в состоянии обработать все эти запросы, или же стоимость инфраструктуры будет непозволительно высокой. Сделав задержку и сохраняя данные только после того как пользователь перестал печатать, можно достигнуть 99% от необходимого результата без огромных затрат на оставшийся 1%.
Следующий пример, давайте предположим что вы хотите опрашивать бэкенд об изменениях, чтобы всегда иметь самую свежую версию .doc файла. Как часто необходимо делать запросы? Чтение намного дешевле записи, поэтому вы можете делать сравнительно больше таких запросов, но они все еще имеют лимит.
Данный лимит зависит от множества факторов, таких как: максимальное количество активных клиентов в промежуток времени, инфраструктура и бюджет. Если вы думаете что ваш функционал может приблизиться к такому лимиту, стоит поговорить с командой бэкендеров, иначе есть риск задодосить сайт вашей компании.
Время простоя (downtime)
Вы должны ожидать и быть готовыми к тому что каждый запрос может в какой-то момент упасть для некоторых пользователей. Это неизбежно, бэкенд может в какой-то момент падать целиком либо же на каком то конкретном эндпоинте пока все остальные продолжают работать.
Вы должны различать какие запросы в вашем приложении являются критичными, когда нужно показать полноэкранную ошибку с сообщением «Попробуйте позже», а когда ошибку можно обработать с помощью постепенной деградации (например серая кнопка для какой либо функции, с сообщением при наведении о том, что функция на текущий момент недоступна)
Если ваш бэкэнд разделен на несколько микросервисов, вероятность сбоя подмножества эндпойнтов выше. В другом случае, eсли ваш бэкэнд представляет собой только один сервер, один сбой может разрушить все эндпойнты.
В любом случае, хороший фронтэнд должен всегда отлавливать ошибки в запросах с помощью try catch и иметь заготовленные ошибки для пользователя. В javascript нет встроенной функции(recovery panic), которая позволяет продолжить выполнение кода после ошибки, поэтому при её возникновении ваше приложение упадет.
HTTP
Бэкэнд и фронтенд должны использовать соответствующие HTTP статусы (в определенной степени). Надеюсь, ваш бэкэнд не воспринимает каждую ошибку как 400.
Интерфейс должен знать каждый статус, который бэкэнд планирует вернуть.
Не парсите сообщения об ошибках, чтобы определить, то что авторизация не удалась, код ошибки 401 подходит для этого больше.
Не повторяйте тот же самый запрос, если вы получили 400-ый код потому что он, вероятно, не будет работать снова. А к примеру 500-ый код может означать, что сервер просто перезагружается и повторная попытка будет успешной.
Другие свойства HTTP запросов которые желательно знать:
- HTTP запросы могут быть закрыты сервером если они занимаются слишком много времени прежде чем завершатся. Если вы думаете что некоторая задача займет больше времени чем лимит на запрос (как правило около 20 секунд), вам следует выбрать вместо единичного запрос-ответа, запрос с последующим опросом результата. Или воспользоваться другими механизмами, например веб-сокетами.
- Если вы отправляете большое количество данных на сервер(например видео), вы должны использовать составной HTTP запрос(multipart/form-data), который делит данные на части перед отправкой.
- Иногда неожиданно возникает то, что существует ограничение размера URL. Некоторые веб-интерфейсы передают данные обратно на сервер с query параметрами, но если они длиннее 2048 символов, вам придется изменить такой способ на передачу параметров в теле HTTP запроса.
Делегирование бизнес логики
Если какая-то бизнес логика вашего функционала может быть реализована и на бэкенде и на фронтенде, где лучше её реализовать?
В основном лучше делать это на бекенде. Причины:
- Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
- Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
- Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для pro пользователей. Если ограничение будет сделано на фронтенде, то кто-либо потенциально может провести реверс-инжиниринг и получить доступ к функционалу.
Кросс-доменные запросы
В качестве протокола безопасности, если запрос к бэкэнду поступает из другого домена, он будет отклонен из-за того что он является кросс-доменным запросом. Такое поведение обусловлено политикой одного источника(Same-Origin Policy). Данная политика запутывает людей в процессе разработки, поскольку порты тоже считаются частью домена.
Зачастую используется сервер npm/yarn для фронтенда и бэкенда на другом порту, что делает каждый запрос кросс-доменным.
Решения:
- Указание одного домена в
hostsфайле и разграничивание фронтенда и бекенда с помощью nginx*. - Включить кроcс-доменные запросы на сервере в зависимости от переменной среды, если production то false, если development то true.
- Включить домен с которого ведется разработка в белый список исключений.
Межсайтовая подделка запросов(CSRF) — так называется атака, которая делает несанкционированный запрос от пользователя инициированный с другого сайта.
Например: вы нажимаете кнопку на каком-либо сайте и он выполняет javascript код, который попытается выполнить запрос на сайт вашего банка.(подробнее)
Чтобы это предотвратить, сервер выдает одноразовый CSRF токен для каждой сессии, так что попытка будет неудачной из-за отсутствия токена. Добавляйте его к заголовкам авторизованных запросов.
Очистка кэша
Каждый запрос проходит через несколько кэшей на пути к бэкэнду. Если вы посещаете сайт в первый раз, подождите, пока он загрузится, а затем перезагрузите страницу.
Веб-приложение загружается быстрее чем в первый раз, поскольку браузер кэширует ресурсы, такие как favouritewebsite.com/static/script.js.
Что если вы хотите внести изменения в script.js? Вы меняете имя файла. Допустим, вы меняете script.js на script.js?v=2, на который ссылается index.html.
Закэшированный script.js становится неактуальным, поскольку к нему никогда не будет другого запроса (если сам index.html не будет закэширован! Запрос к index.html должен быть инвалидирован на бэкэнде).
Современные конвейерные сборки включают в себя очистку кэша для каждой сборки, поэтому большинство javascript файлов выглядят как script.4e885f13.js. Обычно это применяется только к css стилям и скриптам, но вы также можете применить их к изображениям и другим ресурсам.
Однако подобные ресурсы меняются очень редко, и по соображениям производительности стоит их исключить из автоматического кэширования и просто обновлять вручную при необходимости.
*Примечание переводчика:
В оригинале было так:
Map your server domains to some hostname in your dev environment’s host config.
Я мог неправильно понять то что хотел сказать автор, поэтому добавляю сноску.
Что нужно знать для backend разработки? — Хабр Q&A
0. В начале 10 раз подумать — зачем? Если хочется больше денег, то тогда быстрее и намного проще стать Senior Frontend. Так как бекенд намного глубже и сложнее, а платят почти так же.1. В вашем случае действительно лучше всего начать с Node.js + express.js + любая БД, которая будет в том видео курсе, который вы будете смотреть. Так вы сможете сделать свое первое API для фронтенда и понять, что такое бекенд. Но стоит понимать, что Node.js это нишевое решение и для большинства сайтов оно не подойдет по многим причинам.
2. PHP СРАЗУ ЗАБЫТЬ!
Сказки про то, что на PHP написано 99% всех сайтов уже 10 лет не актуальны, а их все повторяют. Особенно смешно когда рассказывают про ВКонтакте и Facebook как о примерах проектов на PHP. И Вк и ФБ давно избавились от чистого пхп и написали свои трансляторы PHP в C++. (KittenPHP и HipHop).
Хотя после JS пхп может показаться хорошим языком (богаче стандартная библиотека, ООП) но не стоит заблуждаться — есть языки намного лучше/проще/мощнее/современнее.
Для тех, кто хочет поспорить — Про 50 оттенков PHP хорошо написано тут: https://habr.com/ru/post/142140/
Хотя тягу истинных индусов кататься на слоне не унять ни какими доводами:)
3. Java, C# — сомнительно. Да, на них пишут большие и серьезные проекты и платят хорошие деньги. Но часто ли пишут такие проекты? Особенно в СНГ. И берут ли на них новичков?:) Лучше вначале хорошо изучить спрос на июней на фриланс биржах и количество вакансий, ОСОБЕННО, если хотите работать удаленно.
Я 4 года был fullstack-разработчиком. Писал на PHP/CodeIgniter/Kohana/Zend/Yii1,2/Symfony/Laravel 4,5/MySql/JQuery/Vue.js. С опытом я понял, что у PHP много проблем. Развитие языка остановилось/идет не туда, сам язык плохо спроектирован. И я стал активно изучать на какую платформу/язык мне перейти.
Попробовал Java, Ruby, Objective-c/Swift, Node.js, Python.
Остановился на Python/Django framework/PostgreSQL. На Python можно писать как асинхронные приложения (здравствуй Node.js) так и синхронные (привет PHP). Django на голову выше любого PHP фреймворка, а порог вхождения ниже чем у Symfony, Zend и примерно такой же как у Laravel, Yii.
В целом Python как язык спроектирован лучше PHP, у него больше возможностей, он современнее и активнее развивается.
Переход на новый язык оказался не таким быстрым и простым, как казалось сначала). Хоть и переходил с бекенда на PHP в бекенд на Python. Кроме самого языка нужно еще освоить новый стек популярных для него фреймворков, библиотек, инструментов. А так же заново наработать портфолио. У меня выход на прежний уровень ЗП занял 2 года. Работаешь на старом стеке, что бы было что кушать, а после работы и по выходным изучаешь новый, если мотивация не закончится:)
P.S Не советую быть Fullstack-ом. Лучше стать грамотным специалистом в одной области чем недоучкой в двух. Платят middle fullstack так же как и middle frontend или middle backend по отдельности. Да, работу найти fullstack-у чуть легче но и обязаностей будет намного больше.
Что нужно знать backend разработчику в 2020
Если вы задаетесь вопросом о навыках разработчиков, значит пришло время раскачать себя по полной программе и наконец подтянуть все те навыки и умения, которых прежде просто не хватало. Новые тенденции и технологии веб-разработки настолько быстро изменяются, что проследить за их работой порой просто нереально. И чтобы не потерять свою любимую работу, быть интересным и востребованным специалистом во все века — необходимо идти в ногу со временем и следить за новинками в сфере программирования и создания сайтов, ибо меняются не только сайты и их составляющие, но и запросы тех людей, которые заказывают себе интернет-платформу для бизнеса.
Backend разработчиком является специалист по программно-административной составляющей интернет приложения, а также внутренней работе системы, технологиями серверов, такими как база данных, архитектура, вся программная логика. Перед ним стоит сложная и ответственная работа, а поскольку тенденции и течения изменяются, необходимо все время учиться и развиваться, чтобы всегда оставаться востребованным специалистом.
Итак, какие же навыки обязательно необходимы для работы?
- самое главное — желание работать, без которого остальное можно и не практиковать;
- владение РНР5 на уровне уверенного пользователя;
- знание английского языка для ознакомления с документацией;
- знание ООП;
- навыки работы с MySQL;
- наличие опыта работы с Git;
- умение разбираться максимально быстро с чужим кодом;
- знание фреймворков.
Сегодня сайты, веб-приложения, игрушки сложные по своей структуре, поэтому и работает над их созданием и функционированием целая группа спецов. Чтобы сделать хороший полноценный сайт – воплощение удобного в использовании, красивого внешне, функционального — необходим огромный труд и согласованность между разработчиками. Подобное позволит ускорить создание сайта, а также разработку приложения, упростить в несколько раз обслуживание такового.
То есть, бэкенд разработка представляет собой создание непосредственно двигателя а все остальное — фронтенд разработка — так называемое создание дизайна, запуск функций по управлению. Такие стороны как бэкенд, фронтенд разработчики взаимодействуют очень тесно всегда.
Основными инструментами в работе каждого из бэкенд разработчиков являются ряд языков программирования, это такие как: PHP, Python, Java, Ruby, Node JS. Плюсом большим будет выучить дополнительно Express, Mongo DB, тогда работаться будет в несколько раз легче.
В качестве вспомогательных средств используют такие фреймворки как Symfony, Yii, Zend Framework, Codeigniter, Kohana. Хранение данных — MySQL/SQLite.
Разумеется, есть еще огромное количество навыков, но всеми ими не овладеть, ибо вакансии разные и могут требовать наличие индивидуальных навыков – не стандартных. Поэтому, одного точного списка просто не существует.
Для современного разработчика умения написать код для различных программ недостаточно. Программисты таким образом работали очень давно – приблизительно 10 лет тому назад. Сегодня подобное определение уже является неуместным, так как в работе часто разрешают и не писать код, а просто соединять готовые составляющие в одну конфигурацию. Помимо этого плюсом будет умение организовать выкладку кода на сервер или хостинг. Чтобы соответствовать последним требованиям законодательства мы рекомендуем купить хостинг в России.
Сфера IT не стоит на месте, развивается постоянно, проекты с каждым днем более сложные, — конструктор, который легко собрать с готовым шаблоном.
Итак, основные функции back end разработчика сводятся к следующим:
- Осуществление задач по проектированию сервиса и архитектуры такового;
- Создание непосредственно ядра сайта;
- разработка в полном объеме платформы, а также ее функционала;
- знание кода, его архитектуры;
- разработка вех приложений, которые осуществляют поддержку интерфейса пользователя, а также безопасность такового;
- осуществление контроля и присмотра за всеми серверами;
- контролирование версий, баз с данными, а также непрерывной интеграции.
Чтобы быть настоящим профи в сфере бэкенд разработки нужно получить образование по специальности, а затем можно продолжить развиваться, посещая компьютерные курсы, проходя онлайн-тренинги и читая дополнительную литературу.
Важно знать и всегда помнить о том, что наличие фундаментального образования – это только основа, и для успешной работы этого будет недостаточно. Настоящий профессионал своего дела изо дня в день учится и развивается в одну ногу с современными тенденциями. Если этого не делать, обязательно придет молодой, успешный и перспективный. Поэтому важная составляющая — самообразование, чтобы знать, что сейчас востребовано, а что нет, какие технологии используются, а какие давно отошли на второй план. Ну и конечно практика и много раз практика!
Большинство современных работодателей, конечно, очень редко смотрят на образование, ибо, если есть желание работать, учиться и развиваться — будет работа и перспективы. А начать своё развитие при должном желании вы можете самостоятельно, благодаря нашему онлайн курсу по PHP с видео уроками.
С чего начинать обучение backend-разработчику и какой минимум знаний нужен на junior’а в 2016-2017?
Доброго времени суток. Небольшая предыстория. В этом году закончил вуз по специальности «Прикладная информатика». Вуз далеко не из топовых, поэтому, думаю, вы представляете какой уровень знаний в региональных вузах России в it-направлении дается. К тому же, я себя не оправдываю, сам тоже, сверх программы не занимался (о чем очень сожалею, конечно же). Знания в it настолько общие, что я беру примерный уровень «с нуля».Сейчас я работаю не по специальности. И появилось желание стать разработчиком. Посмотрев востребованность программистов по направлениям, я понял, что сейчас в тренде веб-разработка (в моем регионе). Меня это интересовало в первую очередь не возможностью зарабатывания денег, а возможностью попасть на стажировку (или в перспективе джуниором).
В 70-85% вакансий backend-разработчиков указан php. но покопавшись немного в интернете, я встретил расхожее мнение, что не стоит начинать учиться программированию с данного языка (мой универский опыт с Delphi и просто Pascal’ем я, конечно,в счет не беру,а базовые знания разметки html/css мне вообще в этом деле не помощник). Мне больше по душе или .net или java (в крайнем случае).
Многие советуют начать изучение программирования с какой-то своей прикладной задачи и говнокодить до посинения, пока криво-косо не получится что-то более-менее похожее на ожидаемый результат, и уже в процессе изучать документацию и прочее. Может это и самый быстрый и удобный вариант с точки зрения уже опытных специалистов, но у меня, как у совсем новичка информация укладывается неструктурировано, отрывками, а хотелось бы, чтобы в голове все было разложено «по полочкам».
Есть неплохая «карта развития веб-разработчика» (https://github.com/zualex/devmap), но там только общий суповой набор для «каждого уважающего себя веб-разработчика». Хотелось бы похожу информацию получить для джуниора. Само собой, я понимаю, что не в таком развернутом виде, но хотя бы приблизительно.
И само собой главная дилемма для меня на данный момент: с чего начать само обучение. С изучения алгоритмов и дискретки, или архитектуры компьютера. Или сразу начинать учить синтаксис какого-то языка. Времени у меня много, поэтому я хотел бы все с азов понять и усвоить.
И, не менее интересующий меня вопрос: какими знаниями, помимо синтаксиса ЯП, нужно обладать, для того,чтобы попытать себя на собеседовании джуниор бэкэндщиком.
P.S. всем заранее огромное спасибо за ответы. так же сильно извиняюсь за «много букв», только учусь правильно формулировать вопросы