Generating Typed Code

Hello, everyone. Today, I'm going to be talking about how type generation helped reduce bugs and improve our developer experience at Rollbar. I'm Paul Sereno. I'm a senior software engineer at Rollbar. I have about 10 years of experience as a software developer, working on web-based applications, and I live in Austin, Texas.

For today's agenda, I'm going to first give a brief introduction into the Rollbar monolith. I'll talk about some of the technical challenges we experienced while maintaining the monolith code. And I'll explain why we made the decision to migrate our code base to TypeScript. Then I'm going to talk about the migration strategy into TypeScript, and I'll provide an overview of the architecture that we decided to implement. After that, I'll discuss how we were using GraphQL Code Gen at Rollbar, and I'll provide a few code examples that will demonstrate various ways we're using Code Gen on both the server side and client side of our application.

Okay, first let's go through the Monolith application. The Monolith tech stack is built primarily on Python Pyramid, a web framework that's similar to Django, Ruby on Rails, or Express. We're using a number of different database technologies like MySQL, Elasticsearch, and Clickhouse. The command is written in React 16, so there's no hooks and everything is styled using a mix of Sass and CSS.

Throughout the years, the Monolith has had 78 contributors, over 44,000 commits, and over 9,000 pull requests, and is 11 years old. There are some benefits of working in a monolithic code base. It's much easier to develop in a monolithic code base, because there's often boilerplate code that developers can copy and paste and tweak to get something working faster. Developing a monolith application is sometimes easier if you can fit everything into a... Sorry about that.

Deploying a monolith application is sometimes easier because you can fit everything into a single Dockerfile. And code search is often a better experience in monolithic applications because a line of code that you'd like to search for is all in a single repository. So it's much easier to search for single lines of code.

Some of the challenges that we experience with working in our monolith applications have been debugging has been a big challenge because there's a lot of code that you have to read through to fully understand the root cause of certain issues. We use Rollbar ourselves to triage issues, and while the grouping features that Rollbar provides are nice, we still find it difficult to root cause some parts of the code base that are really complex. Performance is another issue with our monolithic code base, and it's mostly due to inefficient code. For example, things like making duplicate database calls and doing heavy post-processing on fetching data has been a pretty big bottleneck. We've also experienced issues with just navigating through code. It could sometimes take hours to fully understand how some things work. And given these issues, we decided to make the decision to migrate away from working in a monolithic application towards a newer tech stack.

And that tech stack includes TypeScript. So the new tech stack leverages Next.js, GraphQL, and React Query to help resolve some of the issues related to our monolith application. And of course, everything's written in TypeScript. The new tech stack that we're in the process of migrating to still uses parts of the monolithic application. We made those features from the monolith available through a number of internal API end points. The GraphQL server is essentially used as an API proxy that sits between our internal API and our front end application. And we made the decision to use GraphQL in this way because it not only provides TypeScript, but it not only provides type safety between the server and the client, but it also gives us flexibility in terms of back end migrations. For example, we're planning on placing some of the internal API end points with gRPC calls. In this proxy, architecture allows us to experiment with different back end solutions. All of our API calls from the front end are made through React Query. And the React Query client that we're using is completely generated from the GraphQL queries themselves. And I'll talk about that in a minute. But this setup has allowed us to get a lot of type safety into the front end. So I mentioned that we generate our front end client. So specifically we use a tool called GraphQL Codegen.

And this is an open source tool that will automatically generate TypeScript code from either a GraphQL schema or a GraphQL query operation. So we use Codegen on both the server and client side. On the server side, we use it to generate types for our GraphQL resolvers. And on the client, we use it to generate the React query client from our GraphQL queries.

I'll provide a few examples on the differences between how we use it on the server and client. Using Codegen itself is pretty easy. GraphQL Codegen provides a command line tool that is pretty easy to use. You just have to run GraphQL Codegen and give it a config.

So I just want to give an example of specifically how we're using GraphQL Codegen on the server. This is a code snippet taken from our code base. This represents the environment connection schema that is designed to represent a list of project environments. And using the code connection edge nomenclature is sometimes common in GraphQL when representing paginated lists of data. The resolver for this connection simply fetches from the project environments database and returns a list of environments.

One of the issues that we found with using TypeScript in GraphQL has been adding type safety to these resolver functions. For example, by default, arguments like limit after filter won't get types generated for them. So we have to manually add in types ourselves. So this is an example of a type that we explicitly defined for those resolver arguments. And GraphQL code gen provides a workaround for these issues. It allows you to explicitly add in configuration for overriding their internal generation. So for example, in this case, we are overriding the environment's connection generation using our explicitly defined types here. In the environment connections model, we mapped to the environment connection schema definition.

On the client side, you can use the command line tool the same way by simply calling GraphQL CodeGen. Code generation is a lot easier on the client. So given a GraphQL query such as this one, in this example we are fetching a list of environments from our GraphQL server. And we can generate a hook from that query using GraphQL CodeGen. So this hook will fetch the data that we need, and it will be completely type safe. So in this example, as you can see, when you call, or when you type in through your text editor query.results, you'll be able to see the various attributes that are on that object.

Some of the benefits that we've experienced migrating to this architecture have been debugging. So it's much easier to have the type checker catch any potential issues. Performance, there's various compile time optimizations that you can get from having your code base in TypeScript, and we have seen a performance boost in our application. In terms of navigating the code base, having those type annotations have made working with internal libraries a lot easier to use, especially libraries that don't have very good documentation. And an added benefit to using TypeScript has been it's improved our overall developer experience because it's allowed front-end and back-end developers to work in parallel without having to depend on each other.

Some of my closing thoughts are migrating a monolithic code base is challenging, but with the right architecture, even a small team can make it possible. So we benefited a lot from setting up those internal endpoints and simply using GraphQL as a proxy to our internal API. And overall TypeScript improved our ability to debug and optimize our code. That's all.