Фронтенд и бэкенд: Frontend и Backend-разработка: что это, в чем разница

бэкенд, фронтенд, база данных, API – ProductSense Academy

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

В это модуле вы узнаете, как связаны и взаимодействуют фронтенд и бэкенд, какими бывают базы данных и как устроены API.

Эта тема периодически всплывает в сообществе и вызывает много споров. Должен ли менеджер продуктов большого IT-проекта разбираться в том, как работает сам проект? Кто-то говорит — нет, кто-то — да. А правы и те, и другие.

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

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

Не у всех менеджеров продуктов есть техническое образование. Однако многие навыки можно приобрести самостоятельно. По образованию я физик и инженер, не программист. Но когда начал работать с IT (сначала со стартапами, а потом и в «Яндексе»), прокачал навыки программирования. Расскажу, что помогает лично мне.

• SQL. Умение создавать базовые запросы, простые выгрузки, условия (WHERE) и JOIN-таблицы, зайти в базу данных и посмотреть, какой эффект принесла фича, сколько было кликов. Вам не нужно ждать, пока все это сделают аналитики, вы сами можете за пять минут построить график. Выучить SQL — просто, надо всего лишь пройти двухдневный курс на Stepik или YouTube. Затем пробуйте, просите коллег помогать вам с запросами и примерами. Постепенно вы набьете руку и у вас появится запас базовых шаблонных запросов.  
• Базовое знание языка программирования. Python — самый простой язык. Достаточно пройти два-три курса на Stepik за несколько выходных и создать примеры, чтобы научиться писать несложные алгоритмы и понять, что такое переменные и функции, как работают циклы.
  • Для практики рекомендую использовать HackerRank. Там можно решать легкие задачи, получать баллы, подсматривать примеры решений, общаться с другими программистами. Так вы постепенно научитесь писать простые скрипты. 
  • Также рекомендую Jupyter Notebook — веб-интерфейс, который позволяет писать программы на Python без необходимости компилировать их отдельно. В нем можно проводить простые вычисления. Также пригодятся Pandas и NumPy. За полчаса, пока вы на работе завариваете утренний кофе, ваши данные выгрузятся, прокрутятся в Jupyter Notebook и, возможно, вы найдете себе гипотезу на день.
• Базовое знание работы архитектуры сервисов. Чтобы в общих чертах понимать, как работают IT-сервисы, я советую освоить Python Flask. Это очень простой пакет для запуска сайтов. Начальные знания можно получить на YouTube — посмотрите любой ролик «как создать собственный сайт за полчаса». Соберите сайт и запустите его на локальной машине. Так вы поймете базовые концепции: сервер, запросы POST и GET, HTML. Можно построить красивый сайт на Bootstrap — тогда почти не понадобится писать HTML-код. Я, например, за час создал утилиту, которая помогла мне тестировать фичу, на Flask и Bootstrap. Разработчикам, которые делают то же самое по корпоративным стандартам, потребовалось бы на это гораздо больше времени. Тестирование прошло успешно и мы сделали рабочую версию этой утилиты — но если бы она не взлетела, ее было бы легко удалить.
• Базовое знание продукта, над которым вы работаете. Регулярно общайтесь с техлидом, спрашивайте, как работает сервис. Сначала многое может быть непонятно, но со временем вы разберетесь во всех важных нюансах. К тому же техлиду будет приятно, что менеджер интересуется работой сервиса, хочет понять, почему разработчики делают продукт не очень быстро, какие технические проблемы существуют. 

Если у вас есть эти навыки, вы будете говорить с разработкой на одном языке, быстрее и точнее делиться мыслями, идеями, гипотезами. В противном случае вы приходите к разработчику и говорите: «Сделай мне, пожалуйста, продуктовую фичу». Он отвечает: «Нет, мы не сможем ее сделать, потому что есть технические проблемы». Если вы не знаете, как работает сервис, диалог заканчивается: менеджер говорит в терминах продукта, а разработчик — в технических терминах. Задача менеджера — подогнать продукт под требования техлида, понять его и подстроиться, но ни в коем случае не вмешиваться в техническую часть и ничего не советовать. Придумывать решения за разработчиков — большая ошибка.

