0

I'm working with Meteor (as a newbie) and have made a small app for a site. The data structure, in JSON, is somewhat complex — I load it on the server startup.js into MongoDB if it's not loaded. I'd like to implement an admin backend interface to the site — to manipulate the database directly — so that in future I could offer this to clients. I've done some very basic work in Django and liked the way the backend came easily.

I was wondering whether any packages exist for easy backend admin interface implementation for Meteor, or whether one has to 'roll ones own'. I'd need to be able to write and change and delete elements of the JSON data structure, and if possible upload images (I know there are packages for image uploading).

Or is this something that would be best accomplished through and only through some sort of MongoDB tool (rather less friendly for clients)?

Cerulean
  • 543
  • 2
  • 7
  • 17

1 Answers1

1

I think what you are looking for is Houston. From the readme:

Houston is a zero-config Meteor Admin, modeled after Django Admin, intended as a simple way for developers to give end-users (or themselves) an easy way to view and manipulate their app's data.

David Weldon
  • 63,632
  • 11
  • 148
  • 146
  • It looks good — but I rely a lot on json arrays for variable amounts of data, and it doesn't handle that well (it says it has limited 'read-only' support for arrays). Are there other packages out there that might? Is there a better away to handle varying numbers of sub-documents other than arrays? (Let's say you have 0-n links on a page, each with url, text, etc — I have been putting them in an array for that page, for example) – Cerulean Sep 30 '14 at 21:13
  • 1
    Well the other suggestion I'll offer is to host your db somewhere like [compose.io](https://www.compose.io/). They have a pretty good interface for editing JSON directly (we do that on occasion for our production app). A nice bonus is they give you an oplog URL. – David Weldon Sep 30 '14 at 21:22
  • 1
    An alternative to having a lot of sub-documents is to store your data relationally. I argue that point in my answer to [this question](http://stackoverflow.com/questions/25344444/best-model-for-representing-many-to-many-relationships-with-attributes-in-mongod). Though in your case, that may mean chasing down a bunch of other objects instead of seeing them all at once. – David Weldon Sep 30 '14 at 21:25