Publish and subscribe same collection multiple times + 3 another related questions

Hi, sometimes it is not so simple to explain question in short sentrence.

Q1:
To clear my question from the previous “chat session”, I would like to ask, if Is it possible to publish and then subscribe same collection multiple times, but without merge both publications into same collection.

For example: publish list of users connected with mee - friends (with some fields) together with list of friends of my friend (with another fields). On the server side, they are still only “users”, on the client, they can by: “my friends”, “chat users”, “frieds of my friends”…etc.

Of course, they will be mixed in single minimongo collection on client, but sometimes it is confusing. Therefore, I would like to ask, if is possible somehow define name in minimongo, where I’m subscribing to collection for example: users_chat, users_friends, users_some_another…

Q2:
What is the best practive, how to work with publications? For example in my case, I will subscribe all data, which I’m often using before loading router and than Im subscribing only missing data (for example for forms or datagrids). Is it correct approach?

Q3:
When I will put mongo selections directly into methods and publications, sometimes lot of code (and also list of published fields) are often releated (in some cases). Are you moved mongo selections from methods and publications to some another place (for example Models) to be able to reuse it? Or you are using some another way?

Q4:
@filipenevola how to make performance testing for methods and publications? Does exists some (simple) way to make this kind of tests?

Thanks a lot.
KC

General feedback is that it seems like you are over subscribing data that you don’t need to be subscribed to (of course I don’t know your use cases).

Q2. Only subscribe on the component where you need realtime data. Move higher the component tree as needed or create hooks/helpers/HoCs to minimize use of subscription where you don’t need realtime data. Most of the time you don’t need subscription in forms unless it’s a collaborative form/tool.

Q3. We use collection files (one file per collection).

1 Like

Q2. yes, the reason/usecase why I need it is for longer explanation (for now it’s not so important), but by your answer, it seems to be, that this case is not possible (3 not related subscribes from single collection will be alway mixed in single collection in minimongo without possibility of separate store in minimongo).

Q3. …those collection files, you are using as models? …with methods getItem(id) getItems() saveItem(formData)…etc.? …because, I was also used this way, but it little bit slowing down the development (especially with typescript).

Thanks a lot for your answer.

It’s always a compromise between premature optimization (both performance and process) and technical debt.

1 Like

Q1: You might want to look into observerChangesAsync docs, where you can add and manipulate fields on the document. So that might be one solution for you.
Usually to resolve this on the client you do the same queries like you do on the server to identify the user you need.

Q2: You might want to look into jam:pub-sub, that should give you some extra options. One thing to consider based on your needs might be mizzao:partitioner, that package needs a complete re-write or re-creation (it is somewhere on my todo list), but might be something that you want to look into.

Q3: If I have a selector that I’m re-using I put that into a separate constant/function (if I need more stuff to dynamically populate there), I can then import that selector where I need to.

Q4: There are different profiles. I think MontiAPM might have something. Other logging and analytics SaaS also do profiling on your apps. If you want to go super simple you should learn about console.time() and related commands.


This was answered as part of Meteor.js help desk. Please consider sponsoring me on GitHub.

1 Like

@rjdavid can you share one example pls? Are you mixing “direct mongo selections” used in server meteor methods together with selection functions in your collections files? …or you will always prepare functions for mongo selections before use them and then you are yousing alwys this functions and all mongo selections you have on single place?

Thanks a lot.

We prepare the function for each query to any collection. The functions are created on demand. These functions are reused/updated dependent on business requirements.

1 Like

And where and how are you putting that function, what is your best practice? Are you putting that functions into the same file, when you defined the collection, or into another file? And you have written functions, which you are exporting or you have created a class or abstract class with static method to make imports more simple (import single abstract class, to make all their static methods available in one import)? Sorry for so detailed questions.

One query per function. Each function is exported.

1 Like