I'm admittedly not too tuned-in with the Mongo/Redis/Couch communities, but I do hear from a lot of folks using my native GUI http client tool to interact with their web APIs. I kind of assumed that most users of them were fairly happy to use low level/command-line tooling - is there a big unmet demand for native GUI tools for things like Mongo, Redis, etc?
This is a tad off-topic, but I'd love something that's more like django's admin UI for mongo-using projects. Not the same tool, I know. What's a good word for something like that?
This is something that I am struggling with, I am yet to find a MongoDB GUI tool that I personally or the team I am working with are happy with. Personally I would prefer something that can be run locally (so either desktop app, or web app with integrated web server/easy setup). In regards to support for other databases, my personal view is do one thing and do it well, there is enough complexity in getting it right with MongoDB before you worry about any other databases.
This is something that I have personally been planning on building for a while, so if this were an open source project, I would be interested in contributing.
An interesting problem with making a MongoDB GUI is that a key feature of every SQL GUI -- a rich <table> of your data that you can use to see it and play with it -- won't work as well, because MongoDB doesn't have strict table definitions. (Or 'tables' for that matter). Each item in a collection could have completely different fields. So given a big collection of this irregular data, how do you display it compactly? Listing each element in JSON is inefficient.
Great point. This is what we have been discussing internally. One option would be to let folks define an "object" (Read table structure) and display based on that.
I've kicked around some ideas for this problem a while back. I think letting users define a "view" like this is a pretty good approach.
I also think a reasonable default is to just pick the the N most popular (where "popular" means defined and non-empty) non-object/collection fields in the root document and display them in a table, then double-clicking or whatever on that row brings up the full document.
Curious to understand why the two biggest projects are no longer maintained. Usually usage drives people to continue development, so can we assume nobody used their products? Filled out the survey.
22 comments
[ 7.9 ms ] story [ 56.8 ms ] threadThis is something that I have personally been planning on building for a while, so if this were an open source project, I would be interested in contributing.
I also think a reasonable default is to just pick the the N most popular (where "popular" means defined and non-empty) non-object/collection fields in the root document and display them in a table, then double-clicking or whatever on that row brings up the full document.