Бэкэнд что это: бэкенд-разработчик / Блог компании RUVDS.com / Хабр

Содержание

введение, инфраструктура бэкэнд / Блог компании Surf / Хабр

Оглавление

1. Введение

2. Backend

2.1. Инфраструктура.

2.2. Доменное имя. SSL.

2.3. Серверное приложение на Dart.

…

3. Web

3.1. Заглушка «Under construction»

…

4. Mobile

…

Введение

Меня, Flutter-разработчика, знакомые часто спрашивают: «Что же такое язык Dart?». Качают головой со словами: «А вот Петя серьёзные транспорты на Java пишет, а в Яндексе вообще плюсы в проде…». Ну что ж, пожалуй, действительно, Dart далёк от практик «фабрик для создания фабрик» из Java. Однако если стоит задача реализовать клиентские приложения сразу для нескольких платформ, не утонув в потоке задач по синхронизации разработчиков разных целевых ОС; создать целостный UI, узнаваемый, но специфичный для Android, iOS и веб и в целом уложиться в адекватные бюджет и сроки, — здесь Flutter не имеет конкурентов. И эти вопросы стоят вдвойне если у вас… стартап.

Итак, легенда: некий стартап решил создать новый сервис… ну, например, для

обмена списками покупок

Такая себе идея для стартапа, я знаю, но если я выпущу ещё один ToDo лист в этот мир, мне будет стыдно 🙂

между пользователями сервиса. Цель стартапа — выпустить MVP за три месяца на трех платформах (плюс четвертая — сервер, конечно).

10 лет назад я бы сказал, что этот кейс не имеет решения и постарался бы держаться от него подальше, 3 года назад решением мог стать стек ReactNative/React/NodeJs, в 2020 году для этого есть Dart. Добро пожаловать в атмосферу разработки альфа версии сервиса, я постараюсь наглядно пройти и объяснить весь процесс разработки. Код всех приложений будет выложен в паблик. Комментарии, включая набросы и холивары, приветствуются. Спросить автора «по существу» или просто посоветоваться можно в Telegram канале нашего отдела.

Инфраструктура бекэнд

Типовым способом размещения серверного приложения является, конечно, VPS (виртуальный приватный сервер). Фактически — это часть физического сервера в дата центре, ресурсы которого (ядра процессора и оперативная память) разделены с помощью технологии виртуализации (о наиболее распространённых технологиях аппаратной виртуализации можно почитать здесь XEN, KVM). Внимание: технологии программной виртуализации (OpenVZ, Virtuozzo) для нашей задачи могут не подойти из-за конфликтов с Docker и агрессивным оверселлингом (зачастую, при внимательном прочтении договора аренды такого VPS, можно обнаружить, что провайдеры гарантируют «не менее 5%» (!) утилизации ядра арендуемого процессора. Это означает, что провайдер планирует продать наше ядро процессора 20 (!) раз).

Итак, приобретём бюджетный VPS со следующими характеристиками: 1 ядро процессора, 1ГБ оперативной памяти, 10ГБ накопителя (в моём случае, это гибридный HDD). В качестве операционной системы выберем Ubuntu, желательно одной из LTS версий. После чего в электронную почту придёт сообщение об активации сервера с логином и паролем доступа по SSH (зашифрованный доступ к консоли операционной системы нашего VPS) в формате SSH:

IP-адрес: 91.230.60.120

Пользователь: root

Пароль: <Пароль>

Проверим подключение, введя в командной строке:

ssh [email protected]

и, по запросу:

password: <Пароль>

Результатом должен быть вывод сведений о виртуальном сервере и поле ввода внизу:

Server is hosted by хххххххххх

Hostname: 91.230.60.120

Kernel: 3.19.0-22-generic (Ubuntu хх.хх LTS)

Uptime: 09:07:06 up 3 days, 17:17, 1 user, load average: 0.00, 0.01, 0.05

CPU: Intel® Xeon® CPU 0 @ 2.00GHz (1 cores)

Memory: 989 MB total / 723 MB free

[email protected]:~$

Поздравляю, наш виртуальный сервер создан и доступен для работы.

