Question

We have developed and Enterprise app which is using following technologies:

  1. ASP.NET Web Forms
  2. AJAX
  3. jQueryValidationEngine - For validation
  4. jqGrid - For Data Grids
  5. jqTemplate - For HTML templating
  6. i18Next - For localization
  7. jEditable - For Inline Editing
  8. Several jQuery plugins (dateTime picker control /inettuts for Widgets / jQuery UI Autocomplete).

In the beginning we were very happy with all these plugins and stuff, but as the application kept growing, all the code became very messy (a lot of jQuery selectors / code on every page) and there is no proper pattern being followed for front-end development.
Now, we have decided to invest some time to revamp the application and clean up few things. We have done initial RnD and are planning to move on to AngularJS BUT we are not going to make it SPA (as it is an Enterprise application with some big data and security concerns as well). We just want to exclude all the above mentioned dependent libraries and use single AngularJS for all that and separate our HTML / CSS / Javascript (which will make it more maintainable).

Are we making the right decision? Moving to AngularJS is a good option or not? We should rather restrict developers to follow some parcitular pattern (e.g. module pattern) for front end development?
Please suggest the better option if you have relevant experience.

Thanks.

Was it helpful?

Solution

I work for a consulting company that is currently building a massive enterprise application using Angular.js, and I can unequivocally say that Angular is very well suited to the enterprise.

A rundown of our stack, and the size of our Angular application:

Server:
ASP.Net MVC
ASP.Net WebAPI

Client:
Angular.js
Kendo UI
Underscore.js

Angular Stats:
Controllers: 213
Services: 59
Directives: 130

Trying to cover every single technique we use would take too long, but I will give you several big areas that I believe have been a key to our success.

TypeScript

TypeScript has been a huge part of our success. Early on we were using vanilla JS, and relying on solid practices like modules and Require.js to keep things maintainable. However, as the team size grew, we began stepping on each others toes.

The move to TypeScript gave us the preprocessor type checks we needed where necessary. Since TypeScript is a super set of JavaScript, we were still able to write vanilla JS when necessary, but the added type information and environment tooling has been a huge productivity boost.

An added benefit is that TypeScript is based on ES6, so it helps us make our code forward compatible.

Hybrid SPA

Because most Enterprise applications have many many different areas, it wasn't realistic for us to try and shove it all into a SPA. However, we didn't want to do full page reloads for every screen either.

Our final solution was to do a full page refresh for main areas like Admin, Users, etc... and each of those areas would have it's own Angular Module and act like a SPA. We call this a Hybrid SPA, because it's like a bunch of little SPA's that form one cohesive whole.

Resource Management

Originally we were using Require.js, but we opted to go with the ASP.Net Bundler instead. This wasn't a knock against Require so much as us not wanting to fight against the stack we were working with.

The ASP.Net bundler works great for us and we also added a little bit of smarts to automatically build our individual Page bundles for us.

Security

In a lot of enterprise applications, security and user management tend to be pretty nuanced. We have some pretty complex security requirements, and initially working them into a SPA was a bit of a concern.

Obviously our back-end services are all locked down, but what about the front end?

The nice thing about Angular is it makes it extremely easy to augment with special behavior. In the end we ended up taking advantage of the resolve property on the $routeProvider to load in a user's privelages before the view is loaded in. The routes look something like this:

.when('/foo/bar', {
   templateUrl: '/users/view',
   controller: 'UsersCtrl',
   permissions: ['usersView','usersEdit'],
   resolve: checkUserPermissions
});

The resolve is actually added dynamically, but that deserves a whole blog post. The end result is that we can fail the route and take an action if the user doesn't have the appropriate permissions to view that area of the application.

Again, this is purely cosmetic as all the security checks are being done on the server, but it does keep the application nice and consistent to be able to show a "No Access" view if the user doesn't have permissions.

Conclusion

Angular.js is well suited for enterprise applications, and in fact will help you deliver an even better experience than you could with a more traditional web stack.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top