Annyce Davis, @Meetup

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have Annyce Davis, vice president of engineering at Meetup, and she shared with me the best answer to why a company has adopted GraphQL that I’ve seen, leaving me impressed with what Meetup accomplishes with APIs.

I always start simple, start with the basics. Who are you and what do you do?

What do I do? I do, but these days I’m primarily responsible for a GraphQL API as well as our native applications.

So tell us a little bit about your journey. How did you end up in this world at Meetup? Where’d you get started with your career?

Yeah, a great question. It started a long, long time ago as a little person. I used to love playing this game called Number Munchers, and my teacher told me, hey, if you want to do something like this when you get older, you have to become a computer programmer. And so that was pretty much it for me. Ever since then I wanted to become a computer programmer, so I did. I studied computer engineering in college and then I started working as a programmer. So it’s been a fun ride.

So tell me, I think most people listening to the show are familiar with Meetup. Especially in the tech industry, we’ve all had quite a bit of exposure to the magic that I think you all make happen. So what’s the role of APIs at Meetup?

Yeah, APIs are just central to everything that we do at Meetup. As I mentioned, I’m primarily responsible for our GraphQL API, keeping that performant. It serves all our front-facing clients, so if you’re using your phone, the native applications, or if you visit our website, the API powers all of that, as well as we do offer special API access for some customers who want to just query it directly themselves, which is another interesting use case.

So a lot of folks are aware of GraphQL, it’s definitely, I would say, one of the top types of APIs, flavors of APIs, however we want to frame it today. But what’s the decision making behind choosing GraphQL and moving from a REST infrastructure?

We wanted to experiment with Meetup changing some of the core business model, and it made sense to spin off a separate GraphQL API in order to power it. And then over time we just started seeing how more of our full-stack engineers, even sometimes our apps engineers, can contribute to the GraphQL API, mostly because of some of the simplicity that it offers via the resolvers, as well as on the client side we can say, well, I want to now show a save button here, well that’s already exposed via GraphQL, so just add that field to your query and you’re good to go. So that has really caused us to invest heavily in using GraphQL at Meetup, and it’s been a really great decision for us.

So I think one of the things, I’m seeing GraphQL adopted in fairly large organizations, because they have such an expansive data graph that they need to expose. I’m curious how big of an organization is Meetup?

Meetup is so small. Meetup is less than 100 people, and I remember when I joined Meetup about three and a half years ago and I started to learn about the architecture and some of the functionality, and it is deceptively complicated for an app where you say, like, I just want to go to an event, or I just want to host events, but we offer so much customization, so many hidden features that you don’t even know about. Honestly, I was just blown away by how much is actually Meetup. And also keep in mind Meetup is 20 years old, so there’s going to be a lot of legacy things that are still there that kind of get in the way of some of the things that we want to do at Meetup. And so you always have to keep that portion of infrastructure or product work in mind as you’re moving forward to make changes.

Yeah, it’s interesting just to hear that you’re so small, because when we first talked I was kind of blown away. I just had something else in my head, because y’all have been here for my entire kind of last phase of my career, and so I just assumed it was like GitHub or some other company and just super large. But you’re in charge of engineering. How much of your day-to-day is business versus technical things, do you spend your time on?

I’ll say probably 20 to 30 percent maybe business things, and the rest is very technical. Just to give you an example, business things, negotiating contracts, meeting with a new vendor, following up on these other kinds of things. There’s always a lot of administrative work that needs to be done. And then as far as being technical, that’s where I get to kind of get in the weeds a little bit, look at some performance optimizations, learn about new things that are coming along, and just monitoring the health of the organization and our platform overall.

So as a technical person, how much of the business should us developers understand when it comes to doing APIs? Do we need to be intimate and aware of how business works, or is it all right if we just kind of stay in our little rabbit holes and focus on the code bits?

Yeah, I think it’s good to come out every now and then and take a look around at what’s happening with the business. I know before, as an engineer, when I was just an individual contributor, I thought I knew what was going on with the business, and I would say, like, why don’t they just blank, you know, it’s so obvious, they should just blank, what are the business people doing, they don’t know anything. Right? Because when you’re a programmer, you know everything. And when you start to learn more about the business, learn about how does a business make money, what counts as revenue versus an expense, what’s the difference, where are the buckets of money, how is it allocated, how’s it affect, impact taxes? Do you need to know about every single thing? No, but just knowing that there’s more nuance there than you’re probably aware of, I think it’s really healthy. It helps you to build empathy for some of the decisions that the business makes a lot of times that maybe you might not fully understand or agree with. And I also think that it helps you as an engineer to make sure you’re optimizing for the right things. So if I can just give an example, what if my company is looking to get rid of one aspect of our project and use a third party solution? Would it make sense for me to spend all my time, oh, let me make sure that this is redundant and I’m backing this thing up and it has the perfect architecture and everything is abstracted away, or let’s just make it work, because next month we’re giving it off to a third party? Of course it would be a no-brainer. So you need to know what’s going on with business also to help you make smart decisions as an engineer.

