| Thanks for taking the time to write down your thoughts! I deeply appreciate it! My bad I was not concrete. What I've meant by "this/that" the entire "find the docs - read the docs - program/generate your client using the docs/OAS - maintain your client forever" when we can have application that will do all this without our intervention. > I'm never not going to need API documentation because it's not just syntax. It also tells me how the vendor's object model works. It tells me the right order to make API calls, how to know my rate limit, and how to choose permissions for my API keys that are as narrow as possible. Ideally, you should only need to understand the business logic of the API and not how to achieve it, that part can be figured out by your app. Self-integration approach does not force you to harmonize the offerings. It just abstract you away from the APIs using the business layer (as you are already doing using you classes). You might try to harmonize some of the vendors if that is what you like, but that is not the gist. With Some vendors and in certain domains it might make sense - that's why we see domain integrators. With others, it either does not make sense or it is not commercially viable. Either way, you can have your app integrating on the abstraction level without you caring about the technicalities. The sad truth is that vendors in the first place don't want their offerings to be interchangeable. But that is for another discussion. Also, it is great to hear that codegen from OAS works for you! > losing first-party support from the API vendor and having yet another layer to have to debug 1. if your app self-integrates you will not loose that
2. you have this layer already in your hexagonal / clean architecture wrappers, what is worse, everyone is bikeshedding, writing this part over and over |