Часть 2, Дизайн и настройка среды

Вступление

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

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

В Части 1, Изучение Земли предлагалось разработать приложение Climate Explorer в качестве средства исследования с использованием MongoDB в качестве промежуточной промежуточной области для сбора, очистки и организации больших объемов данных перед их загрузкой в ​​оперативную базу данных. как PostgreSQL. В этой статье будут определены требования и ограничения внешней и серверной сред, необходимые для поддержки этого проекта, и описаны их компоненты.

Репозиторий Climate Explorer находится в ветке feature/05-article-part2 на GitHub.

Как показано на рисунке 2, исходный код и вспомогательные файлы для внешнего интерфейса хранятся в подкаталоге client, а подкаталог server содержит файлы внутреннего интерфейса.

Архитектура внешнего интерфейса

Как и следовало ожидать, ответственность внешнего интерфейса заключается в том, чтобы предоставить пользователю средства доступа и управления климатическими данными, хранящимися в серверной части. Интерфейс также предоставляет административные функции для запуска и мониторинга процесса извлечения, преобразования и загрузки данных (ETL).

Создать приложение React

Интерфейс использует ReactJS для реализации пользовательского интерфейса и был создан с помощью Create React App. Кроме того, поскольку мы хотели, чтобы UI / UX соответствовал концепциям и практикам хорошего дизайна, пакет Material-UI React Components используется для использования Material Design от Google с минимальным временем, затрачиваемым разработчиком.

Цель этого этапа разработки - создать скелет приложения, который на последующих этапах проекта будет улучшен в соответствии с новыми требованиями. Из-за этого интерфейс имеет минимальный пользовательский интерфейс, который содержит только аутентификацию пользователя и страницу «В разработке». Любые новые функциональные возможности заменят страницу «В разработке».

На рисунке 5 показаны компоненты внешнего интерфейса, реализованные в настоящее время в Climate Explorer. Используется упрощенный подход к управлению состоянием компонентов, поскольку варианты использования для представления климатических данных еще не определены.

Глобальная Граница ошибок React определяется вокруг всех компонентов приложения, чтобы отлавливать и сообщать о любых ошибках, которые могут произойти. Дополнительные сведения о границах ошибок см. В разделе Использование границ ошибок React для улучшения UX.

Серверный API

Внешнее приложение не сохраняет данные между сеансами. Данные находятся в двух внутренних базах данных, доступ к ним и управление ими осуществляется через API, построенный на основе Apollo GraphQL.

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

GraphQL включает набор компонентов React, которые, по сравнению с REST, упрощают чтение и понимание кода, поскольку он следует декларативному стилю, основанному на принципах, установленных React. Например, компонент <Query> на экране 6 показывает, как получить логическое значение, которое указывает, завершил ли внутренний сервер аутентификацию пользователя.

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

Бэкэнд-архитектура

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

  • База данных MongoDB, используемая в качестве промежуточной области для процесса ETL
  • База данных PostgreSQL, содержащая оперативные данные
  • API на базе Apollo GraphQL Server.

Как и в случае с интерфейсом, цель этого этапа проекта - создать скелет, функциональность которого будет добавлена ​​позже в проекте. Из-за этого инструментария, который вы могли ожидать в бэкэнде, например webpack и Express, были опущены до тех пор, пока мы не узнаем, что они необходимы.

Подкаталог graphql содержит запросы, изменения и преобразователи, которые реализуют различные функции API. Решатели GraphQL используют модули, находящиеся в подкаталоге datasources, для выполнения определенных бизнес-операций с климатическими данными. Наконец, модули, расположенные в подкаталоге middleware, взаимодействуют с внешними службами и ресурсами, такими как базы данных и службы, для доступа и обслуживания физических данных.

MongoDB

Промежуточная область для входящих необработанных данных использует MongoDB из-за его эффективности, поддержки неструктурированных данных и возможностей запросов. MongoDB - лучший выбор для промежуточной обработки, чем SQL, поскольку загрузка больших объемов необработанных данных в базу данных SQL требует, чтобы необработанные данные были безошибочными, а отношения между сущностями были согласованными. Поскольку SQL должен обеспечивать соблюдение принципов ACID, он по понятным причинам нетерпим к этим типам проблем, поскольку отношения основаны на значениях данных.

