Я планирую приложение для iOS, для которого требуется серверная часть, способная эффективно обслуживать файлы изображений и выполнять некоторые динамические операции на основе получаемых запросов (например, чтение и запись в хранилище данных, например Redis). Мне удобнее, и поэтому я бы предпочел писать бэкэнд на Python.
Я просмотрел множество вариантов веб-фреймворка/сервера Python, среди них Flask, Bottle, static и Tornado. Общая нить, по-видимому, заключается в том, что либо они поддерживают обслуживание статических файлов только для удобства разработки, препятствуя этому в производстве, либо являются эффективными статическими файловыми серверами, но на самом деле не ориентированы на динамическую сторону, подобную фреймворку. Это не значит, что они не могут функционировать как серверная часть, но на первый взгляд все они кажутся немного неуклюжими.
Короче говоря, мне нужна веб-инфраструктура, которая специализируется на обслуживании файлов JPEG вместо создания HTML. Я почти уверен, что такой вещи не существует, но сейчас я надеюсь, что кто-то может предложить решение, которое работает, не изменяя используемые приложения Python способами, для которых они не предназначены.
Технические характеристики и практические требования
Изображения, которые я буду предоставлять клиентам, находятся в файловой системе в неглубокой иерархии каталогов. Фактические имена файлов будут невидимы для клиентов. Сервер, по сути, считывал бы иерархию каталогов при запуске, назначая числовой идентификатор для каждого файла, и направлял бы запросы к методам контроллера, которые затем фактически обслуживали бы файлы изображений. Вот несколько примеров того, как клиент хотел бы получить доступ к изображениям в различных обстоятельствах:
- Случайным образом (пример пути URL:
/image/random) - Случайным образом каждый файл только один раз (
/image/random_unique) создает некоторый подходящий код состояния HTTP, отличный от 200, когда файлы исчерпаны. - Последовательно в любом направлении (
/image/0,/image/1,/image/2и т. д.)
и так далее. Кроме того, будут конечные точки URL для таких вещей, как рейтинги, информация об изображениях и другие метаданные, а также некоторая информация, специфичная для клиента (клиент будет «регистрироваться» на сервере, так что это тоже требует некоторой логики). Эти данные, скорее всего, будут храниться в хранилище данных Redis.
В общем, бэкэнд должен хорошо обслуживать изображения/jpeg и приложения/json (которые он также будет генерировать). Требования к масштабируемости и параллелизму скромные, по крайней мере, для начала (это не приложение из App Store, предназначенное для разового или корпоративного распространения).
Я не хочу, чтобы приложение полагалось на перенаправления. То есть мне не нужна модель, в которой запрос к URL-адресу будет возвращать перенаправление на другой URL-адрес, который поддерживается, скажем, nginx в качестве отдельного статического файлового сервера, оставляя только логику выбора изображения для бэкэнда Python. Вместо этого запрос URL-адреса от клиента всегда должен возвращать изображение/jpeg с метаданными в настраиваемых заголовках HTTP, где это необходимо. Я указываю это, потому что это способ избежать обслуживания статических файлов из Python, о котором я подумал, и кто-то другой тоже может подумать ;-)
Учитывая эту информацию, какое решение вы считаете хорошим выбором и почему? Или это то, для чего мне нужно кодировать нетривиальные расширения для существующих проектов?
EDIT: я думал об этом немного больше. Мне не нужны перенаправления из-за задержки, связанной с многочисленными запросами, которые они влекут за собой, плюс я хотел бы абстрагировать имена файлов от клиента, но мне было интересно, возможно ли что-то подобное:
Это довольно очевидно, но идея состоит в том, что программа Python получает информацию о запросе от nginx (или что-то еще, что выполняет эту роль), обдумывает ее, а затем сообщает nginx, чтобы он ответил на запрос клиента с определенным файлом из файловой системы. . Это так. Клиенту все равно, как был выполнен запрос, он просто получает ответ с правильным типом содержимого.
Это было бы довольно оптимально, на мой взгляд, но возможно ли это? Если не с nginx, может быть, что-то еще?
