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

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

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

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

Система

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

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

Архитектура

Детали

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

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

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

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

Решение

Таким образом, решение было очевидным: использовать управляемую событиями бессерверную лямбда-функцию AWS в качестве прокси-сервера, который, в свою очередь, будет выполнять фактический запрос и возвращать ответ клиенту.

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

Эффективность с кэшем

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

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

Как сделать его более эффективным и практичным? Да, верно... мы кешируем данные. Я решил использовать локальное хранилище в качестве кеша и удалить данные через 12 часов, но здесь нам подойдет любая разумная продолжительность менее 24 часов.

План построения

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

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

Сборка

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

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

Возможно, позже я напишу еще одну статью о реализации.

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

Ваше здоровье.