Hacker News Reader

Comment by okamiueru | Hacker News Reader

Although true to some extent, this is also a tooling issue. We use OpenAPI and generate clients. Strictly speaking the interoperability layer doesn't know the truth on the other side, but when generated correctly, the developer doesn't need to worry about it.

View on HN

When you change function signature it doesn't compile until you fix all the call sites. Maybe after you see all the broken call sites you think that's too much work maybe there is some other way to do what I want.

When you change anything about an endpoint, it compiles just fine no matter what clients there are or what they are doing. You proceed with the change without worry. Yes, you can have some self-discipline to also generate the open api documents, generate the clients and then check all clients but self-discipline like that is not reliable.

So while tooling can help it's still not the same thing.

> When you change function signature it doesn't compile until you fix all the call sites. Maybe after you see all the broken call sites you think that's too much work maybe there is some other way to do what I want.

Improperly versioned dynamic libraries want a word with you!

Perfectly possible to foot gun yourself with compiled code and broken API boundaries.

> When you change anything about an endpoint, it compiles just fine no matter what clients there are or what they are doing.

If I am exporting a DLL, same thing happens. Working on a true monolith, the entire app is compiled as one giant executable, sure, then I get compile errors.

If you use semantic versioning correctly, then you shouldn't need to worry about api<->implementation inconsistency. Or rather, when you need to, you know which parts you have to deal with.

I don't think there is a way to avoid this?

Reply on news.ycombinator.com