Отличие frontend и backend разработчик: принципы и отличия — статьи на Skillbox

«Объясните простыми словами, что такое Frontend и Backend?» – Яндекс.Кью

Могу судить только о веб-разработке, т.к. совсем не интересовался другими направлениями Frontend. Думаю многие согласятся, что Frontend освоить легче, чем Backend. С CSS и HTML, которые являются основой визуальной разработки сайтов, можно неспеша познакомитсья буквально за неделю, еще неделю на JavaScript. Конечно, требуется гораздо больше времени для полноценного освоения, и я не знаю всех особенностей, но хорошо представляю задачи, которые ставит перед собой Frontend. Будучи студентом Backend факультета Яндекс Практикум, для меня эти задачи выглядят довольно простыми. В своих проектах мне приходилось заниматься разработкой frontend-части, инструменты, которые пришлось для этого освоить не вызвали у меня сложностей, по сравнению с задачами backend-части. С этой точки зрения, Frontend действительно выглядит проще. Но стоит подумать о том, что ответ на этот вопрос кроется не только в сложности, но и в тех качествах, которые присущи тому или иному человеку. Frontend разработчик делает визуальный продукт и должен делать его красивым и эргономичным. На мой взгляд, такую спецаильность проще будет освоить людям, у которых есть вкус к таким вещам. Backend же делает незримую часть, работает с базами данных, с различными API, не говоря уже о более сложном языке программирования. Если планируется заниматься только сайтами, не вдаваться в подробности, условно можно было бы равно поставить. Изучить фрейм-ворк Django и клепать на нем сайты. Но так вы никогда не станете хорошим Backend разработчиком. А изучив один лишь Python, еще задумаетесь, не заняться ли вам аналитикой данных, или разработкой игр? Знание этого языка, который мы используем для разработки веб-серверов, открывает огромные возможности. Frontend этим похвастаться не может. Я бы сказал, что Backend подойдет тем, кто больше инженер, чем дизайнер. Тем, кто любит читать ко всему инструкции, строительную документацию и т.п.. Задачи бэкенда предполагают постоянное расширение знаний. Frontend же может сконцентрироваться на скорости работы или посмотреть в сторону веб-дизайна. Перед тем как выбрать свою специальность, я проходил бесплатные курсы на Яндекс Практикуме, которые на деле познакомили меня с несколькими спецализациями. На 90 процентов вопросов, касательно это професси теперь могу ответить и сам. Backend я выбрал именно из-за сложности, и гораздо меньших возможностей получить реальный опыт.

Различия между фронтенд и бэкенд разработкой

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

Front-end, внешний интерфейс

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

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

Стройнов Михаил, веб-разработчки Pear Advert

И сегодня, когда речь идет о фронтенд-разработке, мы подразумеваем специалистов, работающих с Photoshop, Fireworks, HTML, CSS, JavaScript или jQuery. Все, что вы видите при взаимодействии с сайтом — это сочетание HTML, CSS и JavaScript, которые контролируются браузером вашего компьютера. Это и шрифты, и раскрывающиеся меню, и кнопки, и свайпы, и ползунки, и контактные формы и т. д.

Фронтенд-программирование Чтобы быть разработчиком UI-дизайна, вам не нужны навыки внутренней разработки. Сайты, созданные разработчиками внешних интерфейсов, не будут взаимодействовать с информацией, хранящейся в базе данных, для обеспечения их работоспособности. Содержимое будет фиксированным: большие фрагменты новых данных не будут загружаться постоянно. Фронтенд-программирование включает в себя HTML, CSS и Javascript. Хотя jQuery выходит из моды (современные браузеры теперь могут выполнять ту же работу, но гораздо быстрее, чем jQuery), многие проекты все еще используют библиотеку JavaScript. Фронтенд-разработчик Очень часто фронтенд-разработчики называют себя просто веб-дизайнерами. Они фокусируются на пользовательском интерфейсе и пользовательском опыте, визуальных аспектах  сайта. Но чтобы все это стало реальностью, нужны технологии, чтобы это произошло. Настало время бэкенда.

Back-End

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

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

Стройнов Михаил, веб-разработчки Pear Advert

 

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

Бэкенд-программирование

