# Why we chose T3 stack to build our reference apps on Web At Zoom we want to empower developers to build innovative and engaging products with Zoom SDKs. To give them a head start, we're creating a series of reference apps across different verticals to give them a "good" starting point to build their own apps. There is a lot of debate around the best way to build a web app on the internet but this blog is not about that. We will walk you through our process of selecting the technology stack to build reference apps and why we decided to use the T3 stack. ## What's a "Stack" for reference apps anyway? We wanted to ensure that our technology stack would be useful for as many developers as possible. For example, we could consider building our front-end in Rust (to make things blazing fast) but it would be useful for a much smaller subset of our potential developer audience. When building for the Web, it’s hard to justify using anything other than JavaScript. However, the lack of type-safety, among other drawbacks, made us pick [TypeScript](https://www.typescriptlang.org/) – a superset of JavaScript. TypeScript simplified the process of writing and managing the app within our team, ensuring seamless collaboration on shared features across both frontend and backend components. It adds extra syntax that can be intimidating for developers unfamiliar with the language, however the code still reads the same as JavaScript and most of the added syntax can be skipped over while reading through the source. Expanding on the core idea of choosing tools with the widest application, we chose [React](https://react.dev/). It is (still) the most popular framework library to build for the Web because of the simple programming model and composable components. While the [Zoom Video SDK](/docs/video-sdk/) uses JSON Web Tokens (JWTs) for session authorization making it compatible with any backend language or framework, we limited our backend choices to those written in TypeScript so our audience wouldn't need to know another programming language. To build a full-stack web application with React, we chose [Next.js](https://nextjs.org/). It does a great job of abstracting away the complexity in web-tooling both for the frontend and the backend. Now we’re set with a solid foundation (no pun intended). #### Okay, what's Next? React and Next.js set the foundation for our reference apps but we still had to answer questions like "what about the database?" and "how do we handle authentication?". Before we could answer these questions, we needed to decide whether to use open-source libraries for these features or develop our own from scratch. Choosing a specific library requires that the developer using the reference app understands how the library functions, potentially creating a barrier to entry. However, we quickly realized creating our own implementation would present greater challenges for developers. For example, to make any changes, developers would have to read the source code to understand "our way" of handling authentication. But with an open-source library, the user can simply refer to the library documentation when needed. Avoiding reinventing the wheel would also allow us to allocate our time towards building more apps for different verticals. Here is where the T3 stack comes in. ## What's the T3 stack? The T3 stack is built for Next.js and TypeScript. Most projects also use Tailwind, tRPC, Prisma, and NextAuth.js depending on their needs. You can read more about the T3 stack, why it was built and how the pieces work on the [docs](https://create.t3.gg/en/introduction) website for Create T3 App: the CLI to scaffold a new project using this stack. If we started with a new Next.js project and chose from the available libraries, we'd end up with something very similar. The T3 stack made it easy for us to start without having to set up everything ourselves. The option to use the newer [App Router](https://nextjs.org/docs/app) in Next.js was recently added to the T3 stack but we decided to stick with the [Pages Router](https://nextjs.org/docs/pages) for now. #### Styling [Tailwind](https://tailwindcss.com/) is a great choice for styling because its syntax is heavily based on CSS, making it easy to adopt and maintain. We also used shadcn/ui for the UI components to save time on writing the UI while still owning each component as part of the source code. It is accessible out of the box and we can allow developers to easily change the theme according to their brand. #### Authentication For User Authentication within Next, using the [NextAuth.js](https://next-auth.js.org/) was another easy decision. It's open-source, easy to set up and gives access to simple react hooks that can be used to manage authentication. #### Database & ORM We knew we'd have to use a SQL database for storing user data. So we chose PostgreSQL as it is one of the most commonly used open-source databases. To keep our database queries type-safe we needed an ORM. We chose [Prisma](https://www.prisma.io/) as it’s a popular option, plus we really like its syntax as it is easy to understand for developers new to ORMs. #### API The star of the show that brings it all together is [tRPC](https://trpc.io/). It blurs the line between the frontend and backend in the best way possible. I introduced it to the team, which was apprehensive at first but quickly fell in love with it. It allowed us to work individually on the same features across the stack without having to worry about someone else’s code. Not only does it make collaboration effortless, it also makes reading and navigating the code a lot easier. If you're unfamiliar with any of the tools mentioned in this blog, you can find great explanations and guides for each piece in the [T3 Stack docs](https://create.t3.gg/en/why). There is a huge community building and using these tools and we're excited to be a part of it! Huge thanks to everyone who’s building open-source tools and especially the contributors behind this project. ## Conclusion We care a lot about developer experience and developer productivity, both internally and externally. We want to make sure that our reference apps are using modern tools that are easy to build with and maintain, both for our team and yours. We think these tools strike a great balance between impacting most developers and being easy to build with and maintain. You can read about our first reference app for Telehealth in the [introduction blog](/blog/video-sdk-telehealth-intro). In our upcoming blogs for reference apps, we'll dive into the code and how we use these technologies to build our apps. Be sure to keep an eye out for more updates on our blog! ###### Disclaimers: Use of this sample app is subject to Zoom's [Terms of Use](https://explore.zoom.us/en/video-sdk-terms/). This sample app is **not** designed to be a compliant solution for use with protected health information (PHI) under the Health Insurance Portability and Accountability Act (HIPAA).