Seamless Upgrades: Mastering API Compatibility

So this session I’m going to try and wrap up by about 40 minutes or maybe 38 minutes, and then spend some time for the Q and A and then we’ll go to the hangout session. So this session is based on experience, at least the last few years, of helping really large scale products with mobile apps, web apps, multi channel applications. Basically, how do we ensure that we can seamlessly upgrade those channels so those apps? So we look at that.

 

So, quick question for all of you in the audience. When you release new versions of the software, how do you ensure that the upgrades will be seamless for your users? What kind of testing do you perform to ensure this happens? So if you don’t mind, can you please put this in the chat and I’ll quickly look at the chat? So depends on the approach of the team. Backward compatibility testing, backward compatibility testing, different user types, sanity testing. Yeah. For instance, regression testing. Absolutely cool. Those are good answers and I think I’ll quickly share my views on them. So, like some of you rightly pointed out, there’s both the functionality in terms of the functional and the visual regression testing.

 

And you would also ensure compatibility across different devices, different operating systems, different screen sizes and stuff like that. Right? So that’s the first form of testing typically you would perform. I’m sure you would also be keen on, especially for large scale applications. You would also want to make sure that from a performance point of view, you are doing the load test, the stress test, the soap test, looking at things like how long it takes for the first bit to render, and so forth. Right. There would be privacy and security related tests. You know, where you also want to do vulnerability assessments, you want to do pen tests, you want to ensure from a compliance point of view. You know, you do compliance testing, you do usability and accessibility testing.

 

That’s also extremely important to make sure that your applications are accessible to all user base. In a lot of places these days, people also do canary or multivariate like A/B tests kind of things to basically make sure that they can make more informed decisions on how certain features are being perceived and stuff like that. In more really complex applications where you really want to test things at really high volume and high scale, you might do shadow mode testing where you might run the new version of the application parallel, especially on the back end side of things, you may want to run that in parallel to your production system. You know, split the traffic, or rather copy the mirror the traffic and send to both. And then on the way back store the responses from both and then look at the diff or a delta between the two before you do a promotion. So shadow mode testing, the one that we’ll focus today, and I think this is the one that either is really painful for people or actually not enough experience exists on. This is the version skew testing, which is where again we look at the full compatibility testing using API contracts as one way to achieve that. So why do you care about version SKU? You might ask, why should we care about versions? Queue I’m sure all of you are familiar with the device fragmentation in the market.

 

This is a recent data of all the different types of devices that are out in the market. You also, if you just look at Android alone and there are other operating systems, but if you look at Android alone, again, there’s a huge fragmentation in terms of the penetration of Android versions in the market. So that’s not enough to complicate things. You also have different versions of your apps, and there is uneven adoption of your apps. And if people are using certain version of the app, they may not be very keen to upgrade. Even though you as a developer would want them to upgrade, they may not be very keen to do that. So you may end up having to support multiple versions of the app. And these days with microservices, you may actually have multiple versions of multiple versions of the same microservice running in your kits, cluster or things like that.

 

Here’s an example of several different versions of the same applications. As they’ve evolved microservices, have they evolved running simultaneously? So how do you ensure that all these combinations, there’s so many factors, how do you ensure that when you upgrade a new piece of software, it is resilient to all these underlying factors or underlying changes? Let me simplify the problem. Let me simplify the problem. Let’s say I have version one of the app, and that talks to an API gateway, which then talks to v one of orders API and it talks to v one of reservation. So everything is good. You have version one. It is talking to version one of orders and version one of reservations. So this is good.

 

Then you come up with V2 of your app. A new feature gets added, some enhancements come through. You add a V2 version of the app, and then you say, okay, I will need a V2 version of the app of the order API, and similarly a V2 version of the reservation API. I mean, in this case, let’s assume both of these have changed to accommodate this particular feature, right? And then you have a third feature that comes along, in which case you basically use the same V2 version of the order API, but you have aV3 version of the reservation. Let’s say there was a changed feature that had something specific to the reservation aspect, right? So now you have V1, V2, V3 out there in the market. You have V1 of orders and V2 of orders. And then you have V1, 2, V3 of reservation, right? So anytime you’re making a release, you want to make sure that this combination is all working fine. This is what will ensure a seamless upgrade.

 

