📡 TRANSMISSION #20: Help pick topics

[robfallows]

I should have asked sooner!

[pauldowman]

Worth to mention for galaxy user, http://galaxy-guide.meteor.com/, most are kadira based but maybe something specific to galaxy to day ?

@sabativi I’m not sure what you mean, can you explain?

[cfnelson]

Love to hear if there is any progress or update on Source Maps for production.

[sabativi]

The question was : is there anything that meteor added in APM that is worth talking about.

[diaconutheodor]

I would like to see your take on some works that have evolved a lot since you reviewed them

Redis-oplog is production ready, it has dramatic speed improvement, especially for remote databases, can work with galaxy very well, by buying an ec2 instance near your servers and run redis on it.

Grapher has evolved and matured into something robust, faster than any relational data fetcher for mongodb. Compared to GraphQL it can get up to 20x-30x improvements in speed. It’s crazy how efficient the system is in real-life scenarios.

And the fact that both work flawlessly together.

Cheers!

[herteby]

Prepack, Facebook’s new code optimizer!

[msavin]

I would love to hear how Meteor is doing in terms of user adoption. I have an interest in that as a software vendor, but I think it can also help everyone understand where its going and how vested MDG is in it. We certainly don’t want to see what happened to RethinkDB happen here.

My sense is that Meteor and Galaxy might actually be growing, despite everyone shouting that Meteor is dead or that they are switching off of it. It would be nice to hear something real here.

I used to gauge growth through Atmosphere package downloads, but its not working poorly. It would be nice to know if that would be fixed too. Right now, numbers are off, as are top charts and most popular, and that does not look good.

[efrancis]

This isn’t any specific forum topic, but I’d like to hear about plans beyond Meteor 1.5.

For the past year @benjamn has been just about the only person working on the Meteor codebase, with @abernix hopping on board in the last month or two. New feature development has been gradually slowing to a crawl, with 1.5 taking about a year after the release of 1.4, which was an uneventful release without any big headline features. It appears that most efforts have moved to Apollo, Optics and Galaxy. So what’s Meteor’s future plan look like? Is it mostly feature complete now that its stable and does what it’s supposed to do, or can we expect more changes in the future? What should we be excited about beyond 1.5?

[alawi]

Echoing the comments above, I’m also interested at looking beyond 1.5 and specifically if there’re any plans to further bring the Apollo ecosystem closer to the Meteor ‘Classic’.

With that said, I personally don’t expect new features every release. Meteor is relatively a mature framework and I think stabilizing what’s already working is as important as coming up with new features for the sake of coming up with features.

[storyteller]

What @msavin said and the process toward Node.js 6.

[hwillson]

Just a quick update on Node 6 - it’s slotted for Meteor 1.6:

Node 6 is far too big a change to include in Meteor 1.5 at this point. Getting Meteor 1.6 stable will be the top priority after Meteor 1.5 is done. There’s a good chance we’ll release 1.6 before 1.5.1, unless the remaining problems turn out to be really hard to solve, but I’m not too worried about that.

[herteby]

Any specific cool new features you can tell us about, that Meteor will use from Node 6? Performance improvements?

[hwillson]

Node 6 brings many performance improvements to the table, but the biggest advantage to getting to Node 6 sooner than later is that Node 4 just entered maintenance only mode. It’s only getting bug fixes from here on out.

[Volodymyr]

Build system used in Meteor (does it have a name), its advantages and disadvantages, and plans to replace it with something like Webpack.

[msavin]

I just launched Meteor Candy, an all new admin package. I think it’s something that Meteor start-ups will need, and the response to it has been very enthusiastic. Your support on the show would be highly appreciated, so that I can keep bringing new things to the Meteor ecosystem

Meteor Candy, the 5-Minute Admin Panel for Your Meteor.js App

[vikr00001]

Also: benefits of Meteor build system in comparison to Webpack.

[vikr00001]

@msavin This looks really cool. A huge time-saver for developers.

[pauldowman]

Great topics.

But FYI, we had a scheduling problem, and I’m on vacation next week so unfortunately we had to postpone it… I’m sure we’ll have even more to talk about by then.

[vikr00001]

Scaling Meteor, with info from this thread:

@markoshust

I’m one of those guys that doesn’t understand the “scaling issues” of Meteor. AFAIK, the reactive: false property within publications was added years ago, and if you still have issues with large publications, it’s very easy to throw the db call into a Meteor method that doesn’t have to deal with the pub/sub scaling issues. Essentially, this transforms the db call to the backend so it works just like any server-side language, but pipes the response over DDP instead of REST. This has much faster responses than the request->response flow of any other server side language.

@XTA

One thing we do is to transform sub documents, which don’t need to be reactive, straight into the published doc. So we don’t need any method calls or an additional publish to connect relational data. I’m also wondering about scaring scaling issues. We’re running a Meteor app with ~1.5k concurrent users on a single VPS (+ one for the database) and also using individual subscriptions for each visitor. So only performance issues we had so far were missing/wrong indexes in the database.

[pauldowman]

It’s up! https://youtu.be/E5tmLcvr6ok

The audio-only podcast version will soon up up also at: https://transmission.simplecast.fm/

Thanks @sashko for doing this!