Бэкенд-технологии обычно используют PHP, Ruby, Python и т. д. Эти языки используются для создания динамических сайтов, которые хранят информацию в базе данных, так как контент на сайте постоянно меняется и обновляется. Также используются фреймворки Ruby on Rails, Cake PHP и Code Igniter, которые делают разработку быстрее и проще.

Многие веб-профессионалы, которые только начинают работать, слышали о WordPress. Это хороший пример совместной работы внешнего и внутреннего интерфейсов, поскольку WordPress — это платформа с открытым исходным кодом, построенная на PHP, которую необходимо установить на свой сервер с базой данных. Затем дизайнеры настраивают внешний вид и функциональность сайтов WordPress, используя CSS, jQuery и JavaScript.

Заключение

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

Что фронтенд разработчики должны знать о бэкенде? / Хабр

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

Делегирование бизнес логики

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

В основном лучше делать это на бекенде. Причины:

1. Бэкенд может быть изменен намного быстрее — один деплой на все сервера и обновленная логика будет доступна. Фронтенд же, на руках у пользователей и деплой не будет означать что старая логика в которой возможно присутствуют ошибки, не будет запущена на продакшене.
2. Если бизнес логика требует вычислительной мощности, её тяжело протестировать на различном спектре устройств с которых пользователи могут заходить на ваше приложение. Если вы заходите на него с топового macbook, то не сможете представить насколько медленными будут вычисления на chromebook за 100 долларов.
3. Более безопасно блокировать бизнес логику на бэкенде. Предположим у вас есть функционал только для 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.

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

Front-end и Back-end разработка — отличия и проф.стандарты

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

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

Особенности Front-end и Back-end разработки

Front-end разработка – это клиентская составляющая процесса создания веб-ресурсов, предусматривающая формирование макета сайта, шаблонов, интерфейса и скриптов, которые отвечают за визуализацию. На этом этапе разработки также выполняется CSS-верстка.

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

Для понимания особенностей данных частей процедуры создания сайта стоит привести простой пример. Представим ресторан. К «клиентской» части ресторана относятся декорации, музыка и мебель.

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

Front-end vs. Back-end разработка

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

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

Front-end разработчики в основном используют 3 языка – CSS, HTML и Javascript. А вот бек-энд разработчики в своей деятельности используют Python, Ruby,.NET, Postgre SQL, MySQL и MongoDB.

Среда разработки

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

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

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

Цели

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

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

Теги:

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

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

Бэкенд для фронтенда, или Как в Яндекс.Маркете создают 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

Front End Development против Back End разработки: где

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

---

Совместите с учебными курсами , которые обучают программированию переднего и заднего плана!

---

Front End Web Development

Что такое Front End Development?

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

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

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

Языки внешнего интерфейса включают HTML, CSS и Javascript. В то время как JQuery выходит из моды (современные браузеры теперь могут выполнять ту же работу, но гораздо быстрее, чем jQuery), многие устаревшие проекты по-прежнему используют библиотеку JavaScript, поэтому не удивляйтесь, увидев ее в учебной программе учебного лагеря. Вы также узнаете много нового об адаптивном дизайне, а также о типографике, макете, системе сеток и теории цвета. Предвидя типы проектов, над которыми вы будете работать как интерфейсный разработчик, подумайте о создании и перепроектировании веб-сайтов.Чтобы быть фронтенд-разработчиком (иногда его даже называют Javascript-разработчиком), вам не нужны навыки серверной разработки. Сайты, созданные интерфейсными разработчиками, не будут взаимодействовать с информацией, хранящейся в базе данных, чтобы быть функциональными. Контент будет «фиксированным», что означает, что большие фрагменты новых данных не будут загружаться постоянно. У владельцев малого бизнеса и ресторанов обычно есть отличные примеры статичных сайтов.

Задание программирования переднего плана

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

• Front End Developer
• Web Designer — еще одно распространенное название.
• UI / UX-дизайнеры — это фронтенд-разработчики, которые сосредоточены на пользовательском интерфейсе и пользовательском опыте соответственно.UI-дизайнеры оттачивают визуальные аспекты дизайна сайта, в то время как UX-дизайнеры проводят множественное пользовательское тестирование, чтобы убедиться, что сайт хорошо работает с предпочтительными пользователями. (Ознакомьтесь с опытом UX-дизайна одного выпускника GA.)