Yeah, I agree, and I see this divide between business and IT kind of narrowing. I think it still exists, and we need people who are specialized in each area, but I see a lot of the classic divide closing up. But coming back to the GraphQL, because I think a lot of our audience is going to be very curious around, they’re dabbling, they’ve made a decision or they’ve been thinking about implementing GraphQL, what’s been the biggest benefit as far as having GraphQL in place for your team?

Yeah, so I’ll say one is that we understand what is available. I know like in the past maybe we had Swagger, or we’ll have the REST API, and we were just pulling tons and tons of data, too much data, different REST requests. Over the years, as I mentioned, Meetup is super old, so maybe there was some reason why we needed all of that data, and then we changed a UI and we don’t need that data anymore. So on the apps it was always so slow downloading tons of data that we didn’t even end up displaying to the user. So I’ll say one benefit is just performance, that we only pull what we need. I’ll say another benefit is understanding the business, like, these are the groups, the networks are comprised of groups, these groups have events, attendees go, attendees have this, they have tickets, this is the status. I think for being so small, we can’t afford to have knowledge silos where only some people understand the business and know about what makes Meetup tick. Having the GraphQL API has really helped so much, where I know personally I have such a much better understanding of Meetup and how the pieces fit together.

I like that, because I think that reflects what I’m seeing with a lot of groups. They’re just trying to get a handle on that data graph, that sprawl. It’s almost become like a Los Angeles or Atlanta when it comes to the neighborhoods, like it just goes on, you can get lost, you can get lost in those neighborhoods sometimes, where am I, how did I get here, where am I going. And so I think that’s a pretty good reason to jump in. But on the flip side, what’s been some of the challenges in adopting GraphQL, would you say?

I think one of the biggest challenges is not fully letting go of REST, and it just takes so long to deprecate the REST API. So it’s like, first of all, you have to make sure that you’re instrumenting everything properly to try to nail down who’s even calling it, and is it important enough that we don’t want to break it for said person. So it took us a while to just get all of our Pro clients off of REST and onto GraphQL. Once we were able to do that, it’s like, yay, victory, now we have to finish getting off of it ourselves, and just going through, okay, this team, can you make a corresponding query in the GraphQL API, great, now adopt this new query, wonderful, now wait two, three months for people to upgrade their apps, and we no longer have to support that one endpoint. And then while this is all happening, business happens. You never stop building features, you never stop releasing things. So it’s difficult to justify, oh, don’t build any features, instead just deprecate this endpoint, it will be the exact same experience for the customers, no. So for me I think the biggest challenge is just completely being on one system and fully deprecating the other one.

Yeah, it seems like it’s really helping you manage change in a way that’s positive, and I don’t think, not that REST can’t manage change in some ways, just knowing how to manage change with REST I think isn’t a widely shared knowledge, and not everyone is on board or knows how to do it. In GraphQL it definitely kind of comes out of the box in adapting and evolving with the different applications you’re going to use.

Yeah, I have definitely seen it to be the case.

So speaking of change, what’s changed during COVID for y’all?

Yeah, so we’re Meetup, and we were all about people meeting together in person, real human connections, and when COVID hit we really had to make an adjustment, and for the first time ever we introduced online events. And that was huge. I remember when we were initially thinking of it, everyone was like, how in the world can we make Meetup work for online events, there’s nothing in our schema or our database tables, the fields, that could support this. But we were already using GraphQL, and so that was just like the perfect thing, because it’s an abstraction layer, so we could say, hey, everyone start calling this new query and you’ll get some online events data, let’s create a new mutation and then we’ll call that mutation and we’ll say, hey, this is an online event and the venue just happens to be in the middle of nowhere, great. So we were able to sort of hack our own system using GraphQL to support online events, and we did the whole thing in about a week. So honestly it was so impressive, and it’s one of those make-or-break moments in a company, and thankfully Meetup was able to pull it off, because I do strongly believe that it’s good for humanity, and it really does help people do things with someone that has similar interests. So I’m really proud of us for the work that we did there.

Yeah, and I think you all are straddling the line between, we all still need to meet up and share knowledge and share information, we’re in this weird moment where we can’t get together, but then we need to go back, but maybe not all of us can go back to in person, and so hybrid events. And it sounds like GraphQL is allowing you to kind of really flex with that. And I like the Meetup is nowhere, because the virtual events, I feel, my team, my DevRel team, we joke it’s like screaming into the void, because you’ll be talking sometimes and who are you talking to, and so I like the meet up in nowhere.

Yeah, it’s like, is this thing still on?

Exactly, and I’ve done that and had, yeah.

And I’ve done that and had like three or four hundred people listening, like, yeah, we’re all here, we’re listening, we’re interested, it’s like, oh, okay, okay, well thank you.

So how about your consumers? You say your website, mobile, are consumers, but how have your partners adapted to GraphQL? Are they pretty open to this change?

