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

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

Решения для настойчивости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В производственной среде пользователи используют наши материалы.

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

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

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

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

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

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

Заключение

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

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

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