General

This Dot Labs Engineering Levels

Published Mar 10, 2020

Updated Dec 21, 2023

9 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Introduction

There are many different qualities that make software engineers successful. Each company has their own unique set of needs regarding developer skill sets and seniority.

As we continue to grow in numbers at This Dot Labs, we’ve begun to ask ourselves what qualities we most look for in developers, what traits exemplify our conception of a senior engineer, and how we can drive mentorship at the company with clear guidance about how every employee can work towards their next promotion.

We’ve decided to share our thoughts with the community in the hopes of spurring conversations among your team. If you haven’t mapped out a career path for your engineers, we hope that you take the time to start talking about what that would look like. A clear purpose at work leads to higher employee satisfaction and retention, better outcomes for customers, and overall lower costs across the board. It’s truly a win-win-win!

What’s a senior engineer, anyways?

Titles are a funny thing. We know that they’re important. They convey responsibility, status, and achievement. When you’re applying for a job, it can really matter if your previous roles say “senior engineer” or “architect” instead of simply saying “developer”.

However, I’ve known people that tout their CTO experience of the small startup they co-founded, or brag that they were the Senior Architect of their 3 person company. Do their experiences match the experience of other CTOs or Senior Architects? Not necessarily.

More important than titles is what a person actually accomplishes at their job or enables for their customers or team members. Therefore, we think there’s a difference between the title “Senior Software Engineer” at a company and the concept of a senior engineer (as opposed to a junior or mid-level engineer).

Outside of the context of titles, we consider the journey from a junior engineer to a mid-level engineer to be a journey of learning. You gain knowledge by learning the software development patterns, rules, and how-to. The journey from being a mid-level engineer to becoming a senior engineer is a gain in wisdom. You learn how to transcend the rules and how to deliver value to your customers however you can with a strong knowledge of tradeoffs.

We’ve known “Software Developers” who were mid or senior developers, and we’ve known “Architects” who might still be mid-level in the grand scheme of things.

https://twitter.com/robocell/status/1062517501068804098

We want the difference between engineers and senior engineers to really mean something at This Dot Labs. Here are the key distinctions we make as our developers become senior developers:

Culture Stewardship - As developers make the leap to senior developer, we expect them to take an active role in promoting and improving the company culture. We want people to take ownership of their part in making the company culture vibrant, interesting, and inclusive. Building developer communities is in the DNA of This Dot, and we want our senior engineers to exemplify this both internally and externally.
Team Focus over Individual Focus - Mentorship is another thing that we take seriously both internally and with our customers and the community. Whether it’s the fact that every employee at This Dot Labs meets regularly with a mentor (and may have mentees themselves), that we invest in our Apprentice Program that helps women get their first job in tech, or that we offer training and mentorship to all of our clients as a key differentiator in our projects, we value the ability of our developers to help others grow, learn, and be successful. We expect our senior engineers to not only be responsible for their own performance, but also to make sure that everyone on their teams are fully successful as well.
Customer Awareness - Our senior engineers take a larger role in interacting with our customers on a daily basis. While all of our engineers work alongside our customers, and we center our customers in all of our work, our senior engineers are responsible for managing client expectations, establishing strategy, deciding milestones, and setting a good example for the other members of the team. At the end of the day, This Dot Labs is a software consultancy, and giving our customers a positive return on their investment in us is critical to our success.
Business Awareness - Many of us develop software both as a career and as a passion. However, we have to remember that we’re also operating a business that all of our employees rely on to support themselves and their families. Therefore, as our developers transition to more senior roles in the company, they are responsible for more of the financial success of their projects and the company at large.

Why not just hire all senior engineers?

At This Dot Labs, we love to talk about our PAM stack. In the PAM stack, we discuss that teams with junior, mid, and senior level developers are more successful (and cheaper) than teams made up of exclusively senior engineers.

A big reason why this is true is that our senior engineers are often asked to operate at a higher level of abstraction. Our senior developers think at the team or organizational level, consider both our internal staff and external customers, and have to consider both the technical and financial ramifications of their work.

We like to think of this in terms of something like Google Maps. If everyone is looking at the Google Earth view, you’ll miss a lot of details. But, if everyone is looking at the StreetView level, then you’ll miss a lot of context. We need people at different zoom levels to be successful as a company.

