Expanding the Code: The Evolution of Oliasoft’s Tech Stack

In my last article, I discussed the early technology choices we made when building Oliasoft WellDesign™. This week, I’ll dive deeper into the technical decisions and the reasoning behind them.

As I mentioned, we decided to build Oliasoft WellDesign™ using JavaScript to create a front-end that runs inside web browsers. The alternative was developing a native Windows application, which would have made sense since the oil industry primarily uses Windows. Another alternative could have been Java. However, my prior experiences with Java had left me unimpressed. The "write once, run everywhere" promise of Java didn’t live up to its expectations, particularly when it came to making applications feel native across platforms.

Having been through a few startup journeys, I made my bet. I chose JavaScript because of its universality (run everywhere) and due to the significant investments by tech giants like Google and Microsoft in the future.

Why JavaScript for Both Client and Server

It may come as a surprise to some that JavaScript, originally designed to run client-side in the browser, could also be used server-side. JavaScript was invented in a rush, intended to replace Java and other native plugins that had various issues like security vulnerabilities and poor integration with host environments. Despite the name, JavaScript has no connection to Java.

The key breakthrough came when a developer took the V8 JavaScript engine, created by Google for Chrome, and bridged it to Linux, giving birth to Node.js. This turned JavaScript into a full-stack development language, running both in the browser and on the server.

Having built previous products using the lesser-known Perl language, I found JavaScript's abstraction level somewhat familiar, but what set it apart was the backing of major tech companies. I bet on JavaScript becoming a dominant language for cloud applications, and it paid off. Today, even Microsoft’s Edge browser uses Google’s V8 engine, and Node.js is a go-to solution for server-side JavaScript, with newer challengers like Deno emerging.

Structuring the Code: Client, Server, and Common

Nine years later, Oliasoft WellDesign has grown to millions of lines of code, much of it in JavaScript. We structured the code into three top-level directories: client, server, and common.

• Client: This is the human-facing part of Oliasoft WellDesign, including the graphical user interface (GUI), which is primarily built using React, along with 3D graphics, web workers, and browser integrations.
• Server: The server-side code handles requests from the client, including machine-facing components like APIs, client assets, databases, storage, and integrations.
• Common: As the name suggests, this code runs on both the client and server sides, streamlining shared functionality across the platform.

The "Common" area described above is more or less unique to JavaScript. Not many languages allow identical code to run both client-side (inside the browser) and server-side, without any modifications, and without the need to install anything client-side.

Over time, as Oliasoft WellDesign evolved, it made sense to split it into different projects, some of which have been open-sourced, such as our GUI library and units library. Other parts remain internal.

Beyond JavaScript: Why We Also Use C++ and Python

While JavaScript is central to Oliasoft WellDesign, it’s not the only language we rely on. Engineering modules that involve heavy simulations, such as temperature dynamics or fluid flow, are written in C++. There’s a reason for this: certain tasks require domain-specific expertise that goes beyond software development. Also in many cases, performance matters, and C++ delivers faster execution speeds than JavaScript.

Similarly, Python plays a role in our infrastructure, particularly for various calculation engines. Python is beloved by data scientists, and while we often rewrite their code to improve performance or to make it run client-side, some engines continue to run in Python, interfaced through APIs. Python’s strength lies in it's ease of use for domain experts, even if it's not always the fastest option.

The Philosophy of "Good Enough"

As a team, we have the ability to code in almost any language or environment. However, engineering time is valuable, and we aim for solutions that are "good enough" for the task at hand, with room for iteration. This approach not only conserves time but also allows us to learn and improve over time, particularly as developers learn from drilling engineers or data scientists.

We release updates frequently, often every few days, so our customers benefit from continuous improvement, even if the changes are subtle. This iterative process means that the platform gets better incrementally, without disruptive overhauls.

Looking Ahead

That’s a wrap for this week. Next, I’ll dive into more of the choices we made, covering our database and storage technology, 3D technologies in the browser, and more.