Создаём микросервис обработки изображений на Go с gRPC

[eugenehr]

Решал такую же задачу для новостного сайта в web-приложении на Java, но с использованием консольных утилит imagemagick, jpegoptim, cwebp и ffmpeg (для видео). В моем случае изображения создаются при первом запросе "на лету" и сохраняются на диск (трафик на сайте не большой). Рекомендую хранить сгенерированные изображения не рядом с оригиналом, а в отдельной папке уровнем выше, чтобы иметь возможность быстро почистить их, когда место на диске начнёт заканчиваться. Например, на том же уровне, что и папка uploads, сделать папку .thumbs, структура которой полностью повторяет uploads.

[artemkaVlg]

Да по поводу хранения соглашусь с вами, просто пока не выделили с3, момент с папками тоже учту в будущем

[skamenetskiy]

Не думаю что gRPC это лучший выбор для этой задачи.

1. Данные изображения будут целиком загружаться в память при (un)marshal-е proto.

2. Придется настраивать как сервер так и клиентов если размер изображение будет вылазить за стандартное ограничение размера сообщения в gRPC (32mb если память не изменяет).

3. Не будет работать с браузером.

4. По коду стрим открывается и закрывается на каждом запросе, в таком случае gRPC не сильно у http выиграет.

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

[artemkaVlg]

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

[Legion-101]

Почему не рассматривался вариант с multipart/form-data? Как будто решение по http было бы быстрее на мой взгляд.

И я не совсем понял, зачем создавался стриминговый вариант, если вы получаете в 1 запросе - 1 фотографию, возможно стоит рассмотреть oneof реализацию с передачей фотографий кусками, что поможет обойти стандартное ограничение сообщения gRPC.

[artemkaVlg]

Вариант с form data рассматривался, но так у меня микросервисная архитектура, grpc все же быстрее ( 1 сервис ходит в другой сохранить картинки пользователя), и как раз по поводу фотографий, это только в примере она 1 , так же можно отдавать их и несколько, это корректно работает

[yarcat]

Очень люблю grpc. Кайфанул от ностальгии. Советую глянуть на connect, который сделан поверх grpc, так что почти не потребует изменений, а так же прогнать код через govet, чтобы почистить устаревшие конструкции. К примеру, API waitgroup и capture счётчика цикла.

Потенциальные улучшения, которые, заодно, ответят на некоторые комментарии: 1) использование chunked upload, чтобы не десериализовать файлы в памяти целиком, а только их кусочки 2) использование простой абстракции для стораджа/репозитория, что позволит легко (почти без изменения кода) пересесть на серверлесс решения или изменить пути и права файлов, если понадобится

[artemkaVlg]

Спасибо за совет, учту это)