The Question
The “hectic everyday life” cliché haunts us everywhere: television gurus recommend observing the sky daily to prevent depression and bad fortune, and celebrities prescribe hackneyed and eccentric recipes for stress relief and endless spiritual relaxation.
We do not know whether the “hectic everyday life” is such a dramatic problem, but one thing is certain: in the world of software development, the rhythm of evolution is deadly. So far, in Global Consulting , we are coping by continually changing our core corporate information systems . We try to do it in line with global trends, the needs of our customers, with the available building blocks and last, but not least our architectural principles. As every influencer on Instagram will confirm, following principles is an important job.
So, as part of a natural process, about a year and a half ago, it was time to once again answer an existential question:
How do we update the technological stack we use to develop web user interfaces? At that point, Global Consulting’s information systems, where the user interface was built as a web application, were mainly based on ASP.NET MVC and its accompanying technologies, or something similar to the following technology bundle:
A bundle that has served well not only to Global Consulting and our customers, but also many more people and companies around the world, despite the insignificant changes it has undergone in the past 5 years.
The goals we have set
Our goal was to have a set of software tools and technologies to create web-based applications to “multitask” on several levels:
To meet the increased customer requirements
For better or worse, clients are getting more and more demanding. And we adapt by making the user experience richer and screen scenarios implemented with HTML5 and JavaScript more complex. Tools and technologies should look good on screens with different resolutions. Be more secure than ever. They should, unlike people, work 24/7 and respond efficiently to peaks in user activity activity.
Be able to deploy in virtual and cloud infrastructure
We expect web applications to work both in our customers’ IT infrastructure and in cloud environments. No, we do not mean an environment where there is no sun and black clouds foreshadow a hail, but a private cloud built with virtualization tools or public cloud service. The technologies used to build our web applications need to be optimized for high-performance work in an environment with limited and competitive resources.
Our requirements do not end here. We also want from web based applications:
The platform should not be explicitly dependent on Windows
Microsoft Windows is great, but it is important for us that Global Web Applications can also work on Linux-based servers to take advantage of advanced deployment schemes for our applications, such as Docker Containers.
Make the most of our team’s existing know-how
Not to brag excessively, but our team has more than 20 years of experience in engineering information systems, putting them into operation, maintaining them and further developing them.
Taking this into consideration, it would have been a rave decision to ignore this experience and start learning from scratch. The new technology tools we were going to use had to make the most of our experience and allow a relatively smooth continuation of maintenance and development of existing Global Consulting systems.
The solution
In our decision there was an easy part about which we had few worries, and one that was accompanied by doubts, some head scratching, and curiosity about what would “pop out of the hat.” The new web applications in Global Consulting (and newer versions of existing applications) to date are implemented using the following software tools:
The easy part…
…was the switch to ASP.NET Core.
Our experience for the past year and a half has shown that the transition is practically unimpeded. The process of work went smoothly, and we did not find hidden traps along the way. Considering the experience we have gained so far with .NET, we needed just a little bit of “upgrading” so we could make full use of the .NET Core features and benefits. From a purely programmer point of view, there is no difference whether the C # code is referencing to .NET Core or the full .NET Framework.
There are some software design templates, where the utilization is even easier to achieve with ASP.NET Core compared to traditional ASP.NET – such as the use of Onion Multilayer Architecture, Dependency Injection, and more. This is because these design templates are embedded at the architectural level in the new .NET version.
ASP.NET Core architecture allows the app to be targeted for compiling and running both to the .NET Core and the full .NET Framework.
In case you’ve already lost the thread, let’s note what we have covered in a summary:
- The transition to ASP.NET Core / .NET Core allowed us to achieve the goals we had set in answering the question a year and a half ago. If you have forgotten what the question is, we asked how to update the technological pyramid we use to develop web user interfaces
- The transition is painless, routine and too boring to give it more space in a blog post.
The interesting part…
… came from abandoning the traditional web applications where almost all presentation logic (user interface) that is generated by HTML and JavaScript is executed on the web server along with the business logic. Virtually any significant user action generates a full query to the web server where it is handled and returns an HTML result to the client, which more often causes a full load of the entire web page in the browser. Yes, there may be separate user interface snippets that enrich the user experience and work entirely in the browser with jQuery and AJAX queries. But they are few or very isolated, their use is fragmented, and at a time when these fragments become too many, the efforts to maintain and develop them become unreasonably large.
From these traditional web applications we switched to…
…Single Page Applications (SPAs), where presentation logic is fully executed in the browser, and the business logic is running on the web server. This is a one-step advance in the web application implementation of one of the basic principles of software engineering – Separation of Concerns.
Typically, in SPA applications, there is a static home page (index.html), from which all the JavaScript and CSS resources required for the entire web application are loaded in the client browser. In the process, the communication between the browser’s SPA application and the web server’s business logic is performed through JSON Web API queries.
In these web applications, a rich user experience is set by default. It is integrated into the framework used to develop the application – all user elements on the page (HTML tags and CSS) are created and managed dynamically by JavaScript by manipulating the DOM in the browser. It is good to note that the efforts for maintenance and development of the rich user interface are fewer than the traditional approach.
Angular? What is that?
To date, when talking about developing SPA web applications, React, Angular, and VueJS are most commonly referred to. This topic can become a scandal with apocalyptic proportions among the more passionate supporters of one or the other technology. We would even say that Angular VS React VS Vue JS is something like the modern IT version of the feud between Montecchi against Capulet … Or Arsenal against Tottenham if you like that better. You can come across some interesting memes and pictures on the topic online 😊
We will not participate in this dispute, at least not in this blog post.
Here we will only share our reasoning behind choosing Angular.
Angular is a complete SPA development framework
It includes everything (or almost everything) that you need to develop complete SPA web applications – MVC engine, HTTP Client, Routing, strict and clearly defined system for the use of modules, own UI library – Angular Material, Angular Flex Layout, own set of client tools for use by developers, etc.
Yes, compared to other technologies, it may be a bit “heavier”, but our goal is not to carry a backpack in the mountains, but to develop, enhance and support corporate web applications (relatively large and inherently “heavy” web apps). In this sense, this is the right tool for us.
Angular and famous software design templates
Angular shares many of the software design templates known to developers with ASP.NET MVC / ASP.NET Core background and other object-oriented frameworks. For example:
The already mentioned Model-View-Controller. For each Angular component, we have a split between an HTML template and component program code written in TypeScript and separate classes with Data models also described with TypeScript.
TypeScript
TypeScript is a very adequate way to put order familiar from object-oriented languages into JavaScript! While it is possible that things do not look that way for people who do not have backgrounds in C # or Java 😊.
In Angular, the use of software services, dependency injection, modules is primarily covered.
Angular uses the fresh RxJS library to achieve a high level of reactivity in the interaction between the components and the dynamic exchange of information between them.
Angular – Google technology and not just that …
Behind Angular, behind the entire framework, with all its core components, is one of today’s giants in the software industry, Google, with a clear position to maintain and develop the technology. This is an important factor when selecting a tool for the implementation of a corporate software system, which in turn should also be supported and developed over a relatively long period of time.
Other than that another modern software giant, Microsoft, has shown a clear commitment to support the Angular Framework in its own technologies. Both in TypeScript and in the ability to integrate Angular SPA into the ASP.NET Core Technology Stack.
In other words, with Angular we are set on two fronts, both of which are reliable enough.
Angular is a dogmatic (opinionated) framework
Dogmatic, because you can not do whatever you want. When it comes to the Angular Framework, “there’s only one version of the truth, and it is has been created by Google” That is, there is a clear set of rules and good practices that are defined by the developer of the framework, and when programmers develop using Angular they have to follow them. Full stop. The end. Point finale.
If you do not like this approach or you do not like the specific rules and practices defined by Google, Angular is probably not your SPA framework of preference and you have to look for something else to design your saunas (again “ha-ha” ).
The documentation of the entire framework is very good, extensive, supported in one place and updated in a timely manner with changes to the versions of the framework itself.
All important factors when you have a team of developers who have to work on the support and development of several corporate information systems and who are required to follow a unified set of practices in software development and maintenance.
Challenges
In retrospect, the only major challenge Global Consulting encountered in our transition to the use of Angular was the initial familiarization of the team with the framework. Each of us, who had not encountered SPA libraries in practice so far, had to take the time to complete Angular training. Fortunately, there are enough resources on the internet in the form of courses, and as mentioned above, the Angular documentation is quite complete and good. And as we are capable, clever and modest professionals, things have happened smoothly and without any particular catastrophic consequences.