Yeah also schema-first here. I think this is the “easy vs simple” debate all over again. Writing code first schema is very easy, but when you start _using_ tha

Yeah also schema-first here. I think this is the “easy vs simple” debate all over again. Writing code first schema is very easy, but when you start _using_ that api as part of a greater system is where the approach starts falling short. Schema first allows for great communication between teams - one team requires changes to an api service, they can hash it out with the api, and then go back and implement both the client _and_ server simultaneously. The great benefit here is the inevitable back-and forth can be done together, as each side might need to adjust the api while they are implementing the client/server as often happens with engineering efforts. And thats a lot easier to do while each side is working on it rather than the usual one side is “done” and moves to another task and needs to go back and modify. In fact at the time I built quite a nice system of generating typescript types for both client and server - https://github.com/ivank/laminar https://github.com/ivank/laminar I guess because the project tried to introduce strong typing and fp style to node http servers plus a few other ideas stolen from here and there, it tried to do too much and never really got traction.