It’s important to have the right blend of developers. The right blend of developers means having people who are not only focusing on different levels of abstraction, but that those developers feel fulfilled in their career when focusing on those tasks. This is the value of having engineers of many different levels on your teams.

Introducing the This Dot Labs Engineering Ladder

Here is how we’ve decided to break down the engineering roles we currently have available at This Dot Labs. It’s important to also note that we’re a growing, primarily web, primarily JavaScript, primarily front-end, framework agnostic software consultancy. For now, we have a single-track ladder, but we’ll continue to revise and expand this in the future as our teams grow in both size and complexity.

Apprentices - Let Me Google That For You

Our apprentices are getting their first experiences working professionally as software developers. We expect our apprentices to participate in team activities, processes, and the company culture. Otherwise, we expect them to work under the supervision of other developers and/or mentors to complete tasks. Our apprentices are great and growing developers, and usually they have deep expertise in other fields before coming to software development. The extra support given for those in this role is to ensure our apprentices have successful first development experiences, which are so vital to getting more roles in the future.

Software Engineer I - Street View Developers at the Software Engineer I level are expected to participate in the company culture, write and test their code proficiently, work closely with other engineers to accomplish tasks and implement features, and to attend and contribute to all team meetings and processes.

These developers are able to deliver routine tasks on-time with limited supervision. These engineers are working with their mentors to learn software development patterns, best practices, and the software development lifecycle.

Software Engineer II - Neighborhood View Developers at the Software Engineer II level are responsible for all of the same things as those on the Software Engineer I level, but with a little more complexity and scope. These developers are responsible for helping guide and mentor more junior developers and apprentices. These developers are able to write and test code proficiently, but with a greater knowledge of design patterns, approaches, and libraries than more junior developers.

We expect these developers to deliver moderate tasks and features on time with little supervision. These engineers are working with their mentors to learn about software architecture, even more development best practices, and team leadership in preparation for becoming more team focused senior engineers.

Senior Software Engineer I - City View Developers at the Senior Software Engineer I level are responsible for activities at the team level. These developers are responsible not just for participating in the company culture, but they are relied to contribute to and improve it as well. These engineers have knowledge of several design patterns and architectural solutions.

These individuals are able to deliver significant features on time with little supervision. These engineers can work as either the lead engineer or technical lead of a client project. With their mentors, these developers are working on software architecture, team leadership, and soft skills. These engineers often mentor junior engineers and apprentices.

Senior Software Engineer II - State View Developers at the Senior Software Engineer II level are different from engineers on earlier levels in two significant ways. First, they are responsible for mentoring not only internal developers but also client developers, while also working with clients to define new features. Second, they are responsible not only for delivering excellent work under little supervision, but also helping a team to deliver their features on time as well.

These developers have advanced knowledge of coding standards and architectural approaches. These engineers not only attend and contribute to team meetings and processes, but can also lead those activities as well.

They are capable of operating as the technical lead on a client project. With their mentors, these developers are focused on team leadership, soft skills, and strategy. These engineers are responsible for mentoring engineers of all levels and the apprentices.

Senior Software Engineer III - Country View Developers at the Senior Software Engineer III level contribute significantly to the company culture and are recognized as leaders by their peers. These engineers regularly mentor other developers both internally and externally.

They have a deep knowledge of various frameworks, libraries, and architectural patterns backed with significant experience and wisdom. These developers work with team stakeholders to define new features and project strategy. Not only can these developers lead team processes and meetings, but they embody a spirit of process improvement.

These developers are focused on how to embrace quality and consistency across different project teams. They are capable of operating as the technical lead of multiple projects or the technical and project manager of a single project. These developers can manage and grow successful teams with little supervision. With their mentors, these engineers are focused on strategy, relationship management, and entrepreneurship.

Architect - World View At the moment, architects are the highest level in the engineering ladder at This Dot Labs. Eventually, it might become necessary to split the role up into more granular levels. However, developers at the Architect level contribute regularly and significantly to the company culture and represent the company in a public capacity.

These developers regularly mentor other engineers (both internally and externally), including senior engineers. These engineers have subject matter expertise in technologies, methodologies, processes, and/or patterns critical to the success of our customers. These engineers are responsible for contributing to the sales work of the company including the scoping of new contracts.

