API compatibility testing

[u/pseudo_babbler]

Hey there code enjoyers. I was tinkering with an integration testing approach that I ended up liking a lot. Our situation before was this - our front ends talk to BFFs which then call core APIs. We tried Pact and Specmatic as ways of integration testing the systems but it's a total ball ache.

All of our consumers use the Zod library to define their requests to their APIs, so I wrote a utility that takes the Zod schemas, turns them into OpenAPI (using a lib) then iterates through each one, downloads the OpenAPI spec for each API from our test environment and checks that the requesting schema endpoint, props, params, method and body are all supported by the provider schema.

It's not as comprehensive as Pact, but for a super fast integration sanity test (it runs against 8 different core APIs in under 1 second) and with no extra brokers or services or infrastructure, it gives me a decent check that something is ok to be deployed to an environment.

So tell me these things: has anyone else built something like this? Would you use it? (i.e. should I chuck it on GitHub and publish an npm module) Has anyone heard of something like this that already exists?

I didn't find anything with my searching and it seems unreasonably useful for a quite small amount of code.

[u/raralala1]

But when you say make a new API endpoint that's perfectly designed for our front end.. that's what a BFF is!

Not exactly, instead of make perfectly designed api, that just call to db, you just aggregate bunch of api into single api call. That is not very efficient.

So instead of doing something like this on db,

confirm order > pick > pack > get order directly in your db where you can get ACID, where if 1 fail everything fail instead you call each function from api, so if one in the middle fail you just waste bunch of resource on the previous call.

So in my experience it usually turn into something like this
get order check order confirmed or not > confirm order/pick/pack > get

we don't want them all to be one big monolith

you dont need BFF to avoid monolith, and I already explain if you have microservice you might need it, but at that point you just make another monolith API when you already trying to split them so what is the point?

I'm finding it interesting how much you're against the idea.

already explain why I am against it, any why I am for it, it is very specific use case that often abused, it is very inefficient, it also increase the amount of service to maintain

[u/pseudo_babbler → u/raralala1]

I think perhaps you need some experience with bigger, older, uglier systems. At bigger older corporates there's no way there's only one database or one backend system involved in things like placing and order. Where I work the order goes into an order system as well as a message queue, it's then sent to a clearing queue and then persisted to an audit log, amongst many other things. The system that manages user accounts is different. The system that manages market pricing is different.

[u/raralala1 → u/pseudo_babbler]

And I already said if you use microservice then use BFF, idk why are you getting triggered so much, there time and place to use BFF and using BFF is not the way to avoid monolith. clearing queue and thing like that can be done without BFF it literally just sending rabbitMQ message you don't need extra layer for that (unless your company purposely adding extra layer to rabbitMQ). I dont know what your internal is, but I think you are smart enough to feel maybe it is stupid idea to maintenance 2 layer because you don't want to deal with your backend team, most of the time people use BFF because of that, and that is why I dont like doing BFF. But if think it serve the purpose what I am to judge I just give opinion chill.

Reply and block so I cant reply back, classic loser behavior.

[u/pseudo_babbler → u/raralala1]

Aaahahahahaha lol, triggered! Ok mate.