I've been asked to design a web application which has multiple tiers. It will have a client aspect (rendering information for the user), a server aspect (web api serving data) and a database behind it all.
I'm comfortable choosing the technology stack for the web api and database. It will either be a choice of Microsoft Web Api with SQL backend OR nodeJS with MySQL.
For me the challenge (and the prompt for this post), is choosing the correct frameworks for the client side.
I've used AngularJS quite a few times and its fairly straightforward for me to go down this road again but the project in question will have a lifespan of 5 years and I'm worried that choosing Angular 1.x, having been out since 2009 and due to be replaced by Angular 2.0, which is completely different, is a bad investment.
I will most likely use bootstrap for the base css side.
So out of the plethora of frameworks out there - what would be the strongest for client side data driven web applications?
Some obvious choices being:
Ember
Backbone
React
Knockout
Meteor
Polymer
Ractive
Durandal
Angular 2.0?
To name but a few! Which is best and why? I'm not looking to avail of server side capabilities of the likes of React. Just data (read/write) from the client side.
From your list, I tried quite a few: angular (1), backbone, ractive. I had a look at a few others but didn't investigated them further.
From my experience, Ractive was the winner. I still stick to it and am happy with it.
My first experience was with backbone. It looked pretty simple and what I needed. However, when starting to do non-trivial stuff, I ended up pretty quickly in a dead end. My view and data sometimes went out-of-sync and I didn't know how I could perform some other stuff.
My second experience was Angular. With all the hype, I thought it must be great. But getting into it was hard. It's just ...complex. As soon as I wanted to build a non-trivial directive, I was like "wtf? wtf!". The second show-stopper was the debugging ability. At some point, everything broke and my debug console just threw a strange stack trace, giving me absolutely no clue what might be the problem. ...a long time after I discovered by chance that I had placed a # instead of a # or something like this. Also, one thing I disliked from the start is that it forces you to do everything angular-ly, which doesn't always play well with other libs.
My last experience is Ractive and I write production code with it since a year or so. I'm very happy with it. Sure, it's no silver bullet and has some quirks. But overall, it's a lib where you can quickly get started with, which can do a lot, and that doesn't get in your way. The mainainers are also supprisingly responsive.
...but if you're experienced with angular, perhaps it's better to continue that way.
That's my 2 cents.
Related
Inspired by John Papa's video at Pluralsight, I started learning SPA. It appears pretty interesting. However, before I fully jump in, I'd like to clarify some of my questions.
From what I learnt, SPA is a lean server, fat client app. I think this should work well for small apps like what John Para demonstrated. Does it scale? How big it can be? Anybody has experience with this?
In SPA, you seem to code all the business logic in JavaScript. Is this a good idea at all? How do you hide the business "secret"?
With my background primarily in C#/WPF/.NET, moving to JavaScript seems to be very difficult (well, I learnt a little JavaScript more than 10 years ago - I hated it and never touched it again). With my limited knowledge, I ran into several problems. Debugging JavaScript seems to be a nightmare to me. The highly praised component Breezejs seems to be still in its early stage (e.g. it doesn't support UOW, doesn't support CascadeDelete, doesn't support enums). So, I'm wondering this is good time to jump in?
Directly to your questions:
Since the server logic is thin you can use some kind of cloud services and they scale pretty good. The most of the logic will be handled by the browsers of your users.
You should be careful if you depend on client. HTTP protocol can be easily manipulated. Don't forget that you should always do the validation logic both on client and server side! Also the "hidden" validation and other "secret" logic should be located only on the server.
Debugging JavaScript isn't so bad at all. You can use the built-in tools (Inspect element in Chrome and FireBug in Firefox, etc.) Also there are a lot of useful third party tools that will help you with the debugging.
If you start a new project just for your own use then I advice you to try the SPA approach. If you are writing production code you should become an expert in this area and then try to use these technologies.
Regarding UoW, take a look at the TempHire sample. It demonstrates using the UoW pattern on the client as well as the server.
https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire
I believe SPA's provide a better framework for Business Intensive Applications as well as simpler application workflows such as that of Facebook. I have worked with Multi Page Applications for banking application with complex workflows and it get daunting to handle every thing and still keep up the application performance.
But I do think Knockout Alone wont be able to handle large applications as it is to connected in nature. I would recommend something like Backbone Marionete or Angular for that venture.
I am building a framework for large scale SPA development for the opensource community so I do believe it is the right direction.
Interested parties can go to my demo page at http:\saqibshakil.github.io I have demonstrated some of my work there.
i have been looking into it for months. My conclusion is to use Knockout with a light path.js or sammy.js for your url. I use json with a standard Visual Studio MVC ( which can return Json) as the backend.
I am still not done with the project but so far so good. It's lightning fast, elequent and lightweight.
Stay away from the frameworks. Get a look at the standard libraries: how they are written; You can learn a lot of JavaScript that way. Finally debug with chrome or explorer developer tools.
Good luck
I have been working with Django as backend and using jQuery for the front end. Now with web pages been so dynamic javascript has started to get more and more complicated and I feel the need of a better, more organized structure there.
I started reading about Backone and it just feels like a backend approach to frontend (since it's an MVC framework). This would make my code more structured but some functionality seems to be overlapping (i.e. models, urls, ...)
I have also read about using backbone with tastypie and django to implement a RESTful environment here. This is very cool since the app would be ready for phone development too.
now my question is how good or bad this architecture is? what pros and cons it has and if there is a simpler way of achieving a DRY client-side code (maybe following some set of rules/good practices would do)
Any personal experience is more than welcome :)
I was in the same situation a few months as you are right now. Of course the number of tutorials, example projects or documentation is very low and most of them very old BUT one tutorial that I came across fishing night and day for help was this http://joshbohde.com/blog/backbonejs-and-django, was and still is at the moment the only one (that I could find) that was reusing Backbone templates into Django templates with the help of some custom template tags.
My personal experience with Django + Backbone was a good one but only lasted a few months, after that I moved to NodeJS + Backbone. I can only say that even though Django/Python is a fast programming language adding Backbone to it will be even faster (user experience) when you think you will only send (to the REST server and back) small pieces of data and not reloading the entire page on every little detail that has changed.
I find myself in a bit of a conundrum. I'm building a new, modern, web-based application and not only do I have to pick a technology, I have to pick an architecture. I think it is fair to say that these days its a tough choice because we have more options than we did even 5 years ago.
First things first, I've made the decision that Scala will be the server-side language. I have my reasons, and this is not a Scala versus XYZ post - that choice has been made. I've also sucummed to the fact that we're on the web, in the cloud, so I'm not even going to try and get away from Javascript. Maybe I will with CoffeeScript, but I will be writing Browser-hosted code.
Now, assuming Scala, most people would probably jump to either Play! or Lift. Probably Play! given it's endorsement from Typesafe, but I think I have another more important question that needs answering first. What's the architecture? If I want a very rich client, do I really need more than a simple stateless service layer based on the fact that we'll have a tonne of Javascript anyway? I'm not sure it'll be a single-page webapp, but is something like BlueEyes potentially the right choice? Lift and Play! are much more heavyweight in that they take on much more responsibility. They generate the HTML and for these frameworks, the browser is pretty dumb. Things like routing, validation, Ajax and Comet support are all server-side concerns. Because the browser is more capable today, rich, interactive features are normally implemented by generating and injecting Javascript from the server.
My question boils down to this. Do I go with a traditional Lift/Play! framework where the server takes on both the client and server responsibility or do I go with a rich client + REST-style service layer where the client takes a more prominent role in the application? An architecture where the client deals with routing, validation, binding, etc. I'm seeing frameworks like KnockOut.js, Sammy.js, Sproutcore, Backbone.js,... I'm not going to list them all but suffice to say that they all take on some of these framework features from a client-side perspective.
If I choose Play!, am I giving up some of that rich UI? What about situations where I want to provide service API's for integration/mashup/mobile purposes? How would Play! help me here? Clearly BlueEyes plays well here. I think I need a service layer regardless.
If I choose BlueEyes, what does my client code look like? How many of these Javascript-based frameworks do I need to give me what I need? I still want most of my business-logic in my service layer, but routing, binding.. all that UI stuff would be a concern of the client.
I'm not sure there is a right or wrong answer, but I think this community can probably point me in the right direction.
I also posted this to my blog at http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-it-u-45228
If all you want is a REST API on the backend, then Lift, Play! or Blueye will work just fine. But I'll just point the advantages of using Lift.
It is not true that Lift tries to impose doing both, the front and back end. We support REST-only use of Lift and it is encourage for the right project.
While Lift comes with jQuery and blueprint, you can use any javascript library and css framework, there is currently a lot of people on the mailing list showing how they use twitter boostrap with Lift. See this Lift module that helps integrating Bootstrap.
With Lift, you can start stateless, and if along the way you find that your needs change, you can go statefull. You can even mix and match them on the same application.
Want some modern looking UI? Lift's comet support is one, if not the best one, out there. Very simple to use, proven and tested on many browsers/workloads. I have written several posts showcasing Lift's comet support.
If you decide to use Lift for both, front and back end, you get for free an application that is secured by default, no need to worry about xss, xsrf, or many of the top 10 OWASP security vulnerabilities.
Need commercial support, there is a growing list here
Need training? There is a Basic training coming up in London and the founder of Lift also provides other training sessions.
There are several books about Lift available. Lift in Action , Simply Lift and Exploring Lift
There is a very active community ready to help.
Who uses Lift? Just to name a few: Foursquare , OpenStudy , The Guardian UK, StackMob and many more.
Well, I should stop here, but in short, Lift is an awesome framework that has a lot to offer, you take as much or as little as you need.
The Play 2.0 Beta contains a sample application that is exactly what you are looking for (ZenContacts).
Its server side is just a bunch of restful interfaces while its client side leverages coffeescript etc. to build a rich user interface.
As far as I know, both Play! and Lift can be used as basically a "back end", and you can use HTML5+CSS+JS as your "front end"; they do not necessarily restrict your ability to create the front end you desire, so rejecting them for that reason would be silly. Notice things like knockout.js advertise that they "work with any web framework". However, it might be true that they are more "heavyweight" than what you need.
I have never heard of BlueEyes before, but it appears to be aimed at a particular kind of use case. If that fits your bill, then it will probably be the most streamlined solution to your problem.
But if this is something you plan to actually put on the web, "routing, validation, binding, etc" practically need to be handled by the back end; I simply cannot imagine any of these things (securely) being handled by code that runs in the client's browser. Also, if your users choose to disable JavaScript, your website would be completely unusable.
If I choose Play!, am I giving up some of that rich UI?
What exactly you mean by rich UI? more javascript on the frontend?
If you consider - HTML5+CSS3+jQuery as a rich UI - then these work very well with any "backend" (Lift/Play).
The other thing which you might want to consider is the maturity of the framework.
Like you mentioned Play 2.0 supports Scala natively, has endorsement of Typesafe and is rapidly being adopted.
Plus you can expose RESTful services easily and consume then in the frontend (one of your requirement).
Leaning towards HTML5+CSS3+jQuery + Play 2.0 :)
just my thoughts..
What's the architecture?
Play! strongly encourages your server to use an MVC architecture, creating packages in a standard pattern:
app/
controllers/
Application.scala
views/
Application/
index.scala.html
models/
public/
images/
stylesheets/
javascripts/
This makes it easier to follow the architecture than to break it.
I can't speak for either Lift or BlueEyes, but afaik neither of them encourage an architecture as strongly.
Definately have a look at http://twitter.github.com/finagle before making up yiir mind. Finagle can take care of most of your backend stuff. It's desinged around a very flexible architecture that separates concerns cleverly using filters.
I have looked at apache click, wicket, a little bit Lift (feel a bit like wicket), and then play 1.2.4. So far so good with Play. Really beautiful approach to the web development. Keep up the nice work, play! team.
I've been developing in the .NET stack for the past five years and with the latest release of MVC3 and .NET 4.0 I feel like the direction I thought things were headed in were further confirmed.
With the innovative steps the client community has in such a short period of time, it seems like the best in class apps have a UX controlled by a majority of client events. For example, facebook.com, stackoverflow.com, google, www.ponched.com :), etc. When I say client events I am not talking about a server side control wrapped in an UpdatePanel to mask the postback. I am talking about doing all events and screen transitions on the client and use full postbacks only when really necessary. That's not to say things like .NET aren't essential tools to help control security, initial page load, routing, middle tier, etc.
I understand when working on a simple application or under aggressive time constraints using the controls and functionality provided by default by .NET (or other web dev frameworks) isn't practical if the project calls for it but it seems like the developers that can set themselves apart are the ones you can get into the trenches of Javascript/jQuery and provide seamless applications that have limited involvement from the (web) server. As developers we may not think our users are getting more sophisticated because of the big name web applications they are using on the reg but I am inclined to think they are.
I am curious if anyone shares this view or if they have another take on this? Some post lunch thoughts I figured I'd fire out there and see what I got back.
I share this view. We've ironically moving away from thin client and back to thick client, although this time around everything on the client is distributed on-demand via the server so obviously the maintenance overhead is nothing like it used to be.
Rich client-side functionality not only gives you fluid, responsive, interactive apps, but has the significant advantage for large scale sites and applications of being able to palm off a large chunk of processing resources to client browsers rather than having to process everything at their end. Where tens or hundreds of millions of users are involved, this amounts to a very large saving.
I could say more on the matter but time is short. I'm sure there will be other views (assuming the question isn't closed for being subjective).
The point about the developers who set themselves apart is definitely on target. Developers who understand the underlying technologies and can produce customized solutions for their clients are indeed set apart from developers who can drag and drop framework tools and wire up something that works well enough.
Focusing on web development in this discussion, it's vitally important that developers understand the key technologies in play. I can't count how many times I've encountered "web developers" (primarily in the Microsoft stack, since that's where I primarily work) who patently refuse to learn JavaScript/HTML/CSS simply because they feel that the tooling available to them in Visual Studio does the job just fine.
In many cases it does, but not in all cases. And being able to address the cases where it doesn't is what puts a developer above the rest. Something as simple as exposing a small RESTful JSON API and using AJAX calls to fetch just the necessary data instead of POSTing an entire page and re-processing the entire response means a lot to the overall user experience. Both get the job done, but one is considerably more impressive to the users than the other.
Frameworks are great when what you want to do is fully encapsulated in the feature set of the framework. But when you need to grow beyond the framework, it ends up being limiting. That's where a deeper understanding of the underlying technologies would allow a developer to grow outside of the framework tooling and produce a complete solution to the client.
You are right in saying that modern web development involves technologies like jQuery (or similar libraries) and JavaScript in general.
Full page reloads are old fashion and Ajax approach is the way to go, just don't think that the web server is less used or involved than before, it still responds to the ajax calls simply it does it asynchronously :)
MVC does not support any post back actually, because there are no web forms and there is not the same model of page life cycle.
I am facing a decision about the web application architecture I am going to work on.
We are a small team and actually I will work on it alone (everybody work on something else).
This application will consist of front-end build on the ExtJS library
and it will use the model "load page, build GUI and never refresh".
On the web "desktop" there will be a lot of data windows, map views (using openlayers + GeoExt) and other stuff.
GUI should be flexible and allow every user to modify (and persist) the layout to fit his/her needs.
It should be possible to divide the application into modules / parts / ... and then let users in specific groups use only the specific modules. In other words, each group of users
can have different GUI available on the web "desktop".
Questions are:
First of all, is this approach good?
There will be a lot of AJAX calls from clients,
may be this could be a problem.
How to handle code complexity on client side?
So far I have decided to use dojo.require / dojo.provide feature and divide the client side code into modules
(for production they will be put together using dojo build system)
I am thinking about to use kind of IoC container on client side, but not sure which one yet.
It is very likely that I will write one for myself, it should not be difficult in dynamic language like JavaScript.
How to handle AJAX calls on server ?
Should I use WCF on server side ? Or just ordinary ashx handler ?
How to handle code complexity on server side ?
I want to use Spring.NET. May be this approach could help with modularity problem.
Data access - here I am pretty sure what to use:
For DAL classes I will use nHibernate. Then I compose them with business classes using Spring.NET.
I would really appreciate some advice about which way to go.
I know about a lot of technologies, but I have used only little part of it.
I don't have time to explore all of them and be fine with the decision.
We do this type of single page interface where I work on a pretty large scale for our clients. (Our site is not an internet site)
This seems to work pretty well for us. The more js you have the more difficult it gets to maintain, so have as many automated js tests as you can and try to break up your js logic in an mvc fashion. 4.0 is supposed to make this much easier.
Ext 4.0 has this built in if you are trying to limit the code you bring down. If you have the same users day after day, then I think it would be best to just bring all the source down (compressed and minified) and cache it.
We've found asmx to work really well. I have nothing against wcf, but last I looked it seemed like more trouble than it was worth. I know they have made many improvements recently. asmx just works though (with a few request header changes and managing the "d." on the client side).
Our Server side data access layer is pretty complex, but the interface for the ajax calls is pretty simple. You have not really given enough info to answer this part. I would start as simple as possible and refactor often.
We are also using nHibernate. Works fine for us. We have built a DDD model around it. It can take a lot of work to get that right though (not sure if we have it right after months of working at it).
If I were you I'd start with just extjs, your web service technology, and nHibernte.
I would recommend ASP.NET MVC 3 with Razor instead of a lot Javascript and calls to Service you can just do ajax calls to an Action in a Controller and that will let you have more maintainable code and use a IoC like Ninject. EF instead of NHibernate.
But it's your decision.
I would look into using a tool like Google Closure Compiler, especially if you're dealing with a very large project. I don't have too much experience with ExtJS, but large projects in JavaScript are hard and something like Closure Compiler tends to make it easier.