
MiniCouchDB in Rust - garrensmith
https://www.garrensmith.com/blogs/mini-couch-hack-week
======
lukevp
This is really cool, thanks for your work! I really love couchdb. I have seen
tickets for document based ACLs on their github recently, I think this is the
last feature they need to open up usage across many more domains. The core app
works great for replication between dbs and to the edge using pouchdb, but
almost everyone is turned off by the database-per-user that is required to use
it. If they solve that I think their adoption could skyrocket, if they can get
over the hurdle of years of neglecting this core feature where everyone became
disillusioned by it. It’s positioned as a “put your db up on the internet and
interact/replicate over http” but it doesn’t work for most non trivial use
cases because everyone can then see the data, so you end up layering adapters
on to do ACL. This should really just be built in to the core app.

~~~
garrensmith
Thanks for reading. We have some plans around this, see the RFC -
[https://github.com/apache/couchdb-
documentation/pull/424](https://github.com/apache/couchdb-
documentation/pull/424)

In general, we are trying to move away from running your whole application in
CouchDB. We would prefer that you have an application layer in front of your
CouchDB instance. We recommend that you put up a proxy if you want to expose
your replication to PouchDB. That way you can add security around that
endpoint.

~~~
lukevp
Thanks for the reply, that’s the RFC I was referring to, and it’s great that
that’s being reviewed! If you look back on the history of couchdb on HN for
example, the lack of document based ACLs continues to come up as a serious
limitation of couchdb. Because it speaks http(s) natively, it is a perfect db
that can be used directly in place of a lot of the rest of your stack if your
use case is a MBaaS. I see couch primarily positioned to compete with firebase
firestore, but the perspective I see from maintainers is that it should be
competing with mongodb instead (especially with the integration of mango
queries and the push to put proxies in front of it.)

I feel that moving further in this direction to make couch a competitor at the
DB later will be the death of couchdb in the long run, because it is removing
the only real advantage it has over its peers, which is https based
replication to the browser and between peer DBs, and the fact that it’s built
on Erlang and can handle replication to many peers with ease. If you make us
proxy and wrap the Erlang app in our crappy (excuse the language) business
layers like Java and C# to build the proxy ACLs against a separate DB, you’ve
totally covered up the huge benefit of the safety and concurrency of Erlang in
handling the replication to endpoints for us.

