goa VS FrameworkBenchmarks

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

Neat. Thanks for sharing!

Interestingly, may-minihttp is faring very well in the TechEmpower benchmark [1], for whatever those benchmarks are worth. The code is also surprisingly straightforward [2].

[1] https://www.techempower.com/benchmarks/

[2] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

ntex was formed after a schism in actix-web and Rust safety/unsafety, with ntex allowing more unsafe code for better performance.

ntex is at the top of the TechEmpower benchmarks, although those benchmarks are not apples-to-apples since each uses its own tricks: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

Ruby is slow. Very slow. How much you may ask? https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s... fastest Ruby entry is at 272th place. Sure, top entries tend to have questionable benchmark-golfing implementations, but it gives you a good primer on the overhead imposed by Ruby.

It is also not early 00s anymore, when you pick an interpreted language, you are not getting "better productivity and tooling". In fact, most interpreted languages lag behind other major languages significantly in the form of JS/TS, Python and Ruby suffering from different woes when it comes to package management and publishing. I would say only TS/JS manages to stand apart with being tolerable, and Python sometimes too by a virtue of its popularity and the amount of information out there whenever you need to troubleshoot.

If you liked Go but felt it being a too verbose to your liking, give .NET a try. I am advocating for it here on HN mostly for fun but it is, in fact, highly underappreciated, considered unsexy and boring while it's anything but after a complete change of trajectory in the last 3-5 years. It is actually the* stack people secretly want but simply don't know about because it is bundled together with Java in the public perception.

*productive CLI tooling, high performance, works well in a really wide range of workloads from low to high level, by far the best ORM across all languages and back-end framework that is easier to work with than Node.JS while consuming 0.1x resources

Although that seems to have improved in recent years.

https://www.techempower.com/benchmarks/#hw=ph&test=json§...

RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.

On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.

https://www.techempower.com/benchmarks

Most benchmarks you'll find essentially have someone's thumb on the scale (intentionally or unintentionally). Most people won't know the different languages well enough to create comparable implementations and if you let different people create the implementations, cheating happens. The TechEmpower benchmarks aren't bad, but many implementations put their thumb on the scale (https://www.techempower.com/benchmarks). For example, a lot of the Go implementations avoid the GC by pre-allocating/reusing structs or allocate arrays knowing how big they need to be in advance (despite that being against the rules). At some point, it becomes "how many features have you turned off." Some Go http routers (like fasthttp and those built off it like Atreugo and Fiber) aren't actually correct and a lot of people in the Go community discourage their use, but they certainly top the benchmarks. Gin and Echo are usually the ones that are well-respected in the Go community.

There is certainly a lot of speculation in Techempower benchmarks and top entries can utilize questionable techniques like simply writing a byte array literal to output stream instead of constructing a response, or (in the past) DB query coalescing to work around inherent limitations of the DB in case of Fortunes or DB quries.

And yet, the fastest Ruby entry is at 274th place while Rails is at 427th.

https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

oh what machine? with how many workers? doing what?

search for "node" on this page: https://www.techempower.com/benchmarks/#section=data-r21

JustJS would like a word https://www.techempower.com/benchmarks/#section=data-r20&tes...

In terms of RPS, this web service is more-or-less the fortunes benchmark in the techempower benchmarks, once the data hits the cache: https://www.techempower.com/benchmarks/#section=data-r21

Or, at least, they would be after applying optimizations to them.

In short, both of these would serve more rps than you will likely ever need on even the lowest end virtual machines. The underlying API provider will probably cut you off from querying them before you run out of RPS.