Yeah, so a lot of the Pro customers who had to switch from REST to GraphQL, we tried to do it in a very gradual fashion, so we wrote some documentation, I tried to look at the REST requests that they were making the most often and then add that to the documentation as well. So, hey, you want to get a list of all groups in your network, this is the REST endpoint, and now this is how you do it with GraphQL. And so I will go through, just based on data, look at the types of requests they were making and say, here’s how you do it on GraphQL. And then for a few people, actually just hopped on a Zoom call and said, okay, show me your code, show me your queries, what are you trying to find out, oh, okay, this is what you need to do, this is this sort of object. It was very high-touch, white-glove treatment, I’ll say, but in the end it worked out really well, and they were appreciative and grateful that they can still query our API in a way that worked for them. And then also for several of the people this was their first time working with GraphQL, so they were just kind of excited as well to be able to try out this technology that has kind of taken over the industry.

Yeah, do you feel like you learn from those high-touch engagements and learn from the consumers as well?

Definitely. You assume that you know what people are doing, because you have some data, right, I can look in a dashboard and see, oh, they keep using this endpoint, great, I’ll just make the same exact thing in GraphQL. And then you meet with them and you find out, actually we do these two requests, then we do this and put the data together ourselves, and then we loop over, and you’re like, wait, no, you don’t have to do that with GraphQL, one query, combine lists, it’s like, oh, nice. So I think for me it’s always just, don’t make assumptions, you think you know but you don’t know, you have to talk to people. I know I tend to be kind of shy and introverted, despite the fact that I’m talking to you today, and I’m like, Annyce, you just have to talk to people, you have to talk to them, find out what they’re trying to do, how they’re currently doing it, and what are the pain points, because people always have pain points, just because they’re doing something and maybe not complaining about it doesn’t mean that it’s working wonderfully for them. So I definitely get a lot of value out of talking to customers and just finding out what are their pain points, also what were we missing. There were a few things that I didn’t even know they were querying for and we hadn’t covered it in the graph, so I’m like, great, thank you for telling me that, I’ll make sure that I get it prioritized so we can expose that information in a query for you. So yeah, definitely talking to customers, I learned a ton.

Yeah, I think this has been the biggest advantage of APIs being more closely aligned with business, and not just the classic developers in the back room that you feed pizza to and they deliver an API. Because, I get it, that’s why I do APIs, is because, I was an old database architect and administrator, and APIs brought me out of that basement and got me closer to business and closer to needs, and I found that more nourishing than just hacking away at things. And I think we don’t always realize it, and we’re happy being in our little cocoons, but it’s actually better that we’re not.

Yeah, because as engineers we solve real problems with technology. It’s not that we’re just, oh, I love GraphQL, or I love REST, or I love any particular thing, our job is to solve a business problem using technology, for the most part. Most people don’t, the business doesn’t really care, as long as it’s not expensive. So it’s up to us to say, okay, well, what is the real business problem and what is the right technology that will solve it.

Yeah, agreed, I can’t agree more on that, that’s what I said. So what keeps you coming in every day to work?

Team. They’re very smart and humble, which is a great combination, one of my favorites. And I love the mission of Meetup. I love that we’re small, because I just get to wear so many hats, I mean one minute it’s like I’m debugging some performance issue in the API, the next minute I’m talking to the marketing team about how we’re going to put out a new program, and everything in between, and that’s really exciting for me. I like to have it be mixed up, and I like to be able to use my creativity in different aspects of the business. And also it’s a challenge. We’re still a business who is trying to help people form connections, that’s not a simple or easy problem, and so I look forward to trying to develop technical solutions to that business problem. So that definitely keeps me coming to work.

I have to kind of second that. I kind of owe a lot of my career right now to y’all and what Meetup does, because I’m an evangelist, I’m chief evangelist at Postman, but I have this blog called API Evangelist that I’ve run since 2010, and I’ve completely depended on the Meetup ecosystem in different towns and cities. And I used to literally live on the road and travel from Chicago to DC to New York to Atlanta to LA and do meetups, and I’m talking, these are technical meetups, so some of them are APIs, but some were like, in DC, that’s like Smithsonian data sharing for like African American history, and it’s like 15 people that are very specialized coming together to use the Smithsonian API to tell a certain set of stories. And so it’s that kind of enablement that really has given me a career and kind of built up all the people that I know. So that’s awesome.

I love hearing these Meetup stories. It’s like, Meetup is, just even before joining, I also used to meet up, also very huge part of my tech career and growing my network, and yeah, we’re still here, we’re still doing it.

Yeah, well, thank you for being there, thank you for doing it. I love the GraphQL narrative, I think it was one of the healthiest, pragmatic views of GraphQL that I’ve heard recently, so thank you for sharing that, and thanks for coming by today.

Thanks for having me.

Thanks again to Annyce for stopping by. You can find more about Annyce on LinkedIn, and Meetup you can find at meetup.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.