I have very good reasons to rewrite & redesign the architecture. Our Meteor stack is on 1.6 and cannot be upgraded, because it completely breaks (probably due to reliance on Atmosphere packages no longer being maintained). It’s frail, Galaxy is costing an insane $170/mo to host, etc. Mongo 3.x end-of-life is next April (on Mongo Atlas) so Meteor 1.6 won’t work anymore. The stack is definitely far from lean and performant, unlike the Vue + serverless stack.
Yes, there are trade-offs of course: more complexity to design and build up front, but IMO the long-term benefits outweigh this. And lock-in is not a big deal to me. I think that’s true with most solutions. Meteor itself is a highly-opinionated lock-in in and of itself, after all.
it’s super simple, has great type safety, highly customizable and can be deployed either in a node-container (e.g. kubernetes or just a vm) or as static/lambda mix (thanks to nextjs)
I stichted together a demo project, but its not yet polished https://github.com/panter/manul-stack.
it has i18n, an admin backend, a page editor, username/pw login (with admin roles)
The idea is to have something bottom up, where every part is replaceable, but still fast and easy to develop on.
Meteor is not a wrong choice, but I would advice to not use blaze and/or pub sub outside of prototypes as these technologies lock you in and are not really maintained and improved anymore.
Sidenote on mongodb: we switched to postgres just because prisma (2) does not support mongodb yet. (and also because we can use google cloud’s native postgres db). Even with meteor and mongodb, I modeled most data in a relational way anyway. But i still find mongodb really handy and easy to use. And Studio 3T is such a great tool to work on mongoDB.
Rails probably. Rails + erb is basically Meteor + Blaze, in the golden age, which was results oriented. You could spin products in matter of days and implement week long features using gems/packages.
Hello @ffxsam, one of our first Meteor apps was written in Meteor 1.0 in early 2015 and has been updated with each new release of Meteor. On a few occasions, we had to fix breaking changes by forking or replacing atmosphere/NPM packages. These were most often due to major updates to Node.js.
It really would be useful for you to share the details of what has prevented you from updating your app from 1.6 to the latest version. This would include:
The list of atmosphere & NPM packages used in your Meteor webapp
The console messages produced when running meteor update in your webapp project folder
Any startup error messages produced when running your updated Meteor webapp.
It is possible that some or all of your issues may have been encountered in the past by other developers in the community who can recommend atmosphere/NPM packages to replace any broken ones.
@vlasky I think one of the packages in question might be edgee:slingshot which is very old. Given enough time, I could probably (with some help) build a list of what needs to be replaced/updated, it’s just that I don’t have the resources right now to focus on that.
Once v2 of our product is launched, I may circle back to our v1 Meteor app and see if I can salvage it and assess how much time/money it’ll take to bring it up to date.
Everytime someone complains about breaking upgrades, I can read notes like this.
Unfortunately, I have been facing similar problems as @ffxsam with my older Meteor apps. Most of the times, the update either fails a) due to unmaintained Atmosphere packages and/or b) because Meteor did some changes in its build system which caused other packages to fail. The most prominent for this is fourseven:scss. With nearly every update between 1.0 and 1.6-ish, I had to adjust the way I was setting up my SCSS styles. Which was not the maintainer’s fault, but changes under the hood (in the build system) that caused these problems. Fortunately, this has gotten way better in more recent Meteor versions, because there weren’t so many changes here.
The biggest nightmare, however, is upgrading Cordova-based Meteor apps to keep up the pace with rapid changes in the mobile ecosystems made by the Cordova team, Google, or Apple. I had countless situations where either icons did not work anymore, or the whole hot code push stopped working. I finally gave up on developing Cordova apps with Meteor. Since then, I am much happier with Meteor and updates are way easier.
But still, Meteor is a great framework, and I still love it. I just hope that Tiny will be able to get it back to its old glory.
Funny. This is actually the package I never had any problems with. It just worked, up to the latest Meteor version. I’m only using it for S3, though. Don’t know how the situation is for other backends.
I have read your post on the update issues the last few years. It seems that you run into above average amount of issues. I even think we discussed this quite a few years ago also at the forum.
What is hard about the update issues is that they are different to debug compared to code fixes. And it’s impossible to create a simplified reproduction. So that would mean you would need to share your full codebase which is not feasible generally.
That is one problem where it’s hard to help and share as a community because we can only advise generic solutions or experiences.
The biggest nightmare, however, is upgrading Cordova-based Meteor apps to keep up the pace with rapid changes in the mobile ecosystems made by the Cordova team, Google, or Apple.
Definitely agree, that is horrible. We encounter it as well in native projects so it’s not Cordova or Meteor specific.
While working on other projects (Non Meteor) I was surprised about the amount of upgrade issues in for example React, Apollo and other tools which you need to compose together in a project. Compared to Meteor that takes a 10x amount of time to stay up to date in our experience because the integration is open source and quite up-to-date actually. Even when we use React in Meteor it goes more smooth because of the integrations.
Which in the end allows to focus on business development instead of a more technology focus.
Hey @ffxsam
Sorry to resurrect your post so long after
Like with any stack it’s healthy to keep thinking about options. Every time I brainstorm what is needed to replace Meteor, I realize the task is daunting especially that Meteor works really well and is super stable. So am curious how your stack is holding up so far?
My personal comments on your stack:
Lock-in … but you addressed this already and you are ok with it. For us, we need to host in multiple location across the globe. But that lock-in comes with lack of flexibility (what if you need a new feature, e.g. oAuth with Microsoft’s new PKCE-based flow) and substantial risk / dependency!
Maintenance: You have many points of failures. Are you implementing any kind of system to track what is failing? Amazon updates its stuff often and suddenly, so you may face urgent needs to upgrade (which means more testing …)
Are you real-time? One of Meteor’s core strength is the live update features, I can’t see how you can get that with serverless, unless you poll often
Costs … is it really that much cheaper? I think it’s worth challenging. Other than Mongo replica set (which is 3x m5 reserved instances – similar cost to Aurora) we use our own AWS Elastic-beanstalk (granted, not easy to startup, requires dev-ops but so does your stack) which is super cost-effective if you use spot instances. What you pay Galaxy is essentially what you will pay engineers to maintain your stack so you’ll pay it regardless.
What I like about Meteor is that we put as much as we can in a single instance so have little need for external services (didn’t mention redis with elasticache but not that expensive and can take a whole lot of load with a t3 instance)
In terms of external packages, other than key external ones (like aldeed:collection2 and our own fork of redis-oplog) we only use Node packages. So upgrading is a breeze. I really don’t see the need for all these Atmosphere packages any more. The Node ecosystem has matured. You are paying the price of skipping upgrades and having to do it all at once.
Hey @ramez! A bit short on time so I’ll keep my answers brief but hopefully helpful.
Lock-in: Everyone’s situation is different. I’m not sure what “host multiple locations across the globe” means, but of course everything on AWS can be globalized via CloudFront. I personally am not concerned with needing particular new features, but if I do need something super specific, I imagine I can just spin up an EC2 or Lambda function and write a custom interface. AWS has me covered for most things I can imagine needing.
Maintenance: Detailed and organized error logging, via Sentry! Also, thanks to AWS X-Ray, I get X-Ray trace IDs for every process and those are also logged to Sentry, so I can jump into the ServiceLens console and see what went wrong, measure latency, and track issues down to a specific SDK call.
Real-time: There’s a network/performance cost that comes with this when your entire application is real-time for every single data collection. I think it’s unnecessary. I have some pages where users will rely on real-time updates, and for those, I can use either MQTT or AWS’s API Gateway which has WebSocket support (will probably go with the latter, as it’s cheaper). For now, polling works well enough and is a simple solution.
Costs: I pay Galaxy about $230/mo right now for our v1 app. Absolutely, that cost will drop to mere dollars for v2 hosting because Lambda & API Gateway are so cheap, and Lambda has a very generous free tier. Not to mention I have $25,000 in AWS credits to give me a nice head start. Database: at a minimum, Aurora Serverless will cost $80/mo, and could go up higher as it scales based on demand… so, estimating maybe $200/mo at the higher end, maybe? I don’t have real data on that yet.
I also want to address the point, “What you pay Galaxy is essentially what you will pay engineers to maintain your stack so you’ll pay it regardless”. I’m not sure you’re comparing apples to apples, here. All Galaxy does is allow me to deploy and host my application. I still have to design/architect my app, code it, debug it, maintain it, etc. The same is true with our AWS (Lambda, Aurora, API Gateway, Cognito, etc). Those are managed services in the same way Galaxy is. It’s still up to me to build and maintain the codebase, but I don’t have to worry about DevOps-related tasks, scaling containers, fine-tuning config files, hardening servers, etc.
Just my two cents for what it’s worth. Everyone’s needs are different, and there are probably other applications I’d build where AWS may not be a good fit. But for what I’m building now, it’s a great fit.
From a purely scientific point of view (i.e. taking away my affinity for Meteor), my bet is that the total (really total) cost per user would be the same or higher the more complex the infrastructure. AWS is here to make money, they won’t price Lambda lower than a t3/c5 instance for the same usage. It’s all awash.
If you have a large volume of users, your cost per user should be similar in terms of disk / cpu / memory if the two approaches are optimized. I don’t see a technological breakthrough in splitting up in various services. Just more moving parts to manage.
I don’t mean to be rude, looking at it objectively. Your use case is interesting as it validates or refutes that basic engineering principle If you are substantially cheaper, then it’s worth considering for us too. Please please do share your results when you have them. Even big picture if the numbers are confidential.
PS:
My point about Galaxy is that you don’t have to worry about VHA (very high availability), which saves you DevOps. We do it ourselves on ElasticBeanstalk so took on that cost and risk.
Real-time now is cost effective with redis-oplog (including our own optimized fork for scalability)
@ramez Sure thing, I’ll try to remember to come back here once we’ve fully launched and are migrating users from v1 to v2.
BTW, the big cost difference between Galaxy (or any 24/7 servers) vs the serverless stack is that with the latter, we only pay for actual use rather than a flat rate for 720’ish hours of server time per month. I think this will result in quite a substantial cost reduction. And actually, with Galaxy, I have had to worry about availability. Sometimes containers will just die, resulting in users getting a temporary 503 error before it kicks them over to another container (if they reload). Galaxy is very costly to scale. With AWS serverless, it’s effortless and requires no intervention on my part.
But you may be right about costs being the same:
v1
v2
Database
$60/mo
$80-200?/mo
Back-end
$230/mo
Estimating $10-20/mo initially
Of course, the costs of v2 will be more fluid and will scale proportionally as we get more users. With Galaxy, it’s fixed for a longer period of time… e.g. we’ve been paying about $170/mo for a long time, and just recently had to bump up to $230/mo to accommodate more usage.
To compare apples to apples, v1 should be (if single server) $14
(c5.large spot is $0.019 per hour x 730 hours = $14 per month – reserved instance is $39 per month)
Galaxy is managed hosting, while you are transitioning to self-managed hosting
Sigh, this thread is dragging too long, since 2015 Meteor has been bombarded by negative articles that highlight MeteorJS the weakness (sometimes they are true concerns and many times not true or exaggerated), and mention little about the its strength while bragging about the alternatives. That is why people outside the forums have no clue what work is being done and the amazing improvements being made, I have yet to see one of the many over-hyped JS frameworks get 10% of that scrutiny, it’s all rainbow, sunshine, and VC money out there, but then again they have not lived long enough to be scrutinized.
The meteor community is one of the nicest public discourse spaces I have seen, sometimes way too nice for its own sake. I think we have enough threads/articles highlighting the platform weakness, we need to also highlight the strength، especially now since the platform is gaining solid momentum, and those who jumped the ship last few years will have some regrets and they should, wasting engineering cycles rewriting stuff for little innovation and client value many times due to FUD or hype is not so wise.
The question could have been why should you stop using other frameworks and move to Meteor, because frankly there are plenty of reasons to do so, and we need to offer people a balanced perspective not just the negatives, so they can make up their mind.
I’m only using it for S3, though. Don’t know how the situation is for other backends.