Многие разработчики считают, что пакеты объектно-реляционного сопоставления (ORM), такие как Mongoose, упрощают и ускоряют разработку, предоставляя основанный на схеме подход к моделированию и управлению данными. В этом проекте используется только родная MongoDB, основанная на следующих двух предположениях:

  1. Для загрузки и преобразования необработанных данных потребуется только базовая функциональность MongoDB.
  2. Объем обрабатываемых документов в сочетании с дополнительным кодом для Mongoose окажет заметное влияние на потребление ЦП.

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

Для получения дополнительной информации о Mongoose см. Обзор MongoDB и Mongoose.

PostgreSQL

Climate Explorer использует PostgreSQL в качестве постоянной оперативной базы данных. Система управления базами данных (СУБД) SQL предпочтительнее СУБД NoSQL, чтобы предоставить потребителям климатических данных быструю, но хорошо структурированную модель данных. Поскольку Climate Explorer представляет собой демонстрационную платформу для ETL, требование высокой структуры рабочих данных является искусственным.

Как обсуждалось ранее, СУБД SQL требуют согласованных данных, поскольку отношения между объектами устанавливаются с использованием общих значений данных. Например, наблюдение за климатом связано со станцией, на которой оно было выполнено, по уникальному идентификатору станции.

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

В настоящее время ORM не используется для загрузки данных в рабочую базу данных по той же причине, по которой приложение не использует его для доступа к MongoDB. Однако по мере выявления новых вариантов использования они могут потребовать, чтобы API использовал ORM для оперативного доступа к данным, хранящимся в PostgreSQL.

Ретроспектива - Неудача вперед

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

С этим проектом ничего не изменилось. Вместо того, чтобы отказываться от ошибок (т. Е. Тех, что я сделал), они будут восприняты как обучающие моменты.

Аполлон «Альфа»

Использование местного государственного управления Apollo Client было тем, что я хотел изучить в этом проекте. К сожалению, я недостаточно внимательно следил за Руководством по Apollo и потратил 2+ дня, пытаясь заставить его работать правильно.

Основная причина этой проблемы заключалась в том, что были установлены стабильные выпуски пакетов Apollo, а не альфа-выпуск Apollo Client 3.0, поскольку в учебнике не было учтено следующее утверждение:

«apollo-client@alpha: Полное решение для управления данными с интеллектуальным кешем. В этом руководстве мы будем использовать предварительную версию Apollo Client 3.0, поскольку она включает в себя возможности управления локальным состоянием и настраивает ваш кеш за вас ».

Для решения этой проблемы использовалась функция управления локальным состоянием в стабильной версии apollo-link-state, а не подход, реализованный в альфа-версии apollo-client. Хотя метод, предоставляемый альфа-версией, более прост, его использование вместо стабильной версии может подвергнуть Climate Explorer нежелательным побочным эффектам.

Извлеченный урок: прочтите документацию, затем прочтите ее еще раз, а затем прочтите еще раз.

Компонент CEButton

На раннем этапе разработки интерфейса было принято решение, что несколько мест в пользовательском интерфейсе требуют кнопок для ввода данных пользователем. Не желая дублировать код, был создан компонент CEButton для инкапсуляции компонента Button в пакете Material-UI.

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

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

Параметр поиска MongoDB (пользователи против пользователя)

Первоначальное тестирование функции findOne в модуле MongoAPI не привело к получению users документа, хотя документ и его данные были проверены с помощью MongoDB Compass. После нескольких потраченных впустую часов и множества console.log операторов было определено, что вызывающая функция передавала user вместо users в параметре collectionName.

Извлеченный урок: проверьте очевидное и напишите более надежные функции обработки ошибок.

Завершение

У Climate Explorer теперь есть архитектура, интерфейс и серверная часть, которые, мы надеемся, будут поддерживать его цель демонстрации процессов ETL. Целью этой статьи было не только описать, как была сконструирована среда, но и рассказать о факторах, влияющих на важные решения.

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

«Приветствуем меняющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента ».

Далее - часть 3, проектирование баз данных

Что такое Чингу?

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