The Changelog: Software Development, Open Source - Maintainer spotlight! Valeri Karpov (Interview)

Episode Date: October 2, 2019

In this episode we’re shining our maintainer spotlight on Valeri Karpov. Val has been the solo maintainer of Mongoose since 2014. This episode with Val continues our maintainer spotlight series where we dig deep into the life of an open source software maintainer. We’re producing this series in partnership with Tidelift. Huge thanks to Tidelift for making this series possible.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog. Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development.

I'm Jared Santo, Managing Editor here at Changelog. In this episode, we're shining our maintainer spotlight on Valery Karpov, who has been the solo maintainer of Mongoose since 2014. This conversation with Val continues our maintainer spotlight series where we dig deep into the life of an open source software maintainer. We are producing this series in partnership with Tidelift and a huge thanks to them for making it all possible. For the uninitiated, Tidelift is the first managed open source subscription that pays the maintainers of the exact open source projects that you're using while giving you the commercial support you've been looking for. Learn more at Tidelift.com and now on to the show. So Val, first of all, welcome to the show. Secondly, I'd like to say that we were recommended to speak to you or specifically I think about somebody who maintains Mongoose,

probably not just yourself, by Abhishek Elay. Is it just you? It's primarily me. Okay, so then you were the one that was recommended. Abhishek Alai in our Slack channel recommended that we talk to a Mongoose person. And then I looked up your GitHub and I saw, wow, prolific open source contributor. Your contributor graph was almost completely green. And I thought, yep, this is a maintainer spotlight candidate right here. So welcome to the show. Yeah, completely green.

Three and a half years and counting is that an actual goal you're setting out to do or just a circumstance of your life or what it's something that i just kind of started in 2016 just kind of kept on going figured uh you are what you do every day right so i'm gonna start writing open source software every day and that's just how it is wow that's quite a streak are you ever afraid afraid of accidentally breaking it, or do you care that much? It's something that I don't have a concrete goal for. I was thinking I was going to break it this year. I was planning on hiking Kilimanjaro in June with a couple of friends of mine,

but unfortunately those plans fell through because my girlfriend and I ended up finding a good opportunity to buy some property here. So I ended up being like, I can't be climbing Kilimanjaro on a mountain where I have no cell reception whatsoever, while also the mortgage guy is trying to blow up my phone for documents. So I kept on going, basically. Well, choices in life, you you know climb mount kilimanjaro or keep your github street going you got to make choices i hope to be like the first guy to fix a github issue from the summit of kilimanjaro that would be a cool claim to fame but that would be pretty epic i'm not gonna lie that would be cool these friends also i traveled with them a lot

they always like there was one time we went fishing in the panhandle of Alaska. And I was like that guy that brought his MacBook to a fishing lodge in Yakutat, Alaska that had no cell reception. The lodge technically had Wi-Fi, but it only worked one day of the week that we were there. But, well, I still kept my streak going. Well, okay. So this is interesting now. So it's not that big of a goal, but if you've got to bring your laptop on a vacation,

you're going to get that done. That's pretty cool. So let's talk about what you're maintaining. Mongoose, a very popular library, been going for a long time, MongoDB. What do you guys call it, an ODM? Yeah, ODM, like ORM, Object Relational Mapper. We call ODM stands for Object Document Mapper.

I think pretty much ORM, but for MongoDB. Although I think ORMs make a little bit more sense for MongoDB than they do for ORMs with SQL. There's a very key difference between Mongoose and your standard ORM, which is that your document in Mongoose or or what your object looks like in Mongoose is the same as what it looks like in MongoDB. So Mongoose doesn't scatter your data across different collections for you. So tell me how you got involved in Mongoose. It seemed like you were with MongoDB, the company, for a while.

Give us some of the backstory and how you got involved in this project and still maintain it to this day. Yeah. So rewind all the way back to 2012 when I first started working with Node. Got into working with Node, started using Express, started using MongoDB. Really felt like that clicked with me. But I started using the MongoDB driver. Back then, the MongoDB driver had some kind of it required way too many callbacks for my tastes you like at the time you needed to you needed to pass in a callback to get a collection reference and then use the collection reference to execute a find in order to actually really do anything useful or like query a document from the database