~~~
kungfooguru
Curious why they suggest a reverse proxy. It may be a holdover from a time
before Erlang SSL got so many improvements? Heroku moved SSL termination to
Erlang from ELB's and saw great improvements, plus they released a useful lib
[https://github.com/heroku/snit](https://github.com/heroku/snit)

I suppose it could be related to their use of mochiweb still for the web
layer. Maybe they'll add on HTTP/2 eventually and no longer recommend a
reverse proxy.

There are alternatives for HTTP/1.1 and HTTP/2 in Erlang, like Elli (http/1)
[https://github.com/elli-lib/elli](https://github.com/elli-lib/elli) and
Chatterbox (http/2) library
[https://github.com/joedevivo/chatterbox](https://github.com/joedevivo/chatterbox)

~~~
daleharvey
This is an architecture I use a lot. The reverse proxy is there to implement
the replication, having your application understand the replication protocol
is a big ask. Instead, your app takes http requests, handles the ones it is
supposed to, and forwards database requests directly to (c|p)ouchdb (after
checking auth)

[https://github.com/daleharvey/noted/blob/master/index.js](https://github.com/daleharvey/noted/blob/master/index.js)
is a very simple example of how it can work

~~~
lukevp
We really shouldn't be writing our own authentication layers (or anything
security-related for that matter) unless necessary.

Case in point, this example code has a massive security issue that allows
anyone to impersonate without tokens if there is an active authentication
request open. Hopefully no one has used this example code to build a
production system that has real user data.

This is a perfect example of why this should really be part of CouchDB/PouchDB
itself and not something each person must write themselves. This should be
solved once, solved right, vetted by the community, and be easy to fall into a
pit of success.

I really like CouchDB and PouchDB as a product, but this insistence that this
is the right path is really holding you guys back.

~~~
matlin
You're probably write about writing your own authentication layer but it still
shouldn't be part of CouchDB or PouchDB. A better solution is for some OSS
project to build a standard proxy that applies the document level
authorization that everyone is asking for. No reason for it to be built-in.

~~~
lukevp
I would agree if couchdb wasn't positioning itself as being exposed directly
on the internet. If CouchDB is meant to be proxied behind another system /
auth stack, then why does it have CORS support and cookie auth built in?

Both of those features are purely a client-side concern and exist because the
original intent of CouchDB was real-time replication to browsers. Otherwise
the proxy could do the CORS as well as the authentication and CouchDB would
only require an http-level authentication pattern (like basic auth).

Having said that, I do agree that this should be compartmentalized and the end
user should be able to pick and choose what features they want to allow, but I
don't think that this should continue to be a separate concern that everyone
is building themselves, it should be a first-party solution.

------
rstarast
Oh, I first thought this was mimicking the pretty complete Go
[https://github.com/alicebob/miniredis](https://github.com/alicebob/miniredis),
which goes to some effort to be a complete and faithful implementation of the
Redis interface.

Still pretty cool, do you intend to develop this further?

~~~
garrensmith
Thanks. I'm not sure. I have some other project ideas I would probably work on
next. But I might use this as my go to project to test out specific Rust
patterns I've learnt.

------
ruuda
The page only says “You need to enable JavaScript to run this app.”

I expected some kind of live demo, so I enabled Javascript. It turned out to
be a static page with text. Not even a toggle-able menu on narrow screens,
just a static page.

Why does it need Javascript to render a static page?

~~~
Wingy
Probably so that the author can learn whatever JS framework they used.
Overkill tech to learn on a personal site before a production site.

~~~
radicalriddler
It is React based on the unminified source files that I can see.

------
Dowwie
The 'mini-redis' project wasn't intended to build a redis clone as much as it
was to teach many of the asyncio concepts in Rust with an example that uses an
extensive amount of code comments. Such examples have been missing from the
Rust ecosystem.

If you were inspired by mini-redis, why not go the extra mile and turn it into
another great educational resource?

------
nullwarp
This site is completely unusable without javascript, just spits out "You need
to enable JavaScript to run this app."

------
dmix
Both helpful git repos for learning how to architect async Rust apps using
Tokio. `mini-redis` is especially well documented (I understand the current
MiniCouchDB is still early!). Thanks for sharing.

------
jamil7
This is a very cool project and a fun read, I didn't know CouchDB 4 would be
built on FoundationDB. Without trying to hijack this thread, I've been
scratching my head lately looking for open source solution to offline-first,
collaborative document editing on native mobile clients. The closest I can get
is couchbase lite, does anyone know if something like this could be built for
CouchDB? or any other solutions?

~~~
millette
[https://pouchdb.com/](https://pouchdb.com/) is a JavaScript port of CouchDB,
running in the browser and capable of replicating with normal CouchDB.

~~~
jamil7
Thank you! I have come across it before but wasn't sure how I could run it in
a native (kotlin / swift) environment. From memory it also isn't particularly
well supported in React Native.

------
js4all
Awesome, I tried to get it running, but I get value:
Missing("couch_directory"). There is nothing mentioned in the readme about
this. Can anyone help?

------
kiddico
Just a heads up: in dark mode your Opensource page doesn't adjust font color
(black text on dark purple.)

I wish I knew rust and could say something more substantial lol.

~~~
garrensmith
Awesome thanks for the heads up. I just fixed it.

------
aswanson
If you think about it, all future database development should be written in
Rust.

~~~
kasperni
You didn't really want to write database did you?

~~~
aswanson
Nope.

