slightly unrelated but … how tied is client side minimongo to HTML5 features? there seem to a number of platforms for doing native apps in JS nowadays (reactnative, nativescript, titanium etc) and it would be great to use meteor as just a data backend for them (to start with). However, having collections and mini mongo client side to manipulate/filter the data is very convenient.
Most of these platforms are not built on the browser tho, just on whatever JS runtime (javascript core / V8) so the whole html5 APIs aren’t available. I was wondering how difficult it would be to take minimongo to one of these pure JS platforms?
The step after that is of course providing DDP but not everything needs to be reactive…
Let me know if you are interested and have time to work together on integrating these to remove the dependency of Restivus on I:R. It should be minimal work, I just need two things:
What is the return value that Iron Router expects in server side routes? I can’t find it in the documentation, and would like to replicate it in my package.
Would you accept a PR replacing I:R with my package in Restivus?
Hello everyone! I’ve spent my week experimenting and trying to push forward the state of REST APIs in Meteor, and I’ve come up with a preview release of a package:
Let me know what you think! It’s a preview, I’m open to changing anything that doesn’t seem right.
It’s not meant to solve every aspect of REST APIs for Meteor, just make a simple default that works for a wide variety of cases. I’ve also been working with @kahmali to improve Restivus, and will continue in the future.
great discussion. I have just been working with restivus and I really like it. I put together a very simple demo to help anyone get started with it (It’s based on the quickstart from restivus, but doesn’t use authentication and is a bit simpler)
as for one comment about why you might use REST as part of a meteor app, here’s a use-case: Say you are writing a meteor app and it needs to process incoming email messages… and you are using mailgun.com which provides hooks where they will POST to your REST endpoint the contents (json formatted) of any incoming mail message to their servers. In this case, without REST support in meteor, one would have to have a separate server running PHP/Apache or something like that which would accept the post from mailgun and insert it into some mongo database that your meteor app was also connected to. Possible, but much more bother than just enabling a REST endpoint in the main meteor app.
Don’t mean to bring up a dead post but I felt it was important to leave an update here since this page is one of the top hits when doing a google search of meteor + rest.
There’s a meteor supported alternative to these dead packages. It’s in the meteor-base package and is called webapp
Indeed, I ran into a few issues with the lib and decided instead of reinventing the wheel, I’d just use Express.js + Meteor + Accounts. It’s worked out well so far, and I recommend this approach over any other for Web API solutions.
The work I did with JsonRoute helped me understand middleware and absolutely helped me build the custom Accounts token system into my Express.js + Meteor solution, so in the end it wasn’t time wasted.
Ha! I’ve been looking through all these threads and options about creating a web API… I’m thinking I should just go Express, and seems like this gives me the final push. Are there any exceptional Express + Meteor resources that you used to get into it?
This got me started: http://www.mhurwi.com/meteor-with-express/, and with the Express API docs (which are very good), should be all you need (depending on your Accounts requirements that is).
FWIW I’ve been using the simple suite of REST packages and it’s been really easy. I didn’t want the full exposure of everything (all collections, publications, methods) over REST that simple:rest gives you so I’m just using simple:json-routes , simple:rest-json-error-handler, and simple:rest-accounts-password
I think it depends by a “complete” api. Now didn’t dig into the docs or the source code… but first IMPRESSIONS tell me that webapp is meant for simple apis. I don’t think it comes with all the fancy features that express includes.
That being said, if you are using meteor, you shouldn’t need to build a “complete” api. If you did, you should pick a different stack imo. Meteor is best for “isolated” apps that work within it’s own ecosystem because it is so opinionated. If you’re looking to build a more reactive api, id suggest looking into mdg’ s Apollo stack.