Следующий модуль — «Под капотом веб-сервиса: логика, микросервисы, монолит».

2022: действительно ли разработка фронтенда проще, чем бэкенда?

Статья написана студентом Хекслета. Мнение автора может не совпадать с позицией редакции

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

Почему некоторые программисты говорят, что фронтенд проще, чем бэкенд?

Почему некоторые, обычно старшие, программисты говорят, что бэкенд сложнее, чем интерфейс? Вероятно, потому что в 90-е годы разработка фронтенда действительно была не такой уж сложной. Конечно, были проблемы с совместимостью браузеров, а JavaScript был недостаточно развит и глючил. Тем не менее интерфейс веб-сайта был довольно простым — как с точки зрения дизайна, так и с точки зрения технических стандартов программирования. Не было никаких интерфейсных фреймворков, таких как React, Vue или Angular, и большая часть прикладной логики выполнялась на бэкенде. По этой причине разработка бэкенда в 90-е годы была намного сложнее, чем разработка фронтенда.

Чем фронтенд сложнее?

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

1) Необходимость идти в ногу с быстро меняющимися возможностями.

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

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

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

2) Больше принципов, которые следует иметь в виду: дизайн, пользовательский интерфейс, функционал интерфейса, программирование.

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

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

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

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

3) Дополнительные инструменты для изучения.

Постоянно меняющийся ландшафт также означает, что нужно осваивать больше инструментов, чтобы оставаться на высоте. С заменой Gulp и Grunt на Webpack, Angular на React и множеством других инструментов, внедряемых каждый день, таких как Yarn и NPM, нужно держать руку на пульсе, чтобы не остаться за бортом. Иногда, честно говоря, кажется, что ты никуда не идешь, просто чтобы не отставать.

4) Тестирование и тестовые наборы.

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

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

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

Почему бэкенд сложнее фронтенда?

Есть конкретные причины, почему бэкенд-разработку можно считать более сложной:

1) Более крутая кривая обучения начинающих.

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

2) Менее визуальный, чем интерфейс.

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

3) Множество внутренних языков

Наконец, бэкенд может быть сложнее в освоении, потому что существует много бэкенд-языков: PHP, C#, Java, Python, Ruby и т.д. А во фронтенде — только HTML, CSS и JavaScript. Очевидно, есть чему поучиться, но большая часть основана на этих языках.

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

Так что же на самом деле проще: разработка интерфейса или бэкенда?

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

Как говорится, без труда не вытащить и рыбку из пруда!

Front-End и Back-End веб-разработка

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

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

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

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

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

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

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

Front-end разработчики должны знать:

• HTML5
• CSS
• JavaScript
• Ajax

Back-end разработчики должны знать:

• JavaScript
• SQL
• Java
• C#
• Python
• PHP

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

Разработчик веб-интерфейса

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

Обязанности:

• Разработка новых пользовательских функций в веб-браузерах
• Разработка и реализация внешнего интерфейса для веб-сайтов сложных веб-приложений с использованием современных фреймворков JS и CSS Создание повторно используемого кода и библиотек для будущего использования
• Оптимизация внешнего интерфейса приложения для максимальной скорости и масштабируемости
• Код для современных передовых практик REST или GraphQL

Зарплата:

• $61,000 – $118,000 в год; $88 680 в среднем

Навыки:

• Владеет HTML, CSS и JavaScript
• Понимает сценарии на стороне клиента и среды JavaScript, такие как jQuery
• Понимает принципы веб-дизайна
• Имеет базовые знания графического редактора, такого как Photoshop

Back-End Web Developer

Описание: back-end разработчик ориентирован на серверную архитектуру веб-приложений.

Обязанности:

• Разработка и внедрение серверной веб-архитектуры, такой как серверы, базы данных, операционные системы и API-интерфейсы
• Интеграция элементов, ориентированных на пользователя, с серверной логикой
• Создание повторно используемого кода и библиотек для будущего использования масштабируемость
• Внедрение решений по обеспечению безопасности данных

