Interesting blog post, even if I think the title is a bit link baity
Here are our thoughts on your 10 points. We started with Meteor 1.1 with Blaze, but have moved to Meteor 1.4 with React and a complete ES2015 “imports design” that allows us to build multiple Meteor apps from the same code base.
1 - Replace Meteor Packages with NPM Modules
Agreed: besides core Meteor and MDG packages we only use the following 3rd party Atmosphere packages and they can all be replaced by us in the future quite easily except for simple-schema. Good news is there is a new NPM version of simple-schema we will move to in the near future.
2 - Get off Iron Router
Agreed: we moved to React Router from Iron Router.
3 - Remove Blaze ASAP
Agreed: we did major rewrite of our entire UI from Blaze/Meteoric to React/Material-UI. Very happy with the results.
4 - Replace Minimongo/Tracker/ReactiveVar/Session
Disagree a bit with this one.
Minimongo/Tracker works great for us as we only use pub/sub and reactive state where it is really needed. We use ReactiveVar in just a a couple of places to hold some global state that needs to be reactive, such as if a user is offline. We don’t use Session.
If you are going in all in for GraphQL/Apollo then I’d agree to that using Apollo client to manage state would be a good idea, but we are happy with our current data system and don’t see a compelling reason to make the move at this time.
5 - Microservice Feature Development
Agreed: we already run 2 “microservice” Meteor apps, one is a data sync server and the other is a chatbot. Modern web/node apps should be designed this way anyway.
6 - Get on Apollo
Maybe, but not necessary today.
Our data system built using simple-schema, pub/sub and Meteor validated methods works great for us because we don’t overuse or abuse it. Having accounts/users built-in and using the same data system is great. Now with @diaconutheodor’s new RedisOplog and Grapher packages we feel confident staying with this solution in the near future as we scale.
GraphQL/Apollo does not provide enough benefit in the medium term for us to completely rewrite the core of our application.
7 - Replace Kadira with another performance Monitoring Tool
Agreed: we deploy on Meteor Galaxy so have some simple monitoring included. We instrument our app with both analytics events and Winston NPM for logging. We have used New Relic in the past and may fire it up in the future. Your suggestions for error tracking packages is good.
8 - Mount an Express Server on your App
Don’t need. We don’t need server side routes except for our REST API and we use simple-rest package for that.
9 - Create a different Entry Point
Agreed: incremental loading/code splitting is the one big missing feature for us. This webpack based solution looks interesting, but we also need to get all of Meteor moved to NPM. Finally, I thought I saw a new proof of concept someone had done using Meteor’s build tools, but I can’t find the link now. Anyone?
10 - Peak your head in other communities
Agreed: as an engineer you should be monitoring what is happening in the greater JS world, just don’t get bit by JS fatigue
I’ll add one more point:
11 - We still like Meteor’s build system slightly more than webpack, especially with the latest performance gains.