It would be a much better if such a working group is more guided and organized by MDG. Active organization of your community is IMO a crucial part in open source leadership and it brings good PR (public relation, pull request, pizza rounds etc.) without a lot of expensive investment into a ad campaigns.
Great idea, can you call them and let us know 
@thea no longer responds and @sashko is gone. Who do we reach out to?
If there is interest, we can start a new thread ā¦ if not, then itās a sad state of things
1 Like
It would be great if someone from MDG could take a couple of minutes from their schedule and write a few lines here about the general plan they have with Meteor right now and where does it fit alongside Apollo. Meteorās roadmap in github discusess technical matters, but on top of that, a broader view from MDG themselves would be much appreciated. Even if there is no apparent plan, the transparency by itself itself alone would go a long ways.
13 Likes
I canāt speak on-behalf of MDG management about the future of Meteor, but I can say that:
- MDG is still very much up to date with whatās going on in the Meteor community. While not as active as weād like to be on the forums, we still check in daily and are on top of the latest discussions.
- Meteor is still being developed, supported and maintained. Critical bugs/issues are being addressed, and PRās are routinely reviewed and merged. New features are added and implemented in each release, and new releases are coming.
- Meteor is an open source project. If youāre interested in helping out in any capacity, just dive into the repo or ping us!
Regarding where Meteor fits alongside Apollo, letās go back in time a bit ā¦
As many of you remember, one of (if not) the biggest complaint about Meteor way back when, was its lack of support for data stores other than Mongo. This problem was constantly referred to as one of Meteorās biggest shortcomings, and was continuously pointed to as being one of the main reasons why organizations couldnāt adopt Meteor. For those interested in this backstory (and other fun parts of Meteorās history), take a few minutes to run through the old Meteor roadmap.
MDG knew this was a problem, and started to invest time into figuring how to best untangle Meteorās dependency on Mongo. Initiatives like https://github.com/meteor/postgres-packages came out of this work, and while promising, it became pretty clear that the amount of work needed to build one-off integration packages like postgres-packages, for many different data stores, was not something MDG could invest time into doing. There had to be a better way to open Meteor up to be usable with any kind of data source, while at the same time retaining a lot of Meteorās awesome real-time goodness.
While MDG was working on this problem, GraphQL was announced and open sourced. The core ideas behind GraphQL werenāt new, and at the time MDG was exploring various data layer options, including solutions based on graph theory. But along comes Facebook with not only a fully tested and battle-hardened data graph specification (that can work for just about any type of data layer imaginable), but theyāve also open sourced a javascript based reference implementation, and are actively looking for people in the OSS community to help drive it and the spec forward.
Weāve all heard of the benefits GraphQL brings to the table, and MDG was quick to realize those benefits could greatly improve their current data layer issues. They jumped on-board with Facebook almost immediately, and the idea of Apollo was born.
Itās important to remember that one of the other biggest complaints about Meteor at the time, was that it was a monolith. People couldnāt incrementally adopt just the parts they wanted to use, without having to bring in pretty much everything. Needless to say, this was a showstopper to wider spread Meteor adoption, especially for larger organizations with significant technical investments and infrastructure already in place. One of the founding principles of the Apollo data layer (which again was conceived to help address Meteorās data layer issues), was that it would absolutely be incrementally adoptable. With this principle in mind, MDG started working on its new Apollo data layer, engaging anyone it could find to help out, in the open source community.
While MDG was working on Apollo, they realized that most of the people who were working with Apollo and adopting it in their OSS projects, and at their companies, werenāt using Meteor. These people wanted to leverage the advantages of GraphQL, and needed an incrementally adoptable way to get started with it, which Apollo offered through various tools and utilities. MDG was one of the first companies to jump on the GraphQL bandwagon, and with its extensive background in dealing with data layer issues through Meteor, was able to build the right tools at the right time to really kick start an amazing amount of traction in the quickly growing GraphQL space. That traction has snowballed to the point where MDG (Apollo) is now one of the primary leaders in the GraphQL space.
So what does this trip down memory lane have to do with how Meteor fits in alongside Apollo? Everything 
. While Meteor and Apollo were both created by MDG, and Apollo actually grew out of Meteor, itās important to note that one doesnāt supersede the other. Does your company have a massive existing technical infrastructure, and want to make it easier to pull data from hundreds of data sources using a common schema, gateway and query language? Apollo and GraphQL are definitely worth checking out. Does your company want an all in one solution for developing/maintaining a custom real-time logistics app for your entire organization? Meteor is good to go.
Meteor is still hands down the best all in one solution for building modern real-time apps quickly and effectively. I (and other MDG team members) use it every single day, for both personal and commercial projects, and would be very, very, very sad if it didnāt exist. Thanks to MDGās founding members, and their understanding of the importance of open source, weāve all been able to work with this amazing platform, many of us for years, for free. And thanks to the nature of open source, as long as the Meteor community doesnāt want that to change, it wonāt.
29 Likes
@hwillson Iām so glad with your response. Iāve seen those topics and I agree that Meteor is pretty much tied to Mongo atm. Thatās not a bad thing though and at the time most of us agreed with that aswell. I love how well it integrates and it actually made me like Mongo aswell. I do understand that in larger organisations people require this spider like structure where many apiās are combined into one facade. However I still feel that this could have been done with Meteor.
It felt to me that Meteor was moving towards the broader community by allowing NPM packages. Why did that stop?
I totally understand that Apollo has become very popular and that MDG is putting a lot of effort in making it even better. It feels to me however that the whole discussion we have is not about Meteorās features, but more about vision. It stopped. There is no sign of where MDG wants to be in for example a year from now, what it wants with Meteor and how it stands next to Apollo.
The most frustrating part is that while Iāve noticed that even though the Repo is still maintained, there is no communication on the forum, no updates being made to the documentations and even the website links on meteor.com lead to Apollo.
We as a community need a bit of guidance. Because if I know that the plan is to untangle Meteor into plugins allowing for incremental adoption, I would be happy to roll up my sleeves and help out as much as I can.
Hereās what I ask. I donāt expect MDG to radically change back to focus on Meteor again (would be awesome though haha). I do expect community involvement. Regular blog posts, occasioneel Twitter updates, Github activity and most of all, replies to emails. I have sent an email regarding this topjc, but did not receive any response yet. Painfull.
With all of this said, I want to repeat that Iām very very happy that someone is replying and that you took some time to clarify things. Iām not unhappy. I love Meteor and I love what MDG brings to the community with both Meteor and Apollo.
11 Likes
My two cents:
First of all letās keep in mind that MDG needs to make profit, itās a company that is betting on Apollo and GraphQL to achieve this.
It didnāt really work out to make enough money out of Meteor. Galaxy is just a middle man and itās too easy to cut that one out and run your infrastructure yourself, at a much lower cost (my company has done this with a significant decrease in cost).
So it still needs to figure out how to make money to pay the bills and deliver value to their shareholders (founders and VCās).
If we keep this in mind then a lot of this makes sense all of a sudden from their POV. We might not like it, but MDGās focus arenāt the developers and small companies like ours with less than 5 developers. They aim for bigger companies and hope to solve their pain points.
Like others mentioned I do believe that it once went in the right direction, opening up to NPM packages and giving power to the developers and the community. That seems to have come to a slow down or even an almost stop, hence the radio silence as noted on marketing activities but also forum activity.
At the same time it shouldnāt wonder anyone that as a consequences the feedback delivered by the 2018 polls are devastating. To me the most important feedback is that Meteor is going down the drain. Both in importance as well as in progress.
Lastly, weāre still using Meteor and Blaze at my company. We have no reason to switch to anything else now, our code base is too big and there is way more work than developers.
I just hope that things turn around for the positive again as I have the āangstā of Meteor dying with MDG.
1 Like
I think thatās overly negative. While surely Meteor is not receiving the same funding/attention but I think itās being held at higher standards then all the rest of JS framework, Iāve been watching the repos for other open source frameworks and theyāre as active (if not less) then what is Meteor today.
What the VC funding unfortunately did (as it does to a lot startups) it created a community that is dependent on the core specialized salaried developers. I keep hearing of businesses that running viable business on Meteor yet they (a) run from Galaxy to save cost (b) contribute no PRs or close issues on Github. If companies managed to achieve success via Meteor, then what I donāt understand, why they donāt reciprocate and invest in advancing the framework? Like any other open source frameworks, the longevity of it is largely driven by the community support, contribution, value proposition, attitude.
I mean how MDG (now Apollo) are going to die when theyāre leading the most advanced GraphQL framework? thatās not rational fear, they did the right thing as a business to pivot to GraphQL.
Also, I donāt understand why a survey is providing consultation advice by stating to avoid, it should just stick to providing stats and let people use their judgment. All it did is reinforce the majority stereotype, the 50% who judged the framework without even trying it.
2 Likes
Weird that JS developers prefer micro frameworks. A full framework like Meteor (or Rails or Phoenix) takes bit longer te learn, but is so much more productive. Perhaps itās micro services vs. the majestic monolith way of thinking?
And Next.js is just an opinionated way to sever-side render React pages. Donāt get me wrong, itās really great at that but itās no full framework.
4 Likes
For what its worth, I love Meteor 99% of the time, but that 1% I really hate and causes huge stress in production environments. Its the weird, unexpected errors that either crash, or cause a server to be unstable. For example the well known fiber spike, or worse the āMeteor and Mongo disagreeā¦ā which can cause really weird behaviour.
Fixing, or even debugging these can be a harrowing experience. I suspect that smaller frameworks that do less are more appealing because there is less āmagicā in the background that makes debugging hard, and the fact that everything in meteor happens in a signle process is another reason weāre looking at moving toward microservices.
2 Likes
I agree Iāve been load testing the app for several weeks now. Generally speaking, I found that itās hard to do performance testing for socket based applications, most of the testing frameworks are geared towered http requests.
But my biggest surprise came from MongoDB and not Meteor. I was using Postgres/Mysql in the past and I never had major performance issues, but I found that until 2 years back MongoDB has a global lock on the entire DB when doing a write! so that was a huge bottleneck and Iām not sure how a global lock was even acceptable. The other thing is that given node default single thread nature, it doesnāt utilize the CPU horizontal scaling, so weāll have to scale VMs horizontally very early using many single CPU instances.
There are 3 major differences between Meteor and your typical NodeJS app:
- Socket based by default
- Fibers
- Pub/Sub using Oplog
I think (1) and (3) can be managed but (3) is hard to debug since itās really deep in the framework. But the majority of performance issues I ran into so far has more to do with Node ecosystem than the Meteor, but yeah I agree having additional layer of complexity doesnāt really help.
Sorry I think this is really off-topic now!
You forgot to add the book title, I believe itās āSapiensā, by Yuval Noah Harari right? Love this book.
1 Like
I kind of have a love hate relationship with Mongo. the truth is though, itās super easy to get up an running with, and Iāve not had the need yet to adopt Apollo at all. Mongo and Mini Mongo (even without pub/sub, which I donāt use) provide a lot of value, and Mongo has been adding the missing components over time. They now have full text searches (indexes), and aggregation, and all that relational data stuff Iāve been desiring from more traditional SQL sources. I just wish mini-mongo could keep up (client side text indexes would be lovely!).
One of these days Iāll write up my method for Mongo over methods with offline first storage on the client side (itās partly described in another thread on these forums) - all with SSR/fast-rendre. Itās pretty neat - and itās well encapsulated so that it would be relatively easy to move to Apollo should the need arise.
On Meteor more generally, I love it - zero-config build environment, local dev server, easy deployment - dozens of other things I always forget about. I get a lot of value for almost no effort. Itās just weird to see a diminishing interest in it in that survey. I get that every product gets to a point of becoming a diminishing asset, but Meteor doesnāt seem like it should be there yet.
2 Likes
Its not about frameworks, languages or any other tool. They come and go. Iāve worked at quite some startups now and the trend is so clear. As soon as investments come in, dependencies and distractions strike. What begins as a passion and a mission ends up being a struggle to make profit, just because theyāve chosen the quick path by depending on just one or a few investors.
Now people have to jump trough hoops just to stay afloat. They see a trend and jump on it like flies and hope that it will be the holy grail. Lack of focus is what kills business more then anything else. There is a huge potential in both Meteor as Apollo, but so is React, so is Vue and so is blockchainā¦
This is exactly why I love Vue. The team consists out of people that have a great passion towards software and they are eager to help and educate. The Vue core team relies on donations, workshop profits and talks at conferences, but its they themselves deciding what the next most valuable thing is, not the companies. They have complete control over their own process and because of that I see them as the ultimate agile software team. Thank you for that @evanyou.
I just hope that somehow some day Meteor will be ran by us, the community, just like Vue and with a very closely involved core team of people like for example @benjamn and @hwillson . If this happens, I will be happy to donate, provide ways to make them earn a monthly salary by giving talks, workshops and whatever I can do to helpā¦
5 Likes
You take out two small paragraphs which is out of context given the rest of my otherwise positive post.
Fact is that the state of JS 2018 feedback sees Meteor numbers drop a lot and itās already not one of the compared frameworks (mentioned under other or what the author calls it). Also the main concern with Meteor was exactly what I stated with my exaggerating āgoing down the drainā. The same concern is echoed here.
Secondly, MDG can be a leader in whatever topic and it still doesnāt mean itās picked up commercially and turned into profits.
In corporate business I havenāt heard anyone speak about GraphQL as a solution they might look at for their data lakes or Big Data project. So much about that.
Fact is also that development on Meteor has mostly come to a stop.
My apologies that was not my intention. Anyway, will see what 2019 brings, I think the framework will move forward, people has been calling Meteor dead since 2015, yet weāre here, but surely the hype is dead thatās my take from the JS survey.
Agreed, I think itās the best way to run open source.
2 Likes
Agreed. I will continu here, because its still the best out there.
2 Likes
Im also going to keep working with Meteor, and now more than ever I think is the time for us the users of Meteor to take a step forward. I will be happy to be part of a group of devs that maintains and brings back this beast.
Im not the best dev but I think I can help in some way.
Maybe we can start by creating a group and talking about how to move forward.
2 Likes
When it comes to the business side of MDG/Apollo, thereās a lot I canāt talk about (mostly because I write code instead of sales agreements), but I can say this: MDG has successfully turned its investment in the GraphQL developer tools space into profit. This is how the company is able to continuously re-invest in open source software (both Meteor and Apollo).
Side note: Iāve worked with companies in the past who all knew doing some open source stuff was probably a good idea, and even went as far as putting aside some time for staff to work on OSS projects. When push came to shove (or budgets were getting tight), the OSS stuff was always deprioritized and/or ignored. The OSS culture at MDG is completely different; OSS is the lifeblood of the company, coming from the top down. It isnāt treated as an afterthought or seen as a nice to have; it is the company.
Iām a bit surprised that you havenāt heard anyone in the corporate world talk about using GraphQL to manage big data. We definitely have, and theyāre customers. MDGās current paying Apollo customers cover the entire corporate spectrum, ranging from startups to Fortune 500 companies, many of which are using GraphQL for the specific purpose of managing/analyzing/controlling their immense data sets. Actually, in one of our own products, we use GraphQL to interact with a data set thatās currently growing at a rate of 1 TB/d (and that daily rate is continuously increasing).
9 Likes
GraphQL growth is a fact. Here is the chart from 2019 npm survey, Apollo adoption is sky rocketing and itās going to be a real challenge to Rest which is huge.
I think Meteor should embrace Apollo/GraphQL as a first class citizen, if that is missed because people are holding tight to DDP/Blaze, itāll be the same miss to incorporate Vue when Evan (Vue creator) proposed to integrate Vue to Meteor himself. Itās really ironic that Meteor is not benefiting from Apollo growth, a library that was designed to solve Meteor data-layer problems in the first place!
Why canāt we just type meteor create and get a fully functional GraphQL backend powered by Apollo? why we still donāt have official account/graphql packages, payment graphql packages etcā¦
3 Likes
I see an idea for a new PR haha. Would be so nice to type:
meteor create app
It would then ask you some questions
- what data layer do you want to use?
- Apollo
- DDP + Minimongo
- None
- What is your preferred frontend tool?
- Vue
- Blaze
- React
- Angular
- None
If we could start separating these things and make them pluggable first, tgen this stuff would be possible
8 Likes