And then use your created express server in connect:
const app = express()
//....
WebApp.rawConnectHandlers.use(app)
Ah, @tomsp was faster 
4 Likes
It’s astonishing how very few people know this. We needed to authenticate Meteor users to our map rendering backend, which can only do HTTP. So we built an authentication proxy in Express, then simply plugged it into WebApp.rawConnectHandlers.
Receiving uploaded files to pass them through to a different backend? WebApp.rawConnectHandlers again to the rescue.
A real life saver, I tell you.
5 Likes
the reason why meteor is so nice is because it makes the part of application building that is just the boilerplate … fast. And that gives you time to spend on making the application better. Better looking, faster, more features … whatever. So Meteor is a great tool to learn cause it makes you more efficient at the parts of the job that arent that exciting after a few years of being a developer … but that need to get done for every project. So the poll results aren’t too bad in my opinion. cause theyre is still a small minority who like using Meteor and are committed to using it
5 Likes
Well, maybe one reason is the docs don’t mention the possibility of passing an Express instance instead of path…
Wow, sounds really cool 
Not sure I follow, why did you need an Express proxy (as opposed to doing a HTTP call straight from Meteor)?
1 Like
Perhaps they thought it’s obvious (and to me it sort of is), as that guide page has a link to connect. It’s also in the name, rawConnectHandlers . But admittedly, one needs to have heard of connect for this to be self-evident. In the developer’s own words, “connect is an extensible HTTP server framework for node using “plugins” known as middleware.” With that at your fingertips you can easily plug any node middleware into Meteor.
Knowing this, imagine how funny it sounds when one says that they would rather use Express than Meteor. Anyhow, that’s a different discussion.
The HTTP calls for map tiles are made straight from the browser, and there can be many of them per second - it’s just how map tiles work in general (they talk about Google there, but the principle is the same). In illustreets, logged in users get to see whatever geospatial data the publishers share with them, according to certain user access rules.
So to authenticate those tile requests, you have to pass them through a proxy and either use a memory cache, or temporary tokens on the Meteor side to “probe” each request as it passes through, on its way to whatever backend the request is going to. If the check fails, you just drop the request. Quite powerful.
When something like Leaflet.js or Mapbox GL JS makes successive requests to a server route in your app, you can’t just 1) hold that request, 2) make a HTTP requests from Meteor and then 3) somehow “relay” the responses back to the client for the map to get populated with images. The delay would be huge. The latency added by our proxy to each request, as described above, is measured in nanoseconds.
2 Likes
You can also use simple:rest to convert all your meteor methods to REST end points.
1 Like
This would be a great example to add to that page of docs! Any takers?
1 Like
I would really like to do contribute this myself, but I have a couple of crazy weeks ahead. If it can wait, I will come back and do it. I think it’s one those uber powerful features of Meteor that really needs be more evident in the docs.
3 Likes
what would this involve? an example of how to use Meteor to build an application using the Connect/Express libraries that come in the webapp package? Cause i was going to try and build something using that package and see what i can come up with (at some point haha).
1 Like
That sounds right. I was also thinking of an example of connecting Express to Meteor, while also plugging in other middleware built for Express, such as https://github.com/http-party/node-http-proxy or https://github.com/chimurai/http-proxy-middleware. If you want to do it yourself, until I have time to make a contribution myself, and if you hit any snags, feel free to PM me.
1 Like
ok i am curious about this, and how it works. i’ll see how far i can get tho and just see what happens
My first project back in 2016 used the full Meteor+Blaze+pub/sub+mongodb framework and it worked really well. My new projects now are completely React-based frontends using simple JSON apis to communicate with a postgresql backend. IOW, I don’t use any server stuff or reactivity at all. I use Meteor as basically a build tool for my React frontend.
But what a build tool! I think a great article would be comparing using Meteor vs Create-React-App to create a 100% React frontend, without using any meteor-specific technology. Out of the box, you get a great server to serve the code, compiling multiple versions for recent vs ancient browsers, and easy code splitting and all sorts of other goodies with very little mess.
When I first wanted to build my React frontend I never intended to use Meteor, since I needed none of its functionality. I looked into C-R-A but it seemed like such a hodgepodge mess of pulling in a bunch of independent packages to do something Meteor does much more elegantly, so I decided to try to start the project on Meteor, and it’s worked out really well. Using bundle-visualizer, I can see that my bundle sizes are extremely small and contain very little Meteor code.
I could easily port my React code to a C-R-A project if needed, and vice versa. It’s just super easy and takes care of so much under-the-hood plumbing that C-R-A forces you to deal with manually. I think a lot of pure React developers could be convinced to use Meteor as a build tool if there was an easy article comparing the process to C-R-A, including how to load and use certain libraries. For example, I use the loadable components library for async-code splitting and it works fine with Meteor.
And of course, once you use it as a build tool, it becomes much easier to convince them of Meteor’s other advantages The vast majority of React developers would be happy with a simple, out-of-the-box solution for developing and serving React+SSR+async loading. Meteor does this much, much better than C-R-A. And once they’re on Meteor, showing them stuff like the useraccounts package or the Apollo integration would be icing on the cake.
8 Likes
You sound like just the right person to write the article
3 Likes
I’ve thought about it The only problem is I’ve never actually used C-R-A for a project so I’m not sure I could do a great comparison between the two…
C-R-A is sold pretty hard on the pod casts. It seems like a good way to either lock you in to that platform, or lock you out of others. I’m not enamored with it. I do wish Meteor would compete more aggressively on all these fronts - pod casts, and the like.
2 Likes
For the record, since this point, coming up on ~5 years ago, @jkuester ( and @alimgafar and @storyteller ) seem to be answering the call to competitive content. Seems like it has about a year or more to really gain momentum as they stick with it, and as the underlying ecosystem and surrounding culture evolve in parallel.
Including link for posterity since this salient point from @captainn advanced:
Seems to stand on its own, and has a great future if contributions are made on that front as well as in code.
… it is difficult to make some concepts engaging since the space is weary or unoriginal by default. But Meteor is so far-reaching too, which requires even more range, not just energy or interest. It requires depth.
I find a spark in that feed which reminds me of the roots of Open Source. It feels of finding an old bonfire, still burning, rained on, having been through storms. If we all bring a burning log to add it will rage anew.
I appreciate the depth of thought and courage to deal with so much of what others consider a necessary evil, but which a few still know is the single most beloved essential. Meteor fits very near to the soul of */OSS.
2 Likes