OK, well, thank you, everybody, for coming to my talk on Beyond REST, contract testing in the age of gRPC, Kafka, and GraphQL. My name is Matt Fellowes. I'm a Principal Product Manager at SmartBear. I was a co-founder of Pactflow, which joined the SmartBear family back in April this year. And I'm a core maintainer of PACT, which is a consumer driven contract testing framework, an open source one. And the subject, or the course, up until much of today's talk.
Prior to working at Pactflow, I was a consultant. I'm a recovering consultant, and I was lucky enough to work at some of Australia's biggest and largest well known organizations and their distributed systems, and really seen them evolve over my career. There have been, of course, a huge amount of technological change since the days where SOAP, which was the predominant technology when I joined the industry, over the years. And in my relatively short career, I've worked from that SOA, SOAP starting point to rest and microservices, the rise of public cloud and IOT, event sourcing, events framing, modern data pipelines, and of course serverless architectures. And I found in many of these situations and contexts that contract testing was still really relevant and would often look to introduce contract testing into places where there was benefits we had in shifting left, moving faster and solving those problems in itself. But of course during those rollouts or often, I would be on the receiving end of some kind of snarky comment, usually from another competing consultancy of course, that had the following shaped argument. If we just used insert blank technology, then we wouldn't need contract testing. But is it true? Well, today we're going to examine that statement. We're going to ask the question is REST really the problem? And could we save ourselves the trouble of having to think about contract testing, running tests by using a superior technology to API communication? We're going to learn briefly what contract testing is, why it exists in the problem that it solves. And we're going to look into, you know, to see if history is repeating itself or if these new technologies and architectural trends really do solve the problem. Specifically, we're going to look at a few classes of technologies. We're going to look at specifications such as OAS and ASIN KPI to a degree, GraphQL and also IDLs and things like Protobufs and Avroans, Rift. There are of course others, but these are by far the most common alternatives suggested to me by my consultant interlocutors. We'll look at these from a general contract testing lens, but of course we'll use PACT, which is obviously a tool that I work on, as a concrete implementation to help us understand and how it works in practice. And hopefully you'll see that, you know, while PACT has evolved to meet some of these needs, we'll also see that the problem and solution is much more general than any specific technology or language that we've discussed today.
Let's quickly talk about, you know, or understand why contract testing exists and the context in which it operates. I think starting with a customer quote is a good way to set the scene, just to help us, you know, feel the problem. This is a quote from a PACT flow prospect reaching out for some help and for argument sake and to protect the innocent, let's call him Bill. And Bill is a leader of a testing organization for over 40 teams in a very large banking institution. And you can see here, he's basically describing working in this big environment with a highly volatile, sort of, you know, testing environment, which makes it challenging, and he's trying to work out how he can use contract testing to test, you know, all the things he's got. He's got RESTful services, GraphQL, Kafka, third party systems, you know, all these things, right? And where you can take away from this, he works in this chaotic environment, it's complex, and he's looking for ways to bring some process and control to that situation. Now, if it sounds anything at all like your company or architecture, you're not alone. Research from SmartBear's state of quality, as well as Postman's API report, really back this up. And we can see that, for one, internal microservices are becoming a massive focus for teams.
Comments