Теперь определимся со структурой бекэнд. Нам понадобится HTTP сервер. Мы будем использовать NGINX. Его задачами будут:

Раздача статических файлов (файлы веб приложения).

Раздача служебных ресурсов, например, файлов подтверждения владения доменом для мобильных приложений, сведений о владельце для получения SSL сертификатов Let’s encrypt и пр.

Reverse proxy для доступа к серверным приложениям.

Шифрование соединений — https.

Два серверных приложения:

Приложение регистрации и авторизации пользователей. Назовём его auth_app.

Приложение с данными. Назовём его app.

Для каждого из приложений п.2 нам понадобится отдельная база данных PostgreSQL.

Приложение для автоматического получения и обновления сертификатов шифрования SSL (в следующей статье).

Очевидно, что такой «зоопарк» приложений необходимо изолировать друг от друга, а также заблокировать доступ извне. Для этого мы будем использовать технологию контейнеризации Docker и менеджер контейнеров Docker compose. В виде схемы это можно представить так:

Разработку будем вести в IDE Visual Studio Code от Microsoft, которая, благодаря множеству доступных плагинов, позволит работать со всеми необходимыми технологиями. Также необходимо установить следующие расширения:

После перезапуска VScode подключимся к нашему VPS. Нажимаем F1 и начнем вводить команду:

Remote-SSH: connect to  Host…

далее новое подключение:

+ Add New Ssh Host

затем:

ssh root@<ip-адрес сервера>

Откроем окно терминала VScode (Menu/Terminal/New terminal) и проверим системные ресурсы командой:

top

Готово, доступ к консоли и файловой системе VPS получен:

Утилита top будет использоваться довольно часто, поэтому установим её псевдографическую версию htop:

Ctrl-C #Завершаем выполнение утилиты top

apt-get update #Обновляем установленные пакеты

apt-get install htop #Устанавливаем htop

htop #Запускаем

Теперь необходимо установить Docker и Docker compose:

Ctrl-C #Завершаем выполнение утилиты htop

Поскольку docker отсутствует в официальном репозитории Ubuntu, установим дополнительный репозиторий

apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common #Устанавливаем необходимые утилиты

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - #Устанавливаем ключ репозитория docker

add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" #Добавляем репозиторий

apt-get install docker-ce docker-ce-cli containerd.io #Устанавливаем

curl -L "https://github.com/docker/compose/releases/download/1.26.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose #Скачиваем менеджер Docker compose

chmod +x /usr/local/bin/docker-compose #Устанавливаем разрешение для загруженного файла «исполняемый файл»

ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose #Добавляем символьную ссылку в директорию исполняемых файлов

 docker  --version #Проверяем

docker-compose --version

Отлично, сервер готов к тестовому развёртыванию сервиса.

Теперь установим Docker desktop на нашем локальном ПК для разработки. Установщик для Windows 10, версия для MacOS здесь. Будет установлен не только Docker, но и Docker toolbox, в который входят Docker compose и графические утилиты для работы с контейнерами.

Откроем новое окно VScode, Menu/File/Open folder… Создадим новую папку нашего проекта, например, Srv и откроем её. В этой папке создадим файл docker-compose.yaml:

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

Здесь необходимо остановиться и уточнить разницу между образом и контейнером Docker. Контейнер — это приложение + его зависимости (например, пакеты и библиотеки) + операционная система, которую можно с помощью Docker запустить как обычное приложение. А образ — это подготовленный к запуску и упакованный в архив контейнер. Таким образом, весь наш бекэнд будет представлять собой набор контейнеров с описанием сценария их запуска.

Первым контейнером, который мы запланировали станет HTTP сервер NGINX. И давайте подготовим необходимый образ… или нет? Дело в том, что для очень многих веб приложений и сред исполнения их разработчиками или комьюнити уже собраны необходимые образы и размещены в публичном реестре DockerHub. Разумеется такой широко используемый образ уже собран и ожидает нас по этой ссылке.

Обратите внимание на список — это различные версии, они отличаются и версиями самого NGINX и дополнительными инструментами (например, установленным PERL). Для разработки можно использовать тэг «latest» (последняя стабильная версия на момент запроса образа), но для развёртывания на сервере, конечно, стоит использовать конкретную версию. В данный момент это образ nginx:1.19.0.

