I wrote the original Nortridge Loan System (NLS). I’ve been coding for decades. Part of my job today is to meet with our customers and prospects to help them understand how our software works and how we can help to solve their business issues. I get the same questions and comments over and over again. Why is NLS written in C++? Aren’t browser applications and NoSQL the future? Are RESTful APIs or SOAP APIs better? Is it best to structure data in JSON or XML?
Listen to the podcast
Greg is a guest in an episode of the ConsumerFi Podcast, where he talks about the technology Holy Wars. Listen to it below and subcribe.
For the most part, everything is based on personal preferences. There are technical differences that make one technology better for a given task at hand, but the bottom line is we all want software that helps us be more productive. We want to automate whatever we can so we can be more efficient. The technology itself is only important for technology’s sake. There are pros and cons to everything, but honestly, it’s all the same thing – you’re just doing it different ways.
Often these discussions become arguments. People take sides. But at the end of the day, NLS is a business app powering hundreds of lenders of all sizes, and its primary job is making lenders more efficient at what they do.
Here’s my take on several of these technology questions.
1. Why C++?
C++ has been around for more than 30 years. It was created back when computers had limited memory space and programmers needed an efficient language that would work with the hardware limitations. One of the biggest complaints about C++ is that it’s tough to learn compared to Java or C#, but for our customers, learning the language isn’t that important. That’s our job.
C++ is a popular and very robust and expressive language. It’s used to write enterprise applications, for example, Microsoft Windows, Office, SQL Server, and Oracle RDBMS. C++ is also used to write browsers too, including Chrome, Firefox, and Safari. Facebook mobile apps and back-end processes also use C++.
C++ is also portable, in that, we can call those base libraries that we have built over the last 20 years from any other programming language. The last thing developers want to do is to re-write existing code. And C++ is fast! When high performance is needed, C++ is usually what you will see being used.
It might seem like an older programming language, but it’s a proven technology that often outperforms its competition. In fact, C++ has seen a resurgence growing the most in 2020, and it’s in the No. 4 spot in the rankings of overall programming applications used, helped in part by the release of C++20. C++/C/C# all continue to sit in the top 10 development languages. C++ is as relevant today as it’s ever been, which is why programmers continue to choose it over other options.
2. Browser App vs. Desktop App
This is another situation where people take sides. If someone loves browsers, they’ll want everything in a browser because you can access it from a computer, phone, or tablet. IT often pushes for browser only, and I understand why. Browser apps can be easier to deploy to end users, and they’re also easier to maintain since it is generally a single point of install.
I will admit that I love browser apps. But I will qualify that statement with the caveat – I do not like all apps in a browser. The example I often use is this: Microsoft has a desktop app, a browser app, an iOS app and an Android app of their popular Outlook program. While the browser version is handy, the desktop app is much more productive to work in throughout the day. I use the Outlook desktop app the most, followed by the iOS app on my iPhone, and sometimes use the browser app if I am on a computer that is not mine. One of the largest benefits of browsers apps is how easy it is to deploy to thousands or tens of thousands of end users.
At Nortridge, we have done surveys of our customer base, and the results show that around 35% of our users would like to work predominately in a browser. But a majority still want to work in a desktop app. This is why we continue to build on the desktop app. That said, we are releasing a browser version that will work in in conjunction with the desktop app to accommodate the customers who want the deployment of a lightweight interface.
3. REST APIs with JSON vs. SOAP APIs with XML
First, let’s be clear on what these terms mean. SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are simply two different ways to access web services. JSON (JavaScript Object Notation) and XML (Extensible Markup Language) are the ways data is structured when being sent or received from an API. JSON is a lightweight data-interchange format based on the JavaScript programming language, while XML was designed mainly to carry data, but can also display data since it is a markup language.
While REST is stateless by design, SOAP can be stateful or stateless. Stateless just means that when a call is made to the web service end point, it is processed as a singular request, and once completed, is done with no remaining “state.” There is nothing in the previous call available to the next web service call. What is terrific about stateless web services is they are single atomic units that are easy to load balance and tend to be lightweight and fast. By keeping the web service call small and fast, the end user will have a faster and better experience.
SOAP requires XML as its file format. REST doesn’t care. It can use JSON, XML, or any format the user wishes to use.
Asking which is better is the wrong question. You should ask about the intended use case. For financial networks, banking operations, and telecommunications, SOAP is generally used. For social media, mobile apps and web apps, REST is generally used. One main advantage of REST is the lightweight nature and easy implementation with current development tools sets.
APIs are very important in any commercial software, regardless of the type of API. Because of the need of our interconnected systems, having them is an absolute requirement today.
4. SQL Server vs. NoSQL
Let’s get one thing out of the way. If you’re deciding between a relational database like Microsoft SQL or a non-relational database like Mongo DB for our industry – go with a relational database. Period. Full stop.
Now, let’s get technical. SQL Server operates on the premise of ACID (Atomic, Consistent, Isolation, Durable). When data is written to SQL Server, the data must write to the disk before the transaction is returned to the user as successful. This is important from the “Durable” standpoint, meaning the data is permanently written and available – it won’t be lost. This “durability” is well suited to high frequency type financial applications. NoSQL typically operates on BASE (Basically Available, Soft State, Eventually Consistent). When data is written to NoSQL, the data is not required to be persistent at the disk level before returning to the user as successful. While BASE makes for faster databaseoperations, it might not be well suited to high frequency financial type applications.
NoSQL can work for applications such as Twitter and Facebook because instant access to the data isn’t imperative. For example, if I post a picture of my cat, it’s not vital that my aunt on the other side of the country is able to see it right away. But, for financial applications you need durable, consistent data availability.
While some technology (thinking of programming, protocols, etc.) changes can have real value and benefit, it can be easy to get sucked into a holy war between technologists that can oftentimes be more a reflection of their individual capabilities than an actual assessment of what is best for the client. At Nortridge, we have always pursued a strategy that is 100% focused on our clients – financial services companies that need solid systems that are as reliable and flexible as they are secure and stable. We have a rationale behind all of our platform decisions that all tie back to building the best solution for our clients.
A version of this article appears in the November/December 2020 issue of SubPrime Auto News.
