Once a Maintainer: Robert Mosolgo
Linguist by background and creator of graphQL-ruby
Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story. We’re back with a great lineup for 2024!
This week we’re talking to Robert Mosolgo, creator of the graphql-ruby gem and prolific open source maintainer, linguist, and dairy farmer. Robert is a former Senior Platform Engineer at Github and was the first maintainer of the react-rails gem outside of Facebook (now Meta).
Once a Maintainer is written by the team at Infield, a platform for managing open source dependency upgrades.
How did you become a software developer?
I think it starts in like 10th grade with my TI-83 calculator. When I realized that I could create games using the digits and numerals. You know I read somewhere recently that in the past, I think it was in a military prison - people would teach each other languages, passing strings with knots tied in them. It's like, man, when you're in 10th grade science class and you have nothing else to do, programming your calculator seems like a great idea.
I didn't code at all in college. I studied Chinese and linguistics, but I graduated and none of my job plans panned out, so I ended up kind of pushing papers in a professor's office, working on research projects with him. And that's when the opportunity to start writing code again came up as I was smashing CSVs together and learning about relational databases. A buddy of mine said you would really love Ruby on Rails, you should really look it up. And I told him no. And he suggested it again. And I told him no again.
Why did you say no?
Because I had a thousand line php file that was doing a great job. Why would I learn something else?
Right.
But by the end of six months or something, I knew that I just wanted to write Ruby all the time. So I ended up switching jobs just to write code and and that was that.
What time period was this?
Oh, probably 2010-2011. I did Michael Hartl’s Rails Tutorial that had just been updated for Rails 3, and I think in the Rails 2 to Rails 3 shift ERB and Rails became one and the same and so there was like a gathering of momentum. I still think his tutorial is great.
Awesome. So what was the first job that you got?
The company is called Planning Center, and the short description is enterprise software for churches. So if you're scheduling musicians for Sunday church services and you need a bass player, a drummer, three singers and somebody to shake a tambourine, and you've got 20 volunteers, but you can't schedule so and so at the same time as so and so, and you can't schedule [this person] on the same Sunday that they're doing the sound board and you put all these rules in and it gives you a schedule, sends everybody emails. That was that. Now it does a lot more. Every year that passes I realize more and more what an amazing company it was and the owner, also the head developer there was just doing great work and it was a magical time for sure.
Wow. So transitioning from the professional side to your open source work, or maybe they’re related for you - how did you first get exposed to open source software, not just as a consumer, but as a contributor?
In that job at Planning Center, we used JavaScript, and the JavaScript framework wars were just ending as React stomped everything else out. We had one guy who was still going for Ember.js, but we went through a company-wide project replacing everything with React. And there was a React-Rails gem at the time that I think had been put together by someone in Facebook just so they could say there is a Rails integration, but it it wasn't Rails-native. It was just someone’s job to say there was a Rails integration. So I was young and energetic and we started using that gem a lot, and it was almost like a coup. I just started answering unanswered questions on the issues and submitting patches for bugs that were reported. The guy was like, I guess I should just let you take this over now? Could you? And I was like, sure, thank you.
That's really interesting, because a bunch of the people that we've interviewed have said that it was really intimidating to even dip their toe into contributing. What gave you the confidence to participate in the conversation?
I was young. That was a good confidence builder. And, now that I think back there was a first stop. So the JavaScript framework that our company was using at the time was called Batman.JS. It was from Shopify. There are no traces of it on the Internet anymore, but it became clear by the time that I joined Planning Center that Shopify was not actually using Batman.JS, that they were not answering questions. But we had made a big company investment in it and so, looking for a way to make my mark on the company, I devoted myself to becoming the Batman.JS expert in house. And I think at a certain point I was the worldwide Batman.JS expert. So I became the expert in a dead open source project.
But I did learn a ton because it was this full stack front end framework in the sense that it had a router and models and a network layer and views, etc. It was a great learning experience.
So how did you get into GraphQL?
Planning Center sent us to conferences, and they sent us to the first ReactConf at Facebook headquarters. And gosh, we were so eager to go to that conference that we - this is a long story.
They were selling tickets through some kind of ticketing website that we'd never heard of, and we realized that they weren't selling tickets until you know, 9 am on such and such a day. But we realized it was just a client side implementation to keeping you from submitting the form, and we were like, I think if you just open the console and submit the form it will go through. So we did that. We paid for our tickets, but we got in before it was actually open.
There were a lot of interesting ideas at that conference. But at some point during one of the intermissions, they get up and say “Is Robert Mosolgo here? Would you stand up for a minute?” They caught me for for getting my ticket too soon and he said, “We wanted to thank you for taking over the React-Rails gem” and you know, all of your contributions.
It was at that conference that Dan Schafer, and he had a co-presenter whose name is escaping me, described GraphQL and its usage in Facebook for the first time. If you were to go back and look at that conference, you would see the language is different than it is now, but my eyes lit up. I have a background in linguistics and I worked in Ruby on Rails, and I could just see how these things could be really useful. And so I went home from the conference and I pushed an empty gem to the GraphQL name on rubygems.org and decided I was going to do the thing.
Can you talk a little more on the linguistics side? What hit you as Rails and GraphQL, there’s something interesting at the intersection there?
I had recently read the book Ruby Under a Microscope and it's just such a fantastic book, and I loved thinking about how programming languages do their magic. And so you know, having the practical experience to recognize the upsides of using GraphQL, especially when you're fetching data for React and seeing that what we needed was a language implementation, I thought it would be fun.
Language implementation meaning writing the actual interpreter for the GraphQL.
Yeah, like that idea of translating this new kind of programming syntax into the query side. To me computer languages are way easier than human languages, so it made it seem like fun for sure.
How did you find, after creating the gem, being on the other side of it as a maintainer? How did you find interacting with the contributions that you received from the community?
Certainly, mostly good. Especially in those early years. So many people were so hyped up, excited, trying things out, making suggestions. I think at this point, a bit like Ruby on Rails, people take the functionality for granted and they expect it to do what it does and understandably there's a little less wiggle room for for imperfections or shortcomings. And so there's a lot more of you know, I downloaded this and I expected it to work. And for some reason it didn't.
But the other thing is, there are plenty of companies who have made deep enough investments in graphql-ruby that there are a handful of contributors out there who come out of nowhere with a really great patch. There's nothing like waking up to the notification that, you know, somebody's opened a pull request and you read the description, and you can’t think of how you would have done that. This is great. Just click merge and you're done. And I really love that.
Sometimes there's more back and forth. Somebody has a question and got halfway, and then I get to actually be useful. Point them where they need to go for the other half of the way, and I really enjoy that kind of deeper technical conversation. I've been doing a lot of that especially with folks at Shopify this year, working on performance and it’s been a lot of fun.
So you needed to write a parser for the GraphQL gem. As someone with a non-traditional academic CS background, how did you learn how to do that? That’s a hard thing to do independently.
My first parser was written with a ruby gem called Parslet and it has parsley themed documentation and it's super easy. You describe the parser in Ruby and it just makes Ruby objects that parse code. It's not really a parser generator in the more heavy metal sense, but it worked great and it was good enough to get started.
I guess my point about a background in linguistics is that parsing is probably the most familiar thing. If you've taken linguistics courses where the assignment is like, hey, here's a paragraph or here's five sentences in a language that you've never seen before, where are the boundaries between subject, object, and verb? And you've got to recognize the pattern and break it apart into pieces and put it back together. And it's very fun and very similar to parsing a computer language. So bridging the gap from that rusty school knowledge to the Parslet documentation and all of its little vegetables was a bit of work. But it came naturally enough, and it's been and remains a really fun area for nerding out.
There are just so many ways to optimize and improve the parser. Last year, you know, after Parslet, I wrote it in Ruby's own parser generator library called racc. It's a spin on yacc, and it has a similar arcane format for describing how the language is constructed. And it worked fine. But people were always complaining that it wasn't fast enough, too much memory. So this summer, all right, fine. I started from the Ruby grammar. I wrote a yacc grammar that generates a C parser, and it still makes AST nodes in Ruby, but it's 10 times less memory and 10 times faster. But recently, a few months ago, Aaron Patterson wrote a plain Ruby parser that's faster than the C parser once YJIT is warmed up. So now the ball is in my court to get the takeaways from his work and and put them into real life production. So I'm looking forward to giving that a try.
How do you balance the open source work that you do with your day job?
I don't have a day job, which is sweet. Seven years ago it became clear that GraphQL was gonna be a thing, and companies were downloading the gem and starting to use it. And I thought, there's a good place for me to formalize my relationship with them and a good way for me to make some money on all this work that I'm doing, if I do just like Mike Perham has with Sidekiq and Sidekiq Pro and Sidekiq Enterprise.
I don't own a private island like Mike does. I don't think he owns a private island, but I think Sidekiq makes a lot more money than GraphQL Pro, but it pays my bills and I don't have to do that balance. Besides that, my family just moved to a hobby farm this year, and I got to milk cows for the first time, which has been like a five year dream for me. And now I've practiced with other cheese makers and helped out at other people's farms, and so now my cows will make cheese which is sweet.
What other projects are you using now that you think are interesting, or you want people to know about?
I would say probably the newest thing that is on my mind, but it's not that new anymore, is the Fiber API in Ruby. It’s been around for a long time and it's been getting better more and more recently. Samuel Williams is the main hero champion of it right now and he's got a gem called async that once every three months, I work as hard as I can to make async and graphQL-ruby work together, and I have not quite gotten there yet. I keep getting thread deadlocks and I keep getting core dumps from crashing Ruby. But the possibility there for really easy, true parallel concurrency in the Ruby code you already have is really promising.
And I'd say in general, the performance folks at Shopify who are working on YJIT - I'm rooting for them, because I love writing Ruby and I don't want to have to write another language just because Ruby isn't fast enough and it's such cool work the ways they're optimizing it. So those are probably the two things most on my mind right now.
Ruby itself is a hard to parse language. I guess it's got so much syntax to it. Has it gone in the other direction for you at all? Have you gone back to linguistics groups and tried to take anything you’ve done back to that domain?
I have. I've just started what I think of as a 10 year journey to learn Biblical Hebrew, which is kind of crazy. In studying the translation from the Hebrew Bible to your off the shelf English Bible I’ve discovered a deep, rich world of the historical interpretation of the text. So it's not really related to programming. I'm a year in and I can sound things out and I know some words, but it's very much a slow burn and it's probably the hardest language I've ever studied.
To suggest a maintainer, write to Allison at allison@infield.ai.
If you’re interested in learning more about how Infield can help your team keep its open source dependencies up to date, even with breaking changes, write to hello@infield.ai or check out our website.