Здесь и далее необходимые пояснения к содержимому docker-compose.yaml я буду указывать в комментариях в самом листинге файла:

Сохраним изменения в файле, откроем консоль VScode и выполним команду запуска сценария

docker-compose up

Этой командой был не только запущен сценарий, но и вывод консоли контейнера был направлен в консоль хоста. Теперь, если в адресной строке браузера обратиться к локальному хосту на порте 8081 будет получена стандартный ответ NGINX:

Наш первый контейнер уже работает. Обычно запуск сценария выполняется командой:

docker-compose up -d

это позволяет запустить контейнеры в режиме сервиса (без вывода в консоль). Остановка контейнеров сценария выполняется командой:

docker-compose down

Для тестирования http запросов в VScode есть удобное расширение REST client.

Установим его и напишем первый отладочный тест нашего сервиса. Для этого создадим файл client.http в папке test/http_dev/:

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

Теперь давайте заглянем внутрь контейнера. Остановим выполнение сценария в консоли:

Ctrl-C

и запустим с флагом:

docker-compose up -d

Теперь запросим список выполняемых в данный момент контейнеров (процессов):

docker-compose ps

В списке выполняемых только один контейнер. Давайте откроем его:

docker exec -it srv_web_1 bash

Эта команда выполняет (exec) приложение bash (командная оболочка Linux) в контейнере srv_web_1 и не дает закрываться консоли (флаги -it):

Команда ls покажет стандартную структуру папок Linux:

Нас интересует файл /etc/nginx/conf.d/default.conf — настройки NGINX, для просмотра можно использовать утилиту cat

cat /etc/nginx/conf.d/default.conf

В настройках NGINX один блок (так называемый location), в котором включено прослушивание порта 80 и раздача статических файлов из папки контейнера /usr/share/nginx/html. Можно попробовать внести изменения в файл настройки NGINX и перезапустить его, применив изменения, но при перезапуске сценария контейнер будет восстановлен из образа и никакие наши изменения не сохранятся. Это неправильный путь.

Выйдем из консоли контейнера:

Ctrl-D

Мы напишем свой файл настройки и разместим свои статические файлы, а при запуске будем их монтировать в контейнер NGINX. Создадим файл default.conf в папке /conf.d нашего проекта:

Создадим заглушку статического файла /public/index.html:

Теперь в сценарии запуска docker-compose.yaml смонтируем наши папки в файловую систему контейнера:

Обратите внимание, что содержимое папки проекта ./conf.d заменит содержимое контейнера в /etc/nginx/conf.d/, а в корневую папку папку контейнера будет смонтирована папка ./public.

Перезапустим сценарий:

docker-compose restart

Тестовый запрос:

Давайте посмотрим на файл default.conf. Обратите внимание, что мы отключили логирование доступа к статическим файлам access_log off. Это хорошее решение для прода, но очень неудобное при тестировании и разработке. Давайте создадим тестовые файл конфигурации NGINX /conf.dev.d/default.conf и сценарий docker-compose.dev.yaml.

Остановим сценарий:

docker-compose down

и запустим уже с флагами имен файлов:

docker-compose -f docker-compose.yaml -f docker-compose.dev.yaml up

При таком запуске сценария сначала будет прочитаны настройки из файла docker-compose.yaml, а затем будут добавлены или заменены совпадающие поля из docker-compose.dev.yaml (ports, volumes). Проверим логирование повторив запрос:

Итак, нам осталось выполнить копирование и запуск на сервере. Создадим на сервере папку /opt/srv_0/ (мы ведь ещё не закрыли окно VScode c SSH соединением к VPS) и скопируем в неё всё содержимое нашего проекта командой:

