Great News! Can wait to see everything running 
What an awesome update! I think I’m most excited about “Meteor in npm”, if it works out. I love the idea that people outside of the existing Meteor community can be exposed to and start using Meteor core packages - with Apollo being a prime example - and the clearer package independence with community commits.
Also +1 if Webpack works out. I think this is a more maintainable direction, where we get to benefit from all the existing goodness around the Webpack ecosystem, and that any of our contributions (from MDG or community) will likewise bring positive attention back to Meteor.
I guess I just generally love the idea of being more involved in the general JavaScript ecosystem.
7 Likes
Our plan is to ship 1.3 as soon as possible followed (hopefully rapidly) by the updated MongoDB driver and Node4.
5 Likes
Re-reading everything, this sentence caught my attention. @gschmidt could you share more details? Are people moving to other internal teams or are they leaving MDG? “New faces” does that mean the data team will be growing? I know this is a tough subject sometimes for a company to talk about but I figured you included it for a reason.
5 Likes
@debergalis mentioned in the meteor night talk all binary packages would need to be re-published when you guys upgrade to node 4. But afaik, both the source code and the build is uploaded to the package server if you publish a package version. So can’t this just be an automated script that downloads every package and republishes it?
1 Like
There is a technical limitation in that ABI compatibility (ie, “can you use this binary file with that version of Node”) was unfortunately left out of the package server schema/protocol. That’s the basic reason that this Node upgrade (the first major version change since we released the package server) is taking much longer than previous ones. Without improving the protocol, there’s no way to say “Node 4 use this build of P@V, Node 0.10 use that build of P@V”. There are a few different solutions under consideration, I think…
5 Likes
@benstr: All of the above. Some people are moving between teams, some people are leaving MDG, and we’re also hiring for the data team. We’re also making some internal structure changes, for example, having each team (Meteor, Apollo, Galaxy) run their own development process and roadmap. All part of gearing up to focus on Apollo and running a faster and more open development process.
18 Likes
Great to see things moving forward and I’m really glad to hear MDG is doing well on the customer site. I was a bit worried about this. @gschmidt I am bit confused regarding Apollo maybe I missed something or just don’t understand. But does it sound like Apollo is replacing Meteor? And that Apollo is the future? – Never mind just now reading about this and getting caught up.
1 Like
Apollo is the future data layer management for Meteor.
This is how I see it in my head, someone please correct me if I am wrong…
Meteor = A full-stack happy path for developers to build amazing apps. Which will include Apollo managing domain state.
Apollo = Easy reactive data (the stuff that made Meteor famous in the beginning) available for all DBs and front/back ends. Meteor will depend on Apollo but Apollo will not depend on Meteor.
Galaxy = A place to easily deploy specially tuned containers for either your Meteor app or your Apollo dependency server.
16 Likes
It’s possible sometimes.
We could even automated now with using build machines provided.
But, sometimes they don’t work as they contains very old version of libraries to support backward compatibility between operating systems.
So, we can’t use those machines to build these binaries.
Likewise, I see few issues of doing the automated approach. But, that’s doable.
One correction:
Galaxy = A place to deploy anything (or may be any JS app) 
3 Likes
@benstr Actually, I’d add something: Apollo is really intended to solve four problems…
- Reactive data, as you say
- Fetching all of the data needed by a page in a single round trip (Even in complex situations where it’s coming from several different databases or microservices)
- Decoupling your frontend from your backend, so that every time you add a new page to your app, you don’t have to go write a new publication or endpoint on the server (Meaning that frontend and backend teams can work more independently and backend services can be more easily reused)
- Making apps work well on high latency connections/low power devices (optimistic UI, caching…)
Some of those benefits come from being GraphQL-based, some come from its Meteor DNA - they really seem to go together like peanut butter and jelly.
Even if none of your app is reactive, the other 3 benefits still apply and we think that Apollo will be something that every Angular and React developer will want to check out.
27 Likes
That seems really important to me. Just on a conceptual level, decoupling both sides will probably be a lot easier to understand and work with, I think the publication/subscription model has always been a little confusing for newcomers to Meteor.
3 Likes
And this is exactly why we don’t allow server side code in Mantra.
In other way, forcing you to not to mix client server code.
2 Likes
hey, does MDG see an opportunity with apollo and something like kafka ?
Great work, great update. Thanks.
2 Likes
Everything here sounds really great! Congratulations on 1000 customers!
3 Likes