A question for the #Golang crowd! I'm building an API for configuring e-mail hosting. I want a simple #REST #API, and I'd like to build a #kubectl like command line client too. Backend will probably be #GORM and #PostgreSQL with a lot of different entities. What would you recommend for keeping the server and client models in sync? I'm thinking some sort of code generation, but I'm unsure about the direction to go in - #OAPI #Codegen or #Swaggo? Annotations in code or a definition in Yaml? Perhaps with the generated models in a separate module for easy sharing between #client and #server? How do the clever people do it? :-)

#go

@saustrup I need to make a few assumptions in order to keep it short.
If you go with the usual multi-main package layout (my goto reference is https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/) then you can put all API models in a (internal or public) package and reference them from cmd/cli and cmd/server. This is how I quickly roll a CLI for a backend as quickly as possible. At some point openapi might start saving you time. Eg when the API starts to grow, you need docs or non-Go clients. But you can't beat sharing and directly referencing the `api` package in terms of raw productivity.

For when you need (or want) OpenAPI then the goto is usually oapi-codegen. Just stick to the 3.0 spec for now as 3.1+ support is in the works (I would not bet on it in the short term). Recently I tried converting a 3.1 spec down to 3.0 and all the tools I tried failed spectacularly.

Simple Go project layout with modules - Eli Bendersky's website

@bmarinov Thanks! Raw productivity goes a long way here, as this is bit of a side quest for now. I love Go, but as I'm usually doing smaller solo projects, I often lack some direction and input on common practices. I'll read up and get back to you :-)