In the project I am working on, we are using ember.js (1.0rc1) without ember-data which is working out quite fine so far. The reason why we decided to go without ember-data is that we already have some utility methods to handle the integration with the REST interface, and over all because ember-data is not part of the ember.js.
From emberjs.com:
Currently, Ember Data ships as a separate library from Ember.js, while
we expand the adapter API to support more features. The API described
in this section tends to be stable, however. Until Ember Data is
included as part of the standard distribution, you can get your copy
from the GitHub page.
So, to my questions and the input I am looking for:
how much do we lose/gain with this approach? (besides the REST integration)
experiences of somebody that actually might have started also without ember-data, and now migrated to ember-data
maturity of ember-data and its integration into ember.js
And there is another question, which might rather be for the ember.js/ember-data devs:
what's the roadmap to integrate ember-data into ember.js and how strong will be the impact on the APIs?
Thanks for sharing your experiences and giving some hints and advices. // ph
I use ember-data in my project and I'm very pleased with it. I saves you a lot of time developing your own stuff for communicating with the server.
At this time ember-data is not officially production-ready but I use it already.
Read this on the emberjs website about ember-data. It says:
Without any configuration, Ember Data can load and save records and relationships served via a RESTful JSON API, provided it follows certain conventions.
We also understand that there exist many web service APIs in the world, many of them crazy, inconsistent, and out of your control. Ember Data is designed to be configurable to work with whatever persistence layer you want, from the ordinary to the exotic.
There is more information on the github page. There is even kind of a roadmap in it...
Another advantage is that you can define your Models with their relationships. It's also possible to use transactions which are giving you the ability to rollback changes if something went wrong at the server.
I really like the vision behind ember-data that it's not dependent on the kind of backend you use. Or where you define your relationships. If you use Mongo-db where you define the relationships on the parent object, where others do that the childs.
Related
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
I have been working on a web app using .NET web forms. Now I'm trying to move to a Web API and a client side application. I'm trying to use Ember.js right now. I'm starting to get confused with Ember 2.0, Ember-Data and stuff.
My problem right now is that I'm trying to consume some of the REST services in order to show a list of things in my Ember app. Is it mandatory for me to use Ember-Data? If not, how can I consume the services to create, read, update and delete items (I mean, am I able to use only ajax or something)?
The Web API was built in order to be usable for many technologies. I need to build an specific URL for each request (even a simple GET has some mandatory parameters). That's why ember-data is not working well for me, at least not what I have learnt about it. Because this.store.find won't allow me to build the URL I need.
Greetings.
Is it mandatory for me to use Ember-Data?
No, it's not. You can use other libraries such as Ember RESTless, or write your own.
You can even use simple jQuery AJAX calls whenever you need to fire a request to your API, however, you'll loose many benefits of Ember Data, such as lazy, asynchronous loading of models when they are needed.
That's why ember-data is not working well for me, at least not what I
have learnt about it. Because this.store.find won't allow me to build
the URL I need.
You can override buildURL method of adapter you're using(for example RESTAdapter), source code on GitHub could be helpful if you would like to do that, and you can find everything you need to create your own behavior for buildURL method in Ember API documentation.
I have been given a task to do using Ember JS however I can't find any documentation or a direction to point myself in in regards to getting a feed from a API URL - Like you can do with Curl in PHP.
I do no that I will possibly have to store it in Ember Data.
Can someone give me a brief example of what I should be doing - It would be great
EmberJS functions completely differently in how you would contact an API in Curl or PHP.
For starters - in emberjs you are contacting API's straight from the client (and this matters, because there are cases where people use backend code such as PHP to call a third API with a secure, org-level API token. This type of thing should not ever be handled by ember or a single page web app. Keep it in your backend code!
Now to get to the really exciting part about ember - Ember Data.
Ember Data in its own right is a rather complex subject. To simplify, ember stores data in what is known as the Data Store, or DS. The DS API is rather large and very much worth getting familiar with. The store is backed by Models and these models can even form relationships much like a directed graphing database would.
The store operates, like all of the ember I know, on the principle of convention over configuration. Thus, the store receives data most efficiently from a conforming RESTful API through the use of the ember RESTAdapter. However, RESTAdapter API is an extension of Ember Adapter and both are easily customized to suit your needs. I can't mention the RESTAdapter without highlighting the importance of the use of serializers. Serializers are integral in doing just what their name implies - serializing (and normalizing) the data coming in from the server into a JSON-parsable object that conforms to the conventions that the adapter expects.
In my experience I usually have to do some kind of customizing at either the RESTAdapter or Serializer level - more commonly the latter as opposed to the former. I also strongly recommend really getting familiar with Ember Data and the Data Store in its entirety as all this in combination provides you with a tremendous amount of power that brings with it new and interesting design paradigms in efficiently integrating with a REST API.
So the only remaining question is - So when do I call the API? Well - that's the cool part. In configuring your adapters, serializing, setting up models you've kind of done the whole shebang. Throughout your webapp you can now just rely on the use of models connected to the ember data store - and ember is going to take care of the rest (such as knowing when to make an API call).
Anyway, I don't want to fanboy ramble too much. Take a look at their excellent documentation on the topic of Models at their site. Also, take a look at ember-cli! If you're just getting started with Ember, this is most certainly the way to go. Don't expect this to be a short learning curve - ember has a steep learning curve and you are stepping right into the heart of it with your assignment. You will find that once you wrap your head around the use of the store it's an incredibly empowering tool.
Good luck with your work!
I'm currently wrapping my head around Ember.js and converting a previously written PHP application, that application made use of of mysql database and some basic PHP code to display results.
There was a whole bunch of javascript to create interactions, but all that code quickly became unusable.
I have most of my frontend stuff done in Ember.js and started thinking about how I should get started with the backend.
There's not that much data involved, uses can request data, create new data, change data or delete data.
There would be a small part where I would like to get data in real time.
I've looked around on the web, but since it's all relatively new, there's not that much information out there.
I would recommend implementing a RESTful API in PHP and hooking your frontend up with that API. You can use your ember code to handle all user interaction, and then when some actual data needs to be changed send a request to your backend.
I have made apps in the past using this strategy with a Laravel backend which makes it very simple to set up RESTful interactions.
You can read about Ember + REST here: http://emberjs.com/guides/models/the-rest-adapter/
The question is quite vague as you could do it in a thousands different ways.
It doesn't matter which language you use for the backend as the ember app won't care.
The only thing you need for the Ember app to work is a decent REST api.
For resource about best practices, check this
Some examples:
In php: http://davss.com/tech/php-rest-api-frameworks/
In Rails: http://railscasts.com/episodes?utf8=✓&search=api
In Node express: http://blog.modulus.io/nodejs-and-express-create-rest-api
As a Saas: https://www.firebase.com
I have been living with an EmberLoopSql stack (pronounced ember-loop-cicle - just cause I like the sound) for 4 months now and am digging it muchly.
StrongLoop allows you to reverse engineer your datastore, creating models that correspond to tables, and automatically creating a CRUD ReST API for them. This means there is no code in your API, just configuration.
Add the loopback-component-jsonapi to StrongLoop to provide json:api compliant responses.
Next, add relationships to your StrongLoop models - like bubbling up the foreign key relationships from the datastore to the api. Now you have json:api responses that Ember really loves.
I am a big fan of Percona Server (MySQL replacement) and if you de-normalize your tables to align with your application, you have one of the main advantages of a NoSQL style datastore. But if you really like something like Mongo (I do), StrongLoop has a data juggler for that.. as well as for most modern datastores.
Ember's new JSONAPIAdapter recognizes relationships exposed in the json:api responses from StrongLoop. After setting up relationships in your models - again bubbling up datastore foreign keys - Ember will fetch dependencies automatically for you. E.g. If you have model a,b and a hasMany b, you can use a.b in your templates and Ember will understand the relationship and fetch the data for you.
What I really love about this stack is how much boilerplate code just evaporates. Compared with java, php, express, go, etc. the code in this stack is small and well organized. I can implement new features in a couple of hours instead of a couple of days.
Hope these opinions help...
I have a pure REST rails backend and I'm working on the client side using Ember.JS I understand that ember-data is used for REST communications but I see it's not even in production does anyone know when it will be ready?
Or if there is a better solution that can be used?
To be fair, Ember.js itself hasn't actually reached a stable 1.0 version yet. From personal experience, I've only ever used the ember-latest.js because their tagged versions are usually so far behind the latest version, and there are too many things missing for me in their 1.0 pre tag. Even the API documentation on emberjs.com is for ember-latest.js, and the 1.0 pre API docs have been archived.
With that being said, as long as you are willing to dig through the new API documentation which is now quite nice, writing in Ember has been a fairly stable and consistent experience for me all summer. Ember Data has also been pretty good, but you have to look into the source code for most of the documentation.
Ember Data has by far the best REST adapter for Ember that I know of, especially because it is built specifically for rails. Look into Active Model Serializers. It almost makes building your API in rails a trivial task. It works perfectly fine for hasOne, hasMany and belongsTo once you understand the conventions explained in the readme for Ember Data. Many-to-many relationships should probably be decomposed into two hasMany relationships with a model in between.
In terms of when it will be ready, they intend to merge ember-data into Ember.js before the final 1.0 release. (source) They have both been stable enough for me though, and quite a number of companies who have already deployed ember apps. Backbone.js is at 0.9.2 and tons of people have put their trust in that, even though backbone doesn't really have something like ember-data.