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

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

Постоянные решения

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

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

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

Есть несколько видов баз данных. Наиболее распространенными являются реляционные базы данных (SQL). Существуют также базы данных NoSQL, которые хранят данные нереляционными способами.

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

Кроме того, он имеет множество средств защиты, гарантирующих целостность данных и целостность транзакций.

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

Атомная транзакция означает, что каждая транзакция представляет собой единое целое.

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

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

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

Базы данных NoSQL предназначены для горизонтального масштабирования данных и не требуют соответствия ACID.

Существует несколько видов баз данных NoSQL. Они включают в себя базы данных для хранения документов и хранилища ключей.

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

Это полезно для хранения большого количества структурированных документов. Например, CouchDB, MongoDB и ElasticSearch.

Есть также хранилища ключ-значение, которые хранят данные в виде пар ключ-значение, как следует из названия.

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

Работа с различными средами

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

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

Локальная среда для местного развития, как следует из названия. Здесь мы пишем наш код и проверяем, работает ли он.

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

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

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

Среда тестирования — это место, где проводится тестирование. Это общая среда, в которой код развертывается как можно чаще из основной ветви.

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

Продакшн среда — это то, где наши вещи используются пользователями.

Информация в артефактах сборки

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

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

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

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

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

Заключение

Наши артефакты сборки должны содержать полезную диагностическую информацию.

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

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

About the Author

Ergashev Lazizbek

Добрый день, дорогие мои читатели, позвольте мне рассказать вам немного о себе. Я Лазизбек Эргашев, я веб-разработчик из Узбекистана. В основном я использую laravel/php для бэкэнда и vuejs/javascript для фронтэнда. Основная цель моего блога - поделиться с вами своим опытом и знаниями.

View All Articles