Delphi-PRAXiS - A new problem, a new stack

https://4.bp.blogspot.com/-L7dXhDGMx...Delphi2010.jpg

Time to Rewrite

In the past year, my employer decided to rewrite our Internal Application. It's not something we took lightly, the current Delphi Application is over 5 Million lines of code. So as we rewrite portions of that existing application we will need to maintain our existing Delphi application so I will continue to use Delphi for at least 4-5 more years. Our system was released in 1999 as a Y2K project. Most of the original code was had the business rules right in button events, and a majority of that still exists. With my employer, it is unheard of to have an application survive 20 years, and it will most likely be 25 years old when we turn it off. It says a lot about our staff and Delphi.

User Devices are always changing

However, I have always believed we should use the right tools for the job at hand. Our infrastructure is greatly changing, we now have a few telecommuters, with a push to support more. This is not friendly to our existing VCL Client Server Application. We have a mixed environment of Desktop PC, Macs, Tablets and have to be prepared to support the ever-changing device form factors. Our user's desktops are locked down with no administrative rights. Implementing Continuous Deployment with a desktop application has been increasing more difficult to manage.

We decided it was best to create a browser-based application. That is really not something Delphi is a market leader in so a change was in order. Having now spent several months of development using our new stack I am very pleased with this decision.
New Development Stack

Front end

https://1.bp.blogspot.com/-5x13fkHic...r_logo.svg.png

We are using

Angular 7+ with strict compiler settings on the

TypeScript compiler. This Angular CLI provided a huge selling point, it provided much of the front end stack without having to build it up. Angular provided a component model and TypeScript syntax that reminds me of Delphi helped with the learning curve on the transition.

We looked at the ever changing component lanscape with Angular. We spent a few weeks and decided to write own library that provides a facade around the

PrimeNg Controls. This allows a majority of our front end to not care about the underlying library, if control is deprecated or problematic we can swap it out without impacting the rest of the application.

The browser world is always changing, It's a major moving target, things like

web assembly may really change the landscape in this space. As such it's critical to avoid tightly coupling the various parts of our application. We are using Visual Studio Code as the editor of all our front end work and I highly recommend it.

Back end

https://3.bp.blogspot.com/-9XOg4SGmG...sharp_Logo.png

The backend is a series of

REST endpoints written using

C# and ASP.NET Web API. We have no user-facing ASP.NET pages. We now also provide a real-time client to client communication channel implement

SignalR, which has increased our ability for our users to collaborate in our application.

Our data layers are abstracted and loosely coupled to our business rules which has greatly enhanced our ability to unit test, and we chose

XUnit to help us with that. Which has in turn increase our quality.

We are using

Entity Framework to managed our database access, which came with a bit of a learning curve as someone who has used SQL for some many years. But now after using

LINQ, I have found it really easy to use and so far as produced performant access to our data.

We are using Visual Studio 2017 Professional for our back end code, and we will eventually be upgrading to Visual Studio 2019 which was released today.