so i remember i just stumbled across Mongoose one day. At that point, it was still kind of a small project, sort of pseudo-sponsored by MongoDB at the time. But because the maintainer at the time, Aaron Heckman, was an employee, I didn't work for MongoDB yet at the time. I actually had never met anyone who worked for MongoDB. I just started working with it. Let's see. I still remember I put in a pull request for a project that I was working on at the time

that basically cut our code base in half just by using Mongoose. So that kind of was where Mongoose really started to click for me. So that project started up with some friends of mine after I left my previous job. It turned out to not work as well as we would have liked. So when I was kind of on my way out there, I had met some people at MongoDB at a hackathon. So I started, so I reached out to them. I ended up writing a blog post for them that was basically like the blog post

that coined the term mean stack. So that ended up putting me on MongoDB's radar and kind of making it so that we had a good working relationship. So when the startup tanked, I joined MongoDB, and I started working on some internal tools written in Go. So nothing to do with Node, which was not exactly what I wanted to be doing, but it was all right for the time.

But then I spotted an opportunity when Aaron Heckman, the previous maintainer of Mongoose, was leaving MongoDB. So he left for a while, nothing happened, and he was still maintaining Mongoose. But then fast forward to, say, April 2014, after I'd been at MongoDB for maybe about eight months, Aaron had left the company maybe about four months prior. And he sends out a message on Twitter saying, hey, I'm looking for someone to maintain Mongoose. And I was just mindlessly scrolling through Twitter on the air train to JFK Airport in New York. And yeah, I just saw that I couldn't respond fast enough. I can probably still send you that tweet. But yeah, so that's how I ended

up taking over Mongoose. And it ended up being kind of probably the most low-touch handover I have ever seen in that Aaron just sent me some credentials to log into the Twitter account, gave me GitHub access, NPM publish access, and didn't really talk to him for another couple months until I ran into him at a Philz Coffee in Redwood City, California, after I had just moved there. Wow. So you're kind of an opportunist. You just were on the way to JFK and saw the opportunity there on Twitter and hopped all over it. Did you understand maybe the gravity of that move? I mean,

you've been working on the project ever since. I don't know how much time and effort it puts in. You have to put into it on a daily or recurring basis, but it's been your baby ever since. It's like adoption. Yeah, exactly. To be honest, when I first took it over, I didn't really understand what I was getting myself into. But then, well, over the weekend, the email started pouring in from GitHub notifications. And I was wondering, wow, what did I get myself into here? You know, I just kept wading through it, kept chugging along. I ended up probably about three, four months after I started working on Mongoose, I ended up kind of switching to working

on the Node.js team at MongoDB. So I was actually working on Mongoose and the MongoDB Node driver as my full-time job. So that was something that made it a lot easier to work on Mongoose at the beginning. Absolutely. I'm looking at the license for Mongoose. It's still Copyright 2010 LearnBoost. Isn't that Guillermo Rauch's company back in the day? I remember I used Mongoose briefly back when I was dinking around with MongoDB and doing some side projects with it

and just trying to understand document-oriented databases and whatnot. When the NoSQL craze really was hitting, I don't know what year that was when there was a fever pitch for the hype cycle on NoSQL. Yeah, somewhere between 2011, 2015. It's hard to, there were a couple of peaks, but I think 2011, 2012 was the big peak.

I think around 2014, 2015, things started dying down a bit. People started realizing that NoSQL databases are amazing, but they also aren't the final solution to all problems that you've ever had. It goes back to Frederick Brooks. There is no silver bullet, and this is yet another case of trade-offs that have its pros and cons and you know choose your tools wisely but this is not a silver bullet that's going to solve all of our data storage problems that being said they map to some situations better than a relational database what

curious i mean you coined the mean stack phrase i think it was that mongo express was the a angular angular yeah angular one back, Angular 1 back in the day. Angular and Node. What's your current stack look like if you were going to start a brand new project, web app? What would it be? I did actually recently start a brand new project at my day job, and it's Mean but with Vue instead of Angular. So nowadays they call that the Venom stack, I think,

