I’m about to dive into my first official Meteor project, and it’s a big one (along the lines of an e-commerce platform). Are there any best practices I should follow to keep things as neat, maintainable, and easily navigable as possible?
2 Likes
Well I’m not in position to share best prctices, as I’m also new to Meteor. But what interests me is that you are working on product which is on lines of an e-commerce platform. How exactly are you handling the transactions part and the ACID properties?
Because right now, I have an e-commerce related project but I’m in dilemma stage to whether go with NoSQL base solution or not.
Can’t advice much on ecommerce for huge web app. Have you calculate the cost to operate and your budgets for the infrastructure and security? Have you start experimenting Meteor yet before getting into best practices.
When structuring UI code, it’s very hard to suggest a best way. Because there is no such.
There is a lot of discussion about components architecture, but there is no single best way.
I suggest you to browse couple of open source projects like Telescope, LibreBoard.
If you need to learn about best practices on DB modeling and performance, checkout BulletProof Meteor.
1 Like
I don’t have an answer (sorry), but I’m curious, what’s your definition of big?
I ask because I see the term being tossed around a lot these days and people almost invariably use it for sites with a lot of traffic/users/io/etc. I want to ask them “So if your hello world app gets millions of users per day, is it a big app then?”
Please ignore the next “paragraphs”. This thing doesn’t let me post because I posted it by mistake on another thread.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut cursus
aliquam quam, eu gravida lorem fringilla in. Pellentesque molestie odio
tellus, ut viverra orci pretium quis. Vestibulum vulputate, ante ut
blandit facilisis, dui nisi luctus risus, non posuere dolor augue ut
quam. Curabitur tristique, magna quis egestas pretium, ipsum lorem
blandit libero, et euismod ligula diam id leo. Sed ullamcorper ultricies
nulla, posuere vehicula mauris convallis sit amet. Etiam non orci sit
amet velit lacinia maximus. Sed aliquet ex felis, ac porttitor libero
fringilla vel. Sed vestibulum velit est, ac scelerisque mi posuere eget.
Phasellus sagittis commodo augue non efficitur. Sed imperdiet lacus
vitae tellus venenatis, et feugiat mauris pulvinar. Sed tempor risus vel
urna vestibulum lacinia. Etiam in malesuada justo, ut venenatis mauris.
Vivamus mollis facilisis placerat. Phasellus elementum, nisi eget dictum
laoreet, lacus massa dignissim ex, non ultrices magna tortor non nisi.
Aenean ut magna eu quam rhoncus fringilla vitae non erat. Nulla
fringilla ligula ut blandit iaculis. Donec lobortis metus eros, at
luctus orci mattis vel. Quisque eu urna sit amet est efficitur pretium
feugiat et nisi. Sed mollis condimentum lacus, ut ultricies libero
fringilla non. Nunc non diam et turpis dictum blandit. Donec lobortis
lorem eget mi sollicitudin, a maximus elit volutpat. Aliquam eleifend mi
ante, vitae sollicitudin purus euismod ut. Duis quis egestas elit.
Fusce vel lectus in nisi ornare vulputate.
I’m still pretty new to Meteor. I went through the Discover Meteor book, and honestly I got to around chapter 9 or so before my brain said “Stop, I can’t handle anymore.” It’s a good book, but it’s just massive and I got to a point where I got burnt out and I had to just stop completely. I figured I knew enough to be dangerous, and I’ll start building my SaaS and look up things as I go. I learn and work better that way, anyway. (learn by doing vs learn by reading 1000s of pages of materials and trying to remember everything)
To answer several questions above…
@Invictus wrote:
How exactly are you handling the transactions part and the ACID properties?
Honestly? No clue. I’m crossing my fingers and hoping Meteor & Mongo take care of this for me. I suppose I could use a different DB solution, but Meteor and Mongo are so tightly paired, it seems wrong to dismantle that.
@proyb2 wrote:
Have you calculate the cost to operate and your budgets for the
infrastructure and security? Have you start experimenting Meteor yet
before getting into best practices.
Yes and yes. I’m either going to launch this on Modulus, or launch on my VPS, except with the latter I’m not really sure how to deploy and have it be as bulletproof as possible (auto-restarting)
Thanks, @arunoda, I’ll look through those projects and check out BulletProof Meter as well.
@manuel wrote:
what’s your definition of big?
I mean complexity of the site, definitely not traffic. 
It will start off small for sure, and build up.
I can’t get into details of the site as it’s something e-commerce related, but rather new in its approach and something that, to my knowledge, hasn’t been done yet.
Can you be more specific? Lines of code, number of code files, number of screens, something measurable… compare it to other big projects/sites you know.
Something on the complexity level of maybe Airbnb. Roughly.
I see that you believe you are on to a brand new and great idea. Perhaps you are. It is not my place to argue that, especially that I don’t know anything about it yet.
But you say that it is SaaS and it is a commerce solution. That means, businesses will trust you with their money and their reputation.
At this point, given that you have not even gone to a point in Meteor where you are not able to finish through Discover Meteor without your head exploding… well… I strongly suggest, not to sound arrogant or belitteling or anything like that, so please oh god please do not take this the wrong way, that you either go with some tech that you feel you are already well versed with, or get yourself a technicatl cofounder who indeed has a skillset and a toolset that they are confident on.
After all, it is your potential customers’ future you are betting on.
2 Likes
If you can’t code to the metal in assembler, there’s no way you’ll be able to manage pulling off even the most basic SaaS web app. Especially today.
In the company I work for we have a giant in house app. The code base is so huge that we often suffer mental overhead in trying to figure out where things are. But we use the Libreboard file convention and that has helped a lot when it comes to client side code. On the server we create separate folders for publications, hooks, observers and methods. Every publication, method, hook, etc is on its own file in these folders.
1 Like
Are you saying one has to be able to code in assembly language to build a SaaS web app? Surely not.
It’s not that I don’t grasp what the tutorial is teaching, or I’m unable to finish it. It’s that my my learning style is more hands-on, and after covering about nine chapters of the book, I want to shift gears and start learning as I design and build it. Not to mention the Discover Meteor book is massive content-wise.
With my solid background/history in web development, I don’t really have any concerns about building something that’s stable and reliable.
Well, in that case I suggest you at least up to chapter 13.5 during
which you will see good patterns in structuring a web app.
If you don’t, you will regret that you did not because the book is all
about patterns.
Only after chapter 13.5 that it goes into things that you may not
need look up until you actually need to.
And assuming you are not just reading it but actually coding and
playing around with the example app that the whole book is built on,
you will have actually built something that you can reuse pieces of in
any other application you’ll build.
1 Like
Sarcasm aside, the general impression I have (being maybe a few weeks ahead of you in learning Meteor) is that you can just keep refactoring and upgrading your way out of whatever knots you tie yourself up in. The “oh no I shoulda” threat doesn’t seem especially likely given the framework makes a lot of sound architectural decisions for you. I have quibbles with it not making quite enough of those, but it’s young.
Arunoda’s work can help you with performance issues and getting familiar with the packages on Atmosphere can save you a lot of time. But Meteor and the whole JavaScript culture is very freeform and permissive in terms of “The One True Way To Do Things” so, dive in and have fun with it and you’ll get the hang of it. The more doctrinaire types are coding in J2EE instead.
2 Likes
Cool, thanks for that. I think I just needed a bit of a break! I’ll go back and read up on the rest.
1 Like
Thanks, I appreciate the sentiment. I’m definitely not rushing this, and there will be a lengthy closed beta as well. I’ll talk to Arunoda about deployment stuff when the time comes, for sure. I’m still up in the air over using Modulus vs my own VPS. I like the idea of Modulus’s auto-scaling. Just not sure if I need it.
Deployment issues are a bit down the road but on that point I don’t think it’s all that big a deal. If the cloud provider with their nifty auto-scaler is 10x the price of buying EC2 instances direct from Amazon, then your auto-scaling better be very intense indeed to actually save you real money vs DIY. There are good arguments against auto-scaling…for instance, if you have a bug that drives up your CPU it could generate big bills before you track it down. Deployment is easy enough in practice that you can spend a day and get deployed on a variety of hosts and choose amongst them at will if you use DNS management.
The Mongo hosting is more important to me than the commodity middleware hosting and for that there are a variety of good options (MongoLab, Compose.io, etc). I wonder if Galaxy will host Mongo or if it will just be another middleware cloud provider with improved Meteor integration. It’s nice and not so expensive (compare to hiring admin staff) to use a cloud provider starting out but if your thing really gets big you will outgrow them and run your own servers.
I have been studying Meteor for about a year now and, up until a few months ago, was doing all my work on a Lenovo Yoga (I have a MacBook Pro but the Yoga is faster, lighter - too bad it is Windows). Anyways, I have struggled with the changing landscape, names for the packages and various approaches to “best practices”. After trying a few I have found a scaffolding generator that works really well - see Chris Mather from EventedMind scaffold generator.
It makes it really easy to create the stubs for all your files for a particular module and the approach he takes for organizing the routes, controllers and “views” or templates makes it easy to configure and build in a stepwise fashion.
ACID in mongoDB is a whole different subject. A really interesting article you might enjoy can be found here: LSM indexing, new database architectures. You might want to look at the TouMx product that adds performance enhancements and MVCC and ACID support for transactional processing to MongoDB.
Good luck.
1 Like
(And just when it looked like iron:router was going to be the Meteor standard…)
https://meteorhacks.com/flow-router-and-subscription-management.html