2

Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.

So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).

One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.

Thanks in advance!

Kalman
  • 8,001
  • 1
  • 27
  • 45
rjoxford
  • 351
  • 3
  • 12

3 Answers3

5

well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.

today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.

take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages. Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.

MVC vs API Rest

I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.

good luck

pedrommuller
  • 15,741
  • 10
  • 76
  • 126
1

Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.

Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).

I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus

So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.

There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.

kahmali
  • 557
  • 6
  • 10
  • I hadn't thought/looked into Meteor with its own REST API. I know I've got some reading to do here, but I'm a little confused by RestStop2 being deprecated, and (not anything against you!) why you are having to release an updated version. Is it not standard practice to maintain good separation, thereby giving a pretty clean REST layer by default? – rjoxford Jan 15 '15 at 18:23
  • RestStop2 was deprecated because a package that is widely accepted as the default routing solution for Meteor (Iron Router) began supporting server-side routing. The RestStop2 devs suggested folks use Iron Router instead, but there was still enough functionality that it was worth wrapping up into a package of it's own, which I did. None of this was standard in Meteor. If you look at some other more mature web frameworks, like Rails and Django, you'll see that neither of them have a 1st-party solution for building REST APIs either. It's just typically not a goal of these frameworks. – kahmali Jan 15 '15 at 21:08
  • @rjoxford Check out my response here for some more details on the state of REST API support in Meteor: http://stackoverflow.com/questions/10150538/how-to-expose-a-restful-web-service-using-meteor/27828110#27828110. The sections on Iron Router and RestStop2 explain my reasoning behind developing the package. – kahmali Jan 15 '15 at 21:18
0

The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:

Today make a web applications separated in 3 layer (frontend, backend, and databases), if tomorrow you wanna do a mobile application you can develop the application like a extra project in the frontend layer, but use all the features developed in backend. Then the frontend application not need servers why run inside every device, but maybe the load in the backend servers increase, and you only need add 1 more server in the backend layer.

Its a little example, but is the most common case in this new era of mobile applications.

Remember always this in MVC architectures:

Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.

Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.

Model: store data, backups, slaves, etc.

PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.

Jesús Quintana
  • 1,803
  • 13
  • 18