В последних двух статьях мы обсуждали изменения и оптимизации на внешнем интерфейсе прикладного уровня нашей Платформы безопасности пищевых продуктов под названием FOODAKAI. Мы обсудили структуру проекта, управление состоянием, оптимизацию производительности и то, что помогло нам упростить процесс разработки и отладки. Теперь пришло время перейти к серверной части и сосредоточиться на архитектурных решениях и изменениях, которые все еще происходят и меняют будущее нашего приложения, оказывая большое влияние на его расходуемость.
Сторона сервера
Как упоминалось во введении, помимо SPA, мы хотели начать менять всю архитектуру приложения на микросервисы. В прошлом тот факт, что у нас был один сервер Ruby on Rails для всего, что мы хотели делать в бэкэнде, ограничивал наши горизонты и замедлял время разработки и тестирования.
Отделить сервер от клиента
Первым шагом, который мы должны были сделать, было принять решение. Мы хотели создать расширяемую среду, в которой мы могли бы иметь множество небольших серверов, выполняющих независимые задачи. Но перед этим мы хотели полностью отделить сервер Ruby (используемый для рендеринга представлений приложения) от SPA. Это означало, что мы будем использовать сервер Ruby только для доступа к данным через API. В то же время рендеринг и маршрутизацию пришлось перенести на фронтенд. Затем нам пришлось создать некоторые конечные точки API, чтобы заменить коммуникационные части, которые ранее были охвачены соединением, которое Ruby on Rails имеет между клиентом и сервером.
Микросервисы
Второй шаг, который нам нужно было сделать, — это создать отдельные серверы, которые будут обслуживать определенные запросы. Ruby не славится такой гибкостью, поэтому вместо этого мы решили использовать NodeJS/Express. NodeJS хорошо известен небольшими ресурсами, которые он потребляет для запуска, производительностью для задач, управляемых событиями, и в то же время гибкостью, которая дает разработчикам беспристрастную среду. Основные функции управления пользователями (аутентификация, авторизация и пользовательские настройки) останутся с первоначальным сервером Ruby. Однако небольшие задачи будут разбиты на более мелкие серверы. Первыми тремя серверами были: прокси, почта и сервер интеграции данных. Например, одной из функций почтового сервера будет отправка ежедневных предупреждений пользователям, включая графики и изображения в соответствии с каждым профилем пользователя. Для этой функциональности также необходимо было реализовать отдельный сервер для генерации графиков изображений. Сервер интеграции данных поможет импортировать объемные пользовательские данные, которые наши клиенты предоставляют при регистрации. Разработка небольших отдельных серверов дала нам возможность поэкспериментировать с различными типами баз данных, за исключением основной базы данных PostgreSQL, которая у нас уже была. Эксперименты с базами данных NoSQL, такими как MongoDB и Elasticsearch, для определенных частей приложения дали нам некоторые идеи, которые мы записали для будущей, более сложной серверной части.
Выводы и где мы сейчас
Мы еще не закончили со всеми изменениями ни в архитектуре, ни в самом коде, но самые важные части мы завершили. Весь процесс проектирования и разработки изменений дал много уроков и подготовил почву для расширяемого и полностью гибкого приложения.
Производительность приложения и пользовательский интерфейс уже значительно улучшились, а многие новые функции, такие как многоязычие, стало намного проще реализовать. Новый дизайн пользовательского интерфейса также дополнил картину. Хотя многие вещи не могут быть включены в небольшую статью, я надеюсь, что те, которые я решил включить, будут полезны другим людям в их путешествии по оптимизации мира веб-приложений. Общий опыт был веселым и позволил нам двигаться вперед как команда и быть готовыми к еще большим изменениям.
