Я огромный фанат разных сервисов Cloudflare, и меня постоянно удивляют предлагаемые CF инновации и решения. Поэтому мне больно писать эту статью, ведь обычно я не могу сказать ничего плохого о CF, но спустя несколько месяцев в продакшене и отсутствия какого-либо внятного ответа от команды CF Images относительно моих проблем (в постах сообщества по ссылкам нет ни единого официального ответа), я счёл необходимым рассказать о некоторых аспектах CF Images, которые для меня, честно говоря, оказались удивительными, беспокоящими и разочаровывающими. После разрешения проблемы я обновлю этот список.
Ссылки: Cloudflare Images Now Available to Everyone, AWS’s Egregious Egress, Bandwidth Alliance, пост в сообществе 1, пост в сообществе 2, пост в сообществе 3, пост в сообществе 4.
CF известна созданием сервисов, которые невероятно хорошо работают, и при этом чрезвычайно эффективны по стоимости. Более того, компания стремится к устранению оплаты выходной пропускной способности, о чём говорит в «Bandwidth Alliance», выдвигая при этом прямые обвинения AWS в «Egregious Egress», а в анонсе CF Images она написала следующее (выделено мной):
Дело в том, что в CF Images вы действительно платите каждый раз, когда отображается одно и то же изображение, и об этом чётко заявляется буквально двумя параграфами ниже (выделено мной):
Усугубляет ситуацию то, что можно только предполагать, что запросы к CDN тоже считаются, так как это по-прежнему «доставленное изображение», и нигде не упомянуто, что это не так. Более того, поскольку вы платите за изображение, а не за трафик, то за мелкие изображения вы заплатите больше (например, 50 кБ = 0,20 доллара за ГБ), чем при использовании AWS.
Ссылки: пост в сообществе 1 (мой), пост в сообществе 2, пост в сообществе 3.
Ты чётко видишь, сколько изображений было загружено в облако, но в отличие от, например, CF Workers, нет никакой возможности узнать, сколько запросов было сделано, за исключением строчки в полученном счёте. Можно получить частичную информацию, настроив уведомления при пересечении определённых порогов, но если вам нужна детальная информация, сообщений становится так много, что они превращаются в спам.
Ссылки: пост в сообществе, AWS’s Egregious Egress.
Заголовок говорит сам за себя. Пока нет никакой возможности получения исходного немодифицированного файла, то есть ты никак не сможешь мигрировать на другую платформу. В посте CF «AWS’s Egregious Egress», ссылку на который я дал выше, написано следующее:
Так как нет никакого способа извлечь исходное изображение из CF Images, клиенты полностью привязаны к облаку сервиса. Это даже хуже, чем AWS, где скачивание данных «слишком дорого» — извлечь данные из CF Images попросту невозможно.
Ссылки: пост в сообществе 1, пост в сообществе 2, пост в сообществе 3.
Во всех изображениях, скачиваемых через CF Images, по какой-то причине отсутствует заголовок CORS, то есть их нельзя использовать в canvas, в контексте WebGL или в теге якоря с атрибутом download. Это похоже на странный недосмотр.
В случаях, когда вы передаёте изображения только на свой собственный домен, Images теперь могут передаваться напрямую с вашего собственного домена. https://my.domain/cdn-cgi/imagedelivery/<PATH>, где PATH — это путь, который вы обычно используете на imagedelivery.net.
https://developers.cloudflare.com/i...rve-images#serving-images-from-custom-domains
Если вам нужно передавать изображения на другие или неизвестные домены, то необходимо обойти это ограничение самостоятельно чем-то наподобие CF Worker.
Ссылки: пост в сообществе.
По каким-то причинам CF Images ограничены 20 «вариантами», то есть размером + режимом изменения размера, и нет возможности добавить другие, как и нет возможности включения параметров изменения размеров на основании запросов. Это может быть логично для приложений, когда ты заранее знаешь все размеры, но CF Images также поддерживает нечто под названием «Direct creator uploads» — это одноразовые URL, которые вы можете создавать и которые позволяют пользователю напрямую загружать изображения на CF Images без необходимости пропускать их через ваш сервер. Всё это замечательно, но для этого собственную или выбираемую пользователями обрезку изображений нужно выполнять на стороне клиента, и при загрузке обрезанного изображения на CF Images полные данные изображения будут безвозвратно утеряны. Это означает, что пользователь не сможет в дальнейшем изменить кадрирование без повторной загрузи изображения, что и непрактично, и впустую тратит место с трафиком.
Ссылки: Direct Creator Upload в документации, пост в сообществе (мой), пост в сообществе 2 (мой).
Рассмотрим упомянутый выше «Direct creator upload» подробнее — я так и не нашёл ему ни единого логичного применения, хотя и старался. Процесс выглядит так:
Это работает замечательно, но хотя теоретически это позволяет пользователю выполнить загрузку напрямую на CF Images, нет никакого способа узнать, успешной ли была загрузка, как и узнать id и получившийся URL изображения, можно только слепо довериться клиенту.
Для CF Images не существует веб-хуков (как для CF Stream), поэтому первым делом я попробовал обойти эту проблему, сохраняя id, полученный от CF API в запросе на стороне сервера, и заставляя пользователя пинговать сервер после завершения его загрузки. Затем можно снова использовать CF API, чтобы получить изображение по исходному id и проверить, что изображение и в самом деле успешно загружено. К сожалению, это не работает, так как id от CF API отличается от окончательного id загруженного изображения.
Я уверен, что чего-то серьёзно недопонял, но мне хотелось бы знать, как кто-либо может использовать такую систему в условиях продакшена, когда ты не можешь доверять клиенту и тебе нужно отслеживать использование сервиса, а также иметь возможность удаления пользовательских данных.
Это ограничение кажется слишком низким, потому что при изменении размера изображений мы стремимся к максимальному качеству. В обсуждении на HackerNews после выпуска этого продукта сказано, что это ограничение установлено на первое время, и что возможна поддержка бОльших размеров. Надеюсь, что когда-нибудь допустимый размер увеличится до 25 МБ.
Ссылки: пост в сообществе (мой).
На данный момент нет возможности удаления более чем одного изображения за раз при помощи CF API, поэтому вам придётся писать собственное решение, и чтобы при этом частота обращения к CF API не превышала ограничение в 1200 запросов за 5 минут. Это относится к использованию CF API всеми приложениями.
При помощи простого CF Worker можно получить нужные заголовки CORS и обеспечить кэширование изображений. При этом вы получите и ожидаемую функциональность (заголовки CORS), и снизите затраты благодаря правильному кэшированию изображений.
Проблема в том, что вы используете сервис CF для того, что не должно быть обязательным; но более того — если при самостоятельной реализации стоимость снижается, можно предположить, что она бы была ещё ниже, если бы это было реализовано самим CF.
Действительно ли CF Images — это плохой продукт? Нет, ни в коем случае, но учитывая все перечисленные проблемы, он кажется незавершённым и выпущенным в спешке. Я понятия не имею, какие административные и архитектурные процессы задействованы в создании продукта подобной сложности и масштаба, поэтому не знаю, можно ли и нужно ли устранять все эти проблемы. Кроме того, учитывая, что продукт находится на ранних этапах развития, он будет сильно меняться и совершенствоваться.
Я бы очень хотел назвать его бета-версией и очень хотел бы, чтобы CF действительно подкрепила свои слова делами и сделал бы CF Images более доступным, чем AWS, а также предоставил способ извлечения исходных изображений, чтобы предотвратить привязку поставщику сервиса, особенно учитывая его критику конкурента по тем же самым причинам.
Наконец, я надеюсь, что этот список очень быстро устареет, и что я вскоре смогу дополнить все его пункты описанием того, как проблемы решены или обсуждены командой CF.
habr.com
Проблемы
1. Невероятно запутанное и бессмысленное ценообразование в контексте CF
Ссылки: Cloudflare Images Now Available to Everyone, AWS’s Egregious Egress, Bandwidth Alliance, пост в сообществе 1, пост в сообществе 2, пост в сообществе 3, пост в сообществе 4.
CF известна созданием сервисов, которые невероятно хорошо работают, и при этом чрезвычайно эффективны по стоимости. Более того, компания стремится к устранению оплаты выходной пропускной способности, о чём говорит в «Bandwidth Alliance», выдвигая при этом прямые обвинения AWS в «Egregious Egress», а в анонсе CF Images она написала следующее (выделено мной):
Дело в том, что в CF Images вы действительно платите каждый раз, когда отображается одно и то же изображение, и об этом чётко заявляется буквально двумя параграфами ниже (выделено мной):
Усугубляет ситуацию то, что можно только предполагать, что запросы к CDN тоже считаются, так как это по-прежнему «доставленное изображение», и нигде не упомянуто, что это не так. Более того, поскольку вы платите за изображение, а не за трафик, то за мелкие изображения вы заплатите больше (например, 50 кБ = 0,20 доллара за ГБ), чем при использовании AWS.
2. Нет никакого способа отследить, какое количество изображений было передано
Ссылки: пост в сообществе 1 (мой), пост в сообществе 2, пост в сообществе 3.
Ты чётко видишь, сколько изображений было загружено в облако, но в отличие от, например, CF Workers, нет никакой возможности узнать, сколько запросов было сделано, за исключением строчки в полученном счёте. Можно получить частичную информацию, настроив уведомления при пересечении определённых порогов, но если вам нужна детальная информация, сообщений становится так много, что они превращаются в спам.
3. Нет способов получения исходного изображения
Ссылки: пост в сообществе, AWS’s Egregious Egress.
Заголовок говорит сам за себя. Пока нет никакой возможности получения исходного немодифицированного файла, то есть ты никак не сможешь мигрировать на другую платформу. В посте CF «AWS’s Egregious Egress», ссылку на который я дал выше, написано следующее:
Так как нет никакого способа извлечь исходное изображение из CF Images, клиенты полностью привязаны к облаку сервиса. Это даже хуже, чем AWS, где скачивание данных «слишком дорого» — извлечь данные из CF Images попросту невозможно.
4. Отсутствующий заголовок CORS в передаваемых изображениях
Ссылки: пост в сообществе 1, пост в сообществе 2, пост в сообществе 3.
Во всех изображениях, скачиваемых через CF Images, по какой-то причине отсутствует заголовок CORS, то есть их нельзя использовать в canvas, в контексте WebGL или в теге якоря с атрибутом download. Это похоже на странный недосмотр.
В случаях, когда вы передаёте изображения только на свой собственный домен, Images теперь могут передаваться напрямую с вашего собственного домена. https://my.domain/cdn-cgi/imagedelivery/<PATH>, где PATH — это путь, который вы обычно используете на imagedelivery.net.
https://developers.cloudflare.com/i...rve-images#serving-images-from-custom-domains
Если вам нужно передавать изображения на другие или неизвестные домены, то необходимо обойти это ограничение самостоятельно чем-то наподобие CF Worker.
5. Отсутствие динамического изменения размеров, допускается всего 20 «вариантов»
Ссылки: пост в сообществе.
По каким-то причинам CF Images ограничены 20 «вариантами», то есть размером + режимом изменения размера, и нет возможности добавить другие, как и нет возможности включения параметров изменения размеров на основании запросов. Это может быть логично для приложений, когда ты заранее знаешь все размеры, но CF Images также поддерживает нечто под названием «Direct creator uploads» — это одноразовые URL, которые вы можете создавать и которые позволяют пользователю напрямую загружать изображения на CF Images без необходимости пропускать их через ваш сервер. Всё это замечательно, но для этого собственную или выбираемую пользователями обрезку изображений нужно выполнять на стороне клиента, и при загрузке обрезанного изображения на CF Images полные данные изображения будут безвозвратно утеряны. Это означает, что пользователь не сможет в дальнейшем изменить кадрирование без повторной загрузи изображения, что и непрактично, и впустую тратит место с трафиком.
6. «Direct Creator Upload» по сути бесполезен
Ссылки: Direct Creator Upload в документации, пост в сообществе (мой), пост в сообществе 2 (мой).
Рассмотрим упомянутый выше «Direct creator upload» подробнее — я так и не нашёл ему ни единого логичного применения, хотя и старался. Процесс выглядит так:
- Запрашиваем одноразовый URL загрузки у CF API и возвращаем его пользователю
- Он содержит id и uploadURL
- Пользователь загружает изображение с заданным uploadURL
Это работает замечательно, но хотя теоретически это позволяет пользователю выполнить загрузку напрямую на CF Images, нет никакого способа узнать, успешной ли была загрузка, как и узнать id и получившийся URL изображения, можно только слепо довериться клиенту.
Для CF Images не существует веб-хуков (как для CF Stream), поэтому первым делом я попробовал обойти эту проблему, сохраняя id, полученный от CF API в запросе на стороне сервера, и заставляя пользователя пинговать сервер после завершения его загрузки. Затем можно снова использовать CF API, чтобы получить изображение по исходному id и проверить, что изображение и в самом деле успешно загружено. К сожалению, это не работает, так как id от CF API отличается от окончательного id загруженного изображения.
Я уверен, что чего-то серьёзно недопонял, но мне хотелось бы знать, как кто-либо может использовать такую систему в условиях продакшена, когда ты не можешь доверять клиенту и тебе нужно отслеживать использование сервиса, а также иметь возможность удаления пользовательских данных.
7. Ограничение в 10 МБ без возможности увеличить его
Это ограничение кажется слишком низким, потому что при изменении размера изображений мы стремимся к максимальному качеству. В обсуждении на HackerNews после выпуска этого продукта сказано, что это ограничение установлено на первое время, и что возможна поддержка бОльших размеров. Надеюсь, что когда-нибудь допустимый размер увеличится до 25 МБ.
8. Нет возможности пакетного удаления изображений
Ссылки: пост в сообществе (мой).
На данный момент нет возможности удаления более чем одного изображения за раз при помощи CF API, поэтому вам придётся писать собственное решение, и чтобы при этом частота обращения к CF API не превышала ограничение в 1200 запросов за 5 минут. Это относится к использованию CF API всеми приложениями.
9. Часть вещей приходится патчить самостоятельно
При помощи простого CF Worker можно получить нужные заголовки CORS и обеспечить кэширование изображений. При этом вы получите и ожидаемую функциональность (заголовки CORS), и снизите затраты благодаря правильному кэшированию изображений.
Проблема в том, что вы используете сервис CF для того, что не должно быть обязательным; но более того — если при самостоятельной реализации стоимость снижается, можно предположить, что она бы была ещё ниже, если бы это было реализовано самим CF.
Заключение
Действительно ли CF Images — это плохой продукт? Нет, ни в коем случае, но учитывая все перечисленные проблемы, он кажется незавершённым и выпущенным в спешке. Я понятия не имею, какие административные и архитектурные процессы задействованы в создании продукта подобной сложности и масштаба, поэтому не знаю, можно ли и нужно ли устранять все эти проблемы. Кроме того, учитывая, что продукт находится на ранних этапах развития, он будет сильно меняться и совершенствоваться.
Я бы очень хотел назвать его бета-версией и очень хотел бы, чтобы CF действительно подкрепила свои слова делами и сделал бы CF Images более доступным, чем AWS, а также предоставил способ извлечения исходных изображений, чтобы предотвратить привязку поставщику сервиса, особенно учитывая его критику конкурента по тем же самым причинам.
Наконец, я надеюсь, что этот список очень быстро устареет, и что я вскоре смогу дополнить все его пункты описанием того, как проблемы решены или обсуждены командой CF.
У сервиса Cloudflare Images есть множество проблем
Я огромный фанат разных сервисов Cloudflare, и меня постоянно удивляют предлагаемые CF инновации и решения. Поэтому мне больно писать эту статью, ведь обычно я не могу сказать ничего плохого о CF, но...
habr.com