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.
Related
I am a newbie to ember and i am using ember cli mirage for servers side API. For example, i want to POST a movie to the movies route, it gets added to the existing one's present in fixtures and is listed in localhost-4200/movies.
On refreshing the browser, the one's posted gets erased and the default one's remain.
Is this the expected behavior ?? Won't the details remain the same after browser refresh or when i reload the next time?
Yes, this is the expected behavior. Fixtures will be applied on pageload.
Mirage was created to let you easily fake your JSON API. It's built on existing libraries, but brings along conventions to make setting up your fake server quick and painless.
Mirage is not a production API, it fakes your API for easy development and testing, but if you need a persistend API, you need to write one by yourself.
If you want to start building a server, but you dont know where to start, take a look at https://github.com/emberjs/data and JSON-API server implementations: http://jsonapi.org/implementations/
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...
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.
I have read a couple of articles about using new JS frameworks like Backbone.js or Ember.js
I have come up to this statement:
If I use a JS framework like Backbone.js/Ember.js, I then move the logic from the back-end (Django) to the front-end.
Therefore, will Django actually be used only for its Models?
Does that mean that Django Views and Django Template are not needed anymore and the Django back-end is kinda turn into a "basic" REST API that will be consumed by the front end.
Do you agree? Is it then the purpose of Django in this case?
Is turning the django backend into a REST API one of the most suitable use case when using a framework like Backbone.js/Ember.js for the front-end?
Thanks.
Django is perfectly fine to be used this way, you still get the admin, the models, the orm and all the third-party plugins. However, it isn't blazingly fast, so if you're doing simple document level, non-relational REST mapping, you might wan't to look into node.js and mongoDB for instance.
If you're sticking with django (like we are, we like the structure it gives us), you can use one of the REST plugins:
Django Rest Framework A perfect match since DRF 2.0, under very active development!
Django Tastypie (checkout backbone-tastypie.js for integration)
Django Piston (might be a bit stale or has development picked up lately?)
If you only want to work with frontend development, checkout the Backend-as-a-Service places like cloudmine.me or firebase.com that handle all backend stuff for you, for a price of course.
Django may seem unnecessary once you start thinking about single page solutions and Javascript applications, but if you want your site to be 'fail proof' it wouldn't be impossible to develop both a client side Javascript version of the site as well as a backend django side incase the user, or your site's javascript, fails at some level. Of course this requires creating your site twice, and probably isn't needed in the age of modern browsers, but such would be one of the few instances where you would mix the two for a complete solution.
Yes, that's about it. You can use it to manage authentication to resources and such and maybe use a main view for your application but you won't need to use the server side templating since these frameworks are made to work with json/xml response.
That's why a lot of people are moving to lighter backend/backbone or ember combo instead of a complete solution like django. You can also use your django for caching json response which makes your application appears faster.
We are doing that and use django-piston to make it easier on you.
Normally you make your entire website under Django and only one page will be a "single app page" using backbone.js, usually that page is a very interactive page, with lots of small updates that occur frequently and need to be shown very fast to the user. This page, because of the large number of changes and user interactions is constructed on the client-side so that you are using his PC resources and not the server's, the rest of the pages can use django because it offers you a very stable and secure framework for the server-side