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...
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 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!
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'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
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