MDG Meteor Insights and Development News

A new show called Transmission just hit the iTunes store and it was promoted best technological podcast after only being out for three days. It confirms our graving for Meteor Development Group input. Its not that there was a lack of information about whats going on in the community. It just puts more human element toMeteor Development Group. Things felt a bit more to corporate. Meteor doesn’t even consider Twitter for interactivity.

Testing is officially supported and new opinionated frameworks are appearing. It has been kind of neglected for non-meteor packages. Meteor Development Group put a guide article out to get us, the community, exited about the new developments. I would call that document driven development. It seems kind of orchestrated how Meteor posted and communicated their work. But that is fine with me.

Some of the news are that Meteor 1.3 will integrate 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.

Another great subject is that Meteor Development Group announced to build a reactive GraphQL layer with the name: Apollo. Meteor actually cooperates with Facebook and seem to get something really going here. This is big news! It’s designed to be database agnostic so it can be used with SQL databases, MongoDB, existing REST services, or any other data source you may have. And it’s designed from the ground up to scale predictably to very large numbers of simultaneous clients.

Apollo aims to be a complete data stack for modern apps, combining everything that’s good about Meteor with everything that’s good about GraphQL. It’s designed to be database agnostic so it can be used with SQL databases, MongoDB, existing REST services, or any other data source you may have. And it’s designed from the ground up to scale predictably to very large numbers of simultaneous clients.

Having a reactive GraphQL? It is a massive announcement. It won’t just work for Meteor since Facebook is involved. They are going to build a server layer for existing apps. So Rails, Python, and all those apps will become a reactive data source. It could be a database or a RESTFul service. That is the hardest thing. Meteor will not have to get into the nitty gritty with PostgreSQL or Mini PostgreSQL. The issues here is that MiniMongo is very opinionated towards MongoDB. That layer will be disconnected to the client and that is a good idea. That is a very ambitious project and I hope they will get it done.

That means you won’t need to use Meteor for starter projects. Apollo will be a game changer as Meteor was back in time. We will see our community grow, A LOT! But how are you going to manage that? You sit in-between large frameworks and have trillion users coming through your door. So you need a significant portion of their attention which is dedicated to it.

There is so much change within the community but you can’t embrace all of the Javascript changes in the community. Lets see whats about to happen in the next few month. To conclude this. Meteor seems to become a winning choice considering all the components working together. You can use Meteor it self, which is a full-stack path for developers to build amazing apps. And it currently doesn’t include Apollo. But Apollo will be an easy reactive data layer for all database solutions and REST services. Tight into an ecosystem called Galaxy, a place to easily deploy specially tuned containers for either your Meteor app or your Apollo dependency server. Just awesome.

I am currently going to be engage in Telescope’s new architecture. Telescope is written pretty well, from an architecture standpoint. But Telescope will change into Nova. Nova is a compiled power source of knowledge and Best practices for Meteor apps. So that is something I am really exited about.