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

Введение в Back-end: архитектура клиент-сервер и протокол HTTP

Добро пожаловать в мир Back-end разработки. Если вы когда-либо задумывались, что происходит после того, как вы нажимаете кнопку «Войти» на сайте, или как приложение на вашем телефоне узнает погоду на завтра, вы попали по адресу. Эта статья открывает наш курс, и сегодня мы разберем фундамент, на котором держится весь современный интернет.

Что такое Back-end?

Любое современное веб-приложение можно сравнить с айсбергом или театральной сценой.

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

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

!Иллюстрация разделения веб-приложения на видимую и невидимую части.

Архитектура Клиент-Сервер

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

Давайте используем классическую аналогию — ресторан.

Клиент (Client): Это вы, посетитель ресторана. В мире IT клиентом выступает ваш веб-браузер (Chrome, Safari) или мобильное приложение. Клиент инициирует общение, так же как вы решаете сделать заказ.

Сервер (Server): Это кухня ресторана. Там хранятся продукты (данные), там повара (серверные скрипты) готовят блюда по рецептам (бизнес-логика). Кухня выполняет работу и выдает результат.

Запрос (Request): Это ваш заказ. Вы не идете на кухню сами, чтобы пожарить стейк. Вы передаете свой выбор через официанта.

Ответ (Response): Это готовое блюдо, которое вам приносят, или сообщение о том, что ингредиенты закончились.

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

Почему это разделение важно?

* Безопасность: Мы не пускаем клиентов на «кухню» (сервер), чтобы они не могли украсть рецепты или испортить продукты (базу данных). * Масштабируемость: Один сервер может обслуживать тысячи клиентов одновременно, точно так же, как одна кухня кормит полный зал гостей. * Централизация: Если мы обновим меню (данные) на сервере, оно обновится сразу у всех клиентов.

Протокол HTTP: Язык общения

Чтобы Клиент и Сервер понимали друг друга, они должны говорить на одном языке. В вебе этим языком является HTTP (HyperText Transfer Protocol — протокол передачи гипертекста).

HTTP — это текстовый протокол. Это значит, что все сообщения, летающие по сети, представляют собой обычный текст, который можно прочитать (если он не зашифрован через HTTPS, но об этом позже).

Взаимодействие всегда происходит по сценарию:

Клиент отправляет HTTP-запрос.

Сервер обрабатывает его.

Сервер отправляет HTTP-ответ.

!Схема цикла запрос-ответ между клиентом и сервером.

Анатомия HTTP-запроса

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

Пример упрощенного запроса:

Запрос состоит из трех основных частей:

Стартовая строка (Start Line):

* Метод: Что мы хотим сделать? (в примере — GET, то есть «получить»). * Путь (Path): Какой ресурс нам нужен? (в примере — /profile). * Версия протокола: Обычно HTTP/1.1 или HTTP/2.

Заголовки (Headers): Это служебная информация. Например, Host указывает, к какому домену мы обращаемся, а User-Agent рассказывает серверу, какой у нас браузер.

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

Основные методы HTTP

Метод (или глагол) — это первое слово в запросе, которое говорит серверу о наших намерениях. Самые популярные методы часто называют аббревиатурой CRUD (Create, Read, Update, Delete), хотя соответствие не всегда 100%.

GET: «Дай мне это». Используется для получения данных. Когда вы открываете любую страницу, вы делаете GET-запрос. Тела запроса обычно нет.* * POST: «Прими это и обработай». Используется для отправки новых данных (регистрация, вход в систему, публикация поста). Данные лежат в теле запроса. * PUT / PATCH: «Обнови это». Используется для изменения уже существующих данных (редактирование профиля). * DELETE: «Удали это». Используется для удаления данных.

Анатомия HTTP-ответа

Сервер получил запрос, подумал и отправляет ответ. Пример:

Ответ также состоит из трех частей:

Стартовая строка (Status Line):

* Самое важное здесь — Код состояния (Status Code). В примере это 200.

Заголовки (Headers): Служебная информация от сервера. Например, Content-Type говорит браузеру, что мы прислали (HTML, картинку или просто текст).

Тело ответа (Body): Сами данные. В нашем случае — HTML-код страницы, который браузер отрисует.

Коды состояния: Светофор интернета

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

