Where to put publish in my direcotry structure

help
1

I have the following directory structure using autopublish. /client, /server, /public, and /lib <–recommended by discover meteor

So far I’ve been using the lib/collections/subdirectory to put most of my inserts, etc…
On the other hand, most of my read queries I’ve been putting in my /client/templates/subdirectory.

Now I want to turn off autopublish and use Publishing and Subscribing.
Should I put my publications in the /server/publication directory and subscribe to them in the /client/template/subdirectory directory?

Also in this scenario, is there a need for the /lib folder anymore? I’m just starting to get really confused with my directory structure. It seems like things are all over the place.

Any suggestions would help or examples how how you do it. Thanks in advance.

2

Check the docs… http://docs.meteor.com/#/full/meteor_publish

You can see they tell you “Server” beside publish.

My opinion, stop #1 for usage questions should be docs.meteor.com, and guide.meteor.com.

What you want from Meteor is a quick, simple path to get the job done. When you have to go to beyond what’s in the box, there is HIGH risk of losing all the simplicity, and re-entering the chaos of Javascript eco-system… and it’s zillions of shiny new things. ;-). Even Atmospherejs is an incarnation of Chairman Mao’s saying… “let 100 schools of thought contend”.

if they feel 1 package, or API feature is best option to stay way from the chaos, they tell you in the guide. Be kind to yourself, take their advice ;-).

Code is liability… handle with extreme care! whether it’s a package, a JS library, or your own code! http://glinden.blogspot.ca/2008/11/data-is-good-code-is-liability.html

3

wow original talk is still online:
http://videolectures.net/cikm08_norvig_slatuad/?q=norvig

If you want to solve today’s real problems … best answers are at least 8 years old :wink:

4

@artiescie If I wanted the answer “read the docs” I wouldn’t have posted it here. I’ve read them and also the guide. The problem with the docs and the guide is they are average at best as far as a new comer is concerned and there are a bunch of ways to do the same thing. Coming from Laravel where the docs are extraordinary it’s been challenging picking up the inns and outs of meteor. But I’m going to die trying because once it clicks, it’s addicting

Anyway. Thanks for not answering my question.

5

hey ralanyo,
I always have broken my app up like this:

/server/publications.js <- so server side only.
/server/methods.js <- some private methods where I don’t need clients to have latency compensation.
/lib/methods.js <- methods are both client and server for latency compensation.
/client/router.js <- router is on client side, server doesn’t need to know routes unless you have server side rendering (although I haven’t used this so not certain how that works).

All the subscriptions are requested by the relevant templates or react-components.

edit:
I never use insert/update etc… on the client directly, only through methods.
not sure if you’re doing the same but I would recommend that.
its much easier than managing the allow/deny rules.

1 Like
6

@cstrat thanks for the reply. Do you put all of your publications in the publications.js file? I’ve been creating subdirectories based on the part of the application I’m building. Example: /server/publications/players/playersPublication.js. Is this over kill? I guess I thought it made it easier to find what I’m looking for, but it’s all becoming jumbled in my head right now. It’s probably easier your way.

I’ve been doing the same sub directory structure in my /lib directory for methods too. Again probably making more of a mess

My router.js is in the same place as yours.

I don’t do any inserts, etc… In the client directly. Usually call a method in /lib/subDirectory.

7

Yeah I have all publications in the same file, only because my apps never really had more than 3 or 4 collections.

Usually have a null publication for the user account of the logged in user (just to get whatever client side attributes they need). Then there are maybe three collections with data I need to subscribe to through out the app.
Having all the publications in the same place is nice for me - and its not a huge amount of code by any means.

Breaking it up by collection type does make sense but I like just being able to find the one file where publications are defined.

1 Like
8

Thanks again. The difficult part for me with meteor has been that’s it’s not opinionated and there really isn’t one way fo doing something even down to the file structure. So it’s great to see what other people are doing. Thank you.

1 Like
9

Yeah it is a bit hard when first starting. I did exactly what you did and followed the discover meteor examples.
I’m no expert - but I have been playing with Meteor for a while now and this pattern has worked perfectly for me so far.

1 Like
10

@cstrat One last question. I’ve read the docs and the guide and am still stuck on this. When you publish something is it best to be specific in the publication or general and then drill down in the client code?

For example, see my players.find() line with the regex in it.

Server Code

Meteor.publish('players', function(){
  return players.find();
});

Client Code

Template.players.helpers({

  players: function () {
    
    var query = Session.get('query');    
    var allPlayers = players.find({ }, {limit: 25});

    if(query){
      return players.find({"lastName": { $regex: ".*" + query + ".*", $options: 'i' } }).fetch();
    } else {
      return allPlayers;
    }

  },

});//end Template players helper
11

This really depends on your app.

Most collections contain information which you don’t want to share with every client. For example in your players collection you may retain documents for players who were retired or deleted. So you filter those out at the publication. Also people often have attributes in the document which are admin only and need to be filtered at the publication. For example key dates, last IP address, or whatever.

Also consider how many records you have. If you have 600 players do you really want to push that to every client subscribing?

It looks like you’re stepping through documents 25 at a time on the client. You can do that with updated subscription requests on the client. You could get clever and always subscribe to 50 records, so that the next page of results (25 per page) is always pre-cached.

12

Thanks again. Much appreciated.