Does It Make Sense to Start a Meteor 2.0 to Retain "Classic Meteor"?

I tried Meteor when it first came out in 2012. I liked what I saw then, but worked for a RoR shop at the time and could not easily jump ship.

I’m back again now and can control my own destiny. My current project has a number of moving parts. IoT devices that collect data, a central user web app that manages accounts and associated uploaded IoT data, a mobile app that acts as a remote control for the IoT device, a mobile app that duplicates what the web app does, and then finally Virtual and Augmented reality clients that can grab data from an API provided via the main web app. Only the software that runs on the IoT device has been written and to some extent finalised, everything else I have kind of works but needs to be re-written from scratch.

I was going to use Django or Flask + frontend for the web app portion of my project. But I’m building the whole platform in a modular/microservices kind of way and so I’m actually not tied to Python for the other parts of the project.

So my immediate need is to build the multiuser web app that manages data and images that get pulled from the IoT devices.

This IoT hardware device is one that I have designed and built myself. It has a Flask (python) app running on it with a simple API for getting data out of the device and into ‘the cloud’. This will not change much. Also, I currently control operation of the device with a simple CLI based client that interacts with the device’s API too. This CLI client can be pip installed on any computer with internet access. Later this CLI will need to be replaced with a more user-friendly ‘remote-control’ mobile app and possibly a voice client (e.g. Alexa) using something like flask-ask. Sorry for all the detail, but I’m trying to get across the level of complexity and the differing non-web client apps I will need across my platform.

So the web app part of my platform will need to suck up the user data that gets generated on the devices themselves, by pulling data from the Flask api. The users will then have lots of other stuff they can do to manipulate and publish that data from within the web app. As data comes in from the device I’d like users to be able to see it appear in the web app in real-time. Hence why I’m looking at ‘reactive’ frameworks.

So I decided to research some of the ‘new-hotness’ frameworks like React and React Native. Whilst researching, I thought I had better check back in on Meteor again and see if it would be a good fit for some parts of my infrastructure. From what I’d seen in 2012 it seemed like a good fit for the web app portion at least. I also remember reading something about mobile app support a year or so ago.

So, on the face of it, I still like what I see with Meteor. It appeals most. But this thread has me a little worried and wondering where things are heading. Meteor 1.0, Meteor N + React, Vue.js + Asteroid, Apollo vs DDP?!?!! I’m scratching my head a little, but think I’ve caught up to the state of play.

Also, I am concerned by a lot of the negative sounding, perhaps warranted, posts I’m reading here. And this kind of rings true for me too:

That said, given my disparate needs, it sounds like Apollo could actually be a really good thing for me given that only part of my requirement is for a web app. What do you guys think? Is MDG and its suite of evolving products the right place for me to be looking?

Also, out of interest. Could I use Apollo with some parts of this project to get data out of my web app and into the UE VR games engine - GitHub - getnamo/socketio-client-ue4: socket.io client plugin for Unreal Engine 4…?

Thaks for any insight you guys can provide. Also, it would be great to hear something more substantial from MDG ‘The Company’ regarding ongoing support for Meteor. I really want to believe :slight_smile:

Jesus those threads get verbose quite quickly. :slight_smile:

Isn’t the essence of wanting a Meteor 2.0 that people want a more opinionated approach back?

This could

  • speed up learning
  • increase productivity
  • improve package development (Think about rewriting @aldeeds Autoform package today: Blaze, React, Angular? DDP, Apollo?).
  • probably bring the community closer together ?
1 Like