Continuing discussion: I wish Meteor had a middleware-only version

Continuing the discussion from Blaze <==> React Refactor Paths?:

What do you mean by this? Which parts of Meteor could be implemented as middleware?

Perhaps middleware isn’t the right word, my boss and I are only using Meteor for the DDP and Mongo integration, basically everything except Blaze. I wish I could use something else to generate my HTML file/package my frontend code, and require the meteor client-side data tools within that, instead of having Meteor wrapping everything. I’ve heard the same sentiments from others.

1 Like

Haven’t used it myself, but have a look at


Oooh, very cool. I will look into that. Thanks for the link!

That project discusses various reasons in more detail than I have for using Meteor only for data management.

You can actually paste in just the packages you need in the packages file. This can be a bit cumbersome but can leave out the unwanted parts (it’s surprisingly modular, DDP is the only thing that doesn’t swap well). I think MDG is working on a static page package that leaves out Blaze that will ship with 1.2 Create a version of Meteor platform without Blaze by stubailo · Pull Request #18 · meteor/react-packages · GitHub

I’ve done something similar for a backend only meteor app and it worked out well. (Fibers is hard to give up once you’re used to it :laughing:)


Cool, that sounds good. I’ll probably see if I can combine that with Asteroid soon.

@SkinnyGeek1010 @Sanjo I decided not to go with Asteroid, as its collection APIs don’t exactly match Meteor. But I’ve gotten most issues ironed out with my Webpack/React integration.


Nice! Do you have any public packages for the Webpack integration? I don’t know enough about it yet but it sounds really nice!

No, I figured out a different way to do it: have webpack-dev-server serve its bundle(s) up on a different port, and then put <script src="http://localhost:9000/assets/bundle.js"> etc. for them in the root HTML file. I don’t think the source maps that webpack outputs are consumable by Meteor, because the source URLs all use this webpack:// protocol. I don’t actually know too much about what it’s doing there. Doing it this way also allowed me to use the react-hot-loader to reload individual react components when I save changes (I’m not sure if/how hot reloading React components with the official Meteor/React packages works?)

Very cool! Once you have it ironed out it would be great to look at minimal working example/boilerplate repo!

Meteor currently does a full reload like live-reload so you lose all the state. They have a new reloader coming in 1.2 that’s supposed to speed it up so that may change.

Cool, I’ll see if I can port the sample-todos example sometime this week!

Okay, I set up an example repo!

1 Like

Hey this is pretty slick! Can’t wait to try it out more this weekend.