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?
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.
I’m not sure what’s ideal, but FortuneJS came out recently and its being designed as a Node.js backend to Ember.js apps.
I’m a bit biased (author and contributor), but we’ve been very successful with Webmachine (erlang) (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 for a good Ruby example. We still use AM::Serializers there, but there’s no coupling to the Rails stack at all.
We’re using Django and the Django Rest Framework to serve our Ember app Emma Social. In conjunction with @toranb’s rest framework adapter, it works great.
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
or
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.
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.
@seancribbs Webmachine looks interesting. Thanks for the links.
If you’re looking for a Node.js solution, try http://sailsjs.com/
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.
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.
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.
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.
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.
I support @DevinRhode2. Hapi is great.
These are two good starting points to understand the basics of hapi and why it exists: