Node.js proxy и CouchDB ACL

Нарисовался внезапно изумительной красоты кусочек кода, прокси-сервер на ноде (типа там для обхода CORS-блокировок например):

var app = require('express')(), request = require('request');
app.use("/proxy",function(req,res){req.pipe(request(req.query.url)).pipe(res)});
app.listen(80);

Обожаю за такие штуки javascript.

Появился этот код в процессе работы над прокси-сервером для CouchDB, который обеспечит per-document read ACL. Ну и попутно кучу других всяких рестрикшинов, которых в CouchDB сейчас нет, а очень бы хотелось.

Это всё небесплатно в плане производительности, но у меня получилось на бумажке построить схему, как это сделать всеобъемлющим, без щелей, и даже для reduce, а не только для map или выборки по ключам.

Первый подход к снаряду делался ещё летом под моим недостаточно чутким руководством, но я сам там ни строчки не написал, да и вообще мало внимания уделял. В результате получилось хоть и работающее, но далеко не всеобъмлющее и очень громоздкое решение.

“Не всеобъемлющее” означает, что API CouchDB где-то немного изменена, а где-то обрезана. А “громоздкое” – потому что много сложно связанного кода, и требует дополнительно Redis (это memcache) для кэширования и синхронизации ACL и сессий между потоками.

Это оказался подход тупиковый и меня недавно осенило, как можно обойтись без межпотоковых взаимодействий через временную БД. Картиночка цепей обработки раутером КучДБ-шного API в части GET-запросов в результате выглядит примерно так:

То-есть это полное накрытие REST API, при этом получается не так и много разновидностей обработчиков (это которые зелёные и через запятую). Каждый обработчик строк по 30-50, может. Короткие довольно.

Попутно эта штука будет ограничивать к-во запросов, gzip-ить ответы и вести лог. Во всём остальном прикидываясь CouchDB.

Такой подход (per-document read ACL), если брать в общем, разрушает возможность построения колец из реплик, то-есть допустима только звезда. Скажем, есть три базы – главная и две у юзеров. Реплики у юзеров будут различаться – и если они реплицируются друг в друга минуя главную базу, то оба увидят документы друг друга.

Те не менее, жизнь показывает, что колец репликации надо избегать совершенно по другим причинам и в реальных сценариях их возникновение маловероятно. Например, две реплики “главной” БД, помещённые в два разных браузера, напрямую друг с другом соединиться уже не смогут.

Интересно, что общий подход к этой задаче я в обдумывал года два, пока не придумалось. В общем, скоро “смотрите на гитхабе” )