uakob / test

Testing purposes

Redis web proxy

Instructions for how to run the proxy and tests.

Запуск сервисов make start Тест make e2e (не make test т.к. это зарезервировано)

High-level architecture overview

Используемый стек

• NodeJS:latest
• NestJS:latest
• Redis:latest
• Nginx:latest

Приложение состоит из основного модуля и модуля взаимодействия с Redis. Архитектура многослойная и в основном продиктована NestJS best practices. В принципе это обычный MVC с дополнительным внедрением слоя middleware ДО и ПОСЛЕ request.

Ограничение в n входящих запросов обеспечивается Nginx.

What the code does.

Последовательность действий которые выполняются сервисом

• Входящий вопрос приходит транспортный слой приложения
• Слой промежуточных обработчиков проверяет на наличие такого типа запроса в кэше, и если он есть - возвращает его, без перехода к следующему слою
• Фреймворк делает необходимые преобразования со слоя транспорта на "логический" слой приложения без дополнительных преобразований
• Обработанный запрос поступает на контроллер
• Контроллер отправляет запрос без обработки далее на сервисный слой
• Сервис взаимодействия с redis получает искомый ключ с помощью программного клиента
• Ответ передается далее на сервисный слой
• Ответ передается далее, по пути встречая слой "перехватчиков" (в терминологии NestJS, middleware наоборот), кэшируя при этом значение на время установленное в dotenv
• Ответ отдается клиенту

Algorithmic complexity of the cache operations.

see node-cache-manager

How long you spent on each part of the project.

nginx - 6 часов (никогда сам не настраивал) nestJS - 4 часа плюс минус e2e - 4 часа readme - 1 час

A list of the requirements that you did not implement and the reasons for omitting them.

• Я не смог обеспечить искусственный bottleneck (честно, я долго думал, но ничего годного не придумал, нода это не совсем то где именно ограничивают ресурсы, она скорее та, кто их распределяет и "распараллеливает")
• Я не смог сделать последовательную обработку запросов) примерно по той же причине что и до этого, почти все решения которые могут мне помочь в этом плане - это fire-and-forget и подвешивать запрос на стороне ноды, что не есть правильное и элегантное решение в том стеке что выбран
• Я не смог оценить алгоритмическую сложность кэширования т.к. просто не успел залезть в сырцы библиотеки которая делает это из коробки за меня. Доверился тому что этот пакет используют и повсеместно.