@elie @diaconutheodor In terms of MDG support, what do you think is missing? Are there any specific Meteor core changes that you think should be considered to help improve Redis Oplog’s integration with Meteor? MDG is definitely busy hacking away on many things, but they’re very committed to this community. If there are any specific requests or recommendations that should be considered around Redis Oplog and Meteor, let’s get them into a new feature request (or we can keep the discussion here and I’ll extract the relevant requests / requirements out into a FR as needed).
I think as people mentioned above, getting Redis Oplog into the Meteor
Guide. Getting some sort of official backing. Even if they’re not helping
build it having the support of the brand behind it would help things a lot.
A blog post on the Meteor blog. Giving their thoughts on the Redis Oplog
architecture. There are so many things they can do to push this project
without writing any code.
Classcraft running on production in two weeks from now will definitely help
things. A write up of that case study on the Meteor blog, assuming the
integration is successful, would help a lot.
1 Like
Thanks @elie - if anyone wants to write a Redis Oplog section for the Guide, I’ll definitely review it and help get it in. With regards to a blog post, I’m sure MDG would love that! If anyone wants to write a blog.meteor.com post (about Redis Oplog or any other amazing Meteor project/application/functionality/etc.), just let MDG know (cc @thea).
1 Like
I think those suggestions definitely worth internal discussion by MDG.
Those might also help with tighter GraphQL integration.
1 Like
@hwillson , @thea already offered me to do this. She did her job right. It was on my part the fact that I delayed that article on the official Meteor Blog. I aim to do it once I have solid case-studies.
How I see MDG helping:
- Acknowledge officially that it’s as a good tool, once we’ll have the solid case studies, I think it would be a no-brainer for Meteor to do so and mention it in their official docs.
- I needed help in the beginning when I began exploring the inner workings of DDP and Reactivity,
especially OptimisticUI (https://github.com/meteor/meteor/issues/8337) but the people who worked on that, are most likely not on Meteor anymore. - Help with reviewing my code or discussing with me how I can make RedisOplog even better. I’m a good developer, but far from being an excellent one.
MDG needs to understand that this will be their master selling point. Reactivity that scales. I show people Meteor, people with solid backgrounds in programming, they are simply baffled about it’s simplicity, and when they ask about scaling this I proudly present redis-oplog. Then I discuss with clients (non-tech) from around the world, they tell me, “I discussed with this guy and he told me Meteor is only for small apps”. This is how Meteor is perceived and before redis-oplog, it kinda was the truth.
I would like to discuss with some of the Meteor people about this approach, give me a bit of their time, I’m sure I can squeeze some insights from them 
. It’s a preference not an expectation.
11 Likes
I strongly believe official support or mention from MDG will surely accelerate adoption and get people back to using Meteor.
1 Like
What does acknowledging it officially mean though?
-
Getting a blog post (or several) up on blog.meteor.com that demonstrates how great Redis Oplog is? MDG is willing, so we’re all set here (they just need the content).
-
Getting a Redis Oplog section into the Guide? No problem here either; someone just needs to write the content. Actually the best approach here would be to open a new issue about a Redis Oplog section in http://github.com/meteor/guide, and break out a draft outline of what the section should look like. Once people have a chance to discuss the outline, we’re then ready to move to a PR with the new Redis Oplog content. So again, the only thing holding up the Guide changes is someone willing to dive in and supply the content.
What else would you like to see from MDG with regards to officially recognizing Redis Oplog? I know they’ve already mentioned it before (and how exciting it is) in other channels (like Transmission 16), so that’s great. What else is missing? Any actionable items we can break out here have a better chance of becoming reality.
I know someone is going to mention the best official recommendation of Redis Oplog possible would be to have MDG accept it into core. As tempting as that sounds, it’s important to remember that each new feature added to core adds maintenance overhead, and unless there is a specific reason why a package needs to be part of core, it’s better off being maintained separately. Changes that make core easier to work with however, that can facilitate the integration of 3rd party packages, have a much better chance of getting accepted (and open up more possibilities for a wider range of packages).
You’re also a modest developer 
. Seriously though MDG’s Meteor team is certainly busy working on all sorts of cool things that continue to make Meteor awesome, but they still read these forums, and they still read all GitHub issues / feature requests. If you’re interested in getting MDG input, your best bet is to open a feature request. That being said, the Meteor team is certainly smaller than the Meteor community. Anyone who wants to see Redis Oplog continue to succeed should definitely consider jumping in and helping @diaconutheodor out wherever possible, including code review and brainstorming.
2 Likes
We are on the same page on everything that you said.
Totally agree, that’s the smartest way to go.
I’m not expecting them to start coding on RedisOplog, not by far, I just stated I wouldn’t mind their input. But honestly I’d rather them focus on other, more important stuff, we got this.
I will create PRs for Guide section and an article, and we’ll get this more recognition. Thank you for your feedback!
4 Likes
Threads like this make me love the Meteor community even more!
So much love guys! 
And of course a special thanks to @diaconutheodor for all the hard work he puts into RedisOplog and Grapher!
(Sorry for OT)
Is there any reason why redis-oplog would cause subscriptions to stop and restart when an field on the logged in user changes. I’m currently seeing a strange issue when using my socialize:user-presence package.
The package works by allowing registration of callback functions that get called when the user connects/disconnects or goes idle. I’ve registered the callbacks to set the status filed on the user record. When that field changes though it causes the subscription on the client to stop and then start again, which changes the status field again causing an infinite publish/subscribe loop. If I remove redis-oplog the issue goes away and every thing operates as intended.
@copleykj there’s an issue that’s bugging me and couldn’t reproduce:
I think this is it, they use user-presence. Once I manage to reproduce it I can fix it in minutes. Can you help me with a reproduction repo on that ?
I am now trying to see if I can do it with user-presence, also the test I wrote is here:
https://github.com/cult-of-coders/redis-oplog/blob/feature/redis-vent/testing/accounts/client.js
Update:
I reproduced in the test. Nice!!! Finally. Solving it soon.
Sure, https://github.com/copleykj/meteor-socialize-demo is the project I’m experiencing the issue on. The project uses packages that aren’t on atmosphere as of yet so there is a script to facilitate cloning the necessary packages. Details in the README.
@copleykj I found it, thank you so much, I notice now the infinite loop executing onUserOnline over and over again if I do:
UserPresence.onUserOnline(function(userId){
Meteor.users.update({_id:userId}, {$set:{status:"online"}})
});
I will dig into your packages and see why
Yes, specifically the publication in socialize:user-presence is being stopped and started repeatedly.
Meteor.publish(null, function userPresenceSessionConnected() {
if (this.userId && this.connection && this.connection.id) {
userConnected(this.connection.id, this.userId, ServerPresence.serverId(), this.connection);
sessionConnected(this.connection);
this.onStop(() => {
userDisconnected(this.connection.id, this.userId, this.connection);
sessionDisconnected(this.connection);
});
}
this.ready();
}, { is_auto: true });
Updated to 1.2.4
- We have cleared all the (known) bugs
- We worked on improving performance even more.
- We added the Vent mechanism. (https://github.com/cult-of-coders/redis-oplog/blob/master/docs/vent.md)
7 Likes
Thanks so much for this update! This fixed my issue with the presence package.
I’m seeing one additional issue though with optimistic updates on inserts. Upon client side insert I see the UI update to display the new document, then the UI updates again with the new doc removed and then finally back to being displayed again. You can see this behavior in the demo by creating an account, signing in, and creating a new post.
@copleykj optimistic ui is done in the method ? If yes take a look here: https://github.com/cult-of-coders/redis-oplog/blob/master/docs/optimistic_ui.md
Its a client side insert operation.
Ok, please create these issues on GitHub, so we have a centralized place for them I’ll take care of it.
1 Like
Sure thing, headed there now 