These developers are responsible for driving process improvement at an organizational level. They can operate as the technical manager, project manager, or client relationship manager of one or multiple projects. These engineers are able to drive organizational initiatives to success with little supervision. With their mentors, these engineers are focused on senior leadership, strategy, relationship management, entrepreneurship, and sales.

Conclusion

Having documentation like this on-hand is critical to the success of our mentorship relationships at This Dot Labs. People have a better understanding of what is expected of them, what they can expect of those around them, and how they should focus their goals and work to reach the next step in their careers.

We hope that this look into the engineering team at This Dot Labs will spark interesting and useful conversations on your team. If you like anything that you’ve seen here, please feel free to reuse any of our descriptions.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Rob Ocel
Software Architect and Engineering Lead, This Dot Labs Host, Modern Web Podcast and This Dot Labs Podcast 12 years software services experience Passionat about frameworks, mentorship and helping junior developers
@robocell @robocel

State of Headless CMS Wrap-up

We recently hosted State of Headless CMS where we were joined by some very talented people to talk about a growing ecosystem. There are a lot of problems that a headless CMS can solve when it comes to indie development, and even small restaurants and shops. Before we dive into the key points of the event, I'll give you a brief introduction to the hosts and panelists. Hosts - Jesse @jtomchak - Keionne @KeionneD Panelists - Kapehe - Senior DevRel, sanity.io - @kapehe_ok - Daniel Madalitso Phiri - DevRel, Strapi - @malgamves - Samuel Snopko - Head of Developer Relations, Storyblok - @samuelsnopko - Stefan Judis - Dev Rel, Contentful - @stefanjudis - Arisa Fukuzaki - Dev Rel Engineer, Storyblok - @arisa_dev There were a lot of great discussions during this event which is why I want to suggest that you head on over and watch The State of Headless CMS on Youtube to hear all of the great discussions. Who is a headless CMS for? Headless CMSs give developers the ability to use a CMS without being restricted to using the CMS platform itself. It's like using Wordpress, without having to actually use Wordpress itself. This enables developers to build more customized solutions for their clients. Some questions to ponder - What are some Headless CMS technologies that you're excited about? - How do we help the little shop manage their content? - What problems does Headless CMS solve for you? We want to give a huge shout out to our hosts and panelists for participating in the State of Headless CMS event....

Feb 8, 2022

2 mins

General

Common Interview Questions & What They Mean