* 2xx (Успех): Все хорошо. * 200 OK: Запрос выполнен успешно. * 201 Created: Ресурс успешно создан (обычно после POST). * 3xx (Перенаправление): Ресурс переехал. * 301 Moved Permanently: Страница переехала навсегда, ищи её по новому адресу. * 4xx (Ошибка клиента): Вы (клиент) сделали что-то не так. * 400 Bad Request: Сервер не понял запрос (ошибка в синтаксисе). * 401 Unauthorized: Вы не авторизованы (нужен логин/пароль). * 404 Not Found: Знаменитая ошибка. Того, что вы ищете, не существует. * 5xx (Ошибка сервера): Вы все сделали правильно, но сервер сломался. * 500 Internal Server Error: Общая ошибка сервера (упала база данных, ошибка в коде). * 503 Service Unavailable: Сервер перегружен или на обслуживании.

Stateless: У сервера нет памяти

Важная особенность HTTP — он Stateless (без сохранения состояния). Это значит, что сервер не помнит вас между двумя разными запросами.

Представьте, что вы подходите к бармену и заказываете колу. Он наливает. Через минуту вы подходите снова и говорите: «Повтори». В мире HTTP бармен посмотрит на вас как на незнакомца и спросит: «Что повторить? Кто вы?». Каждый запрос — как чистый лист.

> «HTTP — это разговор с человеком, страдающим амнезией. Каждый раз приходится представляться заново».

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

Заключение

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

Back-end — это скрытая логика и данные приложения.

Клиент-Сервер — это разделение обязанностей: клиент просит, сервер делает.

HTTP — это простой текстовый протокол, состоящий из запросов и ответов.

Методы (GET, POST) определяют действие, а Коды (200, 404) — результат.

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

Готовы проверить свои знания? Переходите к домашнему заданию!

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

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

Сегодня мы поговорим о языках программирования для бэкенда и понятии технологического стека.

Что такое технологический стек?

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

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

Обычно стек бэкенда состоит из четырех основных слоев:

Операционная система (OS): Фундамент, на котором все работает (чаще всего Linux).

Веб-сервер: Программа, которая принимает HTTP-запросы (например, Nginx или Apache).

База данных (Database): Место, где хранятся данные.

Язык программирования и Фреймворк: Инструменты для написания логики приложения.

!Визуализация технологического стека как многослойной структуры.

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

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

1. Python

Девиз: «Простота и читаемость».

Python — один из самых популярных языков в мире. Его синтаксис настолько прост, что код часто читается как обычный английский текст. Это делает его идеальным выбором для новичков.

* Популярные фреймворки: Django, Flask, FastAPI. * Где используется: Instagram, Spotify, Pinterest. * Плюсы: Огромное сообщество, множество готовых библиотек, лидер в сфере искусственного интеллекта (AI) и анализа данных. * Минусы: Может быть медленнее компилируемых языков (как Java или Go) при очень высоких нагрузках.

Пример кода на Python (Flask):

2. JavaScript (Node.js)

Девиз: «Один язык для всего».

Долгое время JavaScript жил только в браузере. Но с появлением платформы Node.js он пришел на сервер. Теперь разработчик может писать и фронтенд, и бэкенд на одном языке. Это называется Fullstack-разработка.

* Популярные фреймворки: Express.js, NestJS. * Где используется: Netflix, Uber, LinkedIn. * Плюсы: Высокая скорость разработки, огромная экосистема (npm), отлично подходит для приложений реального времени (чаты, стриминг). * Минусы: Не очень подходит для тяжелых математических вычислений.

3. Java

Девиз: «Напиши один раз, запускай везде».

Java — это стандарт корпоративного мира (Enterprise). Это строгий, надежный и мощный язык. Если вы пользуетесь банковским приложением, скорее всего, его бэкенд написан на Java.

* Популярные фреймворки: Spring Boot. * Где используется: Банковские системы, Android-бэкенды, крупные корпорации. * Плюсы: Надежность, безопасность, строгая типизация (меньше ошибок в коде), многопоточность. * Минусы: Многословный код (нужно писать много строк для простых действий), потребляет много оперативной памяти.

4. PHP

Девиз: «Король веба».

Несмотря на критику, PHP остается одним из самых используемых языков. Он создавался специально для веба. На нем работает около 78% всех сайтов в интернете, включая WordPress и ранние версии Facebook.

* Популярные фреймворки: Laravel, Symfony. * Где используется: Facebook (частично), Wikipedia, Slack, миллионы сайтов на WordPress. * Плюсы: Очень легко начать, дешевый хостинг, простота развертывания. * Минусы: Непоследовательный дизайн языка, репутация «устаревающего» (хотя современные версии PHP очень быстры и хороши).

5. Go (Golang)

Девиз: «Простота и эффективность».

Язык, разработанный компанией Google. Он сочетает скорость C++ и простоту Python. Go создан для современных облачных сервисов и высоких нагрузок.

* Популярные фреймворки: Gin, Echo. * Где используется: Google, Dropbox, Twitch. * Плюсы: Невероятно быстрый, компилируемый, отлично работает с многопоточностью (может делать тысячи дел одновременно). * Минусы: Молодая экосистема (меньше готовых библиотек, чем у Python или Java).

Базы данных: Где хранить информацию?

Выбор стека не ограничивается языком. Вам нужно выбрать базу данных (БД). Глобально они делятся на два типа:

Реляционные (SQL): Данные хранятся в строгих таблицах, связанных друг с другом. Это как огромные таблицы Excel.

Примеры:* PostgreSQL, MySQL. Когда выбирать:* Когда важна структура и связи (финансы, учет товаров).

Не реляционные (NoSQL): Данные хранятся в виде документов или пар «ключ-значение». Это похоже на папку с разнородными файлами.

Примеры:* MongoDB, Redis. Когда выбирать:* Когда данные неструктурированы или нужна очень высокая скорость записи (аналитика, соцсети).

Популярные комбинации стеков

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

* LAMP: Linux, Apache, MySQL, PHP. Классика интернета. * MERN: MongoDB, Express, React, Node.js. Современный выбор для стартапов, полностью на JavaScript. * Python/Django Stack: Python, Django, PostgreSQL. Выбор для быстрой разработки сложных сервисов.

Как выбрать стек для своего проекта?

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

Цель обучения: Если вы хотите быстрее найти первую работу в стартапе или веб-студии — смотрите в сторону JavaScript (Node.js) или Python. Если метите в крупные банки и корпорации — учите Java или C#.

Тип проекта:

* Простой блог или сайт-визитка? PHP или Python. * Чат в реальном времени или игра? Node.js или Go. * Сложная финансовая система? Java.

Скорость разработки: Если нужно сделать MVP (минимально жизнеспособный продукт) «вчера», выбирайте Python (Django) или Node.js. Они позволяют писать код очень быстро.

> «Не существует

Работа с данными: проектирование БД, SQL против NoSQL и ORM

В предыдущих статьях мы разобрали, как клиент общается с сервером по протоколу HTTP, и выбрали язык программирования для нашей «кухни». Но есть один критически важный компонент, без которого не обходится ни одно серьезное приложение. Где хранить список пользователей? Куда записывать заказы? Как не потерять историю переписки?

Сегодня мы поговорим о базах данных (БД). Мы разберем, чем отличаются строгие таблицы от гибких документов, как правильно спроектировать связи между данными и как упростить работу с ними с помощью ORM.

Что такое База Данных и СУБД?

Часто новички путают понятия «База данных» и «СУБД».

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

Когда разработчики говорят «Я использую PostgreSQL», они имеют в виду СУБД. Но для простоты мы часто используем термин «база данных» для всего сразу.

Реляционные базы данных (SQL)

Это классика, проверенная десятилетиями. Реляционные базы данных (от англ. relation — отношение, связь) хранят данные в виде таблиц.

Представьте себе Excel. У вас есть таблица Users (Пользователи) со столбцами: ID, Имя, Email. Каждая строка — это отдельный пользователь. Главная особенность SQL-баз — это строгая структура (схема). Прежде чем добавить данные, вы должны четко определить, какие будут столбцы и какого типа данные в них хранятся (число, текст, дата).

!Схематичное изображение двух связанных таблиц в реляционной базе данных.

Для общения с такими базами используется язык SQL (Structured Query Language — язык структурированных запросов).

Пример SQL-запроса, чтобы найти пользователя с именем Иван:

Популярные СУБД: * PostgreSQL: Мощная, надежная, Open Source. Стандарт современной разработки. * MySQL: Самая популярная в мире, на ней работает WordPress.

Преимущества SQL:

Надежность (ACID): Гарантия того, что транзакция (например, перевод денег) либо выполнится целиком, либо не выполнится вовсе. Деньги не могут «зависнуть» в воздухе.

Структурированность: Вы всегда знаете, в каком формате лежат данные.

Связи: Легко связывать данные из разных таблиц (пользователя с его заказами).

Нереляционные базы данных (NoSQL)

С развитием социальных сетей и Big Data строгие таблицы стали неудобными. Появились NoSQL (Not Only SQL) базы данных. Их главная фишка — отсутствие жесткой схемы.

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

Пример хранения данных в MongoDB (документоориентированная СУБД):

!Иллюстрация гибкого хранения данных в NoSQL в виде коллекции документов.

Популярные NoSQL СУБД: * MongoDB: Хранит данные в виде документов (JSON). * Redis: Хранит пары «ключ-значение» в оперативной памяти. Используется для кэширования и сверхбыстрого доступа.

Преимущества NoSQL:

Гибкость: Можно менять структуру данных на лету, не останавливая базу.

Скорость: Часто работают быстрее SQL при простых запросах.

Масштабируемость: Легче распределять данные по сотням серверов.

SQL против NoSQL: Что выбрать?

Этот выбор зависит от задачи вашего проекта.

| Характеристика | SQL (PostgreSQL, MySQL) | NoSQL (MongoDB, Redis) | | :--- | :--- | :--- | | Структура данных | Строгая (Таблицы) | Гибкая (Документы, Ключ-Значение) | | Связи | Сложные связи (JOIN) | Связи слабые или отсутствуют | | Транзакции | Надежные (ACID) | Часто упрощенные (BASE) | | Лучше для... | Финансов, интернет-магазинов, CRM | Аналитики, соцсетей, кэша, логов |

> «Используйте SQL, если у вас нет веских причин использовать NoSQL. Структура и надежность — лучшие друзья разработчика». — Популярное мнение в сообществе Backend-разработчиков

Проектирование БД: Связи решают всё

Если вы выбрали SQL (а в 90% случаев вы начнете с него), вам нужно спроектировать схему. Главное здесь — нормализация (разделение данных, чтобы избежать дублей) и связи.

Существует три основных типа связей:

1. Один к одному (One-to-One)

Одной записи в таблице А соответствует ровно одна запись в таблице Б. Пример:* Гражданин и Паспорт. У одного человека один паспорт, у одного паспорта — один владелец.

2. Один ко многим (One-to-Many)

Одной записи в таблице А соответствует много записей в таблице Б. Пример:* Автор и Статьи. У одного автора может быть много статей, но у каждой статьи — только один автор. Реализация:* В таблицу «Статьи» добавляется столбец author_id (внешний ключ), который указывает на ID автора.

3. Многие ко многим (Many-to-Many)

Многим записям в таблице А соответствует много записей в таблице Б. Пример:* Студенты и Курсы. Один студент может ходить на много курсов. На один курс ходит много студентов. Реализация:* Создается третья, промежуточная таблица, где хранятся пары student_id — course_id.

ORM: Мост между кодом и базой

Мы пишем код на Python, JS или Java. А база данных понимает только SQL. Писать «сырые» SQL-запросы внутри кода неудобно и небезопасно.

Здесь на сцену выходит ORM (Object-Relational Mapping) — технология, которая связывает базы данных с концепциями объектно-ориентированных языков программирования.

ORM позволяет работать с таблицами как с обычными классами в коде.

Сравните:

Задача: Найти всех пользователей старше 18 лет.

Без ORM (SQL):

С ORM (Python/Django):

!Визуализация того, как ORM транслирует код приложения в SQL-запросы к базе данных.

Плюсы ORM:

* Скорость разработки: Писать код на родном языке быстрее. * Безопасность: ORM автоматически защищает от SQL-инъекций (популярный вид хакерских атак). * Переносимость: Можно легко сменить базу данных (например, с MySQL на PostgreSQL), почти не меняя код.

Минусы ORM:

* Производительность: Автоматически сгенерированные запросы иногда работают медленнее, чем написанные вручную профи. * Сложность: Нужно учить еще один инструмент.

Популярные ORM: * Python: Django ORM, SQLAlchemy. * Node.js: TypeORM, Prisma, Sequelize. * Java: Hibernate.

Заключение

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

Выбирайте SQL (PostgreSQL) для большинства задач, где важна структура и связи.

Используйте NoSQL (Redis, MongoDB) для специфических задач (кэш, неструктурированные данные).

Используйте ORM, чтобы писать чистый и безопасный код, но не забывайте учить основы SQL, чтобы понимать, что происходит «под капотом».

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

А теперь — проверим, как вы усвоили материал!

Разработка API: принципы REST, GraphQL и вопросы безопасности

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

Но как заставить этот автомобиль ехать? Как передать управление водителю (клиенту)?

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

Что такое API?

Аббревиатура API расшифровывается как Application Programming Interface (программный интерфейс приложения).

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

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

Когда вы нажимаете кнопку «Обновить ленту» в социальной сети, приложение обращается к API сервера с просьбой: «Дай мне 10 новых постов». Сервер понимает эту просьбу, идет в базу данных, берет посты и отдает их приложению.

REST: Архитектурный стандарт интернета

Самый популярный способ организации API сегодня — это REST (Representational State Transfer). Это не библиотека и не софт, это набор принципов и соглашений. API, построенное по этим принципам, называют RESTful API.

Главная идея: Всё есть Ресурс

В REST мы мыслим ресурсами. Ресурс — это любая сущность, с которой мы работаем: Пользователь, Статья, Товар, Заказ.

У каждого ресурса должен быть свой уникальный адрес (URL). Например:

* https://api.myshop.com/products — коллекция всех товаров. * https://api.myshop.com/products/42 — конкретный товар с ID 42. * https://api.myshop.com/users/10/orders — заказы пользователя с ID 10.

Использование глаголов HTTP

Помните методы HTTP (GET, POST, PUT, DELETE), которые мы обсуждали в первой статье? REST использует их по прямому назначению, чтобы определить действие над ресурсом.

Представьте, что URL /products — это папка с файлами.

GET /products — Дай мне список товаров (Чтение).

POST /products — Добавь новый товар в этот список (Создание).

GET /products/42 — Дай мне информацию о товаре №42 (Чтение).

PUT /products/42 — Полностью перепиши информацию о товаре №42 (Обновление).

DELETE /products/42 — Удали товар №42 (Удаление).

Это делает API предсказуемым. Если разработчик видит метод DELETE, он сразу понимает, что произойдет удаление, даже не читая документацию.

!Визуализация принципа работы REST API: запрос к конкретному ресурсу и получение ответа.

Формат данных: JSON

В современном REST API стандартом обмена данными стал JSON (JavaScript Object Notation). Это текстовый формат, который легко читается и людьми, и машинами.

Пример ответа сервера:

Проблема REST: Overfetching и Underfetching

Несмотря на популярность, у REST есть недостатки. Представьте, что вам нужно отобразить на странице только имя пользователя и аватарку. Но стандартный запрос GET /users/1 возвращает всю информацию: имя, фамилию, адрес, телефон, историю входов, настройки...

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

Обратная ситуация — Underfetching (недостаточная выборка). Вам нужно показать пост и имя его автора. В REST вам часто придется сделать два запроса:

GET /posts/5 (получить пост, узнать ID автора).

GET /users/10 (получить имя автора).

GraphQL: Гибкая альтернатива

Чтобы решить проблемы REST, компания Facebook в 2015 году представила GraphQL. Это язык запросов к API.

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

Как это работает?

В GraphQL обычно есть всего один URL (endpoint), например /graphql. Все запросы идут туда методом POST.

В теле запроса клиент описывает, какие данные ему нужны:

И сервер вернет ровно то, что просили:

!Иллюстрация проблемы избыточных запросов в REST и её решение в GraphQL.

Плюсы и минусы GraphQL

* Плюсы: * Нет избыточных данных (экономия трафика). * Можно получить связанные данные (пост + автор + комментарии) за один запрос. * Строгая типизация (клиент точно знает, какие поля доступны). * Минусы: * Сложнее в настройке и изучении, чем REST. * Сложнее кэшировать данные (в REST каждый URL уникален и легко кэшируется браузером, в GraphQL URL всегда один).