And at this point, I’m really even just focusing on the functional side of things. Of course, performance and other kinds of security aspects can be added as a top up on top of this. So how do we solve this problem? How do we simplify this problem? Because this combination, right. If you try to measure all these combinations and try to do this, it’s going to become very painful. A lot of teams I’ve worked with, I see them basically doing a full regression cycle with the version three of the app, then doing a full regression with version two, then doing a full regression with version one to ensure that nothing broke. And that can be very time consuming, very expensive, and very painful. And more importantly, if you find an issue during this time, it’s also too late in the game to go and fix this because it’s going to be very expensive, it’s going to be time consuming. Already.

 

There are pressures to release to the market. So trying to do a regression test and then find these compatibility issues is really not an option these days. What’s the solution? How do we get out of this fixed? Let’s take a commercial break. That’s important. So my name is Naresh. I live in Mumbai. Don’t act in Bollywood yet. I run a consulting company called Xnsio.

 

I also am responsible for running all these conferences in India. Ended up building like Sameksha highlighted, ended up building a platform pretty much to scratch my own itch. But later other people started liking the platform and started using the platform. So it’s kind of running in an autopilot mode these days. And I’ve been fortunate enough to have worked with some of these clients and actually learned a lot from them. So that’s kind of a little bit of a background. And like somehow said, the last five years I’ve been predominantly working in Jio across several different platform teams and helping improve their engineering and product delivery. So that’s a quick background.

 

But let’s come back to a problem and let’s take a example that all of you can relate to. Let’s say we have an Apimart e commerce company, and this company basically so far did not allow the users to cancel orders. Once you place an order, you cannot cancel it. But they have now market pressure and they realize that they do need to allow users to cancel the orders as long as they’re not dispatched. And they also have a twist in the story where they say, okay, you know, like just in the airline, when you book a ticket, if you, if you pay a little premium, then you’re allowed to cancel, right. Without a fee. So there’s a little bit extra fee you pay to have this feature to cancel. Okay.

 

If it’s a prepaid order, obviously on cancellation, a full refund needs to be issued, uh, minus the fee, of course. Uh, and upon cancellation, you also need to adjust the inventory, increase the inventory accordingly. So let’s look at what is the current state of our application and then how, when we bring in this cancellation feature, how it’s going to evolve. Okay, uh, so let’s say this is, uh, my app. My app makes a request to the order service. So it’s basically placing an order. So it’s doing a post on slash orders. And then basically I’ve selected two order right, order id ten and order id 13 with the quantity that I need.

 

Okay, what this does is it basically reserves the inventory on the inventory service, and inventory service may internally talk to other services and so forth. And then inventory service can come back with a status of each of the products that you have placed order for and its own reservation id. Okay. The order service would then do some kind of a transformation and send back a order id seven. And the id of the product and the status on the product, because the status is important because sometimes there are things like short picking, which means you may have asked for ten products, but I might not have all ten available. So those kinds of things. Okay, so this is our current design right now. How would this evolve when we want to introduce the cancel feature? So let’s look at that.

 

That new state would look something like this. That is, when you’re placing an order, you are selecting if you want to subscribe for the cancelable feature or not. So now there’s a new field in the request that would go to the order service called cancelable. It’s a boolean value with the inventory. It remains the same, everything is same. Inventory would come back. And then when the response comes back, you have now status which is out for delivery or placed or accepted or different kinds of statuses. And also you would have a cancellable, true or false, coming back whether this particular product is cancellable or not.

 

