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.
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?
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?