20

I'd like to be able to have an admin app and a client app for my project. Ideally, I'd like to be able to have a shared MongoDB collection. How would I be able to accomplish this?

I tried creating collections with the same name in two different apps, but found that Meteor will keep the data separate. Any idea what I can do? Thanks.

Sam
  • 934
  • 2
  • 11
  • 21

3 Answers3

17
export MONGO_URL=mongodb://localhost:3002/meteor

Then run meteor app, it will change the default database meteor uses. So share databases or collections won't be a problem! For administrative reason, I would use a individual MongoDB server managed by myself other than using meteor's internal MongoDB.

Aaron Wang
  • 1,091
  • 1
  • 11
  • 17
9

A reasonable question and probably worth a discussion in excess of this answer:

The MongoDB connection is handled by the Meteor application process itself and this is - as far as I read and understood - part of Meteors philosophy targeting an approach that might be described like: One data source serves one application belonging to it but many clients subscribing to it.

This in mind, combining "admin" and "client" clients in one application (i.e. your Meteor app) is probably the preferred way.

From a server administrative view, however, connections are handled by Meteor in that way that there is always the default local data source which resides in your project directory (.meteor/local/db, try meteor mongo --url to obtain the mongo connection string while the meteor application process is running). But nevertheless one may specify an optional data source string for deployment purposes like described in these deployment instructions.

So you would need to choose a somewhat creepy way of "local development deployment" for your intended setup to get working. Or you go and hack the sources and... no, forget it. You probably want your application and clients to take advantage of e.g. realtime UI updates (publish) and that is why the Meteor application is tied to an "application data source" and vice-versa by now. When connecting from another app, events that trigger changes in the model would not be transported across those applications. The mongoDB instance itself of course isn't aware of that.

I'm sure the core team won't expose the data source connection to a configuration section for considered reasons unless they extend their architecture with some kind of module concept which provides a common service layer of core Model/Collections abstraction across Meteor instances - at least supporting awareness of publish/subscribe events.

matthias
  • 2,255
  • 1
  • 23
  • 28
  • 2
    Thank you for the interesting read. I would argue that building a URL routing scheme appears to deviate from Meteor's principle of simplicity equal productivity. Having separate apps accessing a share database would also allow a nice separation of concerns (keeping admin/login logic apart from a public endpoint). – Sam Oct 30 '12 at 02:48
  • 2
    It is also difficult (impossible?) to hide html containing sensitive data from clients. Imagine for example that I have an "admin" page with my user count and all the user data I look at as an admin. I can "hide" the result but the best I can do in the html is to put my sensitive field names within an #if block which tests admin access. But the whole html in the template is accessible to anyone with the right js skills. – Michael G. Jul 02 '15 at 13:07
4

Try this DDP test I hacked together for a way to bridge two apps (server A and B).

Both servers can manipulate data, but data is only stored in one collection on server A.

See this link as well

Pynchia
  • 10,996
  • 5
  • 34
  • 43
IamLasse
  • 123
  • 1
  • 11
  • This solution is best in the case that only **some** collections are shared between two servers. The currently selected best answer addresses only the problem of sharing **all** collections which isn't always was people are looking for. – a4xrbj1 Sep 24 '15 at 07:41