Robomongo.

Native and cross-platform MongoDB manager
Whatever platform you use today — Robomongo is available for you. Distributed as a native application, fast and snappy Robomongo uses very little of your machine resources.

[Robomongo]

Advertisements

How To Be MEAN: Let’s Be DEAN

Ted Neward. MSDN Magazine. 2016-07-01.
Welcome back again, MEANers. Or, rather, for this month, “DEAN”ers.
One of the things that makes conversations and architecture around the MEAN stack so compelling is that the MEAN stack is intrinsically flexible—you can replace components of the stack with other, more-or-less-equivalent parts and create a new stack that can address corporate/business needs without surrendering the essence of the architecture. As a demonstration of that concept, in this column I’m going to experiment with replacing MongoDB with Microsoft Azure DocumentDB (hence, the “D” in place of the “M”).

[How To Be MEAN: Let’s Be DEAN]

Introduction to DocumentDB: A NoSQL JSON Database

Mimi Gentz. Mcrosoft Azure. 2016-07-01
Azure DocumentDB is a fully managed NoSQL database service built for fast and predictable performance, high availability, automatic scaling, global distribution, and ease of development. Its flexible data model, consistent low latencies, and rich query capabilities make it a great fit for web, mobile, gaming, and IoT, and many other applications that need seamless scale.

[Introduction to DocumentDB: A NoSQL JSON Database]

How To Be MEAN: Robust Validation with MongooseJS

Ted Neward. MSDN Magazine. 2016-03-01.
In my February 2016 column (msdn.com/magazine/mt632276), I transitioned to a MongoDB database. Doing so wasn’t that hard thanks to the JSON-based nature of Node.js and the JSON-based nature of MongoDB. (Life is always easier when working with data if the transition is from apples to apples). MongoDB has a great advantage in that it will “scale up” and “scale out” easily, not to mention that it’s trivial to get started. But it also has a significant drawback: Because MongoDB is a “schemaless” database (in that the schema is already predefined—a database holds collections, collections hold documents and documents basically are just JSON objects), within it lies the seeds of its own destruction.
First, recall that MongoDB queries are essentially query documents (that first parameter to the find call), containing the fields by which to scan the collection for matches. So if the query “{‘fristName’: ‘Ted’}” gets executed against the “persons” collection in the existing database, nothing will come back—the field name in the query document is misspelled (“fristName” instead of “firstName”), so it will match against no documents in the collection. (Unless there’s a typo in the document in the collection, of course.) This is one of the biggest disadvantages of a schemaless database—a simple typo in the code or user input can create accidental bugs of the most furious head-scratching nature. This is where it would be nice to get some language support, whether that’s by a compiler or an interpreter.
Second, notice that the code displayed in my last column is reminiscent of the “two-tier” applications that were popular for two decades during the “client-server” era of computing. There’s a code layer that takes input directly from the user (or, in this case, from the API consumer), applies it and gets a simple data structure back from the database, which it hands directly back to the caller. There’s certainly no sense of “object-orientation” in that code. While not a deal-breaker, it would be nice if we could get a stronger sense of “object-ness” to the server-side code, such that some validation of various properties could be centralized in one place, for example. Case in point: Is it legal for a person to have an empty firstName or lastName? Can he be doing absolutely anything in his status? Is there a “default” status, if he chooses not to provide one, or is an empty status acceptable?
The Node.js crowd has wrestled with these problems for quite a while (it was one of the first language ecosystems to adopt MongoDB on a large-scale basis) and, not surprisingly, it has come up with an elegant solution to the problem, called MongooseJS. It’s a software layer that sits “on top” of MongoDB and provides not only a schema-like language-verified validation layer, but also an opportunity to build a layer of “domain object” into the server-side code. Hence, it’s sort of “the other ‘M’” in the MEAN stack.

[How To Be MEAN: Robust Validation with MongooseJS]