If this particular product is out for delivery, then cancelable is false, else you can still cancel it. So let’s assume now in the UI you can show a cancel button against this particular product where product id 13 is still in a placed state and you can cancel. So let’s assume someone clicked on the cancel button. So basically this will do a patch on the order, and then that would delete the reservation for product 13, uh, which belongs to the reservation 87, uh, and then that would respond back. Uh, at this point you would talk to the refund service, uh, which didn’t exist before because we didn’t have anything to refund. But now because you will cancel, you also have a refund service. And then finally it’ll get back, uh, to the app. Right.

 

So this would be our new flow. Uh, so how do we ensure that, uh, you know, this particular, when the developers implement this particular flow, they do not break anything that was working before. It seamlessly works as before. Let’s quickly look at a live demo of how someone would go and approach this. I have a little app over here. It’s a standard spring boot app. It could be any language. Honestly, it doesn’t matter.

 

Any language, any framework. I don’t really care. And there is the order service API itself is documented using Swagger or OpenAPI. And so what you will see is essentially I only have one path called slash orders, and then there’s only one operation on this allowed, that is slash post. And this is obviously a simplified example. There could be more complication and then the response can be 201, which means order created successfully, or could be 400, which means the request that you sent to me is not accepted. Right? So let’s assume this is what we have as of now. And you notice that I have already run the contract test and I have four, basically three contract tests, and all three of them have, you know, passed successfully.

 

Right. So they’re starting the application, they’re sending a request to the application, they’re verifying that the responses as per the expected schema and so forth. And so this is right now the application is in a working state and we are about to make a change to the application. So we have two options now. One is we could go and start making the code changes. And basically once we’ve done with the code changes, we can then test it and make sure we did not break anything. Like I said earlier, that’s a very expensive process and an expensive way of doing it. So in Contract Driven Development, what we do instead is we first update the contract.

 

We first update the specification. It’s kind of like test driven development, except that we use contract as a starting point. So in the contract I’m basically saying, okay, this is my request. Fair enough. The request is of type object, it’s a schema and it’s required products and product is defined here. So it’s an array of products, uh, which has id and count. Okay, so what we said earlier is that we should be able to add a cancellable. Yeah, a cancellable with type boolean.

 

And uh, let’s also uh, make this uh, here required. So I’ve added basically cancellable boolean. Uh, so when a request comes in, I need to make sure that uh, you know, someone can specify cancelable. Then when the response comes, basically response comes back. What we are saying is that it should also give me a cancellable type boolean. Again, true or false. And this is also mandatory. This is not canceled cancelable.

 

Let’s just make sure this is the same name. So both of them are cancelable and this is what we expect. Right. So now let’s also update the example so someone looking at it can know what is going on. So we are saying cancelable should be true in the request, right? That’s an example we are giving. And in the response, we are saying when the response comes back at individual, you know, this thing, basic cancelable, true or false. Right? So I’m going to make one of them true, another one false. I’m also going to just say this is accepted while this is, let’s say out for delivery, right? So out for delivery is, you know, cancelable is false and accepted.

 

You can still cancel the order. This is very much same like what we just discussed, but just putting it in a structured Swagger or API documentation. So that this is the first change I would make. All right, now, once I’ve made this change, before I start doing any development, before I start writing any code, all I’ve done is I have basically thought through what my interface, my API interface should look like after I implement this feature. Once I’ve made these changes, the first thing I will do is I’m going to go ahead and basically run a simple command saying, okay, if I make these changes, okay, will I break something? Okay. So all I’m trying to make sure is I’ve updated the specification and as soon as I update the specification, before I start my development, I’m going to check if this change is going to break anything or not. So let’s run that command. Okay, so what happens at this point is essentially, of course it’s come back immediately.

 

It was very quick because there’s not a lot in this. So what has actually happened when I ran that command is we took the existing version of the API, it’s already there in git. We took the new version of the API that we have just changed, which is locally available. We took the new version of the API, we ran a mock server with the API. So Specmatic has the ability to basically take a spec and convert that into a service virtualization into a stub or a mock. Right. So it just basically started a stub server for you. Okay, so this is like the real server that just came up.

 

