[![Build Status](https://travis-ci.com/tiburon-777/OTUS_Project.svg)](https://travis-ci.org/tiburon-777/OTUS_Project)
[![Go Report Card](https://goreportcard.com/badge/github.com/tiburon-777/OTUS_Project)](https://goreportcard.com/report/github.com/tiburon-777/OTUS_Project)
# Проектная работа Image previewer service

## Общее описание
Сервис предназначен для изготовления preview (создания изображения
с новыми размерами на основе имеющегося изображения).
#### Пример превьюшек в папке [examples](./examples/image-previewer)

## Архитектура
Сервис представляет собой web-сервер (прокси), загружающий изображения,
масштабирующий/обрезающий их до нужного формата и возвращающий пользователю.

## Основной обработчик
http://cut-service.com/fill/300/200/www.audubon.org/sites/default/files/a1_1902_16_barred-owl_sandra_rothenberg_kk.jpg

<---- микросервис ----><- размеры превью -><--------- URL исходного изображения --------------------------------->

В URL выше мы видим:
- http://cut-service.com/fill/300/200/ - endpoint нашего сервиса,
в котором 300x200 - это размеры финального изображения.
- www.audubon.org/sites/default/files/a1_1902_16_barred-owl_sandra_rothenberg_kk.jpg - 
адрес исходного изображения; сервис должен скачать его, произвести resize, закэшировать и отдать клиенту.

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

- Работаем только с HTTP.
- Ошибки удалённого сервиса или проксируем как есть, или логируем и отвечаем клиенту 502 Bad Gateway.
- Поддержка JPEG является минимальным и достаточным требованием.

**Важно**: необходимо проксировать все заголовки исходного HTTP запроса к целевому сервису (www.audubon.org в примере).

Сервис должен сохранить (кэшировать) полученное preview на локальном диске и при повторном запросе
отдавать изображение с диска, без запроса к удаленному HTTP-серверу.

Поскольку размер места для кэширования ограничен, то для удаления редко используемых изображений
необходимо использовать алгоритм **"Least Recent Used"**.

## Конфигурация
Основной параметр конфигурации сервиса - разрешенный размер LRU-кэша.

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

## Развертывание
Развертывание микросервиса должно осуществляться командой `make run` (внутри `docker compose up`)
в директории с проектом.

## Тестирование
Реализацию алгоритма LRU нужно покрыть unit-тестами.

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

Необходимо проверить работу сервера в разных сценариях:
* картинка найдена в кэше;
* удаленный сервер не существует;
* удаленный сервер существует, но изображение не найдено (404 Not Found);
* удаленный сервер существует, но изображение не изображение, а скажем, exe-файл;
* удаленный сервер вернул ошибку;
* удаленный сервер вернул изображение;
* изображение меньше, чем нужный размер;
и пр.

## Разбалловка
### Обязательные требования
* Наличие юнит-тестов на ключевые алгоритмы (core-логику) сервиса.
* Наличие валидных Dockerfile и Makefile для сервиса.
* Ветка master успешно проходит пайплайн в CI-CD системе 
(на ваш вкус, Circle CI, Travis CI, Jenkins, GitLab CI и пр.).
**Пайплайн должен в себе содержать**:
    - запуск последней версии `golangci-lint` на весь проект с
    [конфигом, представленным в данном репозитории](./.golangci.yml);
    - запуск юнит тестов командой вида `go test -race -count 100`;
    - сборку бинаря сервиса для версии Go не ниже 1.14. 

При невыполнении хотя бы одного из требований выше - максимальная оценка за проект **4 балла**
(незачёт), несмотря на, например, полностью написанный код сервиса.

### Дополнительные требования
* Реализован HTTP-сервер, проксирующий запросы к удаленному серверу - 2 балла.
* Реализована нарезка изображений - 2 балла.
* Кэширование нарезанных изображений на диске - 1 балл.
* Ограничение кэша одним из способов (LRU кэш) - 1 балл.
* Прокси сервер правильно передает заголовки запроса - 1 балл.
* Написаны интеграционные тесты - 3 балла.
* Тесты адекватны и полностью покрывают фукнционал - 1 балл.
* Проект возможно собрать чере `make build`, запустить через `make run`
  и протестировать через `make test` - 1 балл.
* Понятность и чистота кода - до 3 баллов.

#### Зачёт от 10 баллов ( Максимум - **15 баллов** )

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

---

Для упрощения проверки вашего репозитория, рекомендуем использовать значки GitHub
([GitHub badges](https://github.com/dwyl/repo-badges)), а также 
[Go Report Card](https://goreportcard.com/).

---
Авторы ТЗ:
- [Дмитрий Смаль](https://github.com/mialinx)
- [Антон Телышев](https://github.com/Antonboom)