with separate channels for data fetching and data invalidation, you can easily scale out horizontally, as far as I understand it. This is implemented statelessly, which is very much unlike the current data implementation with websockets, but it doesn’t restrict you from getting the same kind of real-time functionality, it just has to be implemented. This is basically done by connecting to the invalidation server using websockets or with higher frequency polling.
Is it an improvement due to past experiences together with a more modern approach and current best practices or has MDG finally decided to definitely tackle one of the most controversial critics Meteor got so far about its ability to scale?
From what I understand from the Transmission episodes on the Apollo project, it’s pretty much just Meteor being in a place where a foundation has been built, and they can now finally invest in making things more modular and emphasis performance and individual parts more than just putting the stack itself together. There’s a lot of great information about this in the previous + upcoming episode on Transmission (#6 and #7).
It makes sense that for Meteor to take off, they’ve had to built a starting point, that showcases what Meteor is all about, with trade-offs in terms of, for example, performance. I’m very happy to see that Meteor is now moving beyond what they already have, reaching for a very performant solution to real-time data.
I highly suggest reading on the github page about the design and the discussion on this - It’s all nothing short of great
@ric0: Both. We’ve worked closely on performance optimization with some of the larger Meteor apps, through our commercial Developer Subscription program (and also through hosting them on Galaxy). Through that we can now benefit from a lot of visibility into the write and subscription patterns of different types of production apps under load.
What we need clearly is a data system that has much less magic inside, so you can reason about exactly what is going to happen without understanding the complexity inside Livedata, and that’s what we’re going to get with Apollo.
Every new system has to build trust around it and make the case that it is scalable, and that design goal of performance transparency (compared to the “trust the magic” approach in Livedata) is a big part of how we hope Apollo will earn that trust.
The roadmap looks nice! Good, that mobile building tools will be developed.
I hope mobile building tool improvement includes fixing the bug, which prevents mobile clients from connecting meteor dev server. Nowadays, in many projects, we need to deploy server code changes to be able to connect to the server with our mobile clients – this makes debugging like a safari in hell.
Well, debugging in production mode sucks, I guess it doesn’t need to be elaborated further.
Im totally siked to hear about these improvements ,especially the NPM support and cordova improvements.
Good to see that MDG is trying to adapt existing standards that come from the JavaScript ecosystems available.
However i have seen the new todo example running 1.3 and im quite disappointed (and not just about the 200 extra lines of code required to make it work… ).
Meteor went from no includes and low hassle framework to a complex structured javascript framework with alot of hassle.
Ive been following meteor since the start and been an advocate of sharing meteor among people i know.
Now im not sure i can say the same.
Currently i have 2 production apps running for customers and to see this almost obligation to adapt React into Meteor makes me very worried.
Im hoping MDG does not forget to do what it was set out to do in the first place.
that is in my opinion; creating the framework that is a true pleasure to work with and while doing that,building great apps in a fraction of the time it used to take.
I have not upgraded to 1.3 yet, I usually let new technology settle a bit before adopting it in order to avoid any potential issues, and to allow time for work-arounds of the issues that do arise.
But after reading this post, I did look at the new Todo’s app on the tutorial… and wow. I have to agree with @timmakken, There really is so many import statements everywhere! It’s like C# or Django all over again…
It really does make Meteor seem a lot less Meteor-like. With all the files in my application, I now dread having to update to 1.3. And I do not like the idea of having to add a bunch of import statements on every single new file I create…
The tutorial itself is an issue now, in my opinion. It’s a lot more verbose and complex. In some cases each step of the tutorial has just as many lines of import statements as lines of actual code! I’m glad I’m not a new user, because TBH the tutorial as it stands right now would probably scare me off… Even being a user of Meteor for over 1 year and it’s intimidating to me.
Prior to this update, I feel Meteor was at the sweet-spot of complexity/comfort of usage. Now… I’m a bit scared of having to upgrade to 1.3… I want to do it for the performance improvements… but it’s going to increase development time & complexity in exchange for the performance… And this is a very bad time for that as I am going to have to start training new employees in Meteor at work here in ~1 week… I’m going to have to hold off upgrading for as long as possible.
By the way you don’t have to write imports in 1.3 if you don’t want to - it’s just the recommended path forward. All of your old code without imports will work just as well as it did before.
Yeah, I have read that in other posts just now. If that is the case… Do all those imports really belong in the tutorial? It makes the tutorial seem tremendously more complicated than it used to be…
Another question regarding that, you said all the old code will work, but will new code work without import statements as well? Or optional except in the case of NPM packages? Or…?
We made a decision to focus more on what a production app would look like rather than trying too hard to reduce the number of characters in the tutorial. If you’ve noticed, we added testing there as well.
Imports are completely optional in all cases except:
Your code is in your apps “imports” directory
You are trying to import an NPM package
But the current best practice in JavaScript is to use imports everywhere, and we want to be aligned with that, especially since it’s part of the new language standard.
That’s a bit of a relief. I will hold off on adding all teh import’s until after the new employees transition in to here.
But I do think the tutorial would be better off as a pure tutorial for newer users. In my opinion, all the imports in the tutorial, testing, and everything else for production app’s… That would be better placed in the Meteor Guide, rather than the tutorial, no?
I would think tutorials for newer users, and the Guide is intended to get users up to speed on production-ready app’s.
My plan was for the new employees to just do the basic tutorial and then I would train them from there with the projects coding conventions/app structure… but as it stands, I will probably end up having them learn on DiscoverMeteor prior to my training them, as I believe the tutorial will leave them confused in it’s current state.
Do you know this for sure? If they have used plain node.js, Python, Java, non-Rails Ruby, or really any other language before they should be pretty familiar with modules, right? All of those languages require manual imports in all files.
One of the reasons for choosing Meteor for the project, was the ease of use alongside being js based. Due to this nature, we looked for people mainly proficient in javascript/html/css, which mainly net us front end developers. And we were completely okay with this, as we can start them focusing mainly on front end (which is one of the reasons for us going with Blaze for this project as well) as I have completed most of the foundation for our project.
With Meteor, once they are comfortable working client side, server side is actually very easy to pick up, especially with our application structure intentionally being pretty straight forward, as it was known from the beginning that we were going to bring some employees in on contract to speed up development.
Our job listing had no requirements related to node, python, java, rails, etc. Only html/css/js. One of the employees had some experience with Java. Some are aware of node, but don’t have much (if any) experience with it.
So as a user who planned a project for my job based around Meteor, it’s just a bit jarring to see these changes. It seems as @timmakken implied, that Meteor 1.3 may be forgetting about the original intent of Meteor (at least the one that was advertised).
With that said, I still believe tutorials aren’t the place to teach users how to make a production ready app. I thought that was the intent of the Meteor guide? And Meteor has been advertised as “easy” to use, so it seems pretty important that users first impressions are of it being easy & quick to use, rather than having to type as many import lines as lines of code themselves.
I guess the real question is, what are we comparing it to? If we are comparing Meteor to a pre-build CMS like Wordpress where you just add some plugins and write some custom themes, then it’s much much harder. If we’re comparing it to vanilla Node or Java, I’d say it’s still much easier.
It’s hard for me to imagine a platform which Meteor became harder than by adding the ability and recommendation to do explicit imports, so if your goal is to use the simplest and easiest full-stack JavaScript platform, Meteor is still the main contender in that category. But we found that people coming from other ecosystems were put off by Meteor’s auto-loading magic, and it led people to write apps that weren’t actually maintainable.
I started playing around with 1.3 today. When I got stuck with my publications, I took a look at the todos tutorial.
It looks like server/main.js imports the startup/server folder which imports index.js which imports register-api.js which imports publications.js.
I found this approach much slower to decipher and it has to make the code harder to refactor.
:
