we orchestrate meteor and other node apps using kubernetes, but that’s not really microservice approach, its just scaling it up to as many apps as you need (usually with a 3-app mongodb-replicaset). Its the same as deploying any other node app.
“Reactivity” with pub/sub works across multiple instances as well when you use either the default mongodb-oplog or with the help of https://github.com/cult-of-coders/redis-oplog. Default mongodb-oplog adds more load to the mongodb, therefore i would add redis-oplog (which needs an additional redis, but thats very easy to install on kubernetes, if you use helm or similar)
meteor is perfectly suitable to be deployed on kubernetes or similar. We also have it sometimes as pure api-app without any frontend, but then, it could also be just replaced with any other packager.
I also want a lot of the things mentioned here (COUGH-hmr-COUGH), but I believe the single most important thing is to hire the right people (to follow up on @sacha’s excellent recommendation to 2x Ben’s salary). Hire some/all of the most dedicated developers in the community and let them get together and figure out what is best.
My advice to Tiny, don’t even wait for their resume’s, hunt them down and give them all the money they want, and watch the community rally around them while they build the most amazing future for Meteor
I think we’d all love that but I’m guessing Ben, Jesse and Hugh will be protected by a Non-Solicitation Agreement (although I hope I’m wrong!) and Theodor has his own company to run. But it would still be great to see @mitar and @captainn on the core team. We could look forward to first class Svelte and Cypress integration amongst other things
It’s nice that graphql query language used by apollo-client has built-in schema/type checking, which is not database-specific, and can be colocated at the component level.
How are things today with fetching an initial set of data, and then also subscribing to changes to the same data, which are merged into the cache? Meteor.subscribe gives you live updates for free (quite magically). On the other hand, with apollo-client you would start off with a query, and then how do you get “reactivity” (updates to the query, which trigger a component update) with subscriptions, which are in their own domain. (Or is it just as easy/difficult as managing the cache with mutations?)
We recently, with a heavy heart, moved off Galaxy in favor of AWS Elastic beanstalk. The performance improvements and price reduction were just too good to pass up. Galaxy has the huge selling point of having fast and reliable deploys which are also super easy to manage, but the rest of the offering has remained stagnant for years. I really want to move back, but the ecu limitations of the current containers are just unacceptable for us, when we have a heavy application with a lot of reactive content.
I would really like to see meteor get similar tools like ionic has with ionic studio and ionic flow, so more GUI tools for managing and building your apps.
Lots of features request, which is good, we all wish to have products where the users are engaged in it.
Perhaps a good start is to update the site with a page where the community can vote on what they deem most important? similar to what webpack has on their site.
This could be another source of revenue from Meteor, those who donate to the framework get influence points and their opinion weight heavier in the overall decision making process.
I’d also decouple the monitoring and hosting in Galaxy, so those who host elsewhere can still use Galaxy’s monitoring agent and portal which would increase Galaxy’s revenue and allow for cross sell later. I think Tiny first goal is make the framework financially self sustaining and allow the community to contribute both financially and technically so it can stand on its own feet long-term without VCs injection.
So many folks are using Meteor in major projects and it’s an organizational flaw that the framework is not getting the care/support it deserves. Again I think the most important thing is to inject stability and confidence in the community and improve the communication, this has been the biggest pain point for the last 3 years, everything else will follow, also investing in the marketing to reduce the broader misconceptions around the framework. No need to deprecate one thing on the expense of the other, there has been enough leadership churn by MDG already.
Regarding reactivity: often it is just not needed. You have to ask: can this data be modified by another user and do i always need the newest data?
Often you will have the situation, where the current user of the application is the only one modifying a set of data, so live updates are not needed in this case. Sometimes live updates can also be annoying. Imaging facebook always pushing new post on the top while you are reading!
There are ways to help be in sync with the backend:
after mutation it makes sense to refetch queries that could be affected by this mutation. depending on the mutation result, you even don’t need to do anything
you can simply poll the data (suprisingly often good enough).
you can use graphql subscriptions (never done that) that give you real server push updates like meteor pub/sub
While I agree with a lot of what you have posted so far, I think you are too quick to dismiss the importance of real-time and reactivity. Granted, an application like Facebook or a website hardly needs any of that, beside pushing some notifications.
But if you switch to the realm of real-time sensors analytics and monitoring, fleet management, collaborative work of any kind (doc editing, mapping, engineering, and so much more), all of a sudden you’re talking about a different league. Pub/sub is a must in these cases and polling will never be good enough.
And that’s where everything is going. There’s even a big drive for machine learning from streams, then pushing results in real time to front-end users. The Meteor of 2012 has foreseen this shift. The problem started when everyone started building websites with it. Ever tried building a highly interactive, real-time app without using reactivity? If so, you must know what a nightmare it is to tie everything together in an imperative sort of way.
We’ve been using Meteor since version 0.49, and grew with it. Developed tens of minor projects with it, and a major one which is our main business today (illustreets.com). What I hope from Tiny is that they recognise the special and unique offering of Meteor, which small to medium business can’t afford to overlook:
Short time to market.
Minimal development costs (and with an improved Galaxy offering, minimal DevOps overhead).
The only serious player in an uderserved market segment: real-time applications. Think drones, think geospatial, think sensors, think logistics. In the last three years, one more billion people just got connected to electricity. And they have lease to own equipment. Which transmits events in real time and are aggregated in real time - visualised by a relatively low number of users.
Seriously, the amount of time I read people complaining about SSR… who needs that in admin dashboards with charts and maps? And there’s a growing market for that - the world just doesn’t belong to Twitter and Facebook clones.
Repackage / rebrand by industry, using the same underlying tech stack, but in different configuration. The brilliant success story of @awatson1978 just a few posts above is good evidence that this could succeed. There is also the financial industry.
Please keep the backwards compatibility, even if it requires effort. A paid support model can be used to mitigate that.
I think this is the main issue with Meteor: people are so used to great core features, that if something is not in core, it is generally hard to find it unless developer put some extra effort in PR. But for almost anything I have ever imagined or there was already a package fixing it (or even multiple of those), or it was possible to do it yourself. There are really very little fundamental issues with Meteor. It is just for three years or so it was not developed anymore feature-wise, so some common features which are in packages never made it into core, or at least guide.
Galaxy has the huge selling point of having fast and reliable deploys which are also super easy to manage, but the rest of the offering has remained stagnant for years.
We host at Scalingo (and Atlas). Scalingo has native support for Meteor, reasonable pricing, and exceptional technical support. for now the only disadvantage for international customers would be that their data centers are located only in Paris (though recently they have managed to open second data center in Paris, presuming tech wise they might be ready to go international).
And Atlas. Oh, this is what I would expect from Galaxy to be to Meteor, as Atlas is to Mongo.
What makes meteor have a special place in my heart?
When I started vetting meteor, I realized it was the Apple of frameworks and it was not just marginally better than everything else, it was a revolution. I chose meteor for my business after a weeks of research wherein I deep dived into many competing web app frameworks, so when I say I was impressed, this was in the context of some serious research.
Meteor was very opinionated compared to other systems. Since the guys behind it were smarter than me, their opinions were right and that is much better that making hundreds of micro decisions and second guesses throughout the whole development process. Other frameworks focus too much on edge cases.
Meteor always has us asking “what’s the meteor way to do this?” If you fight that, meteor is not a good fit for you. You should not be using meteor if you are fighting meteor. Meteor works well for some things, like scheduling platforms, and those companies are really into it. If you embrace the meteor way, things start working beautifully. Code comes out nice and bug free
Like Apple, the guys at meteor had anticipated what the product will be used for, carved out a niche, and built features that supported that use case. That use case is squarely app development for apps with user accounts that interact. Pretty big market if you think about it. Other frameworks don’t attempt to anticipate what they’re used for and they suck to configure.
What did we need that meteor had solutions for?
A good out of the box experience
Database as a straight pipe to the UI, very strong coupling!
Reactivity by default and not something that needs configuring
Query language we can use on the client
Subscriptions
A flawless accounts system
What did we not use and didn’t ever even care about?
Allow/Deny
Blaze
SQL support
SSR
What did I need that meteor provided no solution for?
Simple setup for react
A router
A way to deploy to DigitalOcean
React native in the same codebase
To those in charge of the future…BE the innovation of the entire industry! We want more stuff that supports meteor’s established purpose. Don’t try to be everything to everyone, be something to someone.