which is absolutely the coolest stack name I had ever heard of. Mean stack was good, but Venom is pretty sweet too. Venom is pretty sweet. I always wonder if there's just somebody in a tower somewhere, like an evil genius who just comes up with these stack names. Well, I mean, I'm talking to one of them now because you coined Mean stack. Yeah. I did not come up with Venom stack.

I think I actually saw that first on a Pluralsight course description. Okay. So yeah, it was some other evil genius. Oh, you have a good evil genius laugh even. So you could be legit. So LearnBoost, the original copyright, you're the maintainer.

The repo is actually under automatics organization so there must be more to the story yeah it's a it's a long and interesting story and basically the ip of mongoose has kind of long since diverged from the day-to-day work of mongoose so the reason why it's under automatic is it was originally written by learn boost that was um guillermo roche tj the express guy um aaron heckman was also there it's hard to believe they were all one company LearnBoost. That was Guillermo Roche, TJ, the Express guy. Aaron Heckman was also there. It's hard to believe they were all one company. They were doing some sort of

products for K-12 education but accidentally ended up building the entire Node ecosystem as kind of a side project. I hate it when that happens. Express is not under automatic because it ended up getting bought by Strongloop. I hate it when that happens. Expressen is not under automatic because it ended up getting bought by

Strongloop. I'm not sure how the IP worked there. The lawyers must have had a field day. Learn Boost ended up pivoting to becoming a cloud upload company or online file storage thing called CloudUp. Then they got

acquired by Automatic. By virtue of that, online file storage thing called CloudUp. And then they got acquired by Automatic. Okay, and there you go. So by virtue of that, Automatic took over the IP rights to Mongoose. So they still own the mongoosejs.com domain name. They still have the repo underneath their org. However, I have not had much interaction with Automatic. There was one brief time

when they accidentally took down the docs because they were migrating it to HTTPS. So I had to find the person who pushed the commit was one of their, what do you call it, sysadmin at Automatic. So I ended up finding him on Twitter and just gangrily tweeting at him like, hey, can you please reach out to me?

I don't know what's going on with my dark site that's funny interesting that there's you know there's all these goings on around the the property you know and the domain name and all this but on your day-to-day you know in your life val it hasn't really affected you too much besides that one terrible day and then twitter to the rescue at least in terms of reaching out and getting the right person. Yeah, exactly. Automatic has been very hands-off. Do you ever fear that maybe someday they'll become hands-on and like boot you? Could they boot you as a maintainer, do you think? That's a tough question. They probably could. And I wouldn't really have very much recourse. Yeah, fork it and rename it. Which is why I'm thankful that, what do you call it, that we have companies like Tidelift.

One of the co-founders of Tidelift who I met recently when I went up to meet the team in Boston, Luis Villa is one of the co-founders of MemoryServes. He's apparently an expert on open source law. Did he write the Mozilla license or something like that? Possibly. I met Luis at OSCON, but I don't know exactly his background, but I wouldn't disagree with you. Yeah, so Luis is a great guy to have on my side if that ever happens. I don't really know, and I have seen no indication that Automatic wants to be more hands-on.

Because as far as I know, they don't really work much at all with MongoDB, and I don't think they use Mongoose. So I think they're happy to keep the project as long as it contributes positively to their GitHub stars and doesn't cause them any bad press. Right. There you go. special thanks to Tidelift we're producing this podcast series in partnership with Tidelift because we both deeply care about supporting the maintainers of open source software. Our goal with this series is to dig deep into the life of an open source software maintainer, to learn what challenges they face, the highs and lows of being a maintainer, how they financially support their projects, how they maintain balance between life, day job, and open source, and also how they're supporting and encouraging contributions

and community. For the uninitiated on Tidelift, they're the first managed open source subscription model that pays the maintainers of the exact open source projects you depend on while giving you the commercial support you've been looking for. Tidelift's mission is simple, to support the open source software you depend on and pay the maintainers. Learn more at Tidelift.com. so let's talk about your life as a maintainer with mongoose i'm surprised that you are pretty much sole maintainer used by which is one of my favorite new GitHub features to see all the dependencies of a package on GitHub Mongoose is used by 736,140