Okay, with the new version of the spec I took, then the spec matic will take the old version of the spec and it will run that as contract test against this version of the spec. Okay? And when it runs those as tests, it will see if all the tests that it could think of from the old spec are still working. Okay, that means the change that I just made is backward compatible. If any of the change in any of the tests fail, then it’ll basically be non backward compatible. Right. So what happened here? Let’s quickly look here. So basically it’s saying in the post slash order scenario, you know, basically you expected a body for 201, you expected in the body cancellable, you know, that’s become mandatory. So new contract expects key cancelable in the request, but it is missing from the old contract.

 

So if you make cancelable mandatory, that means your old clients who, old API clients or old mobile apps who are basically calling this, trying to place an order, they are not going to be sending cancelable as a key inside. So if they’re not going to be sending, and if the server is mandating that you need to send, then it’s going to break backward compatibility with them. None of those applications will be able to successfully place an order anymore. So we are getting to know something like this right away with the spec and we can validate it. Of course, this is a very simple example I’m showing you, but you can imagine APIs can get really complicated, really hairy, big ones, very deep nested structure, and sometimes it’s not very clear because you can have all off, one off, lots of different combinations in the APIs. And so why second guess any of those things? Just make the change how you expect it to be and simply run this command and immediately get to know that, okay, with this kind of a change, this is going to become, this is going to break compatibility issue, right? So what is the problem here? What is it complaining? It’s complaining that we have made cancelable as a mandatory thing, which means the old client will not be able to call anymore. Right? So fair enough, we don’t really need to make cancelable mandatory. So here in the request I had made this cancelable mandatory, I’m going to remove it, I’m going to keep it optional and on the server.

 

So this is again a clue for the implementer that when I implement it I may not get cancellable. So if I don’t get cancellable, I should ideally default it to false, right? Which means it was not cancellable. That is what the behavior was before. And so by default if I didn’t get anything, I’m going to make it cancelable, false. These are all clues for how you want to design this so that it’s backward compatible. Now that I have removed the mandatory check, let’s basically look at what happens. I’m going to run the Specmatic command again, and sure enough it ran through and it says this spec is backward compatible with the corresponding spec on your githead. Right? So with this change we know that at least from a spec point of view, we are not breaking any backward compatibility.

 

Okay, so this is fully compatible at this point, at least the spec is fully compatible. Now what happens? Right? Ideally I would raise a pull request onto the central git repo, which contains all my contracts letting know that hey, this is going to be the new version of the contract and this is backward compatible. This is an indication to the provider of the API and the consumer of the API that hey, there is something new coming along. Now let’s assume I am the developer of this API, I’m on the provider side. I’m going to basically be building out this API. What am I going to do, I don’t need to write any line of code. I don’t need to do anything. There is already this contract test, which is a one time thing that was available to us.

 

This in fact only has a before all like a setup and a teardown. It doesn’t really have anything else inside it. It’s just telling you where the application will run, where your stub is going to run, etcetera. So it’s just basic configuration, nothing else inside this. So all I’ve done is I’ve changed the API spec and at this point I’m just going to go ahead and rerun all the tests. These tests were all passing. So now before I start implementing, right, I’m going to just go ahead and rerun all the tests. This is similar to a test driven development cycle, right? So where you would actually update a test and then you would run the test and you would see if anything fails.

 

If it fails, then you know what needs to be fixed. Okay, so we just added cancelable in the request and cancelable in the response. We run the tests, no need to make any code changes at this point. No need to write anything manually. And what has happened now is pecmatic went from basically earlier, you saw that we had three tests. Now it went from three tests to seven tests because it figured out that there are different combinations that are possible because it’s optional. So I need to make sure with and without the parameter, everything is still working fine, etcetera. Of course, I do expect the test to fail at this point because I have not implemented anything in the feature.

 

So what is happening here, if you see, is, let’s just scroll down here for a minute. So I’m doing a post to slash orders and I am sending this cancelable true. Okay. And what I’m expecting in the response is I’m expecting that basically the cancellable true or false is going to be returned back. So this is why this test has failed. It’s saying basically response body product zero, cancellable. The key cancelable in specification was not found in the response. So this is a mandatory key that should have come back in the response.

 

