I don’t see it in the road map, is it normal ? I know there is already packages like Restivus that work well.
But it would be great to make it a core functionnality since it’s something every web framework/platform should have.
It will be easier to create Rest APIs with Meteor than with the other frameworks and will attract a LOT of people since a LOT of these people are not using Meteor just because of that.
I’d love to see where you came up with this data.
Meteor uses DDP. Meteor using Rest concepts would be taking a step back.
From my experience with the Restivus package, so if it’s official then it will be better maybe.
HTTP is a web standard, having a way to use it doesn’t mean taking a step back… DDP is great, it doesn’t mean it will replace HTTP and rule the world…
2.1) Not everyone wants to use Meteor for the client and they already have some clients built for a Rest backend. Not letting them use Meteor is why they won’t use it and go back to express.
2.2) Meteor != DDP …
There are many ways and packages to do this. I have used mrt:collection-api https://atmospherejs.com/mrt/collection-api and it works great. There a document http://www.meteorpedia.com/read/REST_API to see more options.
What?
I’m not sure why your comparing HTTP and DDP, they’re 2 completely different technologies.
Express is a node framework, Meteor is a platform.
I dont even…
Now don’t push it please.
@ccfiel
Exactly, and the best one is Restivus, it offers almost everything a Rest API framework offers. I’m just asking if someday this will be integrated in the core of Meteor since it’s something very crucial for every web facing technology.
There are many ways to create REST API, I would favour having packages rather than made it into Meteor official release, likewise in Node.js, some adopted HAPI.js, some Express.js, some these and that. I hope this answer your question.
Thanks for your answer. I like it and it’s really logical. It would just be nice to have a ‘‘production ready’’ package for this or like I said adding it to core alongside the publications in DDP.
While I certainly think REST APIs are important for any current app server to offer I’m not sure I see the motivation for a core-based implementation of it. It isn’t a cross-cutting concern afaics. In other words, it won’t affect code outside of itself much, and different implementations of it could be swapped in freely as the access is all HTTP standard.
So leave it to packages…yes I know you’re taking a dim view of 3rd party capability but there are some good 3rd parties coding solid packages for Meteor. HTTP APIs aren’t rocket science, and I think there are multiple implementations that do fine already. Note that reactive REST is somewhat of an oxymoron. REST is wrapped around ideas like idempotency that reactivity contradicts.
Just to share, Postman for REST on Google Chrome, cool tool for testing other than CURL.
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
I recently started using Restivus for one of my project, and I’m really happy with the results. I’d like to strongly recommend using it, also I’d like to add my support to having it as an official package.
Hey folks. As the creator of Restivus, I feel somewhat obligated to respond here. I think @spicemix pretty much has it on the money, but I just wanted to show my support.
@orbyt If you ever decide to come back to read this, I think you misunderstood the original post, which has caused a needless argument and some unkind words around what should have been a proactive discussion. skini26 is not saying that Meteor should replace it’s DDP framework with REST. That would be completely absurd, and would absolutely destroy Meteor’s reactivity, which nobody wants. But not everyone everywhere is ready to consume data over DDP, and in fact REST is still a largely popular and widespread technology for non-realtime APIs. If you’re exposing an API publicly, where you don’t have control over every client app consuming your API, chances are you’ll want to have a REST API available, since it is a familiar standard for developers.
skini26 While it would be an honor to someday have something I worked on considered an official package for Meteor, I completely agree with proyb2 and @spicemix that there are plenty of third party solutions in Meteor for tons of other things that are perfectly acceptable solutions. There are plenty of capable developers in the Meteor community, and by taking some of this burden off the core developers, they can work on the difficult problems. Rails is a very mature framework, and a large part of its success is the third party gems. Speaking of Rails, Grape - a third party REST framework - is a widely accepted solution (and my personal favorite from my limited time with Rails). The same goes for Django, another mature web framework. REST Framework is third party, and that is the accepted REST solution, from what i can tell. Those are two of the most popular web frameworks, and they both have widely accepted third-party REST solutions. I don’t think Meteor should or will be any different, for all the reasons @spicemix outlined.
Finally, thank you so much anbuselvan for lending Restivus that huge compliment! That made my day!
Thank you for your answer, you understood exactly what I meant.
You are a competent developer and your package is awesome, I hope that you will have a lot of support and contributors to make it the de-facto Rest API smart package and production ready to handle thousands of requests and be scalable . I’m not competent enough to help you but I wish I was.
Talking about performance and scalability, do you have some benchmarks to compare it to other node frameworks and also to Meteor methods and non-reactive publications ?
If you can prove to people that Meteor can be used as a complete and legit Rest API with the same performance as others, people will have no reasons to use express or any other framework. They will try Meteor and then they will discover DDP and progressively switch to it. I think that this is a really good strategy to attract a lot of people to Meteor.
Thank you !
Not to favor one for the other, but DDP can be, and is being, used outside of meteor. It has a really great specification and some very good implementations.
There are applications out there (java, .net, javascript, ios, etc) that use DDP to connect to meteor apps.
Here is a comprehensive list: http://www.meteorpedia.com/read/DDP_Clients
And here is one that’s the latest ‘hype’: http://mondora.github.io/asteroid/
It is nice to have two different options, and it is even nicer that there are multiple options for each of them and that they are community contributions.
Hi @orbyt, Alice here from the Meteor team.
I deleted your most recent post in this thread; we want the Meteor forums to be a civil and delightful place for community conversation to happen, and this means we cannot tolerate mean-spiritedness or name-calling here. Your post was flagged as inappropriate by 7 people, and continuing to act against the forum guidelines may cause your account to be banned.
I know people will disagree with each other sometimes, but let’s all work to treat each other kindly even when we disagree. I trust that, going forward, you will help us keep the Meteor community friendly, and I hope to see you posting lots!
I too was looking for REST api with meteor. But that was sometime back.
After spending some time with Meteor, it got me thinking - if client is using REST, then is Meteor the right server?
The question I have is: why should one go with Meteor for REST and not go with its parent, NodeJS.
Would Meteor be able to handle serving simultaneous REST connections as efficiently as a base NodeJS server could do?
Accessing collections over REST, that’s a different story though. Meteor may shine there with collections REST api - but then one can always go with MongoDB REST api !!
Hope some one can clarify from “core architectural stand point” if meteor is indeed capable of REST (contrasted against other servers in terms of connection handling and throughput)
Hi guys!
@rgoomar linked me to this thread, seems pretty intense.
@skini26 @anbuselvan @kahmali I agree with you that Restivus is pretty awesome, I also like cfs:http-methods. It seems to have a lot of functionality and options that people would be looking for in an official REST implementation. I think it would be great to somehow promote these packages as a community solution to this commonly requested feature, until Meteor has it built in.
@spicemix I see your point about REST support not necessarily needing to be in core, but I think there are actually some ways that it could be integrated well into the framework. Some examples are having an official solution for HTTP-based authentication, automatically having an HTTP equivalent for your DDP based APIs, etc. Also, there’s a marketing concern - people might feel that Meteor doesn’t really “support” REST if it’s not part of core.
@KrishnaPG @skini26 Regarding Meteor’s performance as a REST API backend, I can’t think of anything that would make it slower than any other Node app when handling HTTP requests. Meteor has many features beyond just DDP, and it would be great for people to use it even if all they need is a REST API for their mobile app. As you said, there are a lot of benefits - Meteor has great built-in functionality for handling collections, easy deployment, fast development with server reloading/hot code push/meteor shell/meteor debug, etc. Plus, if you decide that you want a webapp or PhoneGap/Cordova app to go alongside your native mobile app, you can easily build a DDP frontend to the same data.
In conclusion:
I don’t think DDP and HTTP need to be enemies. There are a lot of cases where DDP is the right solution, and some where you need HTTP. It would be great if this wasn’t even a point of discussion for people when deciding whether to try out Meteor - it should be just as good or better to build your REST backend with Meteor as with Express or Rails, then everyone wins because you don’t need to choose your server by first deciding on DDP vs. HTTP.
Shameless self-promotion:
I’m currently working on a package for Meteor that will make it ultra-easy to have the exact same API for your app over DDP and HTTP: https://meteor.hackpad.com/Meteor-Hack-Week-REST-APIs-with-Meteor-XK2NNXqhUvj
That way, you can just write your app using the normal Meteor stuff like publish, methods, allow/deny, etc. and then consume it over whatever protocol you like.
Awesome! Thanks @sashko for the detailed response. I totally agree with you on the idea about community promoted packages, as still developers are struggling to pick the right package from atmosphere to complete certain task, because it’s just showing whole list of packages, and I’d like to strongly suggest at least all the packages should be tagged to certain categories (an email to the package owner to tag their packages to right category/tag would be sufficient?), so that it’ll be easy to select a right package to complete a task (or entire meteor project) quickly and efficiently.
Here’s a sample flow:
Regarding REST APIs, I have this conversation when I make decision every time like to deploy a Meteor backend to serve the APIs for native mobile clients, and I always convinced to use Meteor for the main website (only!), and Restivus for native mobile clients.
There are few client libraries already available to support DDP natively as well.
e.g:
Can’t wait to try your REST package (HTTP and DDP) once it ready!!
Thanks @sashko From the technical / architectural standpoint, I am looking for pointers on how REST gets impacted due to the differences between the Meteor and Natural Node.js:
For example,
in such situation what kind of performance benefits (throughput, simultaneous user count …) meteor architecture has over bare node.js.
For example, lets say 10K sensor devices from all over the world are using HTTP PUT to insert some data into server constantly.
In such scenario, what are the advantages one can expect from Meteor architecture? For example, Fibers (vs nodejs single threaded model), - how would it affect, and any other differences that contribute to:
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…