Our Technology Stack

Written by: Gabor Kovacs, Software Development Team Lead

Transcend is one of the greatest double-threat companies in the world. We employ the best in engineering and IT to create something nobody has done before: automated engineering designs. This means, that we need to be updated on all sides. Here is a quick recap on our main technology stack, and topics from a “classic developer” point of view.

This does not mean that we use every innovative technology just for the sake of using it, but we should apply those that makes the most sense, even if it means we need to invest in learning it.

We are working with AWS to provide the best experience for all users on the hosting and solution side. We also use options from Azure DevOps to support our development on CI/CD. There are not a lot of examples of this, but we have some great solutions to make it work.

We use microservices which currently hosts about sixty separately deployable units (SDU). We are not making every small calculation to be its own microservice due to inconvenience, but we are still trying to separate the different solutions as much as possible. To understand the size, we have about twenty services around process calculations, and about half on mechanical, civil and document generations, respectively.

Most of our microservices are .NET 6 applications – with the note that we will update all to .NET seven by 2023 Q1. These are usually hosted on docker and deployed as a container to AWS. We are currently working on an upgrade to React 18 for our major frontend language, which solution is also hosted with Next.js on a container. We are using a third-party solution to help our authentication, which means, on our side we mostly just validate a small scope of rights, and we do not need additional solutions to handle that. We use direct API calls with helper packages, but in the major channels of communications we rely on a message queue.

As the data-storage we use S3 to store a lot of files as output documents or templates, SQL Server (AWS RDS) for some solution, and MongoDB for some others, where it fits the most. Only a small set of our services communicate with these databases, we usually have a dedicated repository for that.

Now let us review the exceptions, because in our R&D solutions sometimes we need to make some things differently. For example, we use three different engineering tools, which do not support – for our solutions – container hosting because of licensing. We host these on virtual machines (AWS EC2), but their start, and stop are automated. We also have one deployed console application for all these types of virtual machines to help with the communication between other services and the engineering software. We have multiple internal tools, and they have Blazor frontend instead of React. Our company website is a separate solution also and is not part of the development team’s codebase.

One of our main solutions is called the PlantGraph, which is a multi-dimensional multi-disciplinary graph. This is a form of data storage that mimics how a plant looks from various levels of engineering. Multi-disciplinary as it is managing multiple engineering disciplines: process, mechanical, civil and electrical. Multi-dimensional is a less known term in case of a graph, but it represents the graph has multiple layers, and every node is another graph inside. This is a major development since there are no editors or patterns to store data like this, we needed to create a framework to manage it, including dynamic code generation as well in the background, since this graph contains logic as well.

We have an internal tool connected to a machine learning solution (OpenCV based internal application), which works on recognizing wastewater treatment plants and certain buildings on the sites. This is something that is only in our internal solution, but we plan to use this data to have a better customer experience sooner than later while marking sites.

We have a multi-generation optimization solution to arrange polygons in polygons with certain rulesets for our civil design, which is a completely in-house development. Other than this, we use some more generic optimization algorithms in various parts of our codebase, which are tailor-made to work with our process calculations.

We have an internal package to manage dynamic metrics and unit-changing on a level that is required in multi-disciplinary engineering.

We have an architecture that is like the best games ever made: easy to learn, hard to master. The base solutions are straightforward, and it is quite easy to start working with our codebase, since it is up to the current standards, but we have some deeper concepts that need a level of understanding you will not reach in a couple of hours, specially not with our engineering-based domain.

If you are interested in being part of revolutionizing engineering designs, we are constantly searching for talented developers and engineers to join our team. Reach out to us, even if you do not see a position open: we believe that we grow with the best talent, and usually we only know what we need once we already have them in sight.