По данным PayScale, средняя начальная зарплата фронтенд-разработчиков по стране составляет около 67 тысяч долларов. Заработная плата варьируется от 42 до 108 тысяч долларов в зависимости от опыта, местоположения и отрасли. В Нью-Йорке стартовая зарплата составляет около 78 тысяч долларов с приблизительным диапазоном до 115 тысяч долларов.Не так уж и плохо.

Курсы внешнего программирования

Думаете о разработке интерфейса для карьеры? Обратите внимание на эти школы (в нашем каталоге их более 100, в которых преподают интерфейсную разработку!), У которых есть отличные отзывы об их курсах по разработке интерфейса:

Back End Разработка

Что такое внутренняя разработка?

Определение: Back-end разработка относится к серверной части приложения и всему, что обменивается данными между базой данных и браузером.

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

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

Многие серверные разработчики знают языки интерфейса, такие как HTML и CSS, но им необходимо использовать такие языки, как Java, PHP, Ruby on Rails, Python и .Net, чтобы выполнять работу серверной части. Back-end-разработчики больше всего сосредоточены на отзывчивости и скорости сайта.Эти языки используются для создания динамических сайтов, которые отличаются от статических сайтов тем, что на этих типах сайтов хранится информация из базы данных. Контент на сайте постоянно меняется и обновляется. Примеры динамических сайтов включают Facebook, Twitter и Google Maps.

Задание программирования серверной части

По данным PayScale, средняя начальная зарплата серверных разработчиков по стране составляет около 70 тысяч долларов. Заработная плата варьируется от 38 до 117 тысяч долларов в зависимости от опыта, местоположения и отрасли.По данным SimplyHired, в Нью-Йорке стартовая зарплата составляет около 87 тысяч долларов с приблизительным диапазоном до 120 тысяч долларов. Опять же, не так уж и плохо.

Мы надеемся, что это руководство по разработке интерфейса и руководство по разработке интерфейса было полезным!

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

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

И используйте наш инструмент подбора Bootcamp Matching Tool, чтобы найти лучшую школу для вас!

Больше чтения:

Об авторе

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

.

Front-End vs Back-End vs Full Stack Веб-разработчики

Последнее обновление 10 января 2020 г.

Начать обучение

Вы когда-нибудь задумывались, чем каждый день занимается внешний или внутренний разработчик? Читай дальше что бы узнать!

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

Люди, ответственные за каждую часть этого опыта? Веб-разработчики.

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

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

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

Если вы пробовали себя в HTML, JavaScript или, может быть, немного в Python, но не совсем уверены, какой путь выбрать, эта полезная информация для вас.

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

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

НАВЫКИ И ИНСТРУМЕНТЫ

Front-end разработчики несут ответственность за пользовательский код веб-сайта и архитектуру его иммерсивного взаимодействия с пользователем. Для достижения этих целей разработчики интерфейсов должны владеть тремя основными языками программирования: HTML, CSS и Javascript. Помимо свободного владения этими языками, интерфейсные разработчики должны быть знакомы с такими фреймворками, как Bootstrap, Foundation, Backbone, AngularJS и EmberJS, которые обеспечивают великолепно выглядящий контент независимо от устройства, и библиотеками, такими как jQuery и LESS, которые упаковывают код в более полезную, экономящую время форму.Многие списки вакансий интерфейсных разработчиков также требуют опыта работы с Ajax, широко используемым методом использования Javascript, который позволяет страницам динамически загружаться путем загрузки данных сервера в фоновом режиме.

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

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

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

В целом, интерфейсный разработчик отвечает за дизайн интерьера дома, построенного внутренним разработчиком. Вкус и стиль декора диктует домовладелец. Как сказал Грег Матранга, директор по маркетингу продуктов в Apptix, о команде разработчиков внешнего и внутреннего интерфейса, за которыми он наблюдает: «Разработчики, которые работают над интерфейсом, иногда более взволнованы тем, что они делают, потому что они на самом деле могут использовать свой творческий потенциал.”

КАК ПЕРЕВОДИТЬ

Все, что вы видите на этом веб-сайте сейчас, стало возможным благодаря интерфейсному разработчику. Дизайнер создал логотип и графику, фотограф сделал снимки, а копирайтер написал текст. Но фронтенд-разработчик собрал все эти части, перевел их на веб-язык и создал опыт, который вы получаете с каждой страницей. Чтобы взять один конкретный пример, прокрутите вверх и вниз на главной странице Udacity. Обратите внимание, как буква «U» исчезает и появляется снова? Это дело рук фронтенд-разработчика.