other repos. Yeah, it's unbelievable to imagine that many people. I can't imagine that you're maintaining that many users by yourself. Do you have a team of, I know you don't have a team of like regular core contributors, but do you have like helpers along the way? Are there people in your issues, you know, triaging or anything,

or is it just Val all day, every day? There have been people that have come and gone to help out with, uh, with issues and new features. Um, let's see here. When I was at MongoDB, I had a new grad rotation working on Mongoose at some point. And I also had, the interns weren't working on Mongoose, but I did have some interns that were working on the Rush driver. That was fun. Let's see here. There was one time I briefly had someone as a contractor, a former colleague working on helping triage issues. That worked okay for about a year, year and a half, but he ended up moving on. Sometimes people come and go to help out,

but for the most part, it's been me. So I see that you have currently 286 issues, but only one open pull request. So it seems like you're maintaining the cleanliness of the repository, at least on the PR side, or maybe you don't get very many PRs. You have 1,422 closed,

so you definitely get some PRs. Are most of those issues, like questions or off topics, are they outstanding things that you're going to work on and you're just not getting many pull requests to work on them? Or just tell me the situation of the community that surrounds you. Generally speaking, most of the community that surrounds you um generally speaking the most of

the issues that are open are either features that i'm kind of thrown into the parking lot for future consideration or issues that date back to like 2014 2015 before i took over that i haven't quite had a chance to take a look at every once in a, I kind of get through my issue backlog, I get to the point where I'm like, back pressuring down to like, you know, issues from 2013, 2014. And sometimes I actually find a legitimate bug in there. So I try like not to close them. There have been there have been at least like three or four bugs that I've fixed over the last several months that have been like, you know, someone reported it in 2014. That was kind of like 2013, 2014 before I took over as maintainer.

And just nobody really had quite the time to look at them. But it turns out that, yeah, there was something legitimate there. Gotcha. So here we are about five years into your maintainership and you had some major releases as well. Mongoose 5 released back in January 2018. And so you've been putting a lot of work into this.

You have thousands, I mean, hundreds of thousands of users and lots of issues, some pull requests. You're maintaining that. I'm just curious, like what value do you get out of this part of your life? Like where is the, what's the motivation? You put a lot of work in. What are you getting out? Is it just intrinsic or is there a financial incentive?

What's in it for you? The financial incentive is a bad, but I think what really got me started on Mongoose and what really keeps me going is that it's a project that I have ownership for and I feel a lot of responsibility for. It's something that, like, I can run this project kind of my way and I don't really have to answer to a product manager or a CEO or anyone like that.

I'm the product manager. I'm the CEO. And I get to kind of work on it the way I want to on my schedule, my terms. So that's what's most important to me. That's kind of like why I got into open source to begin with is, you know, working at a company can kind of wear you down when you don't get to kind of code your way, you don't get to prioritize the projects you want to prioritize. No, that absolutely makes a ton of sense, especially when you have, you can have an outsized impact on, like I said, hundreds of 1000s of people your way, you know, it's your ideas,

it's your code, it's your project. And you are helping so many other people by putting the work in that you are. No doubt there's some serious value there. Have you ever thought about hanging it up or passing the torch? You know, the tweeting out just like Aaron did back in the day. Hey, who wants mongoose? I'm out. I've thought about it. I probably have to like vet the person that I would hand it off to more. More than he did.

But it's not something that I'm planning on doing any time in the near future. I think the nightmare scenario is like a vet stream or something like that. No offense to Dominic Tarr. Right. But that one was a bit of a mess. Yeah, for sure. We had a whole episode on it. Dominic didn't feel bad, so I don't think you offend him,

but definitely a thing that can happen. So you haven't really thought too much about hanging it up. What's your greatest challenge with this stuff? Is it time? Is it knowing what to do next? Dealing with humans? A little bit of both, you know, harness challenge. There's no one challenge that's particularly overwhelming. But, you know, some day-to-day challenges. Let's see. Software kind of always changes. And even though Mongoose itself has gone through,

