Engineering Complex Web Applications — 1

Designing large web application is a major challenge in an enterprise. Team size increases, features start to overload application, code quality and management become tougher day after day. So what could be a good design/prototype for your software in present time. What formula can solve your problem and development gets fasten over the time.. ?

Do not over-engineer your design with the hot new technologies rather than try the true ones.

Technologies are changing very fast. New fancy things are coming in market everyday but as we have experienced that no single technology can solve your design paradigm problem. You have to design your application framework in such a way that it can incorporate new concept in future like plug and play. Write your own abstractions but don’t over engineer it.

But before start something, Keep in mind following things:

  • Rewrites are Painful : Everything will need to change in future, so make it easy to change. Your architecture should support easy refactoring. A good design take so much iterations. If working on a significantly large app, remember to dedicate sufficient time to planning the underlying architecture that makes the most sense. It’s often more complex than we initially think.
  • Reduce Complexity, Opt Modularity :

“The more tied components are to each other, the less reusable they will be, and the more difficult it becomes to make changes to one without accidentally affecting another” — Rebecca Murphey.

A systems in which independent programs can work together. To build structure which tackle complexity by distributing it across themselves. Modules are an integral piece of any robust application’s architecture and typically help in keeping the units of code for a project both cleanly separated and organized

  • Less is more: Making generic components that do a lot of different things CAN be extremely useful when you look at the big, long-term picture. It just has to be done well and needs to be given the time to stabilize.
  • Design Patterns: Design patterns are quite a powerful approach to getting all of the developers in an organization or team on the same page when creating or maintaining solutions. If considering working on a pattern of your own, remember that although they may have a heavy initial cost in the planning and write-up phases, the value returned from that investment can be quite worth it. Always research thoroughly before working on new patterns however, as you may find it more beneficial to use or build on top of existing proven patterns than starting afresh.
  • Testing: Write code which are testable. Unit , Functional and E2E testing should be present.
  • Build Process : Enterprises apps are big, distributed in modules and tied in a well defined system but in the end you need a single application binary to run your application.
  • Automation: It could be your CI & CD tasks which fasten your development and facilitate a productive environment among your team. Tasks for development, build, test, deploy and watch.
  • Environments: There should be a functionality for switching different type on environment based on configuration. In development mode create the services which increase your efficiency.
  • Documentation: Good documentation is key to the success of any project. Making documentation accessible enables people to learn about a project; making it easy to update ensures that documentation stays relevant.
  • Changelog: It helps other teams/ Developers to know about the changes and work. All notable changes to the project will be documented in this file.
Software design is a prediction of the future. You make those parts flexible where you will need it. You make other parts simple and opinionated where you need no flexibility.

Five Parts of a Standard Business Process:

Ideally your app should be build to keep in mind the business process and problem which you are trying to solve. Let’s discuss standard points of a business process and how they should incorporate in your application :

  • Authentication/ Permissions : Typically every app requires authentication, an entry point with different features. Create a separate authentication system for each feature. An abstraction that separates the authentication system from the actual feature is really useful.
  • Setup Contextual Data: Controllers, Factory. Your controllers should be thin and contains only the business logic.
  • Validate the Process: Validator, Filters, Models, Services. It should have abstractions which you can in your controllers. Keep the complex part here.
  • Do the Process: API Calls, A separate mid tiers which maintains pluggability.
  • Trigger Side Effect: Notification, Logging services and other services.

A simple app

In an general application, you have an API for back end interaction, but what would happen if API’s response gets a change in future, keys become more or less nested, or someone changes the whole response. If you do not have a mediator pattern which handles above things, your development will become very slow, and suddenly you are just left tweaking here and there in your code fixing the new response. Some time later, business requirement changes more, and you have to reduce the response in more complex nature, and surprisingly you have to do it with more than dozen API endpoints. You start to write logic in your controllers to handle these logic, but ideally, your controllers should be thin and just contains the data which are only relevant to view, not the complex transformations.

Our solution — $http wrapper with models and translators

We have written an API wrapper for http requests which also help us to call the API in more efficient way:

api.get(url).then (function(response) {}).catch(function (error){});
// instead of longer $http method.
// For other http methods, Please refer to the attached code below.

We define the model which help in data validation and integrity. Translators help us to keep the same response of API everywhere. Also if I am using an API which has same response similar to another API, I can use the same model of data.If API response changes in future, I’ll just change the translator at single place

At Innovaccer

We are at Innovaccer Inc. is using AngularJS. When we started to build our product Datashop, there were many options to opt as ReactJS, Angular2 etc but we chose AngularJS. reasons are as following:

Why did we chose AngularJS ?

AngularJS has everything we need. MVC, Simple data bindings, dependency injection, routing, animations, view orchestration and much more.

To Be Continued

It’s the 1st part of this series. In upcoming posts, we’ll discuss about file level architecture, tools to use and patterns which can you help in building an enterprise app.

About the Author

Ayush Sharma is front end developer in Innovaccer and works in Product team. He is much passionate about software development, solving problems and design patterns.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.