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.
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.
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.
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.
Reading all these posts I wonder if Tiny imagined the amount of frustrations, missed opportunities, disappointed hopes caused by the decision of the founders to focus on Apollo to the detriment of Meteor.
my reaction to @sacha’s article was more focused on the first two of his next steps, talk to the community and get a couple big wins to start things off of the right foot (getting a new feature like HMR added to Meteor and hiring Ben would be the big wins). Those two steps would show everyone that Tiny is going to have an impact on things and encourages community involvement. And that will buy them time to then take the transition more slowly and form a plan.
I think they are off to a good start though and hope for more exciting news in the future.
Sharing thoughts as a Meteor user & developer. For me, at a very basic level, the most important elements of the Meteor stack are:
unified framework for both front and back-end, with a single programming language, and a common codebase for both the web app and the iOS / Android apps through cordova.
ability to pick whatever front-end technology is best suited for my project (Blaze, React, Angular, Vue, … you name it).
Reactivity. It may be a small thing, but the way Meteor is natively inducing data reactivity by observing collections is amazing. It kind of forces you to think about your entire app in a reactive way.
Minimongo. Life would not be the same without it. The benefits of data manipulation on the client side using the same exact methods as on the server side are huge. Using the mongodb grammar and syntax is really powerful.
What I would love to have at this stage is an easier way to handle data persistence and offline operations for the mobile apps. This is something we have still not entirely solved in our project.
yes and I replied him back in that post, because I strongly disagree:
Sorry but I think that would be a major mistake. Meteor beauty is derived from its original vision of simplicity. It’s different—and valuable—because of Monimongo. Blaze is just a template engine, but it is simple and perfect for many use cases in mid-range application development. React is fine too, but a lot more complex. It would be ok let the user choose the template/framework for the View, but Minimongo—nad reactivity made easy—is what makes Meteor different. Getting “rid of the old Meteor” is equivalent to kill the project to make “just another Javascript framework”—that we don’t need sincerely. In a Javascript world where new frameworks get released every other day, I think we need something that keeps users focused on the business side instead of configuring and re-configuring their development environment. Not everyone is making big products that need to scale a lot. Most of the programmers create projects for customers or tiny niche products. I think that Meteor should fill the gap in the mid-range applications market to make things even easier and hide the complexity of the Javascript world—which is pretty messed up in my opinion. The enterprise needs this because there are plenty of options to build complex and core business systems. There are just a bunch of options to deploy a project in weeks and none of them is as good as Meteor in the Javascript space.
I strongly agree with this. The fact that there is no Meteor experience equivalent within the webpack/graphql/react ecosystem almost 4 years later is not due the lack of trying by the JS community but due to the inherent complexity of those standards/APIs and tools, a complexity required by large enterprises (thousands of components, multiple endpoints, multiple teams etc.) but unnecessary in many other contexts.
Flexibility in view layer is great but the Meteor experience need to be preserved and even enhanced. Tiny to Meteor can be the Steve Jobs return to Apple, double down on what works, fix what does not but preserve the identity/experience of what we all loved about Meteor when we first joined.
I agree with you regarding Apollo vs. MiniMongo/DDP. But I am not sure if I still agree regarding Blaze vs. React.
One thing is clear: Blaze was what got me into Meteor, since I loved its simplicity, and it was very easy to get into it if you came from a pure frontend web developer background, like me.
However, if I would encounter Meteor today, I would wonder if I should really use a technology that nobody else is using. I guess I would rather go for React, because it’s way more wide-spread in the overall JS community. Or maybe even Vue, because it’s more similar to HTML and Blaze. Plus, there’s so many more ready-to-use React components out there, which is also a big plus.
I built my fair share of apps in Node, some as services to support our main Meteor app, and, damn, I couldn’t find anything to even come close to the simplicity of DDP and Meteor methods.
While in the front-end, Minimongo and Tracker are just a joy to work with. Blaze was and is perfect for any medium size project, though I understand why one would want something that is guaranteed to be maintained.
The preference for a view layer tend to be very subjective and dominated by hype, yesterday it was handlebards (and blaze), today it’s vue and react, tomorrow it svelte and web components. By keeping the core/backend flexible (yes at the expense of some end-to-end full-stack magic) you shield the framework and whatever is built on it from that churn and ensure the longevity of the platform. Furthermore, companies do re-write their view layers to update the user experience every now and then and pick the view technology of that time (hence the churn) but their DBs and backend are way more stable since those are battle tested.
But of course Tiny could always decide to maintain it again. Also, I think given similarities between Vue and Blaze, it would be relatively possible to build compatibility later on top of Vue exposing Blaze. Moreover, I have already done work which allows combining Blaze and Vue together, with great simplicity (using Vue inside Blaze and Blaze inside Vue), with reactivity working across them.
So, putting more people on this and all this could be pretty neat.
I very much agree that Meteor should stay view layer agnostic and just be open to integrations with whatever view layer necessary. There are hordes of developers pouring massive efforts into React/Vue/Svelte/whatnot and no reason for Tiny to duplicate any of that in any capacity (i.e. repeat the mistakes made with Blaze).
A good example here is the semi-official Vue integration created by the Vue core dev @akryum. The only two components of such integration that are actually needed in most apps is the vue-meteor-tracker (links Vue to Meteor’s reactivity) and vue-component (links Vue to Meteor’s build system). The first one is around 400 lines of code and the second around 1500 lines of code. If Meteor is able to maintain a codebase where a nicely working integration can be achieved with only 2k LOC, then I don’t see any good reason why not to keep Meteor separate from view layers and allow such integrations to do the work.
Oh, I’m familiar with your work. I hope there’s going to be some investment put into it. Personally, I have nothing against Blaze. On the contrary, I found it very productive. We have 1000+ templates in our application, many of them as reusable components - using best practices as per Meteor Docs, the app is fast and nimble as a wasp.
To me, the tribalism and “politicking” surrounding the multitude of JavaScript frontend frameworks makes no sense, but, well, such is life.
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.
. I hope there’s going to be some investment put into it. Personally, I have nothing against Blaze. On the contrary, I found it very productive. We have 1000+ templates in our application, many of them as reusable components - using best practices as per Meteor Docs, the app is fast and nimble as a wasp.