Что выбрать? Для большинства стандартных проектов REST остается отличным выбором. GraphQL стоит брать, если у вас очень сложные связи данных или критически важна экономия трафика (мобильные приложения).

Безопасность API: Защищаем крепость

Когда вы открываете API миру, вы открываете дверь в свой дом. Если не поставить охрану, кто угодно сможет зайти и вынести мебель (данные) или устроить погром (удалить базу).

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

Аутентификация (Authentication) — «Кто ты?»

Это процесс проверки личности. Когда вы вводите логин и пароль, вы проходите аутентификацию. Вы доказываете системе, что вы — это вы.

Авторизация (Authorization) — «Что тебе можно?»

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

!Различие между проверкой личности (Аутентификация) и проверкой прав доступа (Авторизация).

Как это работает в API? Токены

В первой статье мы говорили, что HTTP — это протокол без состояния (Stateless). Сервер не помнит вас. Передавать логин и пароль в каждом запросе — небезопасно и неудобно.

Поэтому используется механизм Токенов (чаще всего JWT — JSON Web Token).

Вы отправляете логин/пароль один раз (при входе).

Сервер проверяет их и выдает вам Токен — длинную строку зашифрованных символов. Это ваш временный электронный пропуск.

Теперь, при каждом запросе к API (например, «дай мои сообщения»), вы прикрепляете этот токен к запросу (обычно в заголовке Authorization).

Сервер видит токен, расшифровывает его, понимает, кто вы, и выполняет запрос.

Другие меры безопасности

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

Rate Limiting (Ограничение частоты запросов): Защита от спама и DDoS-атак. Вы настраиваете сервер так, чтобы один IP-адрес не мог делать больше, например, 100 запросов в минуту. Если лимит превышен — сервер временно блокирует этого клиента.

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

Заключение

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

Мы узнали, что: * REST — это классический подход, где каждый ресурс имеет свой адрес. * GraphQL — это гибкий подход, позволяющий запрашивать точечные данные. * Аутентификация отвечает на вопрос «Кто ты?», а Авторизация — «Что тебе можно?».

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

А пока — проверьте, как вы усвоили материал об API!

Основы DevOps: контейнеризация Docker, тестирование и деплой на сервер

Поздравляю! Вы прошли огромный путь. Мы начали с того, как работает интернет, выбрали язык программирования, спроектировали базу данных и написали безопасный API. У вас есть готовое приложение. Но есть одна проблема: оно работает только на вашем ноутбуке.

Как сделать так, чтобы вашим сервисом могли пользоваться люди по всему миру? Как перенести код с «домашней кухни» в профессиональный «ресторан», который работает 24/7?

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

Что такое DevOps?

Раньше в IT-компаниях существовала стена между двумя отделами:

Development (Dev): Разработчики, которые пишут код и хотят постоянно добавлять новые функции.

Operations (Ops): Системные администраторы, которые следят за серверами и хотят, чтобы ничего не ломалось (а значит, чтобы ничего не менялось).

Это приводило к конфликтам. Разработчик говорил: «У меня на компьютере всё работает!», а админ отвечал: «А на сервере всё упало, потому что у тебя другая версия библиотеки».

DevOps (Development + Operations) — это методология, которая разрушает эту стену. Это набор практик и инструментов, позволяющих автоматизировать процессы сборки, тестирования и выпуска продукта. Главная цель DevOps — доставлять код пользователю быстро и надежно.

Проблема: «У меня всё работает»

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

А теперь представьте, что вы отправляете этот код на сервер. Там вообще другая операционная система (Linux вместо Windows/macOS). Настройка окружения превращается в ад.

Решение этой проблемы — Контейнеризация.

Docker: Контейнеры правят миром

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

Аналогия с грузоперевозками

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

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

Docker сделал то же самое для программ. Неважно, на чем написано ваше приложение (Java, Node.js, Python) — если оно упаковано в Docker-контейнер, оно запустится на любом сервере, где установлен Docker.

Виртуальные машины vs Контейнеры

Часто новички путают контейнеры с виртуальными машинами (Virtual Machines, VM).

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

!Сравнение тяжеловесной архитектуры виртуальных машин и легковесной архитектуры контейнеров.

Основные понятия Docker

Чтобы работать с Docker, нужно знать три термина:

Dockerfile (Рецепт): Это текстовый файл с инструкциями. В нем написано: «Возьми Linux, установи Python, скопируй мой код, открой порт 8000».

Image (Образ): Это готовый «слепок» приложения, созданный по рецепту. Образ нельзя изменить, его можно только создать заново. Это как файл установки игры на диске.

Container (Контейнер): Это запущенный образ. Это живой процесс. Вы можете запустить из одного образа хоть 100 одинаковых контейнеров.

Пример Dockerfile

Допустим, у нас есть простое приложение на Node.js. Вот как выглядит Dockerfile для него:

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

Тестирование: Не доверяй, а проверяй

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

В разработке существует пирамида тестирования:

Unit-тесты (Модульные): Самые быстрые и простые. Они проверяют маленькие кусочки кода (функции, классы) в изоляции. Например: «Правильно ли функция считает сумму заказа?».

Integration-тесты (Интеграционные): Проверяют, как разные модули работают вместе. Например: «Записываются ли данные в базу при регистрации пользователя?».

E2E-тесты (End-to-End): Имитируют действия реального пользователя. Робот открывает браузер, кликает по кнопкам и проверяет результат. Это самые медленные, но самые надежные тесты.

CI/CD: Конвейер автоматизации

В современной разработке тестирование автоматизировано. Это называется CI/CD.

* CI (Continuous Integration — Непрерывная интеграция): Как только вы сохраняете код и отправляете его в репозиторий (например, на GitHub), специальный робот автоматически запускает тесты. Если тесты не прошли, код не принимается. * CD (Continuous Delivery — Непрерывная доставка): Если тесты прошли успешно, робот автоматически собирает Docker-образ и обновляет приложение на сервере.

!Визуализация процесса CI/CD: от написания кода до его появления на сервере.

Деплой: Запуск на сервере

Мы упаковали приложение в Docker и протестировали его. Пришло время деплоя (развертывания) — публикации приложения в интернете.

Что такое сервер?

Сервер для веб-приложения — это просто компьютер, который подключен к интернету круглосуточно и имеет статический (постоянный) IP-адрес. Обычно разработчики не покупают физические серверы, а арендуют VPS (Virtual Private Server) у облачных провайдеров.

Процесс ручного деплоя

Самый простой способ задеплоить Docker-контейнер выглядит так:

Аренда VPS: Вы покупаете сервер (например, на Ubuntu) и получаете IP-адрес и пароль.

SSH (Secure Shell): Вы подключаетесь к удаленному серверу через терминал своего компьютера. Это выглядит как управление чужим компьютером через командную строку.

Установка Docker: Вы устанавливаете Docker на удаленном сервере (один раз).

Запуск: Вы скачиваете свой образ и запускаете его.

Эта команда говорит: «Запусти мое приложение в фоновом режиме (-d) и перенаправь запросы с порта 80 (стандартный порт веба) на порт 3000 моего контейнера».

Теперь, если вы введете IP-адрес сервера в браузере, вы увидите свое приложение!

Оркестрация

Когда у вас один контейнер, управлять им легко. А если у вас микросервисная архитектура и 50 контейнеров? Если один упадет, кто его поднимет? Если нагрузка вырастет, кто запустит копии?

Для этого используются оркестраторы. Самый известный — Kubernetes (K8s). Это сложная система, которая управляет флотилией контейнеров, следит за их здоровьем и масштабирует их. Но для старта достаточно инструмента попроще — Docker Compose, который позволяет описать запуск нескольких контейнеров (например, бэкенд + база данных) в одном файле.

Заключение курса

Поздравляю! Вы завершили курс «Основы Back-end разработки». Давайте оглянемся назад и посмотрим на полную картину:

Клиент отправляет HTTP-запрос.

Запрос летит через интернет на ваш Сервер (VPS).

На сервере Docker-контейнер ловит этот запрос.

Внутри контейнера ваш код на Python/JS/Java обрабатывает логику.

При необходимости код обращается к Базе Данных (SQL/NoSQL).

Сервер формирует ответ и отправляет его обратно клиенту.

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

Удачи в разработке!