Borland chased the enterprise market and look at what happened to them!
1 Like
I would be careful calling Apollo well-established. It’s a 3 year old project. Agreed, it seems to be faring better because of some uptake by big players (airbnb etc). But it’s still very unknown outside of the typical silicon valley company. And the typical silicon valley company is also known for continuously changing technology stacks to the hype of the day. So Apollo might be as fast out as it got in. Only time will tell if Apollo is here to stay.
I think the major reason Apollo is getting more traction is that you can gradually introduce it into an existing project, while they can keep their view layer, database, server platform largely untouched. Whereas Meteor is basically an all-or-nothing solution. That makes Meteor only a good choice for rewrites-from-scratch and new projects. But those are much more rare and it’ll be much harder to convince people to switch their entire stack (A lot of people don’t even know Meteor is just a layer on top of Node and you can do all your regular node stuff).
7 Likes
Hm, it’s far more known and used already but by just some silicon valley startups. Many of my clients both here in France and elsewhere, startups, medium size companies and some big corporates already use it, and not only partially. It won’t take over REST in so few years, if ever, but it’s not jsut Apollo, it’s Relay, GQL and Facebook teams behind, it’s gained a huge momentum already and represent more than a smal technical improvment. To me, GQL is to back-end dev the same paradigm shift that component oriented programing has been to front end development.
4 Likes
would be perfect for tiny to integrate that into core! (seriously, mdg should have done that 2 years ago)
2 Likes
This is one of the things about modern tech entrepreneurship that I find a bit weird. So many companies settle on 1 product to sell. Imagine if IBM only had one product, or if Nintendo only sold one video game. I always found it weird that silicon valley companies rarely work on more than one product.
3 Likes
Agreed. I’m already receiving emails from clients and stakeholders who are getting worried by his article. I wrote an article in response.
17 Likes
Great article @awatson1978! I fully agree with your thoughts. Would just add something to your next steps: Adopt Vue.js as an alternative view layer to Blaze and at least with parity to React on integration with Meteor. I know most people are into React and Apollo, but I believe that Vue is a much better fit to Meteor principles and could become a very good alternative to Blaze.
5 Likes
As someone who only recently started visiting the forums, I’ve been wondering where are the women contributors.
A valuable article, worth understanding the minutia.
4 Likes
I do have to wonder… if my analysis is enough to cause “FUD” among your clients and stakeholders, what does that say about their trust (or lack thereof) in Meteor?
4 Likes
It could say more about psychology or mere politics rather than Meteor’s true technical merit. Following all this thread/news closely, it could arguably be that the weight of your opinion with Meteor has historically been heavy, so stakeholders technically-inclined enough to know Meteor will naturally greet any lack of perceived confidence on your part with increased skepticism or perhaps even lost trust in Meteor.
3 Likes
An incomparable analysis. I was using Meteor in 2015, even within driving distance to Silicon Valley/San Francisco, and the energy was palpable. Decisions were made. Projects were announced. It was an epic journey and faults were found. What you describe as “the Monolith Problem” was expressed to me by others and in response we saw that Apollo was “incrementally adoptable”. It’s important and helpful to recall the history.
3 Likes
Because of your past prominent work with Meteor, your opinion is viewed by many as carrying more weight than of a lesser-known person. Therefore, it is easier for your publicly posted opinions to reassure or frighten people regardless of any objective truths or falsehoods you have expressed about Meteor and its future.
9 Likes
Oh, trust has never been particularly robust. I simply locate the reason for that mistrust elsewhere than you do.
Any trust that we’ve developed has been due to the QA and continuous integration infrastructure. Being a monolithic framework has been mostly irrelevant, as long as it supports interoperability channels. It’s the same as dealing with the other monolithic frameworks in Python, .Net, and Java/Oracle, and just becomes a staffing issue.
That being said, I’m mostly all for NPM nowadays. Much better adoption from other Node/Javascript developers when they understand that Meteor-the-build-tool is different than Meteor-the-tech-stack. I really, really, really hope we can rebrand the build tool and disambiguate it from the tech stack that’s shipped by default.
7 Likes
Apollo is far from success. But MDG wants to give us that kind of impression because it’s their hope of financial future.
2 Likes
By this do you mean http and websockets?
oh, gosh, that’s funny. We were asking the exact same question when Congress started using that ‘interoperability protocol’ term in MACRA and 21st Century Cures in 2015.
HTTP and websockets stop at layer 4 in the Open Standards Interconnect 7 layer model, whereas the specifications that have been approved as meeting the definition of ‘Interoperability Protocol’ use all 7 layers. So http/s and websockets are part of it, but not all. Data packet shape is also defined, as well as application registration. There’s also a legacy interop protocol called HL7 v2 that uses push messaging over raw TCP with defined application endpoints.
But once those things are in place, they just park the monolithic app next to the other monolithic apps.
It’s like commercial trucks and having a loading dock and parking for semi’s. If you’ve got the infrastructure, and the vehicle behaves properly, having a monolithic something isn’t a problem. But don’t try to roll your mad-max customized art-car up to a loading dock if it’s not meeting ground clearance requirements, etc.
3 Likes
I speak policy 
Are there any packages, e.g. meteor or npm, or somewhere outside of Javascript, which provide complete compliance?
1 Like
Not even close. The standard is sprawling at this point, and basically amounts to a hospital system architecture. If you add up all ~190 packages we’ve published under the clinical-meteor track, we have about 40% of it?
We only used about 20% of the standard when submitting to Apple, but it’s operating on a Pareto rule, and it’s the 20% that accounts for 80% of the data traffic that’s being sent between hospitals right now. Patient admit/discharge/transfer, observations, medications, allergies, etc. Not the esoteric stuff in the long tail like medical imaging, genomics, nutrition tracking, mental health, etc.
That being said, HL7 publishes the raw standard in JSON and XML in the IETF JsonSchema standard (which Mongo has recently adopted also). Which is why I’m advocating that we help Collection2 refactor away from SimpleSchema to JsonSchema, and increase overall usage of JsonSchema throughout the framework.
https://www.hl7.org/fhir/downloads.html
There have also been some attempts to republish these definition files on NPM. This is the closest thing to a library providing ‘complete compliance’, but would need some heavy lifting from Tiny to support.
In an ‘embrace the ecosystem’ philosophy, I’ve been trying to incorporate any emerging FHIR libraries that are published. So all the following are fair game, but need auditing and reconciliation. It’s a grab-bag of different build pipelines and module formats still, which is where the Meteor build tool could help contain the madness.
2 Likes
Understatement of the year. It was just completely neglected
2 Likes
I will be carefully optimistic. On one hand I think it can’t get any worse with Meteor, so having Tiny on board sounds like we’re finally going up again.
Then on the other hand I don’t know what they are going to do with and I’m well aware of the art of Marketing (that’s why you have PR people that make even worse things sound like the new Hallelujah).
So now they have Galaxy, which finances itself and is a good platform that can be developed further to grow and become a cash cow.
Now what to do with Meteor? I’m not sure what Tiny’s intention is and only time will tell.
Our app is build on Meteor and yes, we’re one of those traditional ones with Blaze (no Vue/React), heavy MongoDb operations at the backend and ready to scale up (thanks to Lambda, AWS Fargate, Atlas and lot’s of time spend on thinking it through). But because MDG neglected Meteor so much, we had to go ahead and write our own extension of it to be able to use MongoDb 4.2 with the newest driver and more importantly for us, use Transactions.
That was painful and a lot of work for a small company. So my sentiment is that it would be great to have that for everyone (as Enterprise apps will have a lot of database interactions) but the benefit for us will be small. It’s rather another PITA to again rewrite much of our code
So in summary, we have one foot out of the door for a long time, not because of frameworks looked more promising or better but because Meteor went nowhere in the last years. Just some small cosmetic changes.
Just my two cents,
Andreas
Author of https://yourDNA.family
5 Likes