That’s for a) people who are incorporating Meteor into pre-existing infrastructures. The company that already has a Mongo database, maybe an Express app, and lots of proprietary company data, etc. (Many B2B projects begin by setting up a mongo database, and importing a huge dataset into it… gigabytes to terabytes of internal company data… then using Meteor to start accessing the data.)
And b) a lot of people are seeking a Meteor IDE. That script is roughly equivalent to what a MSDN subscriber would expect to install when setting up a Dev environment… database server, language interpreters, debuggers, application SDK, etc.
Use cases that are typical for the intermediate developer, rather than the beginner or startup.
I read about halfway down, and then skimmed the rest, so I apologize if I missed this, but one question I’ve had since first adopting meteor is how to develop a really large app (scaling). With meteor sending all of your files down the wire (mobile + desktop and a lot of auxiliary pages such as admin), this becomes a very large package to download initially. @sewdn’s post (http://meteorpatterns.com/Sewdn/project-builds), along with @arunoda’s Bulletproof Meteor courses have been helpful with learning about microservices. However, it would be good if there was a recommended method eventually adopted by MDG. I know lazy loading has been on the development roadmap for a while, but the microservices architecture can help solve the issue with sending excess files down the wire as well.
@seba, thanks for pointing to those. I’ve skimmed the new features, but most of what caught my eye were syntax related features. I’ll have to dig deeper into modules and what http2 will consist of (though how will that work with ddp?). Either way, it would be nice to eventually have some (official) documentation teaching a recommended method.
Coming from Django Framwork I can say that they definetly had really great docs that made it easy to get started and to always go back to for reference.
The outline contains a lot of the topics that I (as a meteor newbie) am struggeling with right now.
Especially important is the relational datamanagement topic (1-1, 1-many, many-to-many) as there are so many third party options available right now. And of course the schema, migrations and form stuff.
I suggest to add a chapter about deployment on your own server/cluster - for the ones of use who want to go with their own servers.
@sashko, I think that’s a really great start, and more or less the conversation parallels my own experiences/needs as my app has grown. I didn’t click a lot of the links in the issues page, but I am guessing @awatson1978’s posts about refactoring touch a lot on how to manage a growing app with different parts.
It might be worthwhile to explicitly acknowledge that an app serving one platform/environment with <2,000 lines of code can be built efficiently in a very different way (e.g., the client/server folder structure) than an app that will have mobile+web+different roles+etc and eventually have a codebase of >10,000 lines (e.g., @sewdn’s packages project structure).
The challenge, as is with the rest of the Meteor Guide, is getting all of this information organized and presented in a way that makes sense to both newbie developers, and also experienced developers who are immediately asking questions of how to scale a meteor application as it grows.
Yeah I’m about to start writing the app structure article now, and I think I’ll go for an approach that tackles simple apps at the top, and gets more and more modular towards the bottom. Probably with refactoring steps in between.
Well, it’s mainly how ES6 modules define a way to state your dependencies and http2 makes it possible to group requests to a server. These are both useful for lazy loading.
The original documentation does need a more in-depth look on all the sections. I’ll do my best to help!
Meteor is quite new (for a framework) and I would like to see a comprehensive guide on how essential things are done. From top to bottom. Right now, my workflow goes like this: I get the basics from the Meteor docs, but I have to look for blog posts and other resources to get a better, more in-depth look. If you develop your guide around the idea of helping intermediate developers, that would be great.
For example, the Rails guide teaches you how to do everything - from the most basic stuff down to very advanced actions.
There’s also a dire need for good examples:
How do I create a good model? Should I use SimpleSchema? What are collection hooks?
I am doing my senior project with Meteor and the best way I can find out how to structure my models/controllers/views/schema is by looking at other successful projects (like Wekan).
In terms of quality of content, material depth for each topic and style the site I linked above is far above and beyond anything else I’ve found. This includes the official meteor tutorials.
If you’re looking for something to aim towards that will appeal to new meteor users, that’ would be it.
We are working on a plan that will include certain stages where we will be asking for detailed feedback from you guys, I’ll keep you posted. The next one will probably be when we create proposed outlines for each article, before we start actually writing content.
Yeah if the current outline doesn’t meet your needs the best thing is to submit a pull request. Is there something in particular that full stack testing means to you?
@joshowens had a great question - what’s the best way to contribute to the guide? I’ve written up an explanation of our plan, and some ideas about what kinds of contributions we are looking for during each stage of the process. Check it out: https://github.com/meteor/guide/issues/2#issuecomment-151354009
While this learning system follows a progressive disclosure dynamic, the experience of learning with it is quite neat. Also the various micro-repos to clone and play-test are great; and the fact that I can reach out to someone who’s learning with me the same topic - also very cool.
How would this Meteor Guide facilitate different learning paths? E.g.: total beginner programmer vs. experienced with other techs