Proxy Routing in Angular 4 Applications

This blog intends to deal and simplify routing in Angular 4 applications in both development and production environment. While working on routing in Angular 4 applications, we often face some of the following challenges:

• Finding a solution to the problem of cross-origin issues in Angular development environment
• Separating routing configurations and APIs servers URLs from the code, making the application more robust and maintainable
• Finding a generic solution where frequent changing of API URLs (due to deployment on different servers, let’s say for the purpose of load balancing) do not force you to modify and change the code
• Servers where the APIs deployed do not appear in your code at all

Why Angular 2

Early this year, I began on a self-righteous (but approved, of course 😉 ) journey to make things right for my project — to break all shackles and limitations that the team faces in working with older technologies, methodologies and guidelines. When I started off, my aim was to make as minimal-but-essential changes to the system as possible, keeping in mind that my project is a live one, having at least 100 MegaBytes of code, with around 16 developers contributed to this application — in batches, of course — in the past 8 years, each having their own signature style of coding. Needless to say, there were more than a few tasks for research in this journey of mine.

One such, important analysis was to decide what UI methodology should the team adopt going forward. This blog post will focus on the analyses and decision-making process that made it happen and finally helped me decide on Angular 2.

Getting started with TypeScript in AngularJS application

Introduction

AngularJS is an undisputed champion among all the front end web development frameworks, well I am no expert to say that since honestly I have not worked much with other popular libraries like Knockout, backbone, amberJS etc. but for last few months I have been exploring the AngularJS and I am loving it.