Reputation: 21
I'm new to Ember.js and trying to see if it fits me.
I'm building a web app where each user can signup and get into its member area. Then the app uses a Platform via RESTful API to provide user with context-specific features (i.e. create a shared folder, upload files, etc..)
The goal is to scale the app later on and deploy it onto different domains leveraging the power of the Platform.
At this point i'm looking for the framework to supply Ember.js with data and handle persistence (i.e. storing info on new users into database and sending corresponding API call to the Platform). The topics I'm concerned with are:
Thanks in advance for any insights and/or references.
Upvotes: 2
Views: 521
Reputation: 3621
The answer to which framework (in any language) is best for Ember.js is basically: "any". You might be thinking of Ember as a framework with a document-scripting pattern (like Backbone or plain old jQuery) where the server renders a document and javascript progressively enhances its behavior into something less static. It's probably better to think of Ember like a miniature Cocoa / Android that targets the browser as a runtime environment instead of a specific mobile platform.
Client applications, regardless of environment, are fine with any language and any server application web framework. As long as the app speaks HTTP and has support for sending data (not just rendering pages) you're good. You don't even need to necessarily use JSON as a data format, although that is what most people select these days.
To answer your other questions:
Authentication is a server concern on the web, so Ember doesn't have anything to do with it. Put the entire application behind a sign in page and use whatever authentication mechanism you want. If parts of your application need to be exposed before authentication, I'd just expose an entirely different build (or the same build with a different router) before and after authentication. Otherwise, you're going to find isAuthenticated
checks littering your routes and templates.
You'd write a full client application for the browser for the same reason anyone builds a client application anywhere: statefulness and data transfer cost. The web stateless by design. You can get rudimentary statefuless with sessions and if your application can be seen as a series of documents this is enough. Just skip having a client application altogether and treat the client device like a dumb document viewer. If you have more complicated state needs, you'll need to handle this in the client environment itself. Once you've decided this is necessary you'll find sending data is much cheaper than sending pages or page fragments. So your server application (in whatever design pattern you want) exposes data and your client application (in an MVC-like pattern) consumes, displays, and allows for navigation through and interaction with this data. This is true if your client is in ObjC/Cocoa running on an iPhone, Java running on android, BrightScript running on a Roku, Ember running in a browser, or even C# powering a Windows application that needs remote data.
Upvotes: 2
Reputation: 3434
I haven't used Ember.js But I was curious watching your question and I just typed "ember js and" on google. There was no Python, but the third option was PHP. The most results are "ember js and rails". I suggest you to take a look at this option. I think it's the best and most documented option regarding Ember.js.
If I have to choose between PHP and Python my option is to choose PHP. It's more complex, a bigger community and many more. But I suggest you to give a chance to RAILS. You must try it. There are lots of tutorials and documentations regarding ember.js and rails.
Hope I helped.
Upvotes: 0