Introduction Who hasn't been asked some weird and interesting questions in previous interviews? Interviewers are known for asking a variety of weird, interesting, and confusing questions to possible employees for a variety of reasons. And this makes sense because they want to know as much as possible about you in the limited interview duration. Here are some interview questions you might be asked and what the interviewer is trying to find out about you from your answers: Introduce yourself Here, the interviewer is not really interested in your answer. What they are looking at your confidence and your passion, so this is the best time to show them your communication skills! So, you should tell them about your education, where you grew up, your past work experience, your hobbies, and your personal interests! Be calm, relaxed, and confident! What are your strengths? Here, the interviewers want to know how positivly you think about yourself! It’s a quite general question, so there is no right or wrong answer for it! So it’s a good opportunity for you to share what makes you so unique, and what are you good at! But you should tie your strengths to what they’re looking for! That’s why you should read the job description very carefully, and get a good understanding of what they are looking for, and then try to fit yourself in there! What are your weaknesses? In this question, the interviewers are looking at is whether you can identify your weaknesses, and how you can cover them up! You need not be really negative about yourself! For example, don't say “I am a very impatient person”, or “I am getting angry easily”. The best way to answer this question is to talk about a weakness that you had that isn’t related to the job, and what you did to overcome it. That way, they can see a progression, and that is what they really want to hear in the answer! What is your expected salary? Here, the interviewers, of course, have knowledge about the typical salaries offered by the company. By asking this question, they're often trying to see whether the applicant did research about the company. So learn about the company before the interview! You can use websites like Payscale or Glassdoor and read the reviews from other people who worked at this company! Can you work under pressure? This is a behavioral question, and the reason behind this question is the interviewers want to know if you get really stressed out. So the best way to answer this question is by talking about a situation where you experienced pressure, and the action that you took to diffuse that pressure. Then, talk about the result and what happened. How do you make your decisions? You might be asked this question if you are applying for management or lead position. They're interested in knowing your process when making decisions, because it's very likely that at some point, you will have to make a critical decision in the workplace. So, the best way to answer is to be confident and walk them through some of your management exercises, or some of your work situations that you handled successfully. What attracted you to this job? Here, the interviewers are typically trying to know if you understand the position you’re applying for, and that your goals and experience align with the role. Always remember that employers value candidates who aim to meaningfully contribute to company goals while also advancing their own careers. Where do you see yourself in five years? This is a growth-oriented question. So, if you just simply say: “I see myself sitting around here for the next five years until I figure out what I want to do”, that’s not what they want to hear. You should align this question to where the company is going and then you talk about how you see yourself fitting in their future. Why are you applying for this job? Here the interviewers want to know if you know their core values. A lot of people make mistakes answering this question and say that they are applying for the job because of the compensation package. Of course, salarie and benefits are an important thing, but you should have a long-term goal you want to achieve from the job! So it’s better to make sure this goal alligns with the company’s goals. That is what they want to hear from you. Why do you want to work here? The key to answering this question is to align yourself with where this company is going, so that’s why you must do some research on the company, like what are their values? What is their mission? Where are they going? What do they want to do? And by doing that, that will make you appear to be someone who can contribute to their overall mission, their projects, or whatever it is they’re trying to do. What makes you a good fit for this job? Here, they want you to talk about your past experiences, your past education, the kinds of things that you have done that are related to the kinds of things that they're looking for. So, you have to get a lot of information about the position, the job description, what they're looking for, and what the goals are for this position. Why should we hire you? I guarantee you are probably going to get asked this question, but it will most likely come near the end of the interview, after they’ve had a chance to build up some rapport and they’re actually thinking that you might be a good fit. Now, this is the chance to sell yourself, but you have to understand what they are looking for and the pains and problems that they have. Do you have any questions? This is usually the last question, and I made it the last one for a reason because this is most likely the last question they're going to ask you. Now that's your opportunity to find out more about what the next steps are, where they're going, or whatever is important for you. Don't just ask them questions to ask questions. Ask them questions that will help you determine whether this is a place that you want to be. Don't just ask questions about their organization chart or their finances or things that just don't really pertain to you. Ask them questions that are going to help you make a decision about whether you want to work there....

Nov 11, 2021

5 mins

General

Why You Should Consider Migrating From AngularJS to Vue