I don't think, like, I have really, like, changed the fundamental ideas of Mongoose or, like, the fundamental concepts have more or less stayed the same. But the JavaScript community around it has just evolved so much that now I have to be thinking about TypeScript. I have to be debugging bugs that only happen in Jest because Jest is a weird JavaScript runtime, not a testing framework. I have to, what do you call it? There's always kind of issues that pop up with people now that Docker is more of a thing. There's always weird things that pop up like, oh, hey, I'm writing MongoDB in Docker here. And how do I get my DNS to work properly? There's always new little things that come up like that. Always strange little surprises. Serverless has been

another interesting challenge for Mongoose as well. How so? So one of the fundamental ideas of MongoDB is you kind of open up one connection and maintain it throughout the entire lifecycle of your application. But with serverless, that's not quite how things work. So we needed to do, there's always like a little bit of works that come in when you reuse a connection between different serverless calls. So there's always like little surprises of people saying, oh, hey, I'm running on Lambda,

and my functions hang for some reason after a certain amount of time. So figuring out what's going on there has proven to be tricky. Tricky. I mean, you told me about the Venom stack, so you're still into Mongo. Have you ever, like,

what if you fall in love with a new data store or something could that be a problem with Mongoose just like well I'm sick of Mongo or I don't like it anymore or I prefer this new and shiny thing like I don't know CockroachDB or something yeah I mean it's possible not yet though

it hasn't happened yet and a lot of the new databases that I have looked into, I like the fundamental ideas, but they just don't work as well as Mongo for what I'm trying to do. One thing that I really liked about Mongo when I first started is it's kind of like the first database that I worked with where running it was just a single command, just a standalone binary.

You download a tarball, you run MongoD, it works. You don't need to install Python 2.7. I have a former colleague who's working on like YugaByteDB or something like that. I've never heard of that one. It's like kind of a distributed Postgres compliant SQL thing. I'm not really sure what that one is. But that one, I'm like, oh, hey, let me try this out. Must have Python 2.7 installed.

Nope. Done. Oh, yeah, no, because I'm like, okay, I went through all this effort to set up Python 3 for a work project that I'm working on. And now all of a sudden, it's like, oh, I have to set up a virtual and so I need to run Python 2.7 so I can just try this database. It's too much effort to just try one thing. I've been looking forward to playing with Datomic and I did back when it was, I guess,

it was something that you could run locally. And they have a lot of really cool ideas with Datomic, but just like the basic DX isn't quite there because you have to point it at AWS. There's like a whole long setup where you need to go through and be like, go into AWS, set up this IAM user, set up this

particular thing, install this thing from the Amazon Marketplace, and now we can finally try Datomic. That's too much effort, guys. One command, I'm out. Exactly. It's 2019, guys. Go has been a thing for so long

that there's really not much reason for you to not offer at least some minimal statically linked binary that you can just run to test something out it's interesting on the ease of use but also just system administration when you talk about a data store I know I enjoyed Mongo when I was thinking around with it and I remember distinctly getting to a point where I'm like, okay, I need to take this now into production.

And I just am more comfortable. I've been a Postgres user for pretty much my entire career. And I just was like, I'm just so much more comfortable deploying Postgres into production. Not that Mongo, I don't know if Mongo is hard or easy or otherwise. But when I got to that point, I'm like, oh, this is another thing I'm going to have to learn is like administration of a new data store. And that for me, similar to you, where it's like, give me the one command and I'm out, or the statically linked thing. I don't want to install stuff myself or I'm out. For me, I just don't want to learn to maintain something else. Well, I already know how to maintain this

thing that works pretty well and has added a lot of niceties around JSONB and being able to store things a little bit in non-normal form. So yeah, it's just funny how different things catch up different one of us. Yeah, exactly. And that's one of the reasons why I continue to run Mongo in production as well. You know how.

Yeah, I'm used to it. I understand kind of the tooling around it. Mongo has made it a lot easier with their Atlas solution, which is MongoDB as a service in the cloud. You just kind of click in a web UI, and all of a sudden you have a production MongoDB instance with monitoring and backup baked in. Nice.

Yeah, MongoDB backups are so good. I am so happy about that. It has really saved my company quite a couple of times. It's like a point-in-time snapshot recovery is amazing. So somebody accidentally fat figures and drops the database at 11.56, you can restore the database to what it was at 11.55.50. Oh, really? Just like right before then?