But that’s not come back because this is just an additional field. Existing clients will just ignore this, but new clients who understand the cancelable functionality will basically get this field and they will respond back. But of course we have not implemented anything at this point. So it’s not sending this cancelable field back. But this is a good first step right now for the developer. They have a failing test and they need to make sure that as they implement this new feature, all the contract tests are passing. So we had a first level of check for backward compatibility when we made the change the spec. Then as we make changes to the code, we also need to make sure that they don’t break the contract so they will be contract compatible.

 

Now, at the same time, your front end developer or your app developer is going to use the same very contract, this new updated version of the contract as a stub for the server and start doing their development. In fact, they will design their app so that it is both forward and backward compatible in the sense that if you get cancellable, I will show cancelable button. If I don’t get cancellable, I’ll assume that it is again not cancelable, assume false and not show the button. So in case this service is not deployed but the app is deployed first, right? Because you know, the app could go out to the market first or the service could go out to the market first. We don’t want to put all restrictions that only the app should go first and then the, sorry, only the service should go release first and then the app should be released. You could actually now independently release in any order. As long as you can basically specify in your configuration file. Then that should be good enough that there is a little file here called Specmatic YAML.

 

In this file you can basically specify here, I’m specifying that this is the provider of the API. On the consumer side, I’ll basically give version one and version two of the API to make sure that both of them are supported in case I have two versions to be supported. So that’s how on the consumer side, I’ll also ensure that my app is forward compatible. Okay, so with this nerish, just a.

 

So this is a quick, just a demo of how we will approach this, right. If a change needs to be made, we will first make the change to the spec. We will make sure the spec itself is backward compatible. Then using the spec as tests, we will do the development and we’ll make sure that we are not breaking anything. Generally these are all part of your CI pipeline.

 

So when you raise a pull request, these tests will run, make sure that nothing is breaking and that is allowed to get merged. Right. So this ensures you’ve shift left all the way onto the development machine, onto your PR, and no braking changes leak in. So this is one very solid way of ensuring, you know, it doesn’t matter how complicated the apps is. But if you put controls at individual API levels and individual consumer level, you will be able to de risk a lot of these complications. You will not find these changes late in the cycle and so forth. Okay, so let me quickly jump back and just quickly summarize the demo that we just saw. Right? So we had the app, we had an order service.

 

The order service was talking to inventory. We didn’t really talk about Kafka. And basically in this case, you’d be sending a message onto Kafka, let’s say, for some analytics whenever an order is placed and so forth. So what I’m interested is I’m interested in testing this for the time being. And I want to basically not depend on actual services. I want to isolate myself so that I can, I can test this in, in isolation and be sure that I can simulate all kinds of conditions. So what I will do is this is my dependency and this is my test, right? So I’ll start replacing them, you know, so here I’ll start replacing this with Specmatic as contract test. Use the OpenAPI Swagger here I would again use the OpenAPI or Swagger for the dependent service.

 

And for Kafka I would use again Specmatics AsyncAPI support, which will create an in memory broker for us as soon as it starts up. And it also does schema validations, message validations and so forth. Right? So this would set an expectation on both of these dependent stubs and mocks. Then it would actually send a request. This request would then hit the stub. Stub already has the expectation set, so it will respond back, a message will be posted, the message will get validated, what message was posted, whether it was posted on the right topic, the format was right, et cetera. And then a response is returned back and then we do a check verification on the mock. So this is kind of like just popping the hood on.

 

When I ran the test, what was happening under the hood? All these things were getting wired up and running. But as a developer, all of this is abstracted away from you. It is. You don’t need to sit and hand wire these things or any of that stuff. It’s all declarative and just in a configuration file. That’s the whole no code approach that we’re trying to take. Because these days very few people are interested in sitting and writing a lot of tests. Right.

 