This year, the popularity and usage of React, Angular, and Vue has refused to slow down. We see continuous and persistent adoption and usage of these frameworks and libraries in both the front-end and back-end JavaScript communities. As AngularJS is faced with an uncertain future, many teams are searching for answers to the current hot topic: if you are using AngularJS, do you continue to maintain your AngularJS applications or do you migrate your applications to another framework? This is not an easy (or cheap) question to answer. In this article, we’ll go over some of the reasons why you should consider migrating your AngularJS applications, and some ideas on how to plan and budget for a successful migration. AngularJS vs Angular — The History Behind Angular 1.x and Angular 2.x “Wait, isn’t AngularJS the same thing as Angular?” Well, not exactly… AngularJS is a front-end JavaScript framework that was first published by Google in 2010. AngularJS grew to be perhaps the most popular front-end JavaScript framework in web development. In concert with technologies like Apache Cordova, AngularJS has been a huge force even in mobile application development. During its early lifespan, AngularJS was known colloquially to the community as simply “Angular”, which confuses many to this day. In 2016 Google released a completely new framework that they called Angular 2. While Angular 2 was in development, people distinguished the two frameworks, AngularJS and Angular, by calling the first Angular 1.X and the second Angular 2. As the Angular team moved to a semantic versioning scheme (the current major version of Angular is 6.X at the time of this post), suddenly, calling Angular v6.0 “Angular 2” was confusing as well. To reduce confusion, the Angular team launched the “It’s Just Angular” campaign, helping create guidelines about how to refer to the different frameworks. The original Angular framework should be referred to as AngularJS and the new Angular framework should be referred to as simply Angular. A great way to figure out if applications are Angular or AngularJS is to look at the date the application was created. Applications that claim to use “Angular” and that were built in 2016 or before are likely using AngularJS (popular versions include 1.2, 1.5, 1.6, and 1.7). Embedded content: https://medium.com/media/afa879bfa6d7b9070019be6885f8be5d Sunsetting AngularJS The AngularJS team recently announced that starting on June 1st, 2018, AngularJS would enter a 3 year “long term support” phase. As of July 1st, the AngularJS team has committed to only releasing new patches to address the following concerns: * Security flaws in the 1.7.X release branch * Incompatibility with a major browser release affecting production applications * Incompatibility with a jQuery library release affecting production applications Come July 2021, any applications that continue to use AngularJS are susceptible to any of the above issues going forward and any other issues with the framework. Why Migrate Now? There are a few reasons to begin migrating your AngularJS applications now: * The cost to migrate increases over time as the deadline approaches * Security and compatibility issues are your problem now * Difficulty finding new hires with AngularJS experience * Brain drain with current staff * Hard technology constraints Framework migrations can be difficult, expensive, and require significant planning and coordination. Waiting until the last minute or until major issues arise to start planning for a migration adds additional risks of issues affecting customers. Waiting also drastically increases the costs of migration due to the possible need to pay for expedited consulting services. Security or compatibility issues? If a security or compatibility issue is discovered in AngularJS after the Long Term Support phase ends, it could expose your customers to the effects of data theft or major product outages until the application can be re-platformed. Hiring AngularJS developers to support your application is getting increasingly more expensive as expertise in the framework becomes ever more rare. Newer developers entering the workforce are predominantly using frameworks like Angular, Vue, and React instead of AngularJS. AngularJS developers within your organization will want to stay current and relevant in the job market. There will be a growing desire internally with your current staff to want to use newer frameworks that are dominating the marketplace and the conversations right now. Migrating now decreases the risk of a brain drain as your developers may start looking for opportunities to leave and join companies with a fresher technology stack. Lastly, newer frameworks have features that cannot (easily) be supported by AngularJS. The newer frameworks such as Angular, Vue, and React were built on top of lessons learned from the era of AngularJS. These new technologies tend to be faster, more ergonomic, and provide better support for modern tooling such as webpack. The features of modern frameworks help your developers deliver new features more quickly and efficiently while enabling them to effectively leverage new web APIs. The modern methods of development can help improve the experience of your customers, lead to more online engagement, and help increase revenue after a successful migration. The need to migrate from AngularJS is no longer a matter of “if,” but is instead a matter of “when.” Therefore, it makes sense to start planning for the migration now, so your team can more quickly take advantage of the new features of these frameworks. Which Framework Should We Use? The three largest and most popular front-end JavaScript frameworks used today are Angular, Vue, and React. Each framework has its own vast set of: * Developer tooling and documentation * Widespread adoption across small, medium, and enterprise-level applications * Extensive third-party library support * Comparable feature sets In the choice of which framework to migrate to from AngularJS, there is no definitive right answer. However, in our experience at This Dot Labs helping clients migrate AngularJS applications, Vue has on average provided the most natural fit for AngularJS development teams. There are many reasons for this, but the most prominent ones are: * Templating syntax — Vue’s templating syntax closely matches that of AngularJS, making AngularJS developers feel very comfortable in the new framework. * Reactive model — Vue’s reactive model is very similar to that of AngularJS, which allows AngularJS developers to adopt the mental model of Vue much faster than comparative frameworks and libraries. * No additional JavaScript syntax or additional libraries — Vue doesn’t rely on a lot of additional JavaScript syntax or additional libraries that also need to be taught to developers, which is helpful for ramping up quickly. We’ve found it common for AngularJS developers to get fully up-to-speed on Vue development with less time and less direct training than a similar move to other popular frameworks. Vue also provides a very clear, incremental migration strategy for AngularJS projects. Vue and AngularJS play nicely with each other side-by-side while features are ported over one at a time. AngularJS controllers and templates can be converted or translated into Vue components in a systematic and repeatable way. It doesn’t matter whether you’re using the latest versions of AngularJS (1.5, 1.6, or 1.7) or older supported versions (such as 1.2); the path to upgrading from AngularJS to Vue can often be a straightforward, mechanical process. Successfully Migrating to Vue from AngularJS The key to every successful migration effort is having a solid plan. The goal should be to execute the migration while: * Minimizing feature regressions * Avoiding platform downtime * Continuing to deliver new features to customers Setting Up Your Application For Migration To accomplish this, you should set up your AngularJS application so that it can simultaneously render both AngularJS and Vue components. This will let you build new features in Vue and port over existing features from AngularJS as you have time, budget, and resources. How To Begin Vue and AngularJS Integration Hosting Vue components in AngularJS can be surprisingly simple. All you need to do is include a script tag pointing to the Vue framework. Then, create your Vue instances pointed to particular DOM nodes in your application. Vue can be set to run alongside your existing AngularJS application in a parallel branch of your document OR Vue components can be included in existing AngularJS components and fully controlled by Vue. You can even do some data and event passing between layers. A simple version of this approach can be seen in this CodePen from David Rogers: Embedded content: https://medium.com/media/ab4818d62b3c0d7d4e61c670212d5cbe Converting AngularJS Components to Vue Components The next step is to begin converting your existing AngularJS components to Vue components. This means converting AngularJS controllers into Vue instances. Then, any AngularJS lifecycle methods are converted directly to the equivalent Vue component lifecycle methods. Lastly, the AngularJS templates are copied into the Vue component and the AngularJS template syntax is replaced with the equivalent Vue template syntax (ex: replacing ng-if with v-if, ng-repeat with v-for, etc.) AngularJS to Vue Migration Code Example In this example, we are taking the following (slightly altered) snippet of templating from the AngularJS implementation of Todo MVC and converting it to a Vue template. {todo.title} Below is a straightforward conversion of the AngularJS implementation to a Vue template: {todo.title} Migrating AngularJS Services One of the great things about migrating is that any AngularJS service can simply be converted to an ES6+ module. There is no need in Vue to register services as is done in AngularJS. Using ES6 modules and import statements will help bundlers like Webpack minimize the footprint of your code by intelligently tracking the dependencies between your modules and optimizing what code is bundled together and delivered at run time. If you still want to leverage the AngularJS dependency injection system for these services, you can wrap your now-converted services in thinner AngularJS service objects like you would wrap third-party libraries like lodash. What’s Next? Early on, there is no need to add a parallel build step during your migration, no need to immediately use Vue CLI, and no need to tinker with Webpack build configurations. You can begin using Vue code with your existing build tooling. When your team and product is ready, then you can start bringing in the more advanced and involved tooling. Successful migrations are ones where the pace of change and the introduction of new technologies is measured. However, after the majority of your application is migrated to Vue, you can begin to invert your tooling from being a AngularJS application that hosts Vue, to a Vue application that perhaps hosts some of the remaining AngularJS code. This process allows you to begin leveraging the power of the Vue tooling ecosystem, set-up a build and bundling step, and start using Vue Single File Components. Later, you can begin refactoring and optimizing some of the previously converted components from a strictly 1:1 translated format to formats that more naturally fit the Vue model, and leverage more advanced features in Vue. You will also be able to begin incorporating additional Vue libraries and features such as Vuex. Conclusion With support for AngularJS set to end in the next three years, migrating to a newer framework will help you and your team avoid issues that may come from the lack of direct support and get your development team excited again about development. You will be able to attract talent easier and improve the speed and performance of your application and developers. But, committing to a system migration without a plan is a recipe for disaster and may slow or halter new feature development. Without an effective plan, you may experience defects, regressions, and excessive unplanned costs. Vue is a natural and proven migration target for AngularJS teams. It is straightforward to learn and allows for incremental migration of any AngularJS application alongside a new Vue application. We hope this article has helped guide your AngularJS migration efforts and wish you the best of luck in your migration journey....

Oct 28, 2019

9 mins

AngularVue

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

This Dot Labs Engineering Levels

Introduction

What’s a senior engineer, anyways?

Why not just hire all senior engineers?

Introducing the This Dot Labs Engineering Ladder

Conclusion

Rob Ocel

You might also like

State of Headless CMS Wrap-up

Common Interview Questions & What They Mean

Why You Should Consider Migrating From AngularJS to Vue

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

State of Headless CMS Wrap-up

Common Interview Questions & What They Mean

Why You Should Consider Migrating From AngularJS to Vue

Introduction to Zod for Data Validation