Что такое внутренний разработчик?

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

НАВЫКИ И ИНСТРУМЕНТЫ

Чтобы сервер, приложение и база данных взаимодействовали друг с другом, разработчики серверной части используют серверные языки, такие как PHP, Ruby, Python, Java и.Net для создания приложения и таких инструментов, как MySQL, Oracle и SQL Server, для поиска, сохранения или изменения данных и их передачи пользователю во внешнем коде. Открытие вакансий для back-end разработчиков часто требует опыта работы с PHP-фреймворками, такими как Zend, Symfony и CakePHP; опыт работы с программным обеспечением для контроля версий, таким как SVN, CVS или Git; и опыт работы с Linux как системой разработки и развертывания.

Разработчики

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

«Я всегда отдавал предпочтение внутренней разработке, потому что мне нравится манипулировать данными», — сказал давний back-end разработчик Дж. П. Тото, который в настоящее время является разработчиком программного обеспечения для Wildbit. «В последнее время публичные и частные API-интерфейсы стали важной частью обмена данными между мобильными устройствами, веб-сайтами и другими подключенными системами.Создание API-интерфейсов, которые общественность считает полезными, — очень приятная часть моей работы ».

КАК ПЕРЕВОДИТЬ

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

Что такое разработчик полного стека?

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

Разработчики полного стека — мастера на все руки.

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

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

НАВЫКИ И ИНСТРУМЕНТЫ

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

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

Изображение через TechCrunch

Изображение через TechCrunch

Независимо от конкретных инструментов, зависящих от проекта или клиента, разработчики полного стека должны быть осведомлены на каждом уровне того, как работает Интернет: установка и настройка серверов Linux, написание серверных API-интерфейсов, погружение в клиентскую сторону. JavaScript поддерживает приложение и обращает «дизайнерский взгляд» на CSS.

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

КАК ПЕРЕВОДИТЬ

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

Итог

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

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

Ознакомьтесь с курсами веб-разработки Udacity, чтобы сделать первый шаг вперед по выбранному вами пути. Удачи!

Узнать больше

.

Backend vs Frontend Web Development — Изучение обеих сторон

Автор Cody Arsenault

Опубликовано 23 февраля 2017 г.

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

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

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

Что нужно знать разработчикам интерфейсов?

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

В результате Facebook стал одним из наиболее посещаемых веб-сайтов в Интернете, а MySpace ушел в безвестность. Независимо от того, насколько плавно работает веб-сайт или сколько ценного контента он может предложить, пользовательский опыт играет важную роль в определении успеха веб-сайта.

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

HTML

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

CSS

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

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

JavaScript

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

Хотя последнее обновление HTML, HTML5, поддерживает некоторые из этих функций, начинающие разработчики окажут себе медвежью услугу, упустив из виду JavaScript. Такие фреймворки, как Backbone, React, Angular и Ember, позволяют ускорить разработку JavaScript. Если во время исследования JavaScript вы также столкнулись с Java, просто обратите внимание, что эти два языка не связаны друг с другом. Узнайте больше о разнице между Java и JavaScript.

Адаптивный дизайн

Согласно исследованию, проведенному компанией Similar Web в 2015 году, 56% трафика , ведущего на ведущие веб-сайты США, поступает с мобильных устройств, таких как смартфоны и планшеты, а не с традиционных настольных компьютеров.Эта тенденция создала проблемы для разработчиков, которые так стараются, чтобы все посетители имели одинаковый опыт при посещении их веб-сайтов, поэтому адаптивный дизайн или оптимизация веб-сайтов для адаптации к разным размерам экрана важны как никогда.

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

Воспринимаемая производительность

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

Что нужно знать backend-разработчикам?

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

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

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

Начинающие бэкэнд-разработчики следует сосредоточиться на оттачивании следующих навыков:

Язык программирования

Источник: Appflower

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

