goa VS dapr

My experience of Golang is that dependency injection doesn't really have much benefit. It felt like a square peg in a round hole exercise when my team considered it. The team was almost exclusively Java/Typescript Devs so it was something that we thought we needed but I don't believe we actually missed once we decided to not pursue it.

If you are looking at OpenAPI in Golang I can recommend having a look at https://goa.design/. It's a DSL that generates OpenAPI specs and provides an implementation of the endpoints described. Can also generate gRPC from the same definitions.

We found this removed the need to write almost all of the API layer and a lot of the associated validation. We found the generated code including the server element to be production ready from the get go.

See https://goa.design/. It automates all the comms stuff, so you just write: 1) a design file showing your functions, 2) an implantation of those functions, and 3) a very generic "main.go" (basically the same for all your services) that decides "how is this exposed over gRPC or REST or other comms?". The rest of the code is generated.

Perhaps the easiest way to find out how to do something (especially when using Meta) is to search the test cases when you have cloned the source code.

If you really need a framework, you can take a look at Echo or, for a contract-first approach, https://goa.design/

Few folks in here are (rightly) frustrated with the code generation story and broader tooling support around the OpenAPI standard. I've found a few alternative approaches quite nice to work with:

- Use a DSL to describe your service and have it spit out the OpenAPI spec as well as server stubs. In other words, I wouldn't bother writing OpenAPI directly - it's an artifact that is generated at build time. As a Go user, I quite like Goa (https://goa.design/) but there are others shared in here like TypeSpec.

- There are situations where sticking a backend-for-frontend (BFF) in front of APIs can yield great productivity boosts. For example, in the past we built a thin GraphQL proxy that calls out to a poorly structured REST API. Integrating with that was much more convenient. Most recently, I've been playing with a BFF built with tRPC (https://trpc.io/) which calls out to a REST API. It seemed to provide an even better experience if you use TypeScript on the front-end and in the BFF. It does not have a codegen step and I was really pleased with how fast I could iterate with it - granted it was a toy project.

One of the biggest issues I see is that you are using the same models for API as you are for the database. That wouldn’t fly in a real work system. And even though your doing simple CRUD I would introduce another layer for business logic. You should never have the Controller calling you database code directly. It never “stays” that simplistic. One of the easiest ways to deal with this is to use Goa. https://goa.design/ It takes care of generating your API models and it creates the Interfaces to implement for your business logic. Furthermore it creates OpenAPI documentation (something missing in this design that is a must for commercial development).

I left PHP for Go.

- with http://sqlc.dev I don't have to write ORM or model code anymore.

- with http://goa.design I can have well-documented API's that any team can generate a client for in any language. It also generates the HTTP JSON and gRPC servers for me so I can focus on my logic.

- with https://github.com/99designs/gqlgen I can define GraphQL revolvers that play well with sqlc (any RDBMS) or I can use a key-value store.

- speaking of key-value stores, Go allows them to be embedded! Even SQLite now has the https://litestream.io/ project to make it super simple to use a durable, always backed-up SQLite database even in a serverless context.

Go is faster, uses less memory, and has really-well designed stdlib without all the bugs I used to face trying to use the PHP stdlib.

Goa and Kong are some of the best frameworks to develop and deploy microservices. They provide features such as out-of-the-box support for service discovery, routing and authentication that make it easier to build more complex applications. There are also newer architectural frameworks with less steep learning curves like GPTDeploy that lets you build and deploy microservices with a single command.

Or the one we use at work: https://goa.design/ Goa does a lot more and maybe more than you need. We use it as it can generate both REST and gRPC as well as API models and OpenAPI documentation (JSON and YAML).

The following two examples are open-source projects maintained by Fermyon with contributions from companies like Microsoft and SUSE. The first is Spin, which allows us to use WebAssembly to create Serverless applications. The second, SpinKube, combines some of the topics I'm most excited about these days: WebAssembly and Kubernetes Operators :) The official website says, "By running applications in the Wasm abstraction layer, SpinKube offers developers a more powerful, efficient, and scalable way to optimize application delivery on Kubernetes." By the way, this post shows how to integrate SpinKube with Dapr, another technology I'm very interested in, and I should write some posts soon.

Speaking of this has anyone had much experience with Dapr (https://dapr.io/) before?

I always thought this was a particularly interesting approach from Microsoft where they use this pattern to essentially take the complexity of micro services and instead try and keep it as simple as a normal .NET application but (and I think this is the clever part) in both a vendor and language neutral way.

But all of a sudden it means you can start removing all kinds of cruft and random SDKs from your codebase and push almost all of your interactions with the outside world into something like this .

Azure Container Apps hosting of Azure Functions is a way to host Azure Functions directly in Container Apps - additionally to App Service with and without containers. This offering also adds some Container Apps built-in capabilities like the Dapr microservices framework which would allow for mixing microservices workloads on the same environment with Functions.

Having containers is nice but everything (well ... nearly everything 😉) gets better with Dapr as an outstanding tool for app development in the container-based area. Here we go what might be worth a look:

Anyone using or planing to use darp Distributed application platform runtime as a microservices platform? https://dapr.io/

A CNCF project, the Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Whether your communication pattern is service to service invocation or pub/sub messaging, Dapr helps you write resilient and secured microservices. Essentially, it provides a new way to build microservices by using the reusable blocks implemented as sidecars.

Dapr is a runtime that implements common patterns such as pub/sub, state storage, etc. It runs as a sidecar to your app. Your app then interfaces with it using an sdk or http calls to use said patterns instead of implementing those patterns directly yourself. Seems pretty cool to me, but you can find out more at https://dapr.io/.

- Over 21k stars on GitHub, see the core repo and devstats.

I would like to build modules, either in a modular monolith style, or in a microservice style using DAPR and/or Tye.