http-spec VS goa

However, we do not need to write the specification by hand, as there are GUI editors to perform that task. We show a couple of examples of Spotlight, which provides an easy-to-use interface:

We use Stoplight Studio https://stoplight.io/ to design APIs, one of the advantages of Stoplight Studio is the Visual interface, it generates OpenAPI specs from the design and supports OpenAPI v3, allowing users to create, edit, and view API designs using the OpenAPI standard.

I'm sorry, but you have completely misunderstood the purpose of Open API.

It is not a specification to define your business logic classes and objects -- either client or server side. Its goal is to define the interface of an API, and to provide a single source of truth that requests and responses can be validated against. It contains everything you need to know to make requests to an API; code generation is nice to have (and I use it myself, but mainly on the server side, for routing and validation), but not something required or expected from OpenAPI

For what it's worth, my personal preferred workflow to build an API is as follows:

1. Build the OpenAPI spec first. A smaller spec could easily be done by hand, but I prefer using a design tool like Stoplight [0]; it has the best Web-based OpenAPI (and JSON Schema) editor I have encountered, and integrates with git nearly flawlessly.

2. Use an automated tool to generate the API code implementation. Again, a static generation tool such as datamodel-code-generator [1] (which generates Pydantic models) would suffice, but for Python I prefer the dynamic request routing and validation provided by pyapi-server [2].

3. Finally, I use automated testing tools such as schemathesis [3] to test the implementation against the specification.

[0] https://stoplight.io/

[1] https://koxudaxi.github.io/datamodel-code-generator/

[2] https://pyapi-server.readthedocs.io

[3] https://schemathesis.readthedocs.io

One of the best tools out there for API design and governance https://stoplight.io/ you can also use the open source tool (also from Stoplight) called Spectral https://stoplight.io/open-source/spectral

Stoplight is a platform for designing, documenting, and testing APIs. Its "Mocks" feature allows you to create mock versions of your API for testing and development purposes. In addition to the mock feature, Stoplight also includes tools for API design, documentation, and testing, making it a comprehensive platform for API development.

Stoplight

JSON visualizer JSON validator YAML validator Collaborative Design & Documentation for APIs

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).