So we are in the era of automating that as well. So just to quickly summarize the approach that I was explaining we call that Contract Driven Development, and we believe that with Contract Driven Development, a lot of late issues that we are finding can be addressed. Right. So like I explained, we start with an API design first, where we update the OpenAPI specification, AsyncAPI specification. If you’re using, if you’re using protobuf, then you would update the proto file. If you’re using gRPC, you’d update the gRPC, the GraphQLs file, etcetera. So there’s several different formats that are supported. First you update the spec.

 

Once you update the spec, you push it into a central git repo. To push it into a central git repo again, we go through the same process that all of us are familiar with. We raise a pull request. We do linting to make sure that the spec is as per the company standards. Then we do the backward compatibility test, which is what I explained, where we take the new version, run it as a stub, we take the old version, run it as a test, and make sure that all the existing contract in the spec, in the existing spec are honored by the new spec. When it’s successful, then we merge the change. And this is when all the changes are available in the central git repo, which is our single source of truth. From here now the provider and consumer can start doing independent development.

 

They don’t need to wait on each other. So the consumer of the API could basically create a stub from the same central repo. In fact, Specmatic automatically checks out the latest version of the spec for you. It’s not left to the developers discretion, it is automatically checked out and it’s available readily as a stub. You can run it locally, you can do your testing locally. Same with the provider. They’ll be able to run contract tests as part of their development cycle, almost like a test driven development cycle that I was showing you. And once they are ready, they go to the continuous integration environment.

 

In CI, you would run your component test and then you would basically, the component test would depend on the stub that again same be generated by Specmatic at runtime, you know, in your CI pipeline. And for the provider, you run the unit test, you run the contract test, you may have other component tests, everything is good. Then these guys can independently keep deploying to the integration environment, making sure that it’s all working and the path to production is clear, right? So here we’re talking about shifting left all the way to the design. We’re not waiting till it’s too late to figure out in the integration environment that, you know, this was a design problem, right. You know, also we are trying to make sure that locally, when developers are doing development, they have the required stubs and mocks and tests to be able to do their development seamlessly and not wait on each other. And so this allows an enhanced developer experience and an improved collaboration using Git, which is something everyone’s very familiar with. This also drastically reduces the time to market because now people are not waiting on each other. It’s all happening in parallel.

 

And finally, there is something called resilient API testing. So where we do a lot of boundary case testing, we do edge case testing, we do mutation testing to make sure that the API itself, which is a building block in our opinion, to be fairly resilient. So these are all the pieces that are the integral part of Contract Driven Development workflow. Once you have done that, then you also can go and look at, you can visualize the dependency graph, you can look at who is dependent on what, what kind of services, who’s consuming whom, et cetera. And all of this information is available in real time. By running these things in, in your CI pipeline, we collect the data and then we visualize this data for you, and you can also track your adoption and so forth. Right? So this is again the kind of insights that someone would need when they are adopting Contract Driven Development. Again, you know, there is a whole bunch of protocols and things that are supported.

 

I think through the day, throughout the day, people have been asking, you know, this, will this work with gRPC, will this work for Kafka, will this work for Redis or database? I have database and I want to stub out the database. So I want to basically stub out my using JDBC or things like that. So all of these capabilities are available. There are videos available, you can actually go check it out. So I think I have about five, six minutes left. I’ll quickly pause here. Think I’ve given a quick view of what I believe, how Contract Driven Development is a key practice in addressing compatibility issues and seamless upgrades for your users. With that, I’ll quickly stop screen sharing and then we’ll take some questions.

 

So if you have questions, you can please put it in the q and a section and I will read out those questions and try to address them one by one. So I see a question from Santosh. Can this be done using open source model? So the OpenAPI piece, which is for HTTP, that’s all completely open source. So certainly you can do that. I’ll tell you a little funny story. So our original idea with Specmatic was to give everything away for free. And so we released this as free and we would, you know, we get at least, I’m not kidding, you would get at least three emails every day asking, you know, what’s your business plan? Are you guys going to be around? We’ve done an evaluation of the tool. We really love it, but we are not sure if you’re going to be around.

 

