Choosing the Right Tech Stack: A Software Engineer's Dilemma

Should I use Java for my app's back-end, or should I use Go ?

Should I code my front-end in Vue.js or React?

Should I store my data in MongoDB or MySQL?

Should my back-end and front-end communicate using REST or GraphQL?

Should I host my app on AWS or GCP?

Decisions, decisions!

Choosing a programming language, an application framework, a persistence store, a communication paradigm, and a hosting service for your software application is nothing short of a herculean task for a software engineer, given the multitude of choices that are available out there.

Heck! Even looking for a simple AJAX library in JavaScript can easily give you a migraine!

I'm not exaggerating!

Just go to, a public collection of open-source libraries for JavaScript platforms (Node.js & Web Browser), type the keywords "ajax request" into the search box, and hit the Enter/Return key.

You'll get a list of approximately 640 libraries, 20 libraries per page with a total of 32 pages, ranked by their search score (percentage of the match with the search keywords), with the libraries having the highest search score displayed first in the list.

You probably won't have to look through all the 640 results to find the ajax library suited for your use, but still, that's a lot to choose from!

When there are so many choices, one might wonder how to make the right choice?

Ideally, your choice should be based on the answers to the following questions that you arrive at after looking at the library's (or, for that matter, any technology's) documentation:

  1. Is it well documented?

  2. Does it cover all the required use cases?

  3. Is it well maintained?

  4. Will it be easy to integrate it into the existing code-base?

  5. Is it easy to use, i.e., will the learning curve be too sharp for other developers on your team?

  6. Is it open-source, or does it require a paid license for commercial use?

A library (read technology) that is poorly documented is always a strict no-no as the only way to learn how to use it is to look at its source code, which is very time-consuming and hence not preferred by most developers.

You might compromise on some of the above points depending on how good the library/technology is.

For example, if the library/technology fulfills all the other criteria but needs a paid license for commercial use, you might be okay with that, provided your company is ready to foot the bill!

Let me give you a concrete example:

In my current company, the project that I'm currently working on requires us to use the iText library (which requires a paid license for commercial use) for generating PDFs.

In addition to that, we also use Adobe Acrobat Pro DC, a paid version of the free Adobe Acrobat Reader. It provides many additional features that allow us to modify PDFs to be consumed by our application and process them further using iText.

Even though we're paying a handsome sum of money for the said software suites, the return on investment (ROI) (we're able to effectively fulfill our client's requirement) is significant enough to justify it!

Are you wondering what all of this has got to do with the choice of our tech stack?

I thought so. So here goes:

You see, the iText library requires the use of either Java or C#, but our core back-end has been developed using the Go language. Hence, to use iText, we had to create a separate Java-based utility whose only task is to generate PDFs.

The Java-based utility runs as a separate application on the Apache Tomcat web server, an open-source implementation of the Java Enterprise Edition (Java EE) specification for Java-based web applications.

Our application also needs to consume Geospatial Data and render it in the form of an image on the PDF generated by the Java-based utility. To do this, we approached one of our GIS experts who wrote a small Python utility that could do this.

Wondering how all the above utilities written in different programming languages work together?

Well, we have linked them together using the HTTP protocol. Here's how it works:

  1. When the Go server needs to generate a PDF, it sends an HTTP POST request to the Java-based utility, which pings our core MongoDB database to obtain all the data required to generate the PDF.

  2. If the Java-based utility needs to use the Geospatial data to generate the requested PDF, it sends an HTTP GET request to the Python-based utility, which retrieves the data from our MySQL database and returns a PNG image in response.

  3. The Java-based utility then embeds the image into the PDF, writes the PDF to its local disk, and returns a URL, using which the end-user can download the PDF file.

From the above description, it seems that everything fits right into its place and works seamlessly!

But that wasn't always the case.

Initially, when we tested the Python-based utility, we found that it did the bare minimum, i.e., it just consumed Geospatial data and wrote the resulting PNG image to the disk. It wasn't able to communicate with the Java-based utility using the HTTP protocol!

To enable it to do that, I had to wrap it in a web application using Flask, a micro web application framework for developing web applications in Python.

And the Flask-based application itself requires using Gunicorn, a WSGI HTTP server for Unix!

So, currently, our tech stack looks like this:

  1. The Vue.js JavaScript framework for the application's front-end

  2. The Go programming language for the application's core back-end

  3. The Java programming language for PDF-generation utility

  4. The Apache Tomcat web server for running the PDF-generation utility

  5. The Python programming language of consuming geospatial data and rendering it in the form of an image

  6. The Flask web application framework for wrapping the Python-based utility into a web application

  7. The Gunicorn web server for running the Flask-based web application

  8. MongoDB as the core persistence store for storing all of the data (expect the geospatial data)

  9. MySQL for storing the geospatial data

  10. And finally, the HTTP protocol to establish communication among all the above modules!

As you can see, our tech stack is quite diverse, and it has evolved (initially, it was just Vue.js & Go) to accommodate new requirements. And it will keep evolving as our project grows in size and we add new features to it!

As far as the criteria for choosing the various components of this tech stack are concerned, some of the choices were made for us (at least initially). In contrast, we chose the other components ourselves to cater to new requirements over the past one and a half years.

The point is: Your tech stack can never be static. It keeps evolving with time. And there's no way you can predict upfront how it's going to evolve and make all the relevant choices then and there!

Here's hoping that you found this article interesting!

Do share your opinions regarding it in the comments section below 👇.

No Comments Yet