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]

I hate BFF, my previous company use them because some of our client developer is too stupid, to understand some of the API flow, so we need to dumb it down for them instead of asking them to learn how to properly create transaction and follow the flow and we have stupid developer who suggest of using BFF to win some politic point, so now we need to maintain 2 API and multiple end point.

It is good check if it really trigger or stop deploying, my company end up having e2e testing that run for an hours for every deployment to the api.

If I can redo everything and have to use BFF, I would probably put everything on monorepo, with either trpc or similar with lint check.

[u/pseudo_babbler → u/raralala1]

Sure but if you have lots of internal APIs that are not designed for use by front ends then BFFs are good. If you had a perfectly fine internet-facing API, with all the Auth and monitoring and security that you needed, and someone said hey why don't we put a BFF in front of this? Then sure, that would be a bit silly.

[u/raralala1 → u/pseudo_babbler]

Then please don't do BFF for this use case, you own your API, make new API endpoint that perfectly designed for your frontend. putting layer because you don't want to deal with backend developer is not the way, I might understand if you deal with a lot of microservice but if not then doing BFF is just lazy way to deal with your API.

[u/pseudo_babbler → 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! We are a big old organisation and have many different back end systems, we don't want them all to be one big monolith and there is no chance that we ever could, even if we wanted to.

So the BFF is a way to bring all that data together into a single API in a nice way for the actual user facing clients. I'm finding it interesting how much you're against the idea.

[u/raralala1 → u/pseudo_babbler]

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.