Right. So we would constantly keep getting people who are interested in using it. They’ve evaluated it, they like it, but they’re not sure whether we’ll be around. Right. And so a good friend called up one day and said, why don’t you think about commercializing this? So we said, okay, what’s already open source? We will leave it. We were also trying to protect some IP. So we had filed for patents and stuff like that. So we had kept certain things that we had not, like async piece that we had not put out publicly.

 

So we said, let’s try it as just an experiment. So we put out a pricing plan and see what happens. And this is very counterintuitive to me. You’re trying to give away everything open source in the spirit of community, want people to come and collaborate, but there are a lot of companies who are worried whether you’ll be around or not. So the moment we put a pricing page, it was not even thought through, just 2 hours. We hacked something together, put it up, and we saw actually the downloads started skyrocketing. A lot of people started downloading Specmatic and started using Specmatic. So I think the interesting thing is that people are worried because they want to make sure that this software is going to evolve and continue to improve and be up to date and someone’s going to maintain it.

 

This is not their core work, so they want someone else to do. And so that’s where we came up with this hybrid model where the whole OpenAPI stuff for HTTP, HTTP rest is open source, free to use. And then there are parts which are commercial that you pay a small license fee and use it. And we are actually seeing a lot of adoption. A lot of companies are saying, okay, this makes sense. We get a taste, we use it. We try it out with the open source for OpenAPI, and then when we want to use for things like Kafka or JMS or let’s say GraphQL, then we are okay to pay a little fee. So it’s kind of an open source model then, like a freemium model, if you will.

 

Hope I answered that. There is one other comment. Why should I choose Specmatic versus tools? For example, pact. That’s a great question. So from whatever we’ve been looking at, so we’ve used pact in the past as well. And as you know, Pact came out of Thoughtworks and this is joint project, and pact was great. I think it’s a great tool. However, pact only addresses partial problem.

 

In fact, with Pactflow, they’ve tried to do this bi directional thing where from an OpenAPI specification you can do things, but it’s not quite there yet. There are a lot of challenges. In fact, before we started building Specmatic, we were trying to use pact. The a, the adoption curve is very, very steep. That’s what we realize. That’s what we hear from a lot of people. It requires you to write a lot of code in a proprietary format. So there are challenges with that.

 

And it’s still quite sequential in the order you would have to, it’s purely consumer driven contract, so you’d have to first get the consumer to finish and then the provider can start. It’s also not quite feasible in many organizations where there are multiple consumers for a provider, and the provider may want to take a certain design decisions and so forth. So there are several limitations. You can actually, one of the most hit page on our Specmatic site is the comparison with pact and pact flow. So if you’re interested in very, very specific details that’s also flushed out on our website, you can just check, or you can just search for Specmatic versus pact and it’ll is the first Google search. You will, you will get that. Okay, I think there’s one more question again from Santosh. Makes sense.

 

Any open source tool we have for gRPC. So there are a few open source tools available for gRPC. However, from our evaluation, they seem very limiting, very superficial. Tick the box. We also support gRPC type thing, but you know, the devil is always in the detail, right? What kind of assurance are you actually providing? If you see, with gRPC, with proto three, pretty much everything’s made optional. So that was their answer of how do we ensure backward compatibility? Just make everything optional. But now when you make everything optional, it’s like basically your SQL schema. Everything is basically where care, you’ve lost the tightness of what a specification should be.

 

So we spent quite, our original reaction was, we don’t need to do anything with gRPC. The proto already takes care of a lot of stuff. But as our customers started saying, no, no, we want something very similar to what you guys have done on this, then our immediate reaction is, hey, why don’t you look at these open source tools? They’re already there. We will focus on this stuff. And then they came back saying, why don’t you go have a look? And then when we looked at it, it was not quite up to the mark. So anyway, that’s obviously my bias to view, but feel free that if you google for it, you will find a lot of tools out there.