Separate REST JSON API server and client? [closed]

Answer 1

Building a JSON API in Rails is first class, The JSONAPI::Resources gem does the heavy lifting for a http://jsonapi.org spec'd API.

Answer 2

I prefer to go the route of #2 and #3. Mainly because #1 violates separation of concerns and intermingles all kinds of stuff. Eventually you'll find the need to have an API end point that does not have a matching HTML page/etc and you'll be up a creek with intermingled HTML and JSON endpoints in the same code base. It turns into a freaking mess, even if its MVP, you'll have to re-write it eventually because its soo messy that its not even worth salvaging.

Going with #2 or #3 allows you to completely have a API that acts the same (for the most part) regardless. This provides great flexibility. I'm not 100% sold on Backbone/ember/whatever/etc.js just yet. I think its great, but as we're seeing with twitter this is not optimal. BUT... Twitter is also a huge beast of a company and has hundreds of millions of users. So any improvement can have a huge impact to bottom line on various areas of various business units. I think there is more to the decision than speed alone and they're not letting us in on that. But thats just my opinion. However, I do not discount backbone and its competitors. These apps are great to use and are very clean and are very responsive (for the most part).

The third option has some valid allure as well. This is where I'd follow the Pareto principle (80/20 rule) and have 20% of your main markup (or vice versa) rendered on the server and then have a nice JS client (backbone/etc) run the rest of it. You may not be communicating 100% with the REST api via the JS client, but you will be doing some work if necessary to make the suer experience better.

I think this is one of those "it depends" kinds of problems and the answer is "it depends" on what you're doing, whom you're serving and what kind of experience you want them to receive. Given that I think you can decide between 2 or 3 or a hybrid of them.

Answer 3

At Boundless, we've gone deep with option #2 and rolled it out to thousands of students. Our server is a JSON REST API (Scala + MongoDB), and all of our client code is served straight out of CloudFront (ie: www.boundless.com is just an alias for CloudFront).

Pros:

• Cutting-edge/exciting
• A lot of bang for your buck: API gives you basis for your own web client, mobile clients, 3rd party access, etc.
• exceedingly fast site loading / page transitions

Cons:

• Not SEO friendly/ready without a lot more work.
• Requires top-notch web front-end folk who are ready to cope w/ the reality of a site experience that is 70% javascript and what that means.

I do think this is the future of all web-apps.

Some thoughts for the web front end folks (which is where all the new-ness/challenge is given this architecture):

• CoffeeScript. Much easier to produce high-quality code.
• Backbone. Great way to organize your logic, and active community.
• HAMLC. Haml + CoffeeScript templates => JS.
• SASS

We've built a harness for our front-end development called 'Spar' (Single Page App Rocketship) which is effectively the asset pipeline from Rails tuned for single page app development. We'll be open-sourcing within the next couple of weeks on our github page, along with a blog post explaining how to use it and overall architecture in greater detail.

UPDATE:

With respect to people's concerns with Backbone, I think they are over-rated. Backbone is far more an organizational principle than it is a deep framework. Twitter's site itself is a giant beast of Javascript covering every corner-case across millions of users & legacy browsers, while loading tweets real-time, garbage collect, display lots of multimedia, etc. Of all the 'pure' js sites I've seen, Twitter is the odd one out. There have been many impressively complicated apps delivered via JS that fare very well.

And your choice of architecture depends entirely on your goals. If you are looking for the fastest way to support multiple clients and have access to good front-end talent, investing in a standalone API is a great way to go.

Answer 4

I'm about 2 months into a 3 month project which takes the second approach you've outlined here. We use a RESTful API server side with backbone.js on the front. Handlebars.js manages the templates and jQuery handles the AJAX and DOM manipulation. For older browsers and search spiders we've fallen back onto server side rendering, but we're using the same HTML templates as the Handlebars frontend using Mozilla Rhino.

We chose this approach for many different reasons but are very aware it's a little risky given it hasn't been proven on a wide scale yet. All te same, everything's going pretty smoothly so far.

So far we've just been working with one API, but in the next phase of the project we'll be working with a second API. The first is for large amounts of data, and the second acts more like a CMS via an API.

Having these two pieces of the project act completely independent of each other was a key consideration in selecting this infrastructure. If you're looking for an architecture to mashup different independent resources without any dependencies then this is approach is worth a look.

I'm afraid I'm not a Ruby guy so I can't comment on the other approaches. Sometimes it's okay to take a risk. Other times it's better to play it safe. You'll k ow yourself depending on the type of project.

Best of luck with your choice here. Keen to see what others share as well.

Answer 5

Isomorphic rendering and progressive enhancement. Which is what I think you were headed for in option three.

isomorphic rendering means using the same template to generate markup server-side as you use in the client side code. Pick a templating language with good server-side and client-side implementations. Create fully baked html for your users and send it down the wire. Use caching too.

progressive enhancement means start doing client side execution and rendering and event listening once you've got all the resources downloaded and you can determine a client capabilities. Falling back to functional client-script-less functionality wherever possible for accessibility and backwards compatibility.

Yes, of course write a standalone json api for this app functionality. But don't go so far that you write a json api for things that work fine as static html documents.

Answer 6

For atyourservice.com.cy we are using server side rendered templates for pages especially to cover the se part. And using the API for interactions after page loads. Since our framework is MVC all controller functions are duplicated to json output and html output. Templates are clean and receive just an object. This can be transformed to js templates in seconds. We always maintain the serverside templates and just reconvert to js on request.