• PHP — чрезвычайно популярный язык программирования, который подходит как для начинающих, так и для опытных программистов. Первоначально он был создан в 1994 году и с тех пор значительно вырос, поэтому существует очень большого сообщества разработчиков .Кроме того, многие популярные фреймворки и системы управления контентом основаны на PHP, включая WordPress, Drupal, CakePHP и т. Д.
• Ruby легко читать и понимать людям, не имеющим предварительного знания языка. Ruby полезен для кодирования бизнес-логики, расчета данных и распределения серверов для обеспечения оптимальной производительности. Ruby on Rails, фреймворк для создания веб-приложений, особенно популярен среди малых предприятий и стартапов, и некоторые крупные компании, включая Twitter и Hulu, все еще используют его сегодня.
• Python также имеет репутацию простого читателя для некодеров. Django, популярный фреймворк для разработки веб-приложений, является эквивалентом Python для Ruby on Rails. Reddit и Dropbox — это примеры крупных веб-сайтов, построенных на Python.

Backend-разработчики также могут извлечь большую пользу из изучения других языков, таких как C #, Java, C ++ и т. Д.

Базы данных

Поскольку универсальный язык запросов к базам данных, SQL или язык структурированных запросов, необходим для каждого веб-приложения, которое необходимо хранить информацию .Независимо от того, используете ли вы Django, Ruby on Rails, WordPress или любую другую среду для создания своего веб-сайта, вы также должны использовать SQL для взаимодействия с базами данных, которые являются частью каждого серверного приложения. Несколько популярных вариантов баз данных включают Postgres, MySQL и MongoDB.

API

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

Веб-службы

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

Что должны знать разработчики внешнего и внутреннего интерфейса?

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

Системы контроля версий (VCS)

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

Источник: GitHub

На схеме выше показан базовый рабочий процесс GitHub (системная служба контроля версий).Еще один надежный провайдер VCS, который вы можете использовать, — Bitbucket.

Тестирование и отладка

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

Разработка полного стека

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

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

Backend vs frontend — выбор стороны

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

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

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

.

Я не говорю на вашем языке: интерфейс и серверная часть

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

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

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

Бесплатная пробная версия Treehouse: Хотите узнать больше о серверной и интерфейсной веб-разработке? Подпишитесь на бесплатную пробную версию Treehouse.

Различия между дизайном и разработкой на самом деле приводят к большему количеству дискуссий вокруг веб-интерфейса и внутреннего интерфейса. Что такое бэкэнд? А что такое фронтенд? Начнем с внешнего интерфейса…

Что такое интерфейс?

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

Раньше, когда кто-то обсуждал разработку, это обычно относилось к бэкэнду, но в последние годы возникла реальная необходимость различать дизайнеров, которые работали строго в Photoshop, и тех, кто мог кодировать HTML и CSS.Дело пошло еще дальше, когда дизайнеры перешли границы и начали работать с JavaScript и jQuery.

Итак, теперь, когда мы обсуждаем термин «веб-дизайн», мы действительно говорим о тех, которые работают с Photoshop и Fireworks, и тех, которые кодируют с использованием HTML, CSS, JavaScript или jQuery (здесь может быть важно указать, что jQuery — это скомпилированная библиотека Javascript).

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

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

Что такое бэкэнд?

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

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

Мы вызываем человека, который создает всю эту технологию, для совместной работы backend-разработчика .Бэкэнд-технологии обычно состоят из таких языков, как PHP, Ruby, Python и т. Д. Чтобы сделать их еще проще в использовании, они обычно расширяются такими фреймворками, как Ruby on Rails, Cake PHP и Code Igniter, которые делают разработку быстрее и упрощают совместную работу. .

Многие веб-профессионалы, которые только начинают работать в этой области, возможно, слышали, как многие люди говорят о WordPress. WordPress — хороший пример совместной работы внешнего и внутреннего интерфейса, потому что WordPress — это платформа с открытым исходным кодом, построенная на PHP, которую вам необходимо установить на свой сервер с базой данных.Затем дизайнеры настраивают внешний вид и функциональность сайтов WordPress с помощью CSS, jQuery и JavaScript.

Заключение

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

Границы между дизайном и разработкой кажутся с каждым днем ​​все более и более размытыми, но в основном они все еще очень разные.

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

Что вы думаете о дизайне и разработке, а также о интерфейсе по сравнению с серверной частью? Пожалуйста, присоединяйтесь к беседе, оставив комментарий ниже. Ура!

---

Разработчиком может быть любой.

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

.