When planning an Ember App, are there any quick guidelines to determine if the BackEnd or the FrontEnd should be responsible for a particular duty?
I’m sure this is true for any MVC(?) JS Framework coupled with a BackEnd such as Rails.
There seems to be overlap n trying to determine if a feature should be handled by the BackEnd or FrontEnd.
For example, creating a new user account. Would you build that in Ember or Rails? Whats a common practice? Build it all in Ember, and just use Rails as storage? In that case, is Rails overkill?
I apologize if this is a dumb question, already well explained somewhere else. I couldn’t find it, but any suggested post on this topic would be greatly appreciated.
Generally for most of the JS Frameworks you build everything related to the view in that framework. The server side is only an api layer on top of your db. That said if you’re on a deadline and it’s more annoying to make something like device work for an api than it is to just use it and have ember live behind the authentication wall then that works too!
This isn’t a dumb question. This is where the art of programming comes in. There are no black and white answers here.
One thing I normally think about when deciding between back end or front end is, does this piece of data need to live across sessions? E.g., in the case of user authentication, you need to know who a user is before you can authenticate them, so users definitely need to be persisted in a shared database in the backend.
Another thing to think about is, does something need to be shared across all clients? E.g., you have a content catalog of videos that all users who visit the site will see. That will need to be handled server side.
The front end is for displaying things, the view later. That’s not to say it can’t do interesting things though. I have an ember frontend that uploads files directly to s3. This is great because every file that needs to be uploaded doesn’t have to needlessly proxy through the backend server.
Agreed, this isn’t a dumb question but not one that has an easy answer either…it’s going to be very dependent on your application, environment, future use cases, etc. The only general guideline I can give you in addition to what’s been said is that “business logic” should generally not be done client-side. Client-side is generally for display related, UI workflow logic only.
For example, the app I’m working on deals with point-of-sale transactions. If you think about that sort of thing, a common need is having to calculate sales tax (which isn’t as straightforward as you might think and can actually get kind of nasty). I could do that calculation in Ember just fine, but since I also publish the back-end as an API for consumption by other systems, doing so makes no sense at all…why push that kind of calculation on the clients of my backend such that if things change, all clients have to change too. You may not be envisioning your back-end being used by anything / anybody else but I generally find assuming that it will be helps delineate responsibilities of front-end vs. back-end. YMMV