Are we referring to the same mailing list? Because an email was sent out just yesterday from developers@meteor.com: “Signup for Galaxy Developer Edition”
@lucfranken There is an in-progress live site up at http://meteor-guide.s3-website-us-west-1.amazonaws.com/
We’ve needed Streamy for temporary messages like WebRTC signaling messages or f.e. to send a “is typing notification…” to a user in a chat room. I know that there is also Socket.io to handle such things, but I didn’t want 2 different user states for one single user (because in this case you have the user session on the Meteor server and the user session on the Socket.io server).
@waldgeist It’s a Node.js plugin (link). We are using it for a social media app which allows file uploads (videos and images), so it was the simplest solution for us to seperate the “file service/server” from the main application.
“jack of all trades master of none” argument. I personally believe it’s a very valid one. It’s extremely hard to stay up on everything in just the Meteor community, let alone NPM, let alone etc.
ic. …definitely see how it feels overkill to go through the db to get what you don’t even want to store. …you still could use it, and just observe the messages collection in a publisher, and manually use added to publish it to subscribed clients. and just delete delete stale messages in an interval that are older than a certain threshold:
Meteor.publish('messages', function() {
Messages.find({}, {sort: {createdAt: -1}, limit: 1}).observeChanges({
added: function(id, doc) {
this.added('messages', id, doc);
}.bind(this)
});
});
Meteor.setInterval(function () {
let threshold = moment().subtract(10, 'minutes').toDate();
Messages.remove({createdAt: {$lt: threshold}});
}, 1000*60*10);
Not that that is anything novel to look at, but you can also use publications/subscriptions like advanced methods (for things like WebRTC signaling or other external requests). Like this:
Meteor.publish('messages', function() {
let self = this;
HTTP.post(WebRTCurl, options, function(res) {
if(res.success) {
self.added('signal_info', res.info.id, res.info); //send to client-only collection (and never persist)
Messages.find({sigId: res.info.id}, {sort: {createdAt: -1}, limit: 1}).observeChanges({
added: function(id, doc) {
self.added('messages', id, doc); //sending to a another collection in same publication (this time backed by a real server side collection)
}
});
}
});
});
Meteor.methods({
sendMessage: function(sigId, type, message) {
if(type == 'im') Messages.insert({text: message, userId: this.userId, sigId});
else if(type == 'disconnect') HTTP.post(WebRTCurl+'/disconnect/'+sigId);
else if //etc
}
);
if(Meteor.isClient) SignalInfos = new Mongo.Collection("signal_info");
I dont how your system all actually works. But the point is if it works for DDP to be the transport format, then you can do a lot more in subscriptions than you might think. Combine that with LiveQuery + Compose.io + a Cluster, and at the very least you won’t have the issue of syncing data between different tools/instances, and perhaps more importantly can code in a very standard Meteor way that will scale horizontally (not infinitely, but very far). You won’t get the throughput and scalability of tools meant just for messaging, but the truth is you will be able to have a wildly successful product before that point comes.
Just to chime in, we can do that today with a few different options. Ultimately it’s up to the user to import the code.
The easiest is to only import the client/server methods you need. Any methods running on both can use isClient/isServer to do conditional logic. For example:
// in client code
import {doClientStuff} from "my-module"
// in server code
import {doServerStuff} from "my-module"
by having different folders (client/server) in the package and then doing an import (perhaps because you need globals)
// in client code for client
import from "my-module/client"
// in server code server
import from "my-module/server"
There are solutions by @SkinnyGeek1010 and @jedwards, but I personally have yet to try them, so I can’t comment, but my guess is there is still major challenges there. Perhaps, I’m wrong, and the only challenge is that it has no “kickstart option” and therefore requires developers to have full knowledge of Webpack, and go through the tedium of importing code.
I think most of the kinks have been worked out. I’ve been using it in prod for several months and it’s working great. Testing with velocity is a bit off since you have to expose globals but other than that it’s great.
If you clone the repo down there’s a hello world app that is heavily littered with comments explaining how it works. Just clone, npm install, run ./dev and start coding. There’s more there than the default meteor scaffold and it even includes a setup for Jasmine unit testing with a passing test. Using Blaze requires adding a loader and my screencast shows how to do that.
It’s a pain to convert to ES6 modules but you’ll be rewarded with 1-2 second reload times and the ability to use normal JS testing tools 
glad to know, the 1-2 hello world app is solid for starting out with. …believe me, i got this on my agenda to assess thoroughly. Can’t wait!
how are integration tests for publications + client & server aspects? Can you run tests that bootup an app with your publisher available, subscribe to it from the client, then spy on and unit test calls made by publisher (say you got a publisher that calls lots of other functions to do advanced stuff), and then unit test the subscription results (within various calls, particularly rendered React views) on the client (or fake client via jsdom)? i.e. the holy grail of Meteor testing. How much closer to achieving that have we come in pure NPM?
…also, what do you think about this:
?
@faceyspacey I’m currently using Velocity but am looking into migrating integration tests to tiny-test.
I’m pretty much going the route of heavy unit testing and heavy end-2-end testing with Cucumber/Capybara and testing little (I posted a thread something like ‘the way forward in meteor testing’ for a cool video on this). This skips the whole Velocity issue.
So currently Velocity in Webpack works the same exact way, it lives in the ‘meteor_core’ folder and starts up like normal. All normal globals are there. However, any modules that you need to use must be globally exported… I have a 'if in dev mode, export module to Test.MyModule so that these are available for test (or shell access).
It ends up looking like this:
const MyModle = {foo: 1};
export default exportIfDev(MyModule);
It’s just exposing to that namespace and returning which then gets passed to export default.
I don’t unit test publications/subscriptions but you could do that with integration tests easily… for my use cases I make sure they’re working with end-to-end tests.
Also functional programming has made unit testing trivial so the more of that you do the easier it is to test.
unexpected-react is interesting… i’ll check it out further. i’m looking into the test tree one too.
I learned that if you want the easy of just adding a package for a new feature, you have at least to overview it’s source code and understand how it will affect your app internally.
Going throught the repository issues help a lot too, in Streamy there is one that tells it’s not contempling a cluster structure. But looking it’s source, is clear that is simple and organized to add a message layer between nodes with Redis, for example.
Great @faceyspacey, this is exactly what i’ve been doing, Meteor provides this kinds of solutions until you work on a more robust one and even really needs one.
It’s needed to reasearch and plan more than one solution and know what to do when the time comes. Trading for another framework probably will bring another set of unpredictable problems.
Meteor has many limitations but many workable paths when you know it better.
And Sashko’s guide will bring better light to many of this paths too.
Really looking forward to the Meteor Guide:sunglasses:
you really hit the nail on its head there. I was also very excited about Meteor from the very beginning but what’s happening now with all the split in the community, no clear way of doing things and so on really makes Meteor one thing… a nice go and have a look thingy but nothing you’d want to use for things that need to pay your bills and put food on the family table.
I really wish it wouldn’t have come to that and that there were decisions made were there was one way of doing things, take routing for example. Meteor as it is now imo is to much time effort to find the right package that’s working, has docs, is supported, to much risk of going with some part of the community that might be declared not the offical way tomorrow etc.
I don’t know. Is that below really much more complicated than having three files per view (handlebars, template events, methods + eventual style sheet)?
https://github.com/ultimatejs/tracker-react (from the sideburns project; paving the way for blaze 2 / inferno)
App = React.createClass({
mixins: [TrackerReact],
// making react - reactive with a meteor collection cursor
tasks() {
return Tasks.find({}).fetch();
},
//state-based reactivity working in conjunction with tracker
title() {
return this.state && this.state.title ? `(${this.state.title})` : ``;
},
render() {
return (
<div className="container">
<h1>
Todo List {this.title()}
</h1>
<ul>
{this.tasks().map((task) => {
return <Task key={task._id} task={task} />;
})}
</ul>
</div>
);
}
});
Now you can go to NPM and grab one of the hundreds of shiny react components. Stuff a meteor cursor inside. Done.
@sergiotapia, I totally get your perspective, but I don’t see any other company that is working to actually “glue” together all of these JS technologies for us. MDG has the vision to make modern app development simple and accessible, and to cover almost all aspects of it, from coding to deployment. It’s a holistic approach that you just don’t get everyday, not in the JS/Node world at least. Correct me if I’m wrong.
I’m quite happy to see @sashko’s vision on this : 1. Significantly increased flexibility in Meteor core and 2. Significantly more opinionated Meteor guide .
Lastly, Meteor is still young and there are changes that MDG will make, but I think they’re on the right path. What we have to do now is keep learning what we can and have patience. Things will eventually settle down. Evolution will become easier as Meteor becomes more flexible.
@sashko I’m glad you’re doing the guide. Unfortunately I don’t see anything at all about SEO in the guide. (Perhaps in the live version that is loading right now?)
Our site went live a few days ago and only one site (the main page) is being indexed, every other page hasn’t even been indexed at all, prerender.io did render them server side though. No idea how to get my stuff indexed, which is really too bad because we’ve already been covered/mentioned several times online.
Same goes for dynamically generated content like store pages based on a user profile’s id, how do you get that indexed if technically the route isn’t defined specifically with an ID?
That’s a really great point - SEO should be in there, and we forgot. Really glad you brought it up! Filed an issue, we need to decide where the best place is to put it:
I’m not sure about this one. Generally isn’t the wisdom of the crowd as good as, and often better than, the answer given by any of the individuals within the group? Back in last 2014 a member for the Meteor core team announced “We now recommend Atom.io” in the Meteor Cookbook. The community seems to feel otherwise. Granted choice of editor is a very personal thing, but just because the core team recommends something doesn’t always mean it’s the best idea right?
I am also frustrated with all this Meteor platform volatility nonsense.
Blaze meets a need. It’s simple, easy to learn, stable, and an effective tool. You can build re-usable components. For many apps it’s all you need. Why Meteor would so quickly abandon this technology baffles me. Yes I use the word “quickly” here - I know it’s been like a whole year since 1.0 was released (I think it was Oct 28, 2014). But to me it feels like the paint on this shiny framework just dried and now we’re redecorating. WTF?
But of course it’s really not about Blaze or React or Angular or whatever the next thing is… is it?
It’s about users who use your application. You know - the one you’ve built or are currently building. And the entire developer community - a number of which like me are all about using a great tool to build great stuff and NOT about adopting new technology for technology’s sake.
If the tools you’re using to build this experience are sitting on a sea of shifting technological sand - everyone loses.
Instead, I’ll argue MDG’s focus should be on responsibly evolving this awesome framework in a way that doesn’t leave developers in the dust.
A few facts (according to me) to ponder:
Meteor got a few things right (reactivity, data on the wire etc) where other frameworks missed the mark - that’s why we’re all here.
I’d like to see more leading and less following going on around here.
That’s the part you’ve got my <3 for.
On the other hand, generalizing is a very bad thing in a long run. As much as “crowd mentality” - “opinion” of the group doesn’t necessarily mean they are right, right? 
We are witnessing large groups of people being mislead each day, while outvoting smart individuals within (and outside) of the group (political insinuations are intentional …
Disclaimer: I’m not an official member of the core team! Just a heavily invested community member. And while Meteor Cookbook is probably the largest resource of its kind, it’s not an officially sanctioned resource. 
That being said, what people probably don’t know is that the initial integration of a Meteor in Webstorm was lifted from the Cookbook. Same templates, spelling typos, etc. I spent a year piecing together the outline of what eventually went into Webstorm. And I got frustrated with Webstorm being written with Java, and hopped over to Atom where I could hack on the editor itself. So, that’s why the recommendation for Atom.
So, now here’s the question… Sublime and Webstorm are the most popular editors because they have the most features out-of-the-box; but neither are written in Javascript and neither will reach the same level of isomorphic integration that Atom can get. Is Webstorm the best isomorphic editor? Or merely the most popularly known editor?
Already, we’re using a Chrome isomorphism between Client, Editor, and Testing Environment, and it’s a beautiful thing. And Webstorm can’t offer that. So, by some standards of comparison, Webstorm isn’t even a consideration.
But not everybody is looking for an isomorphic editing experience. So it boils down to using the right tools for the job. What are people trying to achieve? Are they truly following the Seven Principles? Can Sublime and Webstorm users say they’re following the principle of Pure Javascript if their editors aren’t built in Javascript? Is this a question worth asking? Does it border on being ideological?
I guess what I’m trying to say is that Meteor has some architecture principles, and recommendations like Atom over Webstorm are in accordance with those principles. Even if they’re not the most popular solutions. By that wisdom-of-the-crowds reasoning, gasoline cars are the better solution because they’re more popular, even if electric or hybrid cars are available.