I am working on a app that has multiple types of users, each user has a separate view when they are logged in. for example a business type user will create his profile upload photos etc, create some other stuff. and then the content created by businesses is visible public on the web-app's landing page.
I am using backbone on the client side, but the whole web app isn't all backbone, the business management area is a separate part which a backbone app runs on the client side, and now I am looking to start on the public landing page, I am confused on how to make this work, should I create a new backbone app for this page, or stuff more views models and collections into the same app?
The urls of both pages differ one is like whatever.com/business and the landing page is at whatever.com
Many views and models from the business side are the same as needed on the public landing page. But I can't think of a good solution on how to organize this.
Has any one worked on something like this before. Any insights ?
Thanks
Backbone.js is a great MVC framework but there isn't a whole lot of convention around organising a large application. You need to be familiar with some good design patterns to get the most out of it or it quickly gets messy.
I was looking at AMD earlier. It looks nice:
http://backbonetutorials.com/organizing-backbone-using-modules/
THis might help too:
http://ricostacruz.com/backbone-patterns/
I also enjoyed this rule book on designing a good API. It was only $8 on my kindle!
http://www.amazon.com/REST-API-Design-Rulebook-ebook/dp/B005XE5A7Q
Edit: I recently refactored a large backbone.js application. I found it a lot easier to build if I exploited Javascript event driven architecture.
There are two excellent (pro) Railscasts on this topic, #323 Backbone on Rails Part 1 and #325 Backbone on Rails Part 2, unfortunately they are behind a paywall, but the money is worth it. Ryan uses the backbone-on-rails gem to facilitate the integration of Backbone into Rails.
It is recommendable to do the whole MVC processing either in Rails (mainly in the backend, with a bit of Ajax and without any Backbone) or in Backbone (mainly in the frontend, using Rails only as a storage engine). Selecting Backbone or similar MVC JS frameworks like ember.js is useful if your application consists mainly of Javascript or JQuery calls, or if you want to do realtime web apps and live page updates. Since it is not sure if MVC Javascript frameworks are really technically mature yet, I would recommend to stick with pure Rails if you do not trust that Backbone can handle all your requirements.
An interesting idea for a general architecture is to use a JSON API as a connection between Rails backend and JS MVC frontend, which means the backend can push the same JSON to the webpage as it does to the iOS and Android apps.
Related
I come from using ASP.NET MVC/Web API and now I am starting to use Angular but I am not clear on the proper way to mix them.
Once I am using Angular does the MVC sever side concepts still provide any value ? Or should I strictly be using Web API purely to get data for the angular HTTP calls ?
Any tips you have for a ASP.NET MVC guy transitioning to Angular would be helpful
Pure Web API
I used to be pretty hardcore with ASP.NET MVC but since I've met Angular I do not see one reason why I would use any server side content generation framework. Pure Angular/REST(WebApi) gives a richer and smoother result. It's much faster and allows you to build websites that come quite close to desktop applications, without any funky hacks.
Angular does have a little learning curve, but once your team has mastered it, you'll build much better websites in less time. Mainly this has to do with the fact that you don't have all these state(less) issues anymore.
For example imagine a wizard form with any traditional server side framework. Each page needs to be validated and submitted separately. Maybe the content of the page is dependent on values from a previous page. Maybe the user pressed the back button and is re-submitting an previous form. Where do we store the state of the client? All these complications do not exist when using Angular and REST.
So ... come over to the dark side ... we've got cookies.
Similar question
AngularJS is more associated with the single page application paradigm, and as such, doesn't benefit much from server-side technologies that render markup. There is no technical reason that precludes you using them together, but in a practical sense, why would you?
An SPA retrieves the assets it needs (JS, CSS, and HTML views) and runs on its own, communicating back to services to send or retrieve data. So, a server-side technology is still necessary for providing those services (as well as other means such as authentication and the likes), but the rendering parts are largely irrelevant and not particularly useful because it's a duplication of efforts, except MVC does it on the server side and Angular does it on the client. If you're using Angular, you want it on the client for best results. You can make Angular post HTML forms and retrieve partial views from MVC actions, but you'd be missing out on the best and easiest features of Angular and making your life harder.
MVC is pretty flexible and you could use it to service calls from an SPA application. However, WebAPI is more finely tuned and a bit easier to use for such services.
I've written a number of AngularJS applications, including a couple that migrated from pre-existing WebForms and MVC applications, and the ASP.NET aspect evolves towards a platform for delivering the AngularJS app as the actual client, and for hosting the application layer the client communicates to via REST (using WebAPI). MVC is a fine framework, but it usually finds itself without a job in these sorts of applications.
The ASP.NET application becomes another layer to the infrastructure, where its responsibilities are limited to:
Host the dependency container.
Wire the business logic implementations into the container.
Set up asset bundles for JS and CSS.
Host WebAPI services.
Enforce security, perform logging and diagnostics.
Interfacing with application caches for performance.
Another great thing about an SPA is it can increase bandwidth of your team. One group can blast out the services while the other lays in the client app. Since you can easily stub or mock REST services, you could have a fully working client app on mock services and swap out for the real ones when they're done.
You do have to invest up front on Angular, but it pays off big. Since you are already familiar with MVC, you have a leg-up on some of the core concepts.
It depends on the project you are working on.
If angularJS is something new for you I would rather pick a small low risk/pressure project to get started and ensure you learn how to do things in the right way (I have seen many projects using Angularjs wrong because of pressure, deadlines... lack of time to learn it in a proper way, e.g. using JQuery or accesing the DOM inside the controllers, etc...).
If the project is a green field one, and you have got some experience on AngularJS, it makes sense to abandon ASP.net MVC and in the server side go for pure REST/WebAPI.
If it's an existing project, you can pick up a complex subset of functionality and build that page as a separate angularJS app (e.g. your app is composed of a big bunch of standard simple / medium complexity Razor based pages but you need and advanced editor / page, that could be the target piece to build with AngularJS).
You can use Angular framework for front end development i.e to construct views. It provides you a robust architecture and once you learn you will find it's advantages over Asp.net MVC's razor view engine. To fetch data you have to use WebAPIs and now ASP.Net MVC project support both WebAPI and MVC controllers out of the box. You can refer below link start with Angular and ASP.Net MVC application development.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
There are two frameworks currently available for developing UI components for angular applications. I have used both these frameworks in one of the angular projects that I worked.
Material
https://material.angular.io/
PrimeNG
https://www.primefaces.org/primeng/#/
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I'm making a board game in rails, and was considering using backbone.js (or a competing library) to handle the gameplay page and manage all of the models and the UI. Is it useful for something like this (over just making my own classes)? Or is it really only worth it for making a single page app? I've read a bit about the library, but I can't tell if its features will help simplify what i'm trying to do or if they are just overkill for a single page.
Yes, Backbone can handle this perfectly. 37signals, for example (founded by Rails's creator DHH) uses Backbone for the calendar, but not on the other pages.
I started in the web development world with PHP, and then Rails in the recent few years. Since then I've been doing all my web projects in Rails.
Recently there seems to be a movement towards making Rails as a pure RESTful backend service and using frontend framework such as Backbone.js for all frontend interaction. I'm wondering what's you guys' take on it? Will this be the eventual future?
As well, besides Backbone.js, what are some other alternatives for frontend framework for this purpose?
Also assuming that I will want to support both a desktop version and a mobile version of my app, would this be a proper route to take? So I'll have a single backend service with different frontend services? This way I don't need to manage all the views on Rails' side?
Thanks!
For Client-side frameworks, this article has a list of 20 of them with pro's and con's:
http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/
Here's the list:
Backbone.js
Knockout.js
Asana luna
Cappucino
Sproutcore
BatmanJS
corMVC
TrimJunction
pureMVC
jamal
choco
sammyjs
extJS
agilityJS
eyeballs
activejs
spinejs
qooxdoo
These are roughly all about creating client-side, ajax-based, javascript MVC frameworks.
If you're looking to start somewhere, then I recommend thinking about Client-Side Templates (...ates...ates...ates) (just the "V") to support a service-oriented architecture (many clients are supported by service-endpoints you create).
It's a new technique that involves modularizing your client-side code, bringing MVC to the client, and let business-logic live in the platform. A lot of Software-as-a-Service applications are leveraging them, and with the increasing sophisticated of javascript libraries and frameworks, as well as browser capabilities with HTML5, CSS3, etc. there's going to be an increasing sophistication in client-side presentation.
So learn it.
What are the benefits?
To paraphrase Linked In: for leveraging browser-caching, de-coupling your front-end client-side presentation, asynchronous load, progressive rendering (for some frameworks), performance, ajax-interaction, and more.
Several great frameworks include:
mustache
dust.js
handlebars
Google Closure Templates
Nun
Mu
kite
I highly recommend looking at Linked In's move away from JSP towards Client-Side Templates and why they choose dust.js in Linked In's front-end client-side templates throwdown for a comparison. They go into much greater detail, and research, as to why they changed their stack to support this (it involved using 3 server-side technologies), as well as their comparisons of all the frameworks they could find.
I did something like this a few years ago in .net. Is was not via proper .NET MVC and didn't use the new JS frameworks, but the principle was the same; server code returns JSON to javascript which builds the page and interactions etc.
The result was a lovely responsive website, but, maintenance was a nightmare. Be very careful to keep your JS code well organised.
Personally, I find it easier to maintain server code (in any language) than javascript so I wouldn't go down that route again.
(IMHO)
Fran
It is my opinion that contemporary web applications are moving towards this model of having RESTful back-end and all the view interactions coded in front-end. These free video tutorials from Joe Zim:
http://www.joezimjs.com/javascript/introduction-to-backbone-js-part-1-models-video-tutorial/
helped me understand backbone and how it can simplify templating and view renders.
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.