Hi !
I’m working with Ember.js for 1 month ago, and I really appreciate it. This week, I just began an Ember app (a blog) and I don’t find anything on the web about noSQL databases with Ember-data.
Someone have an adivce or already had experiment ?
Thanks a lot !
I’ve had some great experiences running Riak with Ember.js + ember-data.
Essentially, all of the NoSQL databases speak JSON so it’s really up to you to decide which features you want the database to support from a server-side point of view.
An important aspect is how you wish to query your data since the NoSQL databases vary greatly in this regard.
I chose Riak myself because of the fault tolerance - and it’s been fantastic to work with so far.
I think Mongoid (ORM for Rails) works just fine 
It is natively storing everything as JSON documents so…
Here are two mongo/ emberjs sample apps with rails in the backend.
I can’t say whether it’ll be best, ok or a total failure, but I’m planning to try MarkLogic and BaseX as DBs with a (hopefully thin) Spring REST layer. I’d like to see what happens if I author a lot of the logic in XQuery. Kind of an experiment. If I go this route, I will presumably build the REST layer to suit ember-data’s default expectations.
We have used mongodb running with an express.js server through the mongoose module. This is working extremely well so far…knock on wood.
Spring and XQuery (better XSLT) has been a nightmare for me in the early 2000s. I’m surprised anyone would still go that route 10 odd years later… but hey, some people still code COBOL 
Whatever works for you @stusalsbury I would never work with an XML document if I can avoid it… JSON is so much simpler and more natural IMO.
In my case, Spring is just an HTTP facade for the XML database (which speaks JSON as well, therefore it’s an easy route to the web service). As I said, it’s sort of an experiment to find out if I can write less code by authoring XQuery functions and, yes, XSLT transformations instead of OO code + SQL. Kind of like lisp on steroids.
@kmandrup, I need to thank you. Your complaint about the “fun” you’ve had with Spring caused me to rethink whether I needed it at all. I presumed I needed it for URL rewriting, sessions, handling different database connections due to public vs. registered user access to my site, and for doing things in Java that just don’t fit in xquery (things like emailing, encryption, distributed transactions). I looked into it and found that MarkLogic should be able to do almost all of that for me with relatively painless configuration and code (hopefully less work than with Spring).
I’m trying to keep MarkLogic-specific code to a minimum and keep it isolated, but in this case I’ll take the hit since it looks like it will allow me to ditch Spring (and Tomcat) altogether.
So thanks for pushing me in the right direction. You won’t be able to teach me to dislike XML, though. I’ll have to learn that the hard way
Note: the one area that MarkLogic probably won’t cover is distributed transactions… it can participate in XA transactions but not manage them. I think I can get away with that since it has its own support for queues, and that is the only transactional support I need (as of now) beyond data modifications themselves.
Hi @stusalsbury I’m happy to hear that you feel I pushed you in the right direction. I can give you this simple advice “travel as light as you can”. I used to be a big fan of Enterprise solutions, Web services and all that, but reading 30 pages of the Pick Axe book (Ruby) made me realize that I was stuck in the age of dinosaurs, and that using more agile techs (such as JSON, ruby etc.) would make me a much more agile developer and able to express my code much more concise and easier to understand, with lots less noise and bloat. I would never go the enterprise route myself. Most of their products, including IDEs are over-bloated, only to make it necessary to sell costly consultants. “Genius is the make the complex simple”
Perhaps you should consider using Java at all. It is a dinosaur… the C++ “baby language”, originally designed to teach students OOP without the technicalities of C++ (such as memory management). Programming languages have come a long way since then… Java is simply not “sexy” any more and is evolving so slowly it seems like a standstill… Just my 2 cents. Perhaps look at NodeJS and Mongoose combi, but hey, that is a big step! With Coffeescript it should be okay.
I have been on the Rails band wagon since 2009, but now I see that even Rails is becoming old school and “obsolete” (version 4.0) and about time to move on to faster, slicker and more sexy technologies… All these giant server MVC frameworks were made for a different era, where the server was “master” - now the server is becoming the “servant” once again and those frameworks suddenly seem over bloated for the new way of doing things (see @wycats talk on this, that startups are moving away from Rails now… for that exact reason)
The sad thing of course, as soon as you get sufficient expertise in whatever technology it is a sign it is getting obsolete and time to move on… and gets harder (and shorter lifespans) all the time… Hmm, much like girlfriends perhaps!? Good luck!
Well I’m happy not to have the spring/tomcat baggage. As for ditching Java due to lack of sexiness – well… you are talking to someone who’s planning to do the whole thing in XQuery so it’s kind of strange to talk about ditching Java when I’m essentially ditching OOP (for this project). The goal here isn’t sexy, it’s making great products with low upfront and maintenance costs. Tradeoff triangle… yadah, yadah, yadah.
I enjoyed using CouchDB with Ember Data. I was building on top of https://github.com/pangratz/ember-couchdb-adapter as a CouchDB adapter. (ember-couchdb-adapter isn’t always 100% up-to-date, e.g. looks like it’s currently at 0.11 rather than 0.13, but the tweaks you might need to make are usually minor.)
Hello Kanesteven, Iam also working with such kind of setup (express.js and mongoose), the problem that I’ve got for now is how to set up the ember-data to work with my nested server models. Do you have some insights on this?
var mongoose = require('mongoose'),
Schema = mongoose.Schema;
/**
* Article Schema
*/
var ArticleSchema = new Schema({
title: {
type: String,
default: '',
trim: true,
required: 'Title cannot be blank'
},
content: {
type: String,
default: '',
trim: true
},
author: {
type: String,
required: true
},
summary: {
type: String,
required: true,
trim: true
},
thumbnail: {
type: String,
required: true,
trim: true
},
category: {
type: Schema.ObjectId,
ref: 'ArticleType'
},
tags: {
type: [String]
},
status: {
type: String,
default: 'draft'
},
createdBy: {
type: Schema.ObjectId,
ref: 'User'
},
updatedBy: {
type: Schema.ObjectId,
ref: 'User'
}
});
// mongoose.model('Article', ArticleSchema);
/**
* Article Schema
*/
var ArticleTypeSchema = new Schema({
name: {
type: String,
required: true,
trim: true
},
descr: String,
createdBy: {
type: Schema.ObjectId,
ref: 'User'
},
updatedBy: {
type: Schema.ObjectId,
ref: 'User'
},
articles: {
type: [ArticleSchema]
}
});
mongoose.model('ArticleType', ArticleTypeSchema);
This article written about a year ago, Why You Should Never Use MongoDB, explains that when using NoSQL data stores for relational data, you should use references to avoid duplicating data, or in other words, structure the json just how Ember-Data likes it:
{
// One Mongo retrieval:
comments: [{
user: 1, // <-- Avoid duplicating data by using ID's
content: "hello world"
},{
user: 2,
content: "greetings earthling"
}],
// Another Mongo retrieval:
users: [{
id: 1,
firstName: 'Devin',
lastName: 'Rhode'
},{
id: 2,
firstName: 'Bob',
lastName: 'Lamar'
}]
}
The downside explained in the article is that now you have to go through and replace the user ID’s with the actual user data - this bloats the json payload and is not the format Ember-Data expects.
Are NoSQL databases still a bad choice for relational data if you’re using Ember-Data (with proper references)? What are the tradeoffs?
Also, conceptually, are ember models essentially acting as a schema for the data?
I wrote ember-pouch, so I’m pretty biased towards PouchDB/CouchDB. 
But I’ll offer my perspective.
CouchDB and Mongo are both “NoSQL,” but they’re very different conceptually. For one thing, CouchDB doesn’t have collections like Mongo does, although the problem with inline dependencies vs. expensive map/reduce queries when you’re trying to store relational data is similar.
The tradeoff I made when writing relational-pouch (the core of ember-pouch) was to optimize for performance, while never duplicating any data. Basically I just prefix all the keys by their type (“post_1”, “author_2”, etc.). In practice, it seems to fit the Ember Data use-case pretty well.
A few reasons I like the PouchDB/CouchDB combo:
Anyway I’d recommend just trying out ember-pouch, and if you like it, great.
You don’t have to store any duplicate data, you can always store it with IDs but materialize it as a virtual property and return the JSON that way when you want to do embedded.