Позвольте угадать. Вы посмотрели много туториалов. Вы повторяли действия, указанные в проектах. Вы можете «поднять» Node-сервер, написать несколько маршрутов, подключить базу данных. Но когда кто-то просит вас объяснить, что на самом деле происходит, или, что еще хуже, когда интервьюер начинает задавать уточняющие вопросы, вам становится сложно.
Верно?
Это не пробел в навыках. Это недостаточное понимание концепций.
В бэкенд-разработке есть странная особенность: вы можете писать код, не до конца понимая, что он делает. И это работает до какого-то момента. На собеседовании вы объясняете свой проект, и уточняющий вопрос интервьюера застает вас врасплох.
Эти 5 концепций не научат вас всему. Но они дадут вам ментальную карту. А когда у вас есть карта, все остальное начинает обретать смысл.
1. REST API
Невидимый официант
Вот самое простое объяснение. Вы сидите в ресторане. Вы не идете на кухню сами за едой. Вы говорите официанту, что хотите, официант идет на кухню и приносит оттуда заказ.
Это и есть REST API.
Ваш фронтенд (клиент) делает запрос. API (официант) передает его бэкенду (кухне). Бэкенд делает все необходимое и отправляет ответ обратно. Вы не видите кухню. Вы просто получаете свою еду.
Реальный пример: когда вы открываете Swiggy и нажимаете «Заказать сейчас», ваше приложение отправляет запрос на сервер Swiggy. В запросе говорится что-то вроде следующего: «Размести этот заказ для такого-то пользователя по такому-то адресу». Сервер обрабатывает его, обновляет базу данных, списывает оплату и отправляет ответ: «Заказ оформлен. 30 минут».
Две концепции, о которых вы чаще всего услышите на собеседованиях:
- GET — вы запрашиваете данные. Например, загружаете историю заказов.
- POST — вы отправляете данные. Например, оформляете новый заказ.
Есть и другие (PUT, DELETE), но GET и POST покрывают около 80% того, с чем вы будете работать на начальном этапе.
Почему это важно знать не только для прохождения собеседований? Потому что каждое приложение, которым вы когда-либо пользовались, работает на API. Лента Instagram, UPI-платеж, маршруты Google Maps — все это просто перемещающиеся запросы и ответы. Как только вы поймете API, вы перестанете видеть в приложениях нечто сложное и начнете видеть в них системы. Одна эта трансформация сделает из вас лучшего разработчика.
2. Базы данных
В них живет все
Ваше приложение забывает все в момент выключения. Если только вы не сохранили это где-то.
«Где-то» — это база данных.
Проведем следующую параллель. SQL-база данных похожа на очень хорошо организованную таблицу Excel. Для всего есть столбцы и строки. Хотите найти всех пользователей, зарегистрировавшихся в марте? Для этого есть запрос. Структура строгая, и эта строгость полезна.
Она поддерживает чистоту и согласованность данных.
NoSQL больше похожа на стопку стикеров. Каждый стикер может выглядеть по-разному. У одного пользователя может быть 10 полей. У другого — 3. Такая гибкость полезна, когда ваши данные не вписываются аккуратно в строки и столбцы, например, посты в соцсетях, где у одних есть изображения, у других — видео, у третьих — опросы.
Реальный пример: когда вы входите в приложение, ваш email и пароль проверяются по базе данных. Когда вы что-то публикуете, этот контент сохраняется в базу данных. Когда вы возвращаетесь на следующий день, все еще на месте, потому что база данных это сохранила.
Вопрос на собеседовании обычно звучит так: «Когда бы вы использовали SQL, а когда — NoSQL?»
Простой ответ: SQL, когда данные структурированы и важны связи (пользователи, заказы, платежи). NoSQL, когда данные отличаются гибкостью и скорость важнее строгой структуры (ленты реального времени, сообщения чатов, каталоги товаров).
Вам не нужно знать все о каждом типе. Просто осознайте разницу в подходах.
3. Аутентификация vs авторизация
Вход в систему vs разрешение
Эти два понятия звучат одинаково. Но они совершенно разные. И если вы перепутаете их на собеседовании, это будет красным флагом.
Вот как я запоминаю различие между ними.
Аутентификация — это фейс-контроль на входе, который проверяет вашу личность. Аутентификация отвечает на один вопрос: тот ли вы, за кого себя выдаете? Когда вы входите в систему с вашим email и паролем — это аутентификация. Система подтверждает вашу личность.
Авторизация — это то, что происходит после того, как вы попали внутрь. Теперь, когда мы знаем, кто вы, что вам разрешено делать? Обычный пользователь может просматривать свой профиль. Администратор может удалить чей угодно профиль.
Одно и то же приложение, разные разрешения. Это и есть авторизация.
В связи с этой темой вам могут встретиться следующие термины — JWT и сессии. JWT (JSON Web Token) — это небольшой зашифрованный токен, который сервер выдает вам после входа. Он с вами при каждом запросе, как контрольный браслет на концерте. Сервер проверяет браслет и знает, кто вы, без необходимости входить снова каждый раз.
Сессии — это более старый подход, при котором сервер ведет учет вошедших пользователей и выдает вам ID сессии. Работает нормально, но для больших приложений масштабируется не так легко, как JWT.
Почему это важно в реальных проектах: каждый раз, когда вы создаете систему входа, вы осуществляете аутентификацию. Каждый раз, когда вы ограничиваете доступ к определенным страницам только для администраторов, вы осуществляете авторизацию.
Ошибки в этой области приводят к уязвимостям безопасности. Понимание разницы, хотя бы на концептуальном уровне, выделяет вас из остальной массы разработчиков.
4. Кеширование
Функция, которая меняет все
Позвольте спросить вас: почему Instagram загружает вашу ленту так быстро, хотя она подтягивает посты от сотен людей, на которых вы подписаны? Дело в скорости работы сервера? Иногда. Но в основном дело в кешировании.
Кеширование означает временное хранение данных в месте, доступ к которому намного быстрее, чем к вашей основной базе данных. Вместо того чтобы каждый раз выполнять «тяжелый» запрос к базе данных, когда кто-то запрашивает одни и те же данные, вы выполняете его один раз, сохраняете результат и просто отдаете сохраненную версию всем остальным запрашивающим.
Приведу аналогию. Профессор ксерокопирует самые частые экзаменационные вопросы и держит их стопку у себя на столе. Вместо того чтобы печатать свежие копии каждый раз, когда студент просит об этом, он просто берет их из стопки. Тот же результат, но гораздо меньше усилий.
Инструмент, о котором вы чаще всего услышите здесь — Redis. Это хранилище данных в памяти, которое работает очень быстро. Компании используют его для кеширования пользовательских сессий, часто запрашиваемых данные, ответов API, таблиц лидеров — всего того, что часто запрашивается, но дорого вычисляется.
Недостаток этого метода заключается в том, что кешированные данные могут устаревать. Если пользователь обновит свой профиль, но в кеше все еще находится старая версия, некоторое время будет показываться неактуальная информация. Управление обновлением кеша (это называется инвалидацией кеша), является одной из самых сложных задач в бэкенд-разработке.
Но на концептуальном уровне просто запомните: кеширование = скорость. А в мире, где пользователи удаляют приложения, которые загружаются дольше 3 секунд, скорость — это все.
5. Ограничение частоты запросов (Rate Limiting)
«Вышибала» для вашего сервера
Представьте, что кто-то заходит в ваш ресторан и заказывает 10 000 блюд за 60 секунд. Ваша кухня рухнет.
Это то, что случается с серверами без ограничения частоты запросов.
Эта функция ограничивает количество запросов, которые один пользователь или IP-адрес может сделать за определенный промежуток времени. Слишком много запросов? Пользователь блокируется или, по крайней мере, его действия замедляются, пока окно не сбросится.
Реальный пример, с которым вы точно сталкивались: попробуйте ввести неправильный пароль в любом приложении 5 раз подряд. Вас заблокируют на некоторое время. Это ограничение частоты запросов защищает систему от атак перебором (brute-force), когда кто-то пишет скрипт, чтобы перебрать тысячи паролей, пока один не подойдет.
Это также мешает людям выгрузить всю вашу базу данных за один раз или атаковать ваш API ботовым трафиком до тех пор, пока сервер не рухнет.
Ограничение частоты запросов обеспечивает производительность (ваш сервер не перегружается) и безопасность (злоумышленники не могут автоматизировать путь доступа через ваше приложение).
На собеседованиях эта тема всплывает, когда спрашивают о системном дизайне или безопасности API. Того, что вы знаете о существовании ограничения частоты запросов и его причинах, уже достаточно, чтобы выделиться на фоне большинства. Знание таких инструментов, как Nginx, API-шлюзы или middleware-функции, может сделать вас еще более подкованным специалистом.
Чистая правда
Вам не нужно быть экспертом во всем этом.
Но вам нужно понимать, что это за вещи и зачем они существуют. Потому что бэкенд-разработка — это скорее принятие решений (когда кешировать, какую базу данных использовать, как защитить эндпоинты, как построить поток аутентификации). Принятие этих решений проистекает из понимания, а не просто из синтаксиса.
Читайте также:
- На чем бы я сосредоточился в Golang, если бы начинал писать бэкенд сегодня
- Как убедиться, что бэкенд-команда не испортит ваш фронтенд
- Бэкенд-разработчик: какие знания нужны для трудоустройства
Читайте нас в Telegram, VK и Дзен
Перевод статьи Shreyas Naphad: 5 Backend Concepts You Shouldn’t Ignore
