A NoSQL Conversation

This cropped up recently. It's part of a "replace Mongo with Relational DB" conversation.

I'm going to elide the conversation down to five key points. The three post-hoc nonsensical ideas, and the two real points.

What's (to me) very telling is that someone else published the five reasons in this order. As if they larded three on the front. Or included the two at the end out of guilt because they were avoiding the real issues.

Relational Queries are Desired. "the only way to find [the documents] would be to write a query that literally trolls through the entire database in order to find the most recent values". 

I beg to differ. "Only way" is a strong statement. Mongo has indexes. To suggest that they don't exist or don't work is misleading. The details of the use case involved searching by date. It's possible to contrive a database that does bad searches by date; the implication being that Mongo couldn't do date matching or something. 

To Enforce Constraints and Schema. "It is still possible for the application layer to ensure the constraint, but that relies on every single point in the application code enforcing it – a single error can lead to inconsistent data". 

This runs perilously close to the "what if some bonehead bypasses the API and hacks into the database directly?" question. Which is isomorphic to "what if all corporate governance disappeared tomorrow?" and "what if an evil genius hacks all our database drivers?"

Lack of Document-Oriented Access Patterns.  "If there are more complex access patterns (like reading certain fields from many records, or frequently updating single fields within a record) then a document-oriented database is not a good fit"

That's nonsense. Mongo has field-level updates. There was one example of a long-running transaction that appeared to be mis-designed. I suggested that an improved design might be less complex and expensive than rewriting the API's and moving the data.

  

Desire to Utilize [Relational DB]

More Support Available for [Relational DB]

Clearly, these last two are the real reasons. Everything above looks like post-hoc justification for the real issue. 

We're not sure we like Mongo. 

My point in the conversation was not to talk them out of making a switch. The last two reasons included the kind of compelling rationalization that can't be disputed.  The best I could do was to challenge the errors in the first three reasons so that everyone could be honest about the change. It's not technical. It's organizational.

The GUI Problem

I write Microservices. And not-so-micro Services. API's.

I got this email recently.

"Goal: get you to consider adding Gooey to your Python tool set"

"Gooey
What it's for: Turn a console-based Python program into one that sports a platform-native GUI.
Why it's great: Presenting people, especially rank-and-file users, with a command-line application is among the fastest ways to reduce its use. Few beyond the hardcore like figuring out what options to pass, or in what order. Gooey takes arguments expected by the argparse library and presents them users as a GUI form, with all options labeled and presented with appropriate controls (such as a drop-down for a multi-option argument, and so on). Very little additional coding -- a single include and a single decorator -- is needed to make it work, assuming you're already using argparse."

The examples and the GitHub documentation make it look delightful.

However.  It's utterly useless for me.  Interesting but useless.

From my perspective, API's and microservices are vastly more important than desktop GUI's.

I'll repeat that in order to start a food-fight:

API's and microservices are more important than desktop GUI's

I almost forgot the important qualifiers: When working with Big Data. Or When working with DevOps Automation.

I realize that some people like to cling to the desktop GUI as a Very Important Thing™. Which could be why they send me emails touting the advantages of some kind of GUI tool or framework. The Desktop GUI is important, but, from my perspective, it's a niche.

Actually two niches.

Niche 1. The word processor and spreadsheet and a few other generic tools for putting text into a computer. While desktop versions are better than server-side emacs and vi, they fill a similar purpose. An IDE is (from this perspective) is little more than a glorified text editor. In places that use Jenkins and Hudson and uDeploy and all of those server-based tools, the desktop IDE is a place to stage code for Jenkins jobs to do the "real" build.

Niche 2. All the other tools that turn a small-ish computer into a dedicated workstation for specific kinds of media production. Video. Audio. Image. Typesetting. These are not "generic" applications like word processors or spreadsheets; they're very specific and narrowly-focused applications. They rely on effectively transforming the general-purpose computer into a very special-purpose computer.

Super-fancy desktop-based tools for analytics or Big Data processing are not actually too useful. Anyone trying to use a desktop as an enterprise systems of record is asking for trouble.  I work with folks trying to process terabyte datasets on their laptops and wondering why it takes so long. My company has servers. We pay for MongoDB and Hadoop. We have API's to access big databases with big piles of data. I'm automating the toolsets as fast as I can so they can work with giant datasets.

Gooey looks like fun. But not for me.