Как стать хорошим бэкенд-инженером?
Наткнулся на интересную статью от известного в узких кругах инженера Hussein Nasser про фундаментальные знания для бэкэнд-разработчика — How To Become a Good Backend Enginner. У автора более 18 лет опыта в разработке бэкенда и для себя он выделяет несколько основных фундаментов на которые опирается хорошее бэкенд-приложение:
- Протоколы транспортного уровня TCP и UDP. Самые популярные протоколы прикладного уровня так или иначе базируются либо на TCP либо на UDP.
- Нюансы работы веб-сервера, будь то nginx, apache httpd/tomcat и т.д. Я полностью согласен с автором, т.к. понимание как работает веб-сервер значительно упрощает решение проблем с производительностью приложения. У автора есть статья про разбор архитектуры nginx.
- Базы данных. Бесспорно база данных это сердце практически любого бэкенд-приложения. Понимание как работают индексы, что значит ACID Compliance, как база хранит данные на диске сделают вас лучшим инженером. От себя добавлю, что важно понимать плюсы и минусы той или иной БД, чтобы ваш выбор был максимально взвешенным и обоснованным. Чем с большим количеством баз вы столкнётесь на практике тем более взвешенным будет ваше решение о её выборе.
- Прокси-серверы. В эпоху микросервисной архитектуры появилось множество сервисов для проксирования запросов как транспортного уровня (например, HAProxy) так и прикладного (nginx http reverse-proxy, HAProxy HTTP). Область их применения разнообразная: балансировка нагрузки между серверами, кеширование, проверка авторизации/аутентификации и т.д.
- Системы обмена сообщениями (Messaging systems). Apache Kafka, RabbitMQ, Redis и многие другие популярные системы обмена сообщениями прочно вошли в нашу жизнь в эпоху распределённых приложений. Помимо преимуществ в масштабировании ваших сервисов, системы обмена сообщениями также значительно снижают связность между приложениями. Автор статьи рекомендует читателю разобраться в тонкостях той или иной системы, а именно в механизме создания и получения сообщения, нюансам доставки сообщений (at most once, at least once)
- Формат сообщений. XML, JSON, ProtoBuf, MessagePack и другие. Существует множество форматов кодирования информации для обмена между системами и у каждой есть свои минусы и плюсы (кроме XML, шутка). Если вы уменьшаете размер пересылаемой информации (например, выбирая сжатый формат), то не забывайте про накладные расходы CPU при десериализации сообщения.
- Безопасность. Знания об основах безопаности никогда не будут лишними. Для веб-разработчиков рекомендую ознакомиться с Топ-10 наиболее популярных уязвимостей в веб-приложениях: https://owasp.org/www-project-top-ten/
А что бы вы добавили от себя? Пишите в комментариях.
>>Click here to continue<<
