dapr VS Gin

Fasthttp on which fiber is based has A LOT of drawbacks and I would not recommend for general usage. Among things we found while analyzing it for Dapr: no request-specific context, no HTTP/2 or HTTP/3, almost no support for streaming, and the occasional bug that can’t be figured out.

One thing that I've seen work is that if you absolutely require the ability to deploy on-prem then using something like OpenShift/Kubernetes as a primitive can work per the parent.

Even if you rely on streaming like PubSub or Kinesis, the trick is to write interfaces in the application tier that allow for using an on-prem primitive like Kafka and not depending too much on the implementation of that abstraction.

I've been on a platform team that built these primitives into the application layer, e.g. a blob storage interface to access any blob store whether it's on prem NFS, azure, etc. However I'm looking at newer projects like dapr [1] and have taken them for a spin in small projects. Such a project seems like a favorable way to add "platform services" to a non-trivial app while still maintaining a pubsub abstraction that allows for swapping out the physical backend.

[1] https://dapr.io/

The full analysis is here, and even though some things are specific to our project, most are generic: https://github.com/dapr/dapr/issues/4979

Furthermore, microservices are often deployed together with service frameworks. For example, Dapr is a popular runtime framework for microservices. It provides a “sidecar” service for each microservice. The microservice accesses the sidecar via the Dapr API to discover and invoke other services on the network, manage state data, and access message queues.

Dapr Runtime v1.9.0

It is starting: Dapr WF engine implementation starter

Azure Container Apps is built upon the foundation consisting of open-source technology with CNCF projects like Kubernetes Event-Driven Autoscaling (KEDA), Distributed Application Runtime (Dapr), and Envoy running on the Azure Kubernetes Service (AKS).

https://github.com/dapr/dapr is cool but not easy to start (may be)

Disclaimer: I'm not a frontend dev, I'm not a mobile app coder and I didn't really want to do anything. But I happen to code fairly often in Go, and so I figured the type table was really just a big map of values (either 0, 0.5, 1 or 2) tying one type to all other types... Could I maybe get away with a backend app that would handle it? Surely not... But I had recently noticed the Gin HTTP framework and it seemed fairly easy to use.

gin-gonic/gin

Web framework gin

A lot of places seem to suggest https://github.com/gin-gonic/gin , but it seems too micro for my tastes. There's https://github.com/gobuffalo/buffalo that seems to have the appropriate amount of kitchen sinks included, but does it pass the popularity test? Any other options I've missed?

Gin

I started my project with developing API server in Golang. For the HTTP library I used Gin framework, as it provides an friendly interface to build REST ready API.

Gin is a popular library that claims to use zero heap allocation, for instance.

GoLang Gin Server to create tasks apis