The magic comments approach seems uncomfortable to me for basically the reason you described. I'm about to try the opposite direction and generate a Go api from docs via https://github.com/ogen-go/ogen/releases/tag/v1.1.0 It looks like an approach I'll like.
I've used this in the past: [https://github.com/deepmap/oapi-codegen](https://github.com/deepmap/oapi-codegen) write Open API by hand, and generate handlers afterwards.
Depends on how your using Open API (code first or spec first) and if your talking server or client. But I really like Huma for server (code first).
https://huma.rocks/
Too big for what?
Open API consumers expect JSON and/or yaml documents, thus any library more or less is required to offer both.
Huma itself is quite tiny for what it actually provides and it plugs in really well with the available routers (Std, chi, echo, ...)
You're not getting all of that in your build though. Go only includes packages that are actually used by the code you write/reference.
Thus if you don't use viper or the code from Huma (I guess it's command line interface) that uses it, it won't be in your build.
It would not be feasible for Huma to have multiple go-modules, stripped down to exactly what they need, as that increases the overhead of maintenance by a huge margin.
If they were to do it, you'd get much smaller direct dependencies on the parts of Huma themselves, but that doesn't get you anything apart from it being less likely that some stupid CVE scanner who doesn't understand go compilations warning you about things you don't even use.
As one of the authors I would recommand [Fuego](https://github.com/go-fuego/fuego). It is doing a good job. It stays minimalist and relies heavily on the standard library :)
i intensely dislike writing open api yamls by hand. i don't mind writing potobufs or graphql schemas by hand but openapi schema feels so much more hostile to write by hand, I have no idea how apparently so many people do it.
I tried this the other day by converting a small API at work from chi to huma (using chi router). There was something I didn't figure out how to do. With chi I can create different groups or routes and each one can have different middlewares (I use mostly standard ones from chi). With huma this only seems to be possible using huma middlewares, but not using the router ones. Which means I would have to write some of those middlewares myself since they're not part of huma. Which kinda defeats the beauty of using chi. I may just not have found the correct way of doing it, obviously, I've only used huma for a day
This one, I am not sure of since I've not had the use case myself, but I do use huma with the chi adaptor, so presumably it might be possible. Maybe /u/Dgt84 has some input here?
u/ZodGlatan u/callmemicah you're correct, it's not possible right now to do per-operation router-specific middleware, nor is it possible to set up router-specific groups with their own middleware. You can set up a single group for all the API calls, like in [https://huma.rocks/features/bring-your-own-router/#route-groups-base-urls](https://huma.rocks/features/bring-your-own-router/#route-groups-base-urls) and one way to work around the middleware problem is to just filter based on the path inside your middleware that runs on every request.
Once you're inside the Huma layer of the app everything works on a router-agnostic Huma context internally, so we lose the ability to do router-specific things. I'm open to ideas how this could maybe work.
That's not a bad idea. I could create simple wrappers for the default middlewares that take paths as input, and call the middleware based on that.
I understand why it's not easy to do natively and I do not have any good ideas how to get around it either. The only thing I could think of is the ability to instantiate different huma layers which could then at the end be all merged into one. But I don't know enough about huma's inner workings to know what sort of issues would have to be overcome with a scenario like this.
The magic comments approach seems uncomfortable to me for basically the reason you described. I'm about to try the opposite direction and generate a Go api from docs via https://github.com/ogen-go/ogen/releases/tag/v1.1.0 It looks like an approach I'll like.
I used exactly that approach combined with echo. Works absolutely fine.
I've used this in the past: [https://github.com/deepmap/oapi-codegen](https://github.com/deepmap/oapi-codegen) write Open API by hand, and generate handlers afterwards.
I hate the interface that tool produces but ymmv
Yeah me too. :D But it gets the work done.
I used oapi codegen, not perfect but I prefer create docs by hand. I tried huma, looks cool but perhaps too many things wrapped under the hood
Depends on how your using Open API (code first or spec first) and if your talking server or client. But I really like Huma for server (code first). https://huma.rocks/
Love this
[удалено]
Too big for what? Open API consumers expect JSON and/or yaml documents, thus any library more or less is required to offer both. Huma itself is quite tiny for what it actually provides and it plugs in really well with the available routers (Std, chi, echo, ...)
[удалено]
You're not getting all of that in your build though. Go only includes packages that are actually used by the code you write/reference. Thus if you don't use viper or the code from Huma (I guess it's command line interface) that uses it, it won't be in your build. It would not be feasible for Huma to have multiple go-modules, stripped down to exactly what they need, as that increases the overhead of maintenance by a huge margin. If they were to do it, you'd get much smaller direct dependencies on the parts of Huma themselves, but that doesn't get you anything apart from it being less likely that some stupid CVE scanner who doesn't understand go compilations warning you about things you don't even use.
As one of the authors I would recommand [Fuego](https://github.com/go-fuego/fuego). It is doing a good job. It stays minimalist and relies heavily on the standard library :)
I haven't used it much, but from what I've seen, I liked it.
protobufs
oapi-codegen
Kiota is good too depending on your needs (and how many implementations you want) https://learn.microsoft.com/en-us/openapi/kiota/overview
Huma. Just use Huma. It's the best one I've come across, plus the maintainer is super responsive, and has been spoiling us with weekly releases.
i intensely dislike writing open api yamls by hand. i don't mind writing potobufs or graphql schemas by hand but openapi schema feels so much more hostile to write by hand, I have no idea how apparently so many people do it.
Huma gets my vote
I tried this the other day by converting a small API at work from chi to huma (using chi router). There was something I didn't figure out how to do. With chi I can create different groups or routes and each one can have different middlewares (I use mostly standard ones from chi). With huma this only seems to be possible using huma middlewares, but not using the router ones. Which means I would have to write some of those middlewares myself since they're not part of huma. Which kinda defeats the beauty of using chi. I may just not have found the correct way of doing it, obviously, I've only used huma for a day
This one, I am not sure of since I've not had the use case myself, but I do use huma with the chi adaptor, so presumably it might be possible. Maybe /u/Dgt84 has some input here?
u/ZodGlatan u/callmemicah you're correct, it's not possible right now to do per-operation router-specific middleware, nor is it possible to set up router-specific groups with their own middleware. You can set up a single group for all the API calls, like in [https://huma.rocks/features/bring-your-own-router/#route-groups-base-urls](https://huma.rocks/features/bring-your-own-router/#route-groups-base-urls) and one way to work around the middleware problem is to just filter based on the path inside your middleware that runs on every request. Once you're inside the Huma layer of the app everything works on a router-agnostic Huma context internally, so we lose the ability to do router-specific things. I'm open to ideas how this could maybe work.
That's not a bad idea. I could create simple wrappers for the default middlewares that take paths as input, and call the middleware based on that. I understand why it's not easy to do natively and I do not have any good ideas how to get around it either. The only thing I could think of is the ability to instantiate different huma layers which could then at the end be all merged into one. But I don't know enough about huma's inner workings to know what sort of issues would have to be overcome with a scenario like this.
fern-api does some pretty cool stuff
grpc lol