What your (open source) tech stack says about you

A company’s tech stack — the technology it uses and relates to — says a lot about how the people behind it think and operate.

In this insight, we’re going to share just what a tech stack says about a company, give you a behind-the-scenes look at our open source tech stack and why it makes sense.

Why you should be thinking about your tech stack

In every company, you are confronted with challenging problems that need to be solved. To do this efficiently, you and your team need to have processes in place and become proficient in using your technology tools to solve them.

This is not gained overnight but is built over time, especially when we’re looking at a team of people collaborating rather than individuals: the more technology, the more complexity.

When you have lots of different technologies to support, maintenance costs rise, and efficiency drops, making it difficult or even impossible to have a deep knowledge of all technologies. This is why most companies settle on a specific tech stack they are comfortable with.

What a tech stack says about a company or software service provider

With over a decade of experience working in and with tech teams, we’ve seen that the type of tech stack you use says a lot about your company, culture, and the processes it operates on. Here are the most distinct features we’ve identified and what you can reflect on in your company:

New vs. old

A tech stack can show you some of the inner workings of a company. Are you still using technology from the last millennia or last decade? Is it only using the fancy new stuff? Both extremes can have reasoning behind them but should definitely be questioned once in a while. For example, older software can be stable and less error-prone, whereas new software may be just the right fit for a current problem.

The following are the main problems we’ve seen pop up if you’re using outdated software and what questions you should ask yourself:

• If the software is not updated regularly, it may also put you at a security risk. How often do you or your software provider update?
• Old technology puts you into a lock-in where you will find fewer and fewer people who are familiar with it. Finding talent is tough, and the ones you find will be costly. Reflect on whether you depend on a software consultancy or skill set.
• Cutting edge technology is not battle tested, problems may arise when you deploy to production systems. Integrating it into your solution might take longer than you expected and might result in higher maintenance costs.
• Good software developers tend to avoid archaic software for good reasons; they want to leverage technology advancements and build their skill set on the latest developments. Old software can leave a company operating inefficiently and make it incapable of attracting new and top-notch talent. Ask yourself whether your tech stack is attracting great talent or if finding new team members is easy.

Closed vs. open

In our insight, open source vs. closed, we covered just what open source is and why we’re doubling down on it.

Companies or consultancies using closed source software often have a specific interest: to sell and continue selling the software to you as they receive a percentage of every sale they make. This bias may lead to a subpar solution as the company prefers the solution with additional financial gains. Selling closed source software is a business model for consultancies. So be aware of what you’re getting yourself into.

It can leave you as the client dependent on the vendor. We’re not saying that closed source is generally bad; it can be precisely the right tool to achieve your goal, but we always like to point out the pros and cons.

On the other hand, companies (we’re one of them) using and contributing to open source are invested in the developer community and its well-being. Together we can achieve more than every single developer and company alone. We have the flexibility to try out different solutions to solve a problem and find the right fit. Also, we are not as tied to one technology as closed source users are. The biggest question you need to ask here is:

Are we working with open or closed source and does that make sense?

Simple vs. complex

Should you try to keep your tech stack to a minimum or always use the perfect solution to get the job done? As always in software development, it depends. As we already talked about above, it’s essential to be proficient in the technology you use, so it does not make sense (and is probably not feasible) to try to use every technology out there.

On the other hand, if you narrow down your stack too much, you may not use the right or best tool to solve a problem.

The first step is to take a step back and analyze, ask yourself:

• How many tech products are our team using?
• How many times do they need to switch tools in their workflow?
• Can we cut down on a tool? Perhaps another tool we’re using has a similar functionality?

Maintenance

It is vital to reevaluate your tech stack from time to time.

ThoughtWorks has used its famous tech radar for a long time and inspired many other companies to copy it. This is one method to check if your stack meets current standards, evaluates new technology, and retires old technology. It does not have to be this fancy, and it does not have to be this big. Your tech stack should reflect the size of your company.

To evaluate your tech stack when it comes to maintenance, ask yourself:

• How often are we updating the software we’re using?
• How much are we investing into software maintenance every year?

Our open source technology stack

We ❤️ open source, and our stack reflects this, although that doesn’t mean we always refuse to use closed source software. Still, the only reason we would consider turning to closed source is when the open source alternative is either: non-existent or has considerable flaws.

Over the years, we’ve used many tools and settled with a modern but not cutting-edge tech stack that helps us deliver reliable software at a decent speed. This is primarily because we know that the software has a proven track record and integrates recent developments while not being an experimental technology we might not be able to rely on in a couple of months.

Front-end

We use Next.js to build our user-facing services. It handles a lot of setup work for us and has improved our developer experience. It resembles the way we used to write applications but with much less effort on our side.

With Next.js comes React as our front-end framework — so no surprises here.

We tried different component/UI libraries and currently chose Chakra UI as the best fit for our needs. It has a solid variety of components and integrates well into JSX without going too far away from CSS (at least most of the time). It enables both old CSS junkies and newbies to create compelling UIs.

When applications get complex, it is best to have solid-state management. XState is a remarkable piece of software by itself but also includes some fantastic tooling like the visualizer and the editor. It enables you to get rid of entangled logic and write it declaratively.

Back-end

When it comes to the back-end, we have a combination of tools and technologies. If we need to write custom logic, we do it in Node.js, but amazing software like Hasura diminishes this need by the day. With Hasura, we create a GraphQL API in front of PostgreSQL that is defined declaratively; it has a decent authorization scheme and can take over most of the classic API code. It enables us to only concentrate on essential business logic. Hasura handles all the boring stuff.

For authentication, we use a combination of Keycloak and OAuth2 Proxy. There is no need to handle any authentication inside the application. Take a look at How to customize Keycloak themes to gain insights on how Keycloak theming works.

For data processing, transformation, or routing — depending on the use case and the project size - we use either Apache NiFi or Apache Kafka. Both help to handle the communication between services.

Dev Experience

Although we weren’t the first ones in the TypeScript game, we now fully embrace this fantastic language as editor and tooling support has matured significantly. We generate typed GraphQL API code with GraphQL Code Generator, use XState with TS (support improved significantly this year), and try to have a fully typed experience. These refactorings and changes are a joy. The trust in our code has risen, and it’s much easier to spot problems at coding time. Going back to JS-only projects feels weird and awkward.

For a long time, we believed that using Docker helps provide consistent environments on different machines, be it developers' machines or production systems. This adoption has ruled out many configuration-dependent bugs that are sometimes hard to track down. Instead, we use it to spawn development environments, build images on our CI, and try out the software without directly changing our systems.

Databases

We rely mainly on the power of PostgreSQL, which, combined with Hasura, is a real game-changer. However, if PostgreSQL's search facilities are not enough, we fall back on ElasticSearch's strengths to power the most sophisticated searches.

Deployment / Hosting

Our elaborate deployment pipeline is powered by Jenkins, which builds, tests, and deploys our applications into various stages in our OpenShift cluster. In addition, application logs are transported via fluentd into Kibana, which helps us find and debug production issues.

A tech stack is always a work in progress

Our stack is by no means finished or final. The software world evolves too quickly to take a back seat and relax, yet we’ve built a solid foundation both we and our clients can rely on.

We’re constantly testing and evaluating new software. Some tools have stayed with us for years; others are recent additions. We are constantly amazed by which tools and technologies pop up almost daily. Sometimes it’s hard to keep up, but we’re up for the challenge.

Want to chat tech stack? Drop our Developer and Insight Author Thomas Peklak an email at thomas.peklak@trigodev.com.