# The ideal backend for serving JSON to Ember

**URL:** <https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460>\
**Category:** Uncategorized\
**Created:** [September 5, 2013, 3:35pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460 "2013-09-05T15:35:33Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![jtrinker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jtrinker/32/14715_2.png) [@jtrinker](https://discuss.emberjs.com/u/jtrinker)\
**Post date:** [September 5, 2013, 3:35pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/1 "2013-09-05T15:35:33Z")

</div>

I just wanted to get smart people’s opinion on what their ideal backend for an Ember app would be.

Let’s say that Ember Data is out of beta and bug free, working perfectly. What would you use to serve data to Ember? I would use the Rails API and serializers but that is simply because that is what I know. Is there a a better solution?

---

<div class="post-metadata">

**Author:** ![MarceloMira](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/marcelomira/32/15057_2.png) [@MarceloMira](https://discuss.emberjs.com/u/MarceloMira)\
**Post date:** [September 5, 2013, 6:41pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/2 "2013-09-05T18:41:01Z")

</div>

I don’t really know much about it, but i believe i have read that it is meant for used with that configuration as the best option, not the only of course.

---

<div class="post-metadata">

**Author:** ![tarasm](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/tarasm/32/15980_2.png) [@tarasm](https://discuss.emberjs.com/u/tarasm)\
**Post date:** [September 6, 2013, 2:13pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/3 "2013-09-06T14:13:09Z")

</div>

I’m not sure what’s ideal, but [FortuneJS](http://fortunejs.com/) came out recently and its being designed as a Node.js backend to Ember.js apps.

---

<div class="post-metadata">

**Author:** ![seancribbs](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/seancribbs/32/14221_2.png) [@seancribbs](https://discuss.emberjs.com/u/seancribbs)\
**Post date:** [September 11, 2013, 1:50pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/4 "2013-09-11T13:50:08Z")

</div>

I’m a bit biased (author and contributor), but we’ve been very successful with Webmachine [(erlang)](http://github.com/basho/webmachine) [(ruby)](http://github.com/seancribbs/webmachine-ruby) in several of our applications. It gets you focusing on the resources themselves instead of MVC. Have a look at the code in [GiddyUp](https://github.com/basho/giddyup/blob/master/lib/giddyup/resources.rb) for a good Ruby example. We still use AM::Serializers there, but there’s no coupling to the Rails stack at all.

---

<div class="post-metadata">

**Author:** ![commadelimited](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/commadelimited/32/3548_2.png) [@commadelimited](https://discuss.emberjs.com/u/commadelimited)\
**Post date:** [September 11, 2013, 2:35pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/5 "2013-09-11T14:35:34Z")

</div>

We’re using Django and the Django Rest Framework to serve our Ember app [Emma Social](http://myemma.com/social). In conjunction with @toranb’s [rest framework adapter](https://github.com/toranb/ember-data-django-rest-adapter), it works great.

---

<div class="post-metadata">

**Author:** ![eccegordo](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/eccegordo/32/14927_2.png) [@eccegordo](https://discuss.emberjs.com/u/eccegordo)\
**Post date:** [September 11, 2013, 9:27pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/6 "2013-09-11T21:27:56Z")

</div>

Personally, I believe if you can render JSON in a structure that the Ember app expects then it really doesn’t matter. The primary considerations are performance, hosting and deployment, manageability, and perhaps most importantly “developer happiness”.

It is my impression that the core people behind Ember come from a Rails background so there is likely implicit bias in the conventions and they are informed heavily by Ruby and Rails patterns.

That being said, there really is a clean separation between client and server. In a lot of ways a more pure separation because the server only has to render data structures (JSON) and not (too much) markup HTML.

It is probably worthwhile, to explore the server side technologies and languages independently to get a a sense of the practical tradeoffs. A lot of intangibles. A lot of this is personal feel. What is it like to live within an environment? What is the documentation like? What is the community like when you need help? Do you have co-workers or friend who you bug when needed? What are the build and deployment tools like? Over the years, I have programmed in Perl, PHP, Ruby and some Python.

There are a lot of things to be said about Python with its whitespace syntax. The code is generally easy to read. It is kind of hard to write insane obfuscated code that used to be the hallmark of Perl. But these days I tend to appreciate Ruby. There is an amazing number of “meta programming” type things you can do. Which for me seem useful.

If you just want to work locally and want to quickly prototype some backend ideas you might consider checking out lighter weight tools

> **[Magazine de Communication Entreprises : Gagner en visibilité sur Internet](https://www.cherrypy.org/)**
>
> communiquer sur les logiciels et services et prestations de l'entreprise. Publier des actualités pour améliorer son référencement avec la promotion de son activité professionnelle sur le Web

or

[http://www.sinatrarb.com](http://www.sinatrarb.com)

The thing I hear many people mention is that they tend to come back to Rails because it has a lot of conveniences baked in.

At the end of the day the server side technology doesn’t matter to your end users because they are experiencing client side javascript and HTML. Not the backend environment. So use what works best for you is primary. If you can groove on the technology stack, great. If not move on. Little need to be religious about anything these days.

My two cents.

---

<div class="post-metadata">

**Author:** ![eccegordo](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/eccegordo/32/14927_2.png) [@eccegordo](https://discuss.emberjs.com/u/eccegordo)\
**Post date:** [September 11, 2013, 9:32pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/7 "2013-09-11T21:32:49Z")

</div>

One other point I would add is that the backend datasource you are talking to can have some influence.

Is it a traditional RDMS SQL database? A NOSQL system like mongo or Couch DB? Some other big data analytics system that must use something like Hadoop to aggregate data sets.

These considerations imply different backend technology stacks that are specifically optimized for the use case.

---

<div class="post-metadata">

**Author:** ![eccegordo](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/eccegordo/32/14927_2.png) [@eccegordo](https://discuss.emberjs.com/u/eccegordo)\
**Post date:** [September 11, 2013, 9:37pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/8 "2013-09-11T21:37:52Z")

</div>

@seancribbs Webmachine looks interesting. Thanks for the links.

---

<div class="post-metadata">

**Author:** ![brado](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/brado/32/15067_2.png) [@brado](https://discuss.emberjs.com/u/brado)\
**Post date:** [September 12, 2013, 2:16am UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/9 "2013-09-12T02:16:01Z")

</div>

If you’re looking for a Node.js solution, try [http://sailsjs.com/](http://sailsjs.com/)

---

<div class="post-metadata">

**Author:** ![jtrinker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jtrinker/32/14715_2.png) [@jtrinker](https://discuss.emberjs.com/u/jtrinker)\
**Post date:** [September 12, 2013, 3:04am UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/10 "2013-09-12T03:04:45Z")

</div>

I appreciate all of the comments. This is a great repository of information for future projects. I’ll be looking into most all of these in more detail.

---

<div class="post-metadata">

**Author:** ![joefiorini](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/joefiorini/32/3902_2.png) [@joefiorini](https://discuss.emberjs.com/u/joefiorini)\
**Post date:** [September 12, 2013, 5:57pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/11 "2013-09-12T17:57:15Z")

</div>

I’ve been using Fortune to prototype a backend for an ember-app-kit app. Use the ember-json-api adapter/serializer linked to in Fortune’s README. Create a grunt-connect task to start up the API server when you run “grunt server”.

I’ve been enjoying this workflow so far, but I don’t think Fortune is made for production APIs. It has the concept of transformation filters on your routes (like before/after filters in Rails) but you only get 1-per-route. Customizing any part of the request lifecycle means writing your own middleware. It’s great for prototyping your UI, but when you are ready to go to production, you will probably want to write the API in something more geared towards production.

---

<div class="post-metadata">

**Author:** ![knownasilya](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/knownasilya/32/12912_2.png) [@knownasilya](https://discuss.emberjs.com/u/knownasilya)\
**Post date:** [September 12, 2013, 6:39pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/12 "2013-09-12T18:39:26Z")

</div>

Do you still use the views in Sails.js, seems like you’d drop that for Ember’s Templates/Views? I’m interested in your workflow.

---

<div class="post-metadata">

**Author:** ![brado](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/brado/32/15067_2.png) [@brado](https://discuss.emberjs.com/u/brado)\
**Post date:** [September 12, 2013, 7:57pm UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/13 "2013-09-12T19:57:56Z")

</div>

correct. U only use sails for creating the API. Sails has API scaffolding which allow you to create a full CRUD api for any type of entity. Plus it supports MySQL as well as MongoDb.

---

<div class="post-metadata">

**Author:** ![DevinRhode2](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/devinrhode2/32/14826_2.png) [@DevinRhode2](https://discuss.emberjs.com/u/DevinRhode2)\
**Post date:** [December 5, 2014, 1:10am UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/14 "2014-12-05T01:10:16Z")

</div>

In researching node backends to use instead of rails, I found sails and hapi are and will probably be the most secure for now and the foreseeable future.

Sails has several integrations built for ember, if you search google you’ll see what I’m talking about.

I didn’t think I would really consider anything other than rails, but low and behold, there is sails.

---

<div class="post-metadata">

**Author:** ![dennismende](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/dennismende/32/9958_2.png) [@dennismende](https://discuss.emberjs.com/u/dennismende)\
**Post date:** [December 5, 2014, 10:11am UTC](https://discuss.emberjs.com/t/the-ideal-backend-for-serving-json-to-ember/2460/15 "2014-12-05T10:11:16Z")

</div>

I support @DevinRhode2. [Hapi](http://hapijs.com) is great.

These are two good starting points to understand the basics of hapi and why it exists:

- [NodeJS at Walmart](http://nodejs.org/video/)
- [Hapi introduction](https://www.youtube.com/watch?v=Recv7vR8ZlA)
