Сложилось впечатление, что автор весь этот опус писал вокруг бесполезной ссылки с типовыми лендинга и по продаже уникального комплекта нижнего белья и пачки гречки. Реклама как она есть, только тебе предлагают ещё тонну ненужного текста прочитать с схемой уровня 2 курса регионального ВУЗа.
Нет, как раз для таких отзывов я и интересуюсь, думаем в какую сторону упростить. Для теста поддержка всегда может в ручном режиме подтвердить домен, вот сейчас у вас он заапрувлен мной. Но я подумаю лично, как сделать систему эту проще, чтобы без регистрации можно было пробовать, вы абсолютно правы. С Cloudinary ознакомлюсь, только тогда смогу сказать что-то по этому поводу.
Спасибо! Все просто, вы не подтвердили домен, в cp.imagecdn.ru в таблице доменов первая колонка, солнышко должно превратиться в галочку. Для этого нужно кликнуть на галочку, вернется файл, который нужно бросить в корень домена для подтверждения. Потому вам и возвращается ошибка. А вот с https спасибо, действительно, сертификата на панели нет, что более чем плохой тон, я этот вопрос решу на днях, а на корневом домене наверняка ссылка стоит вида \\:domainname, потому он и схватил https. Такая мелочь и так неприятно в результате.
П.С. Когда мы делали сервис, нам показалось что самое простое верифицировать его через файл на хосте, заморочки с DNS как-то сложнее, а файл с хэшем бросил и бросил себе, тем более после подтверждения его сразу можно удалить.
Можете попробовать каналы у мэйла (mail.ru), они тут свой ДЦ для других открыли, публичный доступ и дают 3000р на тестирование. Там и хранилища есть, виртуалки можно развернуть, все по взрослому, но сам не пробовал. Зарегистрировался, но пока не использовал, вот хочу инстансы пары сервисов там запустить ради эксперимента.
А еще мне нравится, когда разносортные сервисы через общую шину решат задачи независимо, при этом можно отключать то одни, то другие, а система устойчиво работает, забавно, как живой организм.
Можно это делать синхронно, на общий бекенд, мы так делали изначально. А можно асинхронно разными способами, например у нас событие просто IIS примет, создаст задание и отправит его на выполнение и будет ждать события о том, что выполнилось все и тогда получит изображение из кэша. Т.е. не результат обработки от сервисов обработки, а именно от сервисов кэша, туда же перед тем как маякнуть событием об окончании той или ной обработки, положил его обработчик, допустим CropHandler. Вариантов по сути масса. Мы делали это для распределения нагрузки по нескольким серверам независимо, без балансировки нагрузки на базе бекенда, т.е. выбора при синхронном запросе одного из набора сервисов — обработчиков.
А как вы обрабатываете? Первичная обработка, нет картинки в кэше. Прямо пришел запрос — обработали — сразу отдали? Или как-то интереснее? Волнует меня тема эта.
Да, на .NET и IIS. Нас не очень волнует первичная обработка, основной кейс работы заключается в том, что картинка создана, она лежит на Redis и отдается исключительно от туда, там же в фоне мониторинг и обновляется по мере необходимости. Ну и по верх этого панель прикручена, с графиками и небольшой статистикой, для понимания. Ссылка imagecdn.ru статья с главной ушла, надеюсь не сочтут за рекламу, уже больше суток прошло. У вас именно проблема в загрузке с AWS, тут надо искать каналы, которые позволят получить достойную скорость, возможно в каких-то ДЦ он и будет в России.
Нет, к сожалению пока нет такого параметра, как quality, но вопрос интересный. У вас они в разных форматов? У нас основной кейс это кэширование пережатых изображений, а вот просто компрессии нет. Плюс сами мы не можем узнать, появились у вас файлы или нет, т.е. запрос всегда идёт от клиентов, по сути — их браузеров. Первый запрос строит изображение, остальные его из кэша подтягивают, который с использованием ETag и Last-modified обновляется. Те сервисы, что я встречал и искал, все равно работали по запросу клиента. Но каждый из них имел тот или иной API, можно соответственно вызывать его скриптом, а не браузером. В любом случае писать что-то. Я не подскажу универсального рабочего решения к сожалению.
Всегда есть версионность апи, но мы поступили по другому, один раз мы сменили API, но не могли никак сообщить об этом нескольким клиентам, кроме как подменять им картинки с сообщениями на английском языке. Но, мы пошли иным путем — редиректом. Т.е. старое апи осталось рабочим, а они сами зашли на сайт (обычно проверяешь изредка сервисы, с которыми сотрудничаешь, я например не могу налюбоваться на zilore) и сменили редирект на активную версию. В ASP.NET мы это вынесли в хелперы, сменить одно на другое, в случае необходимости — никаких проблем. Мы ведь пользуемся и сторонними сервисами тоже.
Не могу ничего сказать, пока сервис абсолютно бесплатный, но рано или поздно мы будем вынуждены или ограничить поступление клиентов или вводить какие-то рамки. Но доступные аккаунты, полученные сейчас, будут работать по тем же правилам — бесплатно. Надо просто не злоупотреблять сервисом, не пытаться на нем выехать с посещаемостью уровня Ленты или Медузы какой, условно, но у них свои подрядчики и вряд-ли они посмотрят в нашу сторону:)
Меня лично, как пользователя, больше заботит доступность сервиса 24/7, а не работа раз от раза. Если происходят какие-то проблемы — знать о них. Если я хочу что-то сказать — чтобы меня услышали.
В высоко нагруженных проектах с mssql и радостным linq, когда начинаешь разбираться в миллионе планов, безумном их трафике и удивительной их параметризации, понимаешь, что это далеко не преимущество и так делать не нужно. Что значит отключать автокоммит инструкции и главное зачем?
Зачем вам докер? Я уже лет 6 автоматически выкладываю asp проекты и иные используя от простого паблиша через msbuild, заканчивая release management + новинками в 2017 tfs. Что я упустил, если ваше апи это один или несколько сервисов или сайтов в iis?
Если он не последователен то не подходит для ключа в подавляющем большинстве случаев использования индексов, будет приводить к безудержной фрагментации. Если он последовательный, то как решаются коллизии?
Не сможет он прочитать и погасит всех когда общая папка была не доступна. Просто нужно иметь кластер на стороне хранилища и не будет этих проблем. Странно иметь шаред конфигурацию которая на каждом сервере своя:)
Таки если вы будете читать ссылки, что даете, то поймете что от покупки кассы печати чеков яндекс вас не спас. Первое же предложение после заголовка, крупным шрифтом. Никто за вас ничего не печатает, они отправляют вам запрос на печать, а печатает — вы, вернее касса, которая уже отправляет в налоговую через агрегатора.
Сложилось впечатление, что автор весь этот опус писал вокруг бесполезной ссылки с типовыми лендинга и по продаже уникального комплекта нижнего белья и пачки гречки. Реклама как она есть, только тебе предлагают ещё тонну ненужного текста прочитать с схемой уровня 2 курса регионального ВУЗа.
П.С. Когда мы делали сервис, нам показалось что самое простое верифицировать его через файл на хосте, заморочки с DNS как-то сложнее, а файл с хэшем бросил и бросил себе, тем более после подтверждения его сразу можно удалить.
Меня лично, как пользователя, больше заботит доступность сервиса 24/7, а не работа раз от раза. Если происходят какие-то проблемы — знать о них. Если я хочу что-то сказать — чтобы меня услышали.