Заработная плата:

• 56 000–128 000 долларов США в год; В среднем 88 488 долларов (самая последняя информация Glassdoor о зарплате бэкэнд-веб-разработчика относится к 2016 году)

Навыки

• Владеет такими языками, как JavaScript (NodeJS), Ruby, Java, SQL и C#
• Обладает практическими знаниями PHP, Ruby, Python и .Net
• Обладает практическими знаниями на стороне сервера Препроцессоры CSS, такие как LESS и SASS
• Понимание доступности и соответствия требованиям безопасности
• Способность выполнять аутентификацию и авторизацию между системами и серверами
• Способность интегрировать несколько источников данных в единую систему
• Способен управлять хост-средой
• Понимает, как масштабировать приложения
• Понимает миграцию данных, сценарии и преобразование
• Способен настраивать и поддерживать резервное копирование
• Понимает управление версиями и бизнес-логику
• Понимает управление сеансами

6

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

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

[cta id=”589″ vid=”0″]

Frontend и Backend разработка

Основы сборки

Типичное приложение имеет frontend (клиентский компонент) и backend (серверный компонент).

• Внешний интерфейс относится к пользовательскому интерфейсу, который получает пользовательский ввод. Он создан с использованием таких технологий, как HTML, CSS и JavaScript для веб-приложений и Objective-C, Swift, Java или Kotlin для приложений iOS и Android.

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

Square предоставляет библиотеки API, которые разработчики встраивают при разработке внешнего и внутреннего интерфейса приложения.

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

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

Square поддерживает обработку платежей по нескольким каналам, включая онлайн, в приложении и лично (см. Платежи). Square предоставляет клиентские библиотеки для этих сценариев.

Некоторые из этих клиентских библиотек необходимо использовать в сочетании с серверным API Square. К ним относятся:

• Оплата онлайн обработка. Разработчики могут использовать SDK Square Web Payments для обработки платежей в веб-приложениях. Этот SDK создает платежный токен на основе платежной информации, которую предоставляют пользователи. Разработчики должны реализовать серверную часть, которая вызывает API Square Payments для обработки платежей с использованием платежных токенов в качестве источника платежа. Пример приложения см. в разделе Пример обработки платежей на GitHub.

• Оплата в приложении обработка. Это относится к мобильным приложениям, созданным продавцами, которые покупатели устанавливают на свои устройства Android или iOS. Эти приложения встраивают SDK Square In-App Payments в интерфейсную разработку. Этот SDK создает безопасный платежный токен. Приложение должно предоставить сервер (внутреннюю часть), который вызывает API платежей для принятия платежа. Пример приложения см. в разделе SDK для платежей в приложениях: быстрый старт.

  Square также предоставляет плагины с открытым исходным кодом, плагин Flutter и плагин React Native для Square In-App Payment SDK.

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

• Reader SDK. Разработчик встраивает Reader SDK во внешний интерфейс своего мобильного приложения для обработки платежей. В этом случае приложение использует Reader SDK, подключенный к их мобильному устройству, для обработки платежей. Обратите внимание, что Reader SDK доступен только в США. Пример см.

  в разделе Reader SDK: быстрый старт.

  Square также предоставляет плагины с открытым исходным кодом, плагин Flutter и плагин React Native для Square Reader SDK.

• API точек продаж. Чтобы обрабатывать личные платежи с использованием оборудования Square, разработчики могут внедрить Point of Sale API в свое мобильное приложение. API просто действует как переключатель приложений. Когда приходит время для обработки платежа, API плавно переключается на приложение Square Point of Sale и собирает платеж с помощью Square Reader. Приложениям не нужно выполнять какие-либо внутренние вызовы Square API. Примеры см. в разделе Point of Sale API: обзор.

Square API (и соответствующие SDK-оболочки) интегрируются с серверной разработкой. Ваш сервер приложений отправляет эти запросы API в Square и обрабатывает ответы от Square. Например:

• API бронирования. Приложения могут использовать Bookings API, чтобы позволить покупателям управлять бронированиями у продавца Square.