ws VS rest

Then take a look at this article - https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ - using external from Go std lib epoll implementation and https://github.com/gobwas/ws lib it's possible to reduce memory usage per connection drastically. Though keep in mind that this approach is not obvious to implement right and you better to go with STD lib.

Yes, but there are two excelent libs for golang websockets - https://github.com/gobwas/ws - https://github.com/centrifugal/centrifuge

Yes, I find https://github.com/gobwas/ws to be far superior. It has a lot more ability to customize and get high performance as well as a utility package that is much higher level and makes it easy to use. It doesn't have some of the problems of gorilla because they didn't have to support people already depending on it

There's https://github.com/gobwas/ws and https://github.com/nhooyr/websocket but neither have seen a commit in over a year

Oh, thanks! And sorry for still not switching to https://github.com/gobwas/ws :)

Hello, +1 to WebSockets. If you need to choose WS library – go with https://github.com/gorilla/websocket or https://github.com/gobwas/ws. You can also look at Centrifugo server (https://centrifugal.dev/, supports WebSocket, SockJS bidi transports, also EventSource, HTTP-streaming, GRPC unidirectional transports and many builtin features) or https://github.com/centrifugal/centrifuge Go library.

I prefer gobwas/ws because it has the high level "easy mode" (though some things will still be a small learning curve if you are used to REST mostly) and a low level API that you can dive into if you need very high performance and don't mind getting deeply into the details. It has the advantage of being written much after the most popular Gorilla websocket implementation which has some complexity and other issues that it can't totally remove in order to keep compatibility for all of its many users. It's also battle-tested via mail.ru. See A Million Websocket and Go for more details on its inception.

Swaggest Rest can generate OpenAPI definitions from Go code, but it's not as comprehensive as Goa and does not support gRPC.

This is what I use: https://github.com/swaggest/rest

This has been the best implementation of the use case interactor I’ve seen and it outputs spec 3: https://github.com/swaggest/rest

Other times you might need a JSON REST API to generate OpenAPI docs code-first… for that I’m a fan of Swaggest REST. REST through clean arch.

For full code-first OpenAPI v3 REST, I’ve been using https://github.com/swaggest/rest and I like it.

For anything that needs OpenAPI docs, I’ve honestly found https://github.com/swaggest/rest pretty awesome. It’s basically just doc generation on top of Chi, but it does a lot of stuff right.

I used Echo for a lot of stuff (and it was easy to work with), but recently OpenAPI 3 has been a requirement, so I've switched to https://github.com/swaggest/rest

I've tried go-swagger comments to instrument existing code, but wasn't quite satisfied due to magical nature and error friendliness of those comments. So I decided to implement first-class OpenAPI generation on top of self-documenting action handlers: https://github.com/swaggest/rest/blob/master/_examples/basic/main.go. Schemas are generated from request and response structures using reflection and field tags.