Keep on bringing movie ljke quotes in here. 
We’re drifting off. Its not a discussion of what Meteor exactly is. Its about why and why not its interesting fpr entrepreneurs 
3 Likes
That’s Meteor lol.
I’d like to see the recommendation in the official docs where it says not to use publications. That really would have been a change of tone for Meteor.
And the Metoer simplicity the OP, I’d love to know if that included publications. I would put money it did because that’s how you can work 3x quicker than Apollo. Otherwise I really don’t see the gain in development time they’re talking about.
I think we can to improve the guide to add performance section, this has been suggested before here, clearly some folks are abusing pub/sub. But If you can’t scale above 50 users then surely you’re doing something wrong, but that’s what you heard not what you tried…You’re thinking black and white, it’s either no Meteor or all pub/sub. For the fourth time, I’ll stay it again, I’m using pub/sub only when needed, some sections in the app don’t need to be real-time then why do I need to force it to be real-time? that’s what the methods are for and it put less strain on the CPU/Memory. But yeah like others said, with all pub/sub, you’re burning your Bugatti tires and running out of bullets in your first 15 minutes 
Anyway, I’ve made my points and we’re getting repetitive and off-topic here…
1 Like
I have been working for almoat two years with a group of entrepreneurs and all our projects are using Meteor from the start, we love it because we can just test and validate our ideas.
And I personally also use Meteor for my projects and startups, speed of dev was the main reason I switched to Meteor and I still have that. Even when using it in a more scallable way is faster in my experience.
In my latest project I use grapher with almost everything using methods instead of subs. I recognize that its takes a little longer but is not that much, and the performance gains seams to be exceptional.
Offcourse there are things that Meteor could improve, but thats true for everything and everyone in my opinion.
And probably you are right, the Meteor guide doesnt mention much about scaling and perf best practices. But thats our job as a community to also share the knowledge we have acquired. I do it myself in spanish, I think Meteor have a great opportunity in the Latin America market that currently is having a startup bloom.
Im actually starting this year to host again after sometime the Meteor meetup in Bogotá, and also looking forward to translate the docs and guide to spanish.
8 Likes
I think the following hits the nail quite on the head
And encapsulates a lot of the technical merit that Meteor provides in a non-technical way, but in a way that makes arugably the most sense from what counts the most (for entrepreneurs), the business value.
Since we have already established that Meteor can be used and tweaked in ways that mitigate (mythbust) many flexibility and scalability concerns, the extra edge it does provide in terms of time to market is very valuable.
Add to that the fact that an entrepreneur might not always be a multifaceted technical expert, the ease of meteor’s built in isomorphic data and reactive ui apis add even more value to people who want to validate and even simply start a business idea without having to onboard or partner with experienced developers.
1 Like
Don’t get me wrong. It became a yes/no game. I didnt ask to close the thread
Oh no, I think we should thank you for keeping us focused and eyes on the target. The topic of the post is very valuable and such topics can easily be derailed in and around fud.
2 Likes
Thanks for everyone’s comments on this topic.
However I’m concerned about Meteor’s limitations of scaling above 50 concurrent users. This must surely be deal-breaker for any Entrepreneur as it clearly prevents adding “Business Value” beyond creating a prototype.
I’m also unclear as to the analogy with a Bugatti. Can someone please explain exactly why this is and which features of Meteor is causing it to “dissolve and burn tires in 15 minutes” and what is best practice to avoid such a situation ?
1 Like
I found the comparison of Meteor with the bugatti a bit weird. Main point is that Meteor has many tools and can be used for many different purposes. Some parts though have a full-stack and tightly coupled implementation and should or should not be used depending on use-case.
Like all tools, you should choose the right one for the job. If you expect a massive amount of users and the data is just static, then Minimongo with DDP might not be the best choice compared to using Meteor methods or an implementation with Apollo or maybe even a static Rest implementation. That’s besides the discussion if it would scale. I’m sure it does. Especially in combination with redis-oplog. Some are not, though I’m confinced that some other issue made them not able to scale beyond 50 users… (really?)
However I’m concerned about Meteor’s limitations of scaling above 50 concurrent users. This must surely be deal-breaker for any Entrepreneur as it clearly prevents adding “Business Value” beyond creating a prototype.
This is the part that I don’t get. It actually makes me sad each time people make these weird statements and I totally understand that these people make you doubt. These statements usually come from people that have no idea about how to use, maintain and scale a Node based app. This again, is not a Meteor problem, but of the ones developing the app, drift off from the path and then expect the same magic of the paved road to still apply. You can go off-road, but expect to face obstacles.
Its the Javascript world. Meteor is Javascript. Its pluggable, its scaleable - like any other Node app. The ones running into scaling issues with Meteor usually run into exactly these issues when they need to scale with other apps, only later, because they are spending all of their time building the initial stuff that Meteor already did.
Use Meteor. If you run into trouble, ask the question here. You might have noticed that we are very active knowledgeable and involved.
11 Likes
Here is my experience so for. When you scale, every part of your stack will be pushed to the edge, and for the Meteor app server (like any other web server) you need to pay close attention to the average memory and CPU usage. Again I speak from my own testing, the most expensive from what I’ve seen in Meteor is the number of unique publications you’ve per user and the size of those publications on a given page.
It has been shown many times in the community the you can scale Meteor app horizontally, here is a video of the folks from classcraft claiming they can go up to 30k of concurrent session with their stack and LumindPDF supporting 5k concurrent session on Galaxy. In my load tests I was also able to grow horizontally indefinitely. So the question is not whether it’ll scale or not, but how much it’ll cost to scale per user session when you’ve a lot of specialized pub/sub serving many users and also whether you’re prepared to scale.
For me the biggest selling point when it comes to Meteor is the convention over configuration, the package system and the many specialized packages packages, RPC methods, community, flexibility and maturity. But historically (I’d stay after Benjamin joined and the pivot to multiple view layers) Meteor was a highly coupled framework with a focus on real-time pub/sub and I think that’s why we’ve two type of usage in the community. Those who see Meteor as a full-stack real-time pub/sub and those who see it as a flexible tools with convention over configuration.
Going forward, I think Meteor needs to build on its strengths, specifically the convention over configuration, developers experience and flexibility, and double down on entrepreneurs and SMB. These values are missing in the node ecosystem, it’ll give Meteor a long-term competitive advantage. The focus on pub/sub is actually the root of Meteor issues in my opinion, if developers start using RPC methods and only add pub/sub when needed and then optimize those when scaling then there won’t be an issue. But if they start doing pub/sub for everything, create many user specific publications without any consideration to performance then host it on 1 GB instance and invite everyone to join then surely it’ll crash. With that said, I think there is a room to improve the Meteor’s pub/sub. Specially, we need have a section on the guide for performance because right now the information is all over the place and technically I think Meteor’s pub/sub engine needs to be decoupled from the application server. The pub/sub engine (mergebox and diffing algorithms) should be made scalable on a separate cluster from the application server with their own UI dashboard, DDP interface and alerts.
Meanwhile, here is what I think would be a good recommendation (and please community keep me honest here):
- If you don’t need real-time then just use Meteor methods or Apollo. This will make Meteor as scalable as any other socket based node app
- Do use out of the box pub/sub to validate ideas quickly but don’t expect to scale without any tweaks
- If you’ve a lot of per user pub/sub observers and you don’t want to worry about the technicalities of scaling, then I’d recommend Galaxy
- Use as many re-usable publications as you can, the cost of scaling those are minimal compared to user specific publications (from my test, on average user specific publications are around 6 times more expensive in memory then generic re-usable publications)
- If you’ve many user specific publications then I’d either switch to redis or really bump up the memory per VM
- If you expect a lot of traffic spike then you need to overprovision the VMs or cluster meteor instances on the CPUs. Remember node is single threaded so by default it doesn’t leverage the multiple CPUs, so you either fork multiple meteor processes or scale the app horizontally with many small nodes and put load balancer in front of it, this is true for all node applications
- If you really want to have full control over you reactivity try the awesome redis-oplog package by cult-of-coders.
I hope that helps, and again I really believe Meteor is the tool for entrepreneurs in the NodeJS ecosystem. By the time you start worrying about serving thousands of concurrent users, you’d have already validated your idea (which is critical for entrepreneurship) and you can start optimizing the weak points of your app for performance, this is much better approach for entrepreneurs then creating their own stack, building their pub/sub engine, glueing hundreds of NPM packages, configuring web-pack just to find out their ideas were invalid.
11 Likes
Thank you for your thoughts. You have in mind what I’ve been thinking. I’ve watched the Laravel community just grow and grow and I think the same thing can come from meteor. Being that its all Javascript makes learning for entrepreneurial minded folks much easier. I have just been wondering why are people spending so much time trying to build things with Express when you can find much easier ways to get products to market. Ideas crash and burn fast so being able to just build fast to me is a huge advantage of meteor.
The other thing I see is that there are a lot of myths about meteor out here and a lot of you are doing a great job of linking other threads and working people out of those problems. If I do start having the scaling issues I know I can come right back to this thread and get the links. Once I get up to speed I will try to write some articles on medium about my experience as an entrepreneur vs a guy looking for a job and some short cuts you can take when you actually want to code yourself. Meteor is at the top of the list of a short cut.
6 Likes
@alawi Thanks for the helpful scaling tips! I hadn’t seen all of those. Maybe you can write a first PR for a new Guide section. 
Do you have recommendations for how to fork multiple Meteor processes to exploit multicore computers? I’ve looked for nice packages to make this easy, but didn’t find one. (Maybe we should write one…) Also, I’ve tried to figure out whether MongoDB naturally exploits multicore or whether it also needs to be forked. I assume it’s multithreaded, so on a single computer I actually need to trade-off between cores for MongoDB and cores for Meteor. I assume there’s a communication penalty for running Mongo and Meteor on separate computers, but at a certain level of scaling, this is worthwhile.
2 Likes
Thanks @edemaine I’m glad those help, yeah I’m thinking of helping to expand the guide.
For the multi-core, right now I just deploy on many single core machines, this turned out to be more cost-effective than spinning higher end servers with multi-cores, although the tradeoff is in the dev ops and managing those extra servers.
However I did research some libraries that can be used to fork multiple node/meteor processes, namely PM2, passenger and meteor cluster. But as I said, right now I’m just spinning more single core VMs.
I personally think you’re better off just separating the mongoDB and application server early on given that you’ll most likely need to scale horizontally quickly. And yes you want to keep an eye on the latency by keeping your MonoDB cluster as close as possible to the application servers cluster and also minimize the number of trips to the database and the size of the data being fetched.
I hope that helps.
I’ve created a really slick SSR/offline first pipeline with fast-render - I really gotta publish how I did that. I basically abstracted out an alternative to pub/sub (using meteor methods, but the concepts should work as nicely with apollo) where you pass a “connector” creation HOC a collection and two functions - one method call, and an isomorphic “tracked” function, and it returns another HOC to wire up the data. It’s so easy to set up offline first, server side rendered (and auto-captured data server side and auto-hydrated data client side) with this approach. Product ships soon - after that I’ll try to post a description and see what you all think!
I mention this is because I’m excited about Meteor - this platform rocks, and if there isn’t more buzz about it, I think maybe we just need to generate some!
I also have thoughts on Atmosphere (I think it’s better than npm in many ways, even if some of the legacy stuff is a bit too, err, legacy).
7 Likes
Ah so full disclosure: I didn’t bring up the name of my startup because I don’t want to be salesy on these forums, but Pitchly (my startup) is basically Airtable for serious people. I feel I can talk about this now that they’ve been brought up - this is the product we’ve been developing for 3 years all on Meteor. We came up with the idea independently of Airtable, but we ended up evolving into very similar solutions. Even down to “blocks”, we released Pitchly “apps” right around the same time. But unlike Airtable, you can build your own apps in Pitchly today (something Airtable isn’t yet offering), and we are releasing the ability to integrate your existing databases into Pitchly at the turn of the new year (like SQL Server, MySQL, Mongo, etc.) followed by services like Salesforce.
Us and Airtable could have been cut from a similar fabric - we are also very well designed and have high standards when it comes to usability and ease of use. And after this release, you will be able to have a database-like interface for Mongo. Where Airtable and we differ, however, is we don’t want to replicate the spreadsheet. We’ve made a super human friendly interface for your data, but this is a product for managing your business data, not to carry over bad spreadsheet habits. Another key difference is we are specifically for business and the enterprise. Some of our clients have moved to Pitchly from Airtable because Airtable is great for personal use, but it’s not as friendly for business - we don’t have a 50,000 record limit like Airtable - and our apps are better suited for business. International companies, like BDO Global, use our product every day.
And not to mention all of this was made in Meteor. I will say we are in the middle of a website redesign right now…so don’t let the website scare you. We aren’t just for law firms and M&A firms. We serve all kinds of businesses. But I’m happy to be able to share this. My business partner and I also started this business in between me having surgeries to remove my large intestines… so if Meteor needs a glowing review on how easily and quickly you can build with it, I’d say our company is the one. We also employ one of the frequenters on this forum (so we are hiring, btw).
Anyway, enough sales talk.
14 Likes
Regarding pub/sub vs. methods to fetch data: I really like Grapher made by @diaconutheodor (founder of cult-of-coders), as it allows you to define the publication (called exposing a query in the world of Grapher) once, and you can use it reactively using pub/sub or non-reactively like using a method. (See https://cult-of-coders.github.io/grapher/#client-side)
There’s also a GraphQL bridge created by @diaconutheodor (I didn’t use it yet), or you can expose all your publications using the package simple:rest (made by @sashko) as REST API for traditional clients – out of the box, no configuration needed.
3 Likes
I am not a huge fan of blaze but meteor with react is a very good stack in my opinion.Currently we are developing an e commerce website with react+meteor.Also bulding mobile apps with react native and again meteor backend.Actually one of the only things i dont like with meteor is reload time is very long…
2 Likes
I agree on the reload time. It’s fast for CSS and JS inside the client folder, but once react components are coming from /imports it gets very slow, and it always seems to rebuild the server, even if the files you edit are not linked in the server app. I wonder if there is a way to improve that.
It’d be great to have some control over this. A mode where you had to manually trigger server rebuilds for example, or a hot reloader for react modules would be nice, again, with a manual full rebuild, maybe in a dashboard like interface, instead of the simple terminal output we get now. A dashboard interface with info about what the build server is doing would be great too!
behavioral economics probably could explain it
You can ‘work around’ this by adding your app into a client folder. I don’t mean outside of the imports, just in your client main it should do something similar to this:
import './client/app.js';
You can also work without the imports folder now. Just add the client and server entry point to your package.json.
1 Like