Yeah, exactly. You know, modulo, like, whatever, clock skew or time, minor time inconsistencies. But you can pretty accurately get, like, what was the database like at this particular minute of the day, which is pretty amazing. So I talked to a lot of maintainers, and you're going strong here five years in. It doesn't seem like you have, you know, burnout you got a github streak going you're ready to maintain this seemingly into the future unless you fall out of love with mongo db which probably won't happen in this case or if automatic kicks you off the project which also probably won't happen at this case do you

have any advice tips tricks like things that make your life as a maintainer easier that you've learned over the years that you could share with us, maybe people who are struggling a little bit more. And maybe you are struggling, you just put on a good face about it. But what do you have for me in terms of ways that you go about doing what you do? I think number one thing that helps keep me sane

over this long time period was I learned very quickly that if I just respond to every GitHub issue as it comes in, I'm going to lose my mind. So no email notifications, none of that, just respond to GitHub notifications in batch. So I just have like a separate, just a separate filter that filters all Mongoose traffic into a label in Gmail. And I just go through it maybe once or twice a week

if I have time. Sometimes with a glass of wine if I'm feeling a little too shrunk up. So yeah, that's one thing that's really helped keep me sane. Moggage does have a Slack channel, but I don't really check it as often as I would like just because I realistically just don't have time

to answer everyone's question. And there's a lot of people on the Slack channel that come and go and respond to questions as they can. But realistically, just being okay with the fact that you're not going to answer every single question that comes in on Stack Overflow or Slack. And if something comes in on GitHub, do what you can take a look at it. Also setting up kind of boundaries and expectations for issues on GitHub, like the GitHub issue templates. Something that I didn't adopt as quickly as I should have, but it's something that somebody put in a pull request for. And to be honest, it's been quite great because it's kind of helped people see, like, people always say, oh, there's this particular bug, and if I can't really reproduce it locally,

if it's just a long, big paragraph of text that's saying I'm just doing this one basic thing and everything's breaking, and I say, well, we probably have a dozen tests that cover that case. So it's clearly not that. So there's something else in here. There's,'s like some variable that you're not accounting for it seems like with a with a library that has both a runtime right it's got a language runtime and it has a connection to another thing you have a lot of

moving parts in terms of what mongoose has to do to do its thing so like what version of it seems like there's a lot of version mismatches that could just be problematic. Like what version of Node are you running? What version of Mongo are you connecting to? What version of Mongoose are you using? These are probably things that probably like if you have any of those older or outdated,

you might run into bugs that are otherwise either been fixed already or just don't happen with newer versions. Like a newer version of Node comes out. You have a lot of that stuff going on? That I don't really get affected by as much. For the most part, Mongo has been... Pretty stable.

Yeah, it's been pretty stable. And also, what do you call it? Mongo hasn't really been broken by a new Node version in a long time. I think kind of the biggest thing was, the biggest one recently was the changes to the custom inspect functions. That caused a little bit of headache, but we needed, but not too much. Mongoose is not the only thing that's built

on top of the MongoDB driver on NPM. There's a lot of other things that are built on top of the MongoDB driver on NPM, like ConnectMongo or ConnectMongoDB session, the express session stores. There's Agenda, the task scheduler, all these other projects. And now what happens if you have an old version of ConnectMongo that's using an old version of the Node MongoDB driver, and then you take a MongoDB object ID object from this old version of the node driver and pass that into Mongoose, which is using a totally incompatible version of the

node driver. That kind of like version resolution thing ends up being a bit of a mess. So was that something that you found out on your own or did your users dutifully tell you about it when the bug started hitting? Oh, no. These are just the sort of issues that sometimes pop up. They come up every once in a while where someone is getting a warning message and it's like, oh, wait a minute, where's this warning coming from? Because you're using this version of Mongoose. So why don't you just give me your NPM list type grab Mongo output and then and then we can see like where that might be coming from. So one thing you mentioned earlier, and I was gonna follow up on it, and I forgot to, but I'm remembering now is you said, well,

I've been considering like a TypeScript stuff, I as the as things change around me, as the ecosystem moves more so than Mongoose moves, you have to consider new things i was looking at the stats and 99.3 javascript only 0.7 other which is probably just the markdown files or you know maybe that yeah markdown css yeah exactly i mean this is like a pure javascript thing and it has been probably the entire time what are your thoughts around typescript is that something that you're considering using or trying? What are your thoughts there? I mean, I've been tempted to try playing with TypeScript, but it's something that I haven't really found a use for yet.

Mongoose would be one project where I would either be interested in someday supporting official TypeScript bindings or maybe even porting parts of the project to TypeScript. But Mongoose is a very different project than most other projects. Like in my day job, I would not recommend we use TypeScript. And I've been very adamantly opposed to us using TypeScript at all. Because we don't really have like a very deep, like a very deep code base in my day job. Things end up being pretty flat where it's just, okay, here's an Express API.

Here's a route handler. We've got a little bit of wrappers around it to make it so that, you know, we can use async await with Express. And then we just kind of write a bunch of functions. They don't really share too much logic other than a database connection. They just do their thing. Our UI also is relatively flat, passing data down. The component tree isn't too deep, maybe like two or three layers. So putting in TypeScript for that, there aren't really too many massive pieces of code in our code base that kind of share a function

call interface with each other it's more just okay here's a big front end or here's a big wide front end here's a big wide http api they need to be able to communicate with each other and typescript doesn't necessarily help with validating that because typescript is compile time only, not runtime. So if you're relying on TypeScript to check the parameters coming into your Express API, it'll check that it's technically correct at compile time, but a malicious user can still throw in a bad request. Yeah, exactly.

So we talked about tips and tricks. Let's talk about services or tools that you use with regard to Mongoose or any of your open source work that you is there anything that you think i couldn't live without this i'm so happy i adopted this pattern this tool this library this service whether it be free or paid that others might find and be like oh i should try that for my open source project there is this one tool that i built called acquit back in 2015 that has been one of the most important things that I've worked with.

The general idea there is it compiles Mocha tests into documentation so I can more easily maintain my docs. I want to make sure I have the examples that I'm showing are correct so it helps me stay confident that the releases or changes to documentation that I'm showing are correct. So it helps me stay confident that the releases or changes to documentation that I'm putting out actually make sense with the current API. So that's a big one. What was it called again? I'm looking it up now.

Acquit? Acquit, yeah. Like you're acquitted of a crime or whatever. Or you've acquitted yourself well. Gotcha. Let's see. I actually use that to also write my my two ebooks and now the uh the third one that i'm working on also still uh still with equip so like you know i have like ci set up

for my uh for my ebooks which is pretty great nice that's uh you're ahead of the game on that one so links to equip will be in the show notes anything else that you use whether you wrote it or somebody else did that's uh you could recommend to somebody who's either writing similar libraries or maintaining things as well? I am a big fan of Mocha, the test framework. That's my go-to right now. I feel like it attracts a good balance of minimal API with just enough stuff to be useful.

So yeah, big fan of that one. Although I guess I am technically on the MochaCore team, so maybe it was a survey. Let's see here. I do love ESLint. It took me a while to kind of like warm up to it because I was a little worried about it. I wouldn't say, yeah, worried is kind of a weird term.

Concerned. I guess what i wanted to say about es lint is that for a while i just didn't think like i would get too much value out of it and it seemed pretty overwhelming to lint the entire mobius code base because the style was a little inconsistent when i first started but like once I kind of got past that initial hurdle, ESLint has been quite great. Helped me catch quite a few bugs. And there's a pretty surprising amount of cool things you can bake into ESLint. The serve module on NPM.

That one is also a pretty important module in my workflow. It's more of a command line tool for spinning up a web server. So just serve dot gives you a web server that just serves up the current directory over HTTP. That one is pretty amazing for testing docs sites. And I've been looking to migrate Mongoose over to using it, but most of my other stuff already uses Serv. Serv is great. Another reason why I really like it is just like it has like really great developer experience

baked in. Little things like when you run Serv. it automatically puts the URL to your clipboard so you can just go to the browser, control V, and all of a sudden, you're looking at your directory. I love when there's projects where you can tell that the person that created the project really uses it all the time, because those little niceties are there, because they just think about them as they're building it out. And they're using it so much that they think, you know what would be nice? Like this little thing. And then they go ahead and add it. You can always tell when there's something that's kind of a tool that's beloved by the creator itself and uh that's awesome i'll just check that out so let's focus

