I am very new to Meteor. I have been reading the docs and the Meteor Book to get a grasp on what Meteor is all about. So far I think it is really amazing. I love the full stack…how it works with you and not against you.
I do have a question though. I have a project in mind that doesnt necessarily need to be real-time. Is Meteor still a good fit for apps that do not require real-time data? To be more specific, the idea is an Human Resources system(payroll, benefits, and employee self service). What I really want is the SPA user experience.
Would I be crippling my app by using Meteor without real-time (the cpu usage of multiple connections is what concerns me)?
Being a single-page-app means that there is probably a lot less load on the server as there are no full page round trips anymore - each page will require only a little bit of data.
If you like the development experience, then go for it! The development model, the ease of getting things done… all these things matter a lot.
There’s definitely nothing wrong using Meteor for non-realtime stuff. Just because it does realtime quite well doesn’t mean it’s all it does well.
As for your concerns regarding CPU usage: If you manage your subscriptions well (i.e. don’t oversubscribe massively) you’ll be just fine. Should it prove critical and you don’t need realtime updates anyway, you can always also go with getting data “manually” from the server through Meteor methods. In key spots, and again, should that prove really critical. But usually it doesn’t, and you’re fine getting all the benefits of Meteor’s reactivity, without paying any unacceptable price, without sacrificing flexibility to optimize critical pieces of the app.
Go for it! The SPA user experience is fantastic with Meteor, and with all of the fantastic developments in frontends (React, various component packages, Angular 1/2, …) that can all be chosen on top of Meteor*, there has never been a better time to create great UX with Meteor.
(*: Blaze is a bit bare-bones/low-level at the moment, sure needs some <3 in order to be an excellent choice long-term and for medium-sized to big apps. But it still works really well, the developer UX is just not quite on par with much of the rest of Meteor!)
I’ve done it for a few smaller apps. You can disable the reactivity with {reactive: false}
Any change to the collection that changes the documents in a cursor will trigger a recomputation. To disable this behavior, pass {reactive: false} as an option to find.
That certainly makes me feel more confident. I do have two other concerns:
MongoDB. I am not a DBA but I have read some troubling things concerning Mongo. For the idea I have, data accuracy is of extreme importance (people’s pay checks). I have heard if you model the data correctly this isnt much of a problem. Then again others say to avoid it if you need 100% accurate data. Now I hear PostgresSQL is coming to Meteor and I know that would work perfectly. Thoughts on Meteor for sensitive data?
Client vs Server side processing. I need to be able to generate various reports in both web and PDF formats. Is that too much to ask a client to process? If so, would that hold Node up? These wouldn’t be overly intensive reports (simply generating paystubs, liability reports, etc). Most would involve simple addition, subtraction, and division. Ideally some real time graph generation.
I’ve made a few Meteor apps that do not need to be realtime. Meteor’s latency compensation is really really nice and makes the user experience better. Just for that I would be willing to pay the overhead of having a subscription open. Having a fast dev cycle is also worth a lot.
You can also disable reactivity like suggested above. Another option is to have a Meteor method that returns an object (essentially JSON). This is not ideal though because you can’t query MiniMongo and you’re kind of using it as an API.
MongoDB gets a lot of flak currently. As far as I can tell a lot of that is based on the analysis that it got from Kyle aka aphyr. And people just don’t have a clear enough understanding what has been tested there and what’s relevant to who, and what it all means.
Basically, MongoDB is not much more broken consistency-wise than most other complex pieces of (DB-ish) software we use. Check out the other posts on Kyle’s blog for that.
BUT one key thing is that MongoDB did say things about its consistency guarantees that simply do not hold. It doesn’t mean MongoDB is mega broken, it only means that, as with every other distributed system, you have to pay good attention to what you’re doing and how you’re configuring things, based on the guarantees you need.
Basically it boils down to regular users with a single node don’t need to worry about consistency at all. If you absolutely cannot lose any data, then check out the options MongoDB provides for making tradeoffs towards better consistency and a little less performance. I believe it can make all the tradeoffs you need.
Now I might also be wrong, or at least a bit inaccurate, on some of these things here, but it’s important right now to not jump on the “MongoDB is so broken” bandwagon, just because lots of people are saying lots of things.
There are many more success stories with MongoDB than horror stories. It would never be where it is right now if it truly were not trustworthy of taking good care of people’s data. And MDG would have never chosen it as a key component for Meteor. They make very good decisions overall, and they’re much smarter than I am, so there’s also the point of trusting them that they have made a good enough choice in this aspect as well. (But this latter part is of course in addition to actually taking a stab at understanding what’s actually going on with MongoDB and my/our own perception of how well it can be trusted and how well it works, or not.)
tl;dr – lot’s of fuss around MongoDB at the moment, a lot of that is not very accurate, a lot of that is indeed accurate, but irrelevant to most of us who are not running bigger clusters, across data-centers etc.
But do your own research, reading and experimentation if this aspect is really really key to your project. Most projects will be absolutely just fine.
You can simply move processing intensive parts out of the main (Meteor) node app and into worker processes. No big deal at all and it won’t hold up the Meteor server at all any more.
And it’s perfectly fine architecture, too. If you’re not doing lots and lots of heavy computation (which most of us don’t), then Node is just fine for that.
And if you should ever need to move beyond that, for something that requires more punch in terms of processing power/efficiency, you can always build another service in a different programming language, and connect it via any remote communication method you like, like queue, message bus, ddp, http/rest api, websockets, … and that is also sound architecture and advisable.
You’re definitely not hindering yourself by using Node for simple computational tasks and for all kinds of other things it’s really really good at – you’re always free to easily expand your architecture to work with additional, more specialized services that are not based on Node.
I agree. I have an app that has a lot of PDF processing and that part of the app is split off into it’s own service. You can call it with something like ddp_pdf.call('processFooPdfs', ....) and then when the PDF is done it can return the binary string or return an S3 URL, etc…
Meteor Hacks BulletProof Meteor series has a great tutorial on using a Meteor workers to process long running jobs. It’s a great example of a simple worker pattern.
Or you can add entry to collection and other meteor instance can pick it immediately ( cause oplog ) if you just want to offload it and scale as separate service in kubernetes or so.
While Meteor’s development experience is nice, I personally wouldn’t recommend using it for such a website due to two main reasons; performance & cost.
I’d personally recommend something like Laravel, you can easily use a CDN and still keep availability high while keeping the costs down. Running Mongo costs money. Running Meteor servers to handle scale cost money. Much cheaper to use alternative tool imo.
If you had to use Meteor for a basic content site, then you’d have to disable reactivity, get server-side rendering sorted (maybe use Prerender.io - more money) for optimal SEO and pop it all on to a CDN. Also remember that those without Javascript won’t be able to use your site at all.