A solid tech stack can make or break the usability, scalability and editability of a project. Your tech stack also influences who is able to work on a project and help make quick fixes when issues arise. Built In NYC spoke to a handful of tech companies to learn which specific tools go into building their platforms, and why they chose them.
At BCG Digital Ventures, no two projects are alike. The company invests in high-potential startups to help them scale and flourish. As DV Lead Solution Architect Ashok Kanumalla told Built In NYC, this business model requires an adaptable tech stack.
What products comprise your company’s tech stack?
BCG Digital Ventures adapts its tech stack to individual projects. An example of a tech stack used on a recent project included React, Spring Boot, JavaScript, Rancher, Docker, Terraform and GitLab.
What went into building this tech stack?
Typically, BCG chooses platforms that offer great ecosystems for developers. In terms of flexibility and extensibility, we choose platforms that are either lead by industry innovators like Amazon, Microsoft and Google, or open source platforms or frameworks that offer wider acceptance and adaptation for developers, and that offer good built-in engineering practices.
JW Player CTO Pablo Calamera explained that when it comes to building the company’s tech stack, flexibility and scale are key factors. In addition to building the player used for online video, ads and streaming content, JW Player’s engineering team also works to process mass amounts of data.
What products comprise your company’s tech stack?
Our video player is written in Javascript. Our backend is mostly in Python, with some Java. We make extensive use of, and contributions to, open source. Some frameworks/services/tools we use include: Celery, Flink, Kafka, Spark, ffmpeg, Luigi, Airflow, MySQL, Postgres, ElasticSearch, Redis, TensorFlow, R, AWS, EMR, EC2 and S3.
What went into building this tech stack?
In general we are well known for our best-in-class video player, but a lesser known fact is that we do a massive amount of data processing— from usage-based analytics to machine learning to drive recommendations. For data pipeline processing we've been migrating over to Flink because we have found it to very scalable and stable for our use case. Further, we have implemented a massively scalable multi-topic message and data pipeline on top of Kafka; it’s a core part of our backbone for distributing change logs about pretty much any asset on the service and we're planning to open source it in the not too-distant future.
Every day, Teachers Pay Teachers helps millions of educators around the world share educational materials on virtually every subject. Engineering Manager John Hatcher explained to Built In NYC exactly what goes into creating a tech stack that helps create a seamless user experience.
What products comprise your company’s tech stack?
At Teachers Pay Teachers, we leverage React to build our user interfaces, Elixir for our backend business logic and GraphQL as the interface between the two. We are deployed in AWS and largely orchestrate our processes as Docker containers with Kubernetes.
What went into building this tech stack?
We chose React for modeling our front-ends because it has an incredibly robust community surrounding it and thus it is easy to find everything from tutorials to libraries we can leverage as we adopt the framework.
On the backend, we chose Elixir as our primary language for business logic. We were really interested in utilizing a functional language for our backend processing work. This approach helps us keep our code simple and maintainable by focusing on simple stateless composable functions.
To tie the two together, we’re utilizing a GraphQL interface. Some of the advantages for us include allowing the client to describe what data it actually needs, rather than choosing from a set of fixed endpoints. This approach has made it quicker to iterate on our data and our front-end, and ultimately made for an easier-to-understand application.
TransferWise helps individuals around the world send, receive and spend money. Their borderless work requires a carefully-planned and executed tech stack. As CTO Harsh Sinha explained to Built In NYC, that stack is constantly evolving.
What products comprise your company’s tech stack?
Our system is split into more than 100 microservices built on Spring Boot with Java 8. A big part of our business revolves around state changes of a transfer. There are many things that go into taking a new transfer through our system to a customer getting paid out, including fraud checks and analytics updates, to name a few. These changes are handled asynchronously where we use Kafka, which has become the backbone for our overall infrastructure over the last few years. On persistence, we use both MySQL and PostgreSQL. On the front-end, we have a mix of AngularJS and React, (we’ve invested more into React over the last year). Finally, we use Envoy proxy for service discovery and client-side load balancing; Config server for externalizing our configurations from applications and Jaeger for transaction tracing. We are in the process of moving our infrastructure orchestration to Kubernetes as we speak.
What went into building this tech stack?
Like a lot of startups, we started with a monolith. Our founder was comfortable in Java and wanted to get something running quickly without a lot of the boilerplate that can come with Java, so he picked up Groovy on Grails to build the first version. As the engineering team grew, scaling the monolith got harder and we moved to the microservices world. Hence we picked Spring Boot with Java 8 as our core microservices stack.
While there is a similar story for a lot of our tech stack evolution, the main principle we use to build is that we are here to solve real problems for our current and future customers and don’t tend to get hung up on language, framework or library wars. It’s our job as engineers to pick the right tools and practices that allow us to deliver value quickly and sustainably.
Call9 works to help individuals in nursing homes receive medical treatment without having to leave their beds. Call9’s Director of Engineering Ben Hass explained that this task involves building an interconnected platform that’s mobile friendly, responsive and capable of parsing large quantities of data.
What products comprise your company’s tech stack?
Call9 treats acutely sick patients in nursing homes, and our engineering team builds a lot of different products for this goal. We have a web app that our physicians use to treat patients, and an Android app that’s used in the nursing homes to connect to the doctor and upload medical information. The backend for our web app is Ruby on Rails, and we use React and Redux on our frontend. We also have a data warehouse where we aggregate clinical data from our system, the nursing homes and other sources. We have several rails servers that do this aggregation. We also use Looker for visualization, and have Postgres, and Snowflake databases. The data in our warehouse is used for analytics and visualizations that provide useful information to the nursing homes we work with.
What went into building this tech stack?
Our stack has changed a lot since Call9 started. We initially had a lot of separate servers and repositories; over time, we’ve moved towards consolidating these for a few reasons: There is a lot of shared behavior, such as account logins and navigation, that’s simpler to deal with if your codebase is unified. You can use external modules to get around this, but it’s often a hassle.
Also, it’s simpler to coordinate deployment and testing with a single repository and server. We still have separate servers for some cases, but have found in general that motion is towards fewer services and repositories.
Other important choices we’ve made were to use Aptible for hosting most of our servers and databases. They’ve been super helpful in reducing our devops workload while being HIPAA compliant. We chose React because we liked the modularity it provided, and we use Normalizr with Redux because we like having a sensible data store on our frontend.