scp scp -r ./* [email protected]:/opt/srv_0/

Теперь на сервере в папке проекта /opt/srv_0/ выполним команду:

docker-compose up -d

Напишем ещё один http тест, теперь уже для VPS:

Ну или откройте в браузере ссылка.

→ Исходный код github

Вместо заключения

Итак, сделан первый шаг. Мы успешно раскатили на боевой сервер приложение. Во второй статье мы продолжим настройку сервера: назначим доменное имя и установим сертификат шифрования SSL. В третьей статье напишем flutter web приложение с обратным отсчётом времени до запуска нашего сервиса, соберём его и разместим на нашем сервере. В четвертой статье напишем и соберём нативный сервер под Linux на языке Дарт, который станет основой для приложений авторизации и данных нашего сервиса.

Комментарии и предложения приветствуются. Пообщаться с автором можно в Telegram-канале.

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

Любой backend-разработчик столкнётся с тестированием API. Для этого нужны запросы PUT, DELETE, PATCH и POST. Протестировать их работу невозможно через командную строку. Приходится писать запросы в коде PHP и использовать CURL, что занимает много времени и создаёт лишние проблемы.

Советуем программу Postman, где тестирование максимально комфортно. Просто вбивайте URL и параметры, и ответ вернётся в трёх форматах: как запрос выглядит на сайте, в JSON и в текстовом виде. Postman невероятно удобен и очень облегчает разработку API.

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

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

Рекомендуем три системы:

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

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

3. Ещё одно решение кроссплатформенного версионизатора — программа от Atlassian.

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

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

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

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

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

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

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

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

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

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

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

Спойлер

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

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

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

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

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

result: null

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

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

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

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

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

Эту технику принято называть BFF (Backend For Frontend). Впервые этот термин ввел SoundCloud в 2015 году, и схематично идею можно изобразить в таком виде:

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

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

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

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

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

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

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

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

Фильтрация. Клиент получает только то, что ему нужно, ни больше ни меньше.

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

Кэширование. Ваш повторный агрегированный вызов не будет лишний раз никого дергать, а просто вернет 304 Not Modified.

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

Микросервисы. Если у вас на бэке монолит, то BFF — это первый шаг к микросервисам.

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

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

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

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

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

GraphQL

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

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

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

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

Best Friends Forever

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

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

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

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

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

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

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

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

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

Swagger

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

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

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

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

Faker.js

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

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

Валидация

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

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

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

Выводы

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

Требуем Swagger-документацию. Нет документации — работа бэка не выполнена.

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

Поднимаем фейковый сервер и начинаем работать над фронтом не дожидаясь реального API.

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

См. также

→ Как построить REST-like API в крупном проекте

→ Backend In the Frontend

→ Using GraphQL as BFF Pattern Implementation

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

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

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

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

Предыстория

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

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

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

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

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

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

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

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

Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

API

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

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

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

Высокая масштабируемость, чтобы новый API не мешал наращивать функциональность.

Стабильность и согласованность.

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

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

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

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

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

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

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

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

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

Результат

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

За отображение отвечает фронтенд, а за данные — бэкенд.

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

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

Появилась возможность использования mock-данных для фронтенда, когда ещё не готов бэкенд.

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

Появилась возможность планировать работы на спринт параллельно.

Для реализации отдельных микросервисов теперь можно набирать разработчиков, не знакомых с C++.

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

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

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

Что нужно знать для backend разработки? — Хабр Q&A

0. В начале 10 раз подумать — зачем? Если хочется больше денег, то тогда быстрее и намного проще стать Senior Frontend. Так как бекенд намного глубже и сложнее, а платят почти так же.

1. В вашем случае действительно лучше всего начать с Node.js + express.js + любая БД, которая будет в том видео курсе, который вы будете смотреть. Так вы сможете сделать свое первое API для фронтенда и понять, что такое бекенд. Но стоит понимать, что Node.js это нишевое решение и для большинства сайтов оно не подойдет по многим причинам.

2. PHP СРАЗУ ЗАБЫТЬ!
Сказки про то, что на PHP написано 99% всех сайтов уже 10 лет не актуальны, а их все повторяют. Особенно смешно когда рассказывают про ВКонтакте и Facebook как о примерах проектов на PHP. И Вк и ФБ давно избавились от чистого пхп и написали свои трансляторы PHP в C++. (KittenPHP и HipHop).
Хотя после JS пхп может показаться хорошим языком (богаче стандартная библиотека, ООП) но не стоит заблуждаться — есть языки намного лучше/проще/мощнее/современнее.
Для тех, кто хочет поспорить — Про 50 оттенков PHP хорошо написано тут: https://habr.com/ru/post/142140/
Хотя тягу истинных индусов кататься на слоне не унять ни какими доводами:)

3. Java, C# — сомнительно. Да, на них пишут большие и серьезные проекты и платят хорошие деньги. Но часто ли пишут такие проекты? Особенно в СНГ. И берут ли на них новичков?:) Лучше вначале хорошо изучить спрос на июней на фриланс биржах и количество вакансий, ОСОБЕННО, если хотите работать удаленно.

Я 4 года был fullstack-разработчиком. Писал на PHP/CodeIgniter/Kohana/Zend/Yii1,2/Symfony/Laravel 4,5/MySql/JQuery/Vue.js. С опытом я понял, что у PHP много проблем. Развитие языка остановилось/идет не туда, сам язык плохо спроектирован. И я стал активно изучать на какую платформу/язык мне перейти.
Попробовал Java, Ruby, Objective-c/Swift, Node.js, Python.

Остановился на Python/Django framework/PostgreSQL. На Python можно писать как асинхронные приложения (здравствуй Node.js) так и синхронные (привет PHP). Django на голову выше любого PHP фреймворка, а порог вхождения ниже чем у Symfony, Zend и примерно такой же как у Laravel, Yii.
В целом Python как язык спроектирован лучше PHP, у него больше возможностей, он современнее и активнее развивается.

Переход на новый язык оказался не таким быстрым и простым, как казалось сначала). Хоть и переходил с бекенда на PHP в бекенд на Python. Кроме самого языка нужно еще освоить новый стек популярных для него фреймворков, библиотек, инструментов. А так же заново наработать портфолио. У меня выход на прежний уровень ЗП занял 2 года. Работаешь на старом стеке, что бы было что кушать, а после работы и по выходным изучаешь новый, если мотивация не закончится:)

P.S Не советую быть Fullstack-ом. Лучше стать грамотным специалистом в одной области чем недоучкой в двух. Платят middle fullstack так же как и middle frontend или middle backend по отдельности. Да, работу найти fullstack-у чуть легче но и обязаностей будет намного больше.

Что такое внутренняя разработка? — Простой программист

Программные приложения похожи на айсберги.

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

В главе о веб-разработке мы в основном говорили о веб-разработке, поскольку она связана с прямым взаимодействием с конечным пользователем — то, что мы могли бы назвать «интерфейсной веб-разработкой».”

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

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

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

Все это происходит за кадром.

Внутренний разработчик — это тот разработчик, который делает все это возможным.

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

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

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

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

Проще говоря: back-end разработка — это просто написание кода, который нельзя увидеть напрямую.

Чем занимаются внутренние разработчики?

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

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

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

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

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

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

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

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

Back-end разработчики обычно тратят гораздо больше времени на реализацию алгоритмов и решение проблем, чем front-end разработчики.

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

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

Первичные технологии и навыки внутренней разработки

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

Один из важных навыков, который необходим back-end разработчикам, связан с SQL и базами данных .

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

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

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

Например, в то время как интерфейсный веб-разработчик может быть сосредоточен на HTML, CSS и JavaScript, внутреннему разработчику может потребоваться дополнительная информация о веб-фреймворках PHP, Ruby on Rails, ASP.NET MVC или любой другой серверной инфраструктурой веб-разработки, которая используется для создания приложения.

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

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

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

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

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

На самом деле, разработка полного стека включает в себя работу над всеми компонентами и уровнями системы или стеком разработки программного обеспечения . Это может даже включать знание серверного оборудования и архитектуры, или того, что можно считать «операциями разработки».

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

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

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

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

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

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

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

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

Тогда вы все еще можете называть себя «full-stack», но на практике вы будете гораздо более полезны для команды.

Руководство для начинающих для Backend-разработчиков на 2020 год

Backend-разработка (также стилизованная как back-end или back-end разработка) — это навык, который поддерживает Интернет. И все же он делает это скромно, без лишнего шума, позволяя людям просматривать свои любимые сайты, даже не зная обо всей работе, проделанной внутренним разработчиком или командой.

Итак, чтобы помочь развеять эту загадку… что такое , что такое бэкэнд-разработка ? Как это работает?

В этом специальном гостевом посте Кристал Толани из GoSkills пишет о различных типах бэкэнд-языков, о том, что вы можете с ними делать как бэкэнд-разработчик, компаниях, которые их используют, и (вопрос о деньгах!) О том, какую зарплату вы можете получать, специализируясь в определенных серверных навыках.

Вот Кристал!

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

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

Jump Ahead: 7 типов языков внутреннего программирования

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

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

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

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

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

Интерфейсное программирование против внутреннего программирования

Интуитивно понятно, что другая сторона backend-разработки — это front-end.

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

Что такое бэкэнд в разработке? (Объясняется простым английским языком)

Backend — это технический термин, используемый для описания области конфигурации приложения. В WordPress бэкэнд используется для определения административной области веб-сайта, где вы создаете контент, устанавливаете плагины, управляете настройками дизайна и т. Д. Бэкэнд WordPress также известен как wp-admin или админка WordPress.

Бэкэнд WordPress

Вы можете войти в бэкэнд WordPress, добавив / wp-admin / в конце URL-адреса вашего веб-сайта.

Бэкэнд WordPress состоит из следующих страниц:

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

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

Media позволяет загружать, просматривать, искать, редактировать и управлять медиафайлами.

Страницы — это место, где вы можете просматривать, создавать и управлять статическими страницами.

Комментарии позволяет модерировать и управлять комментариями посетителей.

Внешний вид — это место, где вы можете изменять темы, управлять меню и виджетами.

Плагины позволяют устанавливать приложения, расширяющие возможности вашего сайта.

Пользователи позволяет вам добавлять, просматривать, редактировать и определять роли пользователей на вашем сайте.

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

Настройки — это центральное место для настройки основных параметров вашего сайта.

В зависимости от плагинов и тем WordPress, которые вы используете, в вашем бэкэнде WordPress могут быть другие настройки и параметры.

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

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

Давайте посмотрим на каждый из них и на то, что они означают.

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

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

Что такое серверные языки?

Backend языки помогают серверам, приложениям и базам данных взаимодействовать друг с другом. Backend-разработчики используют специальные языки программирования, такие как PHP, Ruby, Python, Java и .Net, для создания серверных приложений. Эти серверные языки используются для управления системами с MySQL, Oracle и SQL Server для поиска, сохранения и редактирования данных для внешних пользователей.WordPress использует PHP и Javascript в качестве внутренних языков. Эти языки кодирования взаимодействуют с базой данных WordPress, используемой для хранения и организации данных ваших веб-сайтов.

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

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

В чем разница между серверной частью и фронтендом?

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

Не забудьте проверить ссылки ниже для получения дополнительной информации о WordPress Backend.

Дополнительное чтение

Что есть, инструменты и примеры

На главную
Тестирование
- - Назад
  - Гибкое тестирование
  - BugZilla
  - Cucumber
  - Тестирование базы данных
  - Jmeter
  - Jmeter Тестирование
  - JUnit
  - LoadRunner
  - Ручное тестирование
  - Мобильное тестирование
  - Mantis
  - Почтальон
  - QTP
  - Назад
  - Центр качества (ALM)
  - 000
  - Центр контроля качества (ALM)
  - TestLink
SAP
- - Назад
  - ABAP
  - APO
  - Начинающий
  - Basis
  - BODS
  - BI
  - BPC
  - CO
  - Назад
  - CRM
  - Crystal Reports
  - MMO
  - Назад
  - PI / PO
  - PP
  - SD
  - SAPUI5
  - Безопасность
  - Менеджер решений
  - Successfactors
  - SAP Tutorials
000
Web
AngularJS
ASP.Net
C
C #
C ++
CodeIgniter
СУБД
JavaScript

Назад
Java
JSP
Kotlin
Linux
Linux
Kotlin
Linux

Perl

Назад
PHP
PL / SQL
PostgreSQL
Python
ReactJS
Ruby & Rails
Scala
SQL

000

0003 SQL

000