now on some people so you're talking about some tools links will be in the show notes to acquit mocha eslint and serve of course for those interested but what about other maintainers is there anybody you look up to or appreciate? Somebody who does a really good job maintaining open source software or writes a lot of software that you consider to be high quality and you'd like to share them with us? Yeah.

I'm always reading Tuolity or however you pronounce that. Dr. Axel's blog. Excel. Excel Rauschmeier. I don't even know how to pronounce his name. I never spoke to him in person. All I know is his content is great, and I really enjoy it.

Let's see here. Also, Gleb Bakhmutov. I'm not sure if I'm pronouncing his last name correctly, and I should because I'm Russian. Well, whatever. I probably messed it up, but he's the VP of Engineering at Cyprus. He also has an excellent blog. I've known him since, what do I call it? He and I actually got acquainted because he found Acquit back when I first put it out and this was back in like 2015 when he was working

at Kensho which was a startup that got acquired a couple years back. So I almost got a job at Kensho but ended up passing, well ended up up not getting the offer and Gleb and I have been, what do you call it, well we've corresponded every once in a while ever since. Yeah, his blog is great. Another interesting little bit of backstory. I interned at Google back in, I want to say it was summer of 2009 when I was in college and my mentor when I was in college. And my mentor when I was there was a gentleman named Mishko Hevery, who was like one of the original authors of Angular 1.

I remember I met Mishko briefly. I think I was at the inaugural ng-conf. And a very smart guy. Yeah, yeah. So getting to work with Mishko for a summer was pretty amazing. He taught me pretty much more about software engineering in like 12 weeks than I learned in my first three years of college. So he was a big influence on me and I look up to him a bit. Another guy who used to be on the Angular team, Vojta Gina, who originally wrote Karma. Karma is one of those tools that I really thought was extremely well done.

You can kind of tell that Karma was actually Vojta's master's thesis project. He wrote a thesis about it and then implemented it as an open source project and then actually got great adoption as well. So it was great to see like that whole uh that whole process that he went through to make that happen although i'm not actually sure where he is right now last i talked to him he joined apple for a while i don't know what he's doing now yeah his um karma was like a pretty amazing tool at the time really groundbreaking cool val well uh last thing i'll ask you is if you have a call to action or if you have anything in particular with regard to Mongoose, or I know you have some e-books in the JavaScript space

that you'd like to have the community rally around you, support you, help you, get involved with anything, what would you say to the open source community out there with regard to you and the projects that you're maintaining? Yeah, check out my ebooks. I have an ebook on generators and more recently an ebook on async await. Just look up mastering async await. The website is asyncawait.net. Put that out about, I want to say last June, and just kind of like distilling all the patterns that I've learned from using async await and before that co and generators over the last several years. from using async await and before that co and generators

over the last several years. I think async await will kill or change the way we think about JavaScript, the JavaScript frameworks in particular. A lot of JavaScript frameworks, especially ones that kind of predate 2015 were written kind of one of their core tenants was to minimize the amount that you had to use callbacks. And now that we don't really need to use callbacks, we need to, JavaScript is going to have to evolve. And I think mastering async await kind of helps you see how JavaScript is going to evolve in response to async await. Awesome, Al. Well, thanks so much for coming on.

Thanks for all the work you do. And I'll just encourage you to keep up the great work and keep that GitHub streak going, man. It's long enough now. You can't stop. Keep it going. We'll see. It's got to stop at some point. Thanks for having me on, Jared. It was great. All right. Thank you for tuning into this episode of The Change Law. Guess what? We have comments on every single podcast episode.

Head to changelog.com, find this episode, and you can discuss it with the community. Huge thanks to Tidelift for their support of our Maintainer Spotlight series. And, of course, thanks to Fastly, Rollbar, and Leno for making everything we do possible. Our music is produced by the one and only Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for Changelog Master. You'll find it. Subscribe.

Get all of our shows as well as some extras. Only hit the master feed. It's one feed to rule them all. Again, changelog.com slash master. Thanks for tuning in. We'll see you next week. Thank you.