couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: CouchDB and future
Date Tue, 09 Jul 2019 08:02:35 GMT


> On 9. Jul 2019, at 08:56, Johs Ensby <johs@b2w.com> wrote:
> 
> Chintan,
>> On 9 Jul 2019, at 05:50, Chintan Mishra <chintan@rebhu.com> wrote:
>> 
>>> CouchDB 1.x is no longer supported, even for security updates.
>> Johs had some interesting points regarding 1.x and their stability. Would you mind
sharing those?
> CouchDB 1.x can run uninterrupted for years. We used it to create quite complex web sites
like this https://www.goltens.com This particular site has been managed (tech and content)
by one guy spending a few hours every second week or so. The client, being a multinational
company with most of its business coming through this site got nervous about their site being
hosted on an unknown platform and managed by one guy, and commissioned a fullservice comms
agency to move it to WordPress. They have been trying for 6 months now, and are still not
ready.
> I'm not into IoT (yet) but working with a project in developing countries that could
need a large number of local web servers with replication over mobile and service small rural
centers with content and applications to smartphones/tablets over WiFi. CouchDB 1.x will do
fine. CouchDB/PouchDB is good for data collection in areas with poor connectivity and there
were some interesting early use cases, but projects like https://www.kobotoolbox.org/ and
https://five.epicollect.net/ have filled this niche.
> 
> My love for CouchDB 1.x is mainly related to feature stability as a single-tier platform.
> - Build-in web server
> - Rewrite/vhost for easy configuration of several access points to the same data (Rewrite
as a JS function was a big step forward for creating advanced routers/API servres, and is
patched into 1.x here https://github.com/b2w/couchdb/blob/Rewrite-function/README.rst)
> - Map/Reduce indexing
> - the data on disk as one single file, just copy it, move it, back-up, drop it at another
server
> - and single-node master-to-master replication is as simple as you can get data sharing,
backup, staging sites, etc. automated or by manual one-click operations
> - direct-to-design-document deployment (robust IDE for this here: http://ddoc.me/)

CouchDB 2.x has and does all of these things.

* * *

Specifically, and we talked about this many many times in the past and you continue to conveniently
ignore this fact:

The JS runtime implementation in CouchDB 1.x and 2.x used the 1990s-era CGI-BIN model, where
a separate operating system process is forked for each concurrent HTTP request accessing JavaScript
resources. That means this model is only really suitable for
10s and maybe 100s of concurrent requests (views are a special case and don’t really factor
in here). That means that it is EXTREMELY ancient and unsuitable for modern web development.
I know we have talked about this, Johs, because I’m writing this kind of mail for the fifth
time to you now. One of my previous mails even included a design proposal for fixing all of
the above and you all even formed a couchapp sub-group here but never showed any prototypes
or started on code, let alone even commented on the design proposal I put forward. You did
nothing to advance the state of the art in 5+ years.

The technology here is SO BAD that we have deprecated it years ago, after your group failed
to take action on it, because the rest of the team didn’t have the resources to building
something decent. You all (mostly Ermouth) have gone outside the project to solve your problems,
and that is fantastic, if CouchDB wasn’t this modular, you couldn’t even do any of those
things.

Can we, pretty please, but the notion to rest that CouchDB becomes a single-deployment modern
web-application app server UNLESS a group of developers steps up and contributes this technology.

If Ermouth’s projects are what you need, then that’s great, but unless you are prepared
to spend the time and constructively engage with the project (and sending your 10s iteration
of “here is what I think marketing is” is not what I have in mind), please let this rest.

Instead, I’d love to see a PR to the website from you, or a blog post with a case-study
about how you use CouchDB in non-standard ways.


> Futon is very functional, but a bit primitive as admin panel. Photon is available as
a stronger tool (better than Fauxton) https://github.com/ermouth/couch-photon
> Ddoc Lab and Photon (both by ermouth) are examples of apps that you can drop into any
CouchDB bucket as single design documents.
> As such these are excellent examples of how community-generated tools of great value
could evolve around CouchDB and extend the core project. 

We’d love to discuss this, but so far, we haven’t been approached about maybe including
any of these things, so complaining about them being available and fully usable is really
not fair.

Best
Jan
—


> 
> Your input was a flash of light when it comes to market orientation.
> The big platforms (AWS/Google/Azure) offer more and more developer-friendly solutions,
but their lock-in disadvantage is a huge risk, and IoT and distributed systems is what the
world needs for recillience.
> A leaner version of CouchDB would have a very large potential.
> 
> Johs
> 
> 
> 


Mime
View raw message