So I guess I can be more specific about why we feel Meteor isn’t a good fit for us:
- We don’t have a use case for reactivity, which I see as Meteor’s sweet spot
- We need SQL support (hence we use Apollo GraphQL rather than Meteor methods)
- Our enterprise data is spread across multiple sources and we can’t change this (again a reason to use GraphQL)
- We have to host some services on internal infrastructure
- We have to support hosting in China (www.shipafreight.com.cn), as it is a major market for us - right now we use AWS China CloudFront for edge networking, but then our Galaxy deployment is still outside China, which significantly impacts performance
- We use a monorepo with several non-Meteor packages, but we can’t find a way to make this work with
lernaoryarn workspaces. So we are usingyalcat the moment, but this has other compatibility issues and complicates our CI setup - Running the complete dev environment is now a strain on even the fastest of hardware, and Meteor is taking up the most resources and causing long rebuild times
Ultimately our project has gotten so big that we have a lot of particular needs requiring custom setup beyond what Meteor supports. We have the resources to configure WebPack and a CD pipeline and feel that the cost of having to do these ourselves is outweighed by alleviating other pain points.