top | item 43307888

(no title)

ayuhito | 11 months ago

The standard library.

It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.

discuss

order

9dev|11 months ago

I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing other developers to get productive immediately.

Comparing that to the go standard library is apples to skyscrapers.

charlie0|11 months ago

It's so obvious when someone hasn't even looked at those 3 frameworks because they think those are just some simple routing/controllers + ORM, lol. That's like 10% of the total functionality they offer, not counting all the extra stuff provided by their respective ecosystem.

I don't mean to knock on Goravel or things like Apollo, but they got a very very long way to go to even measure up against Django, Rails, or Laravel in terms of functionality.

ayuhito|11 months ago

Almost everything you listed already exists in the standard library.

And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary.

There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.

kgeist|11 months ago

Just my two cents how we do it in most of our projects at this point (~70 services in Go):

>routing, middleware

ogen (OpenAPI code generator), or a similar library

>database connections

from Go's stdlib mostly

>an ORM

sqlx (a lightweight wrapper around Go's stdlib which allows to hydrate results into structs)

>authentication, sessions

homegrown stuff, due to existing complex legacy stuff

>job queues

RabbitMQ's official Go wrapper (rabbitmq/amqp091-go)

>email sending

we delegate to a few separate VMs which already have postfix installed (and have good reputation)

>dependency injection

manual construction, works fine if split correctly

>logging

sirupsen/logrus (structured logger)

>view template rendering

React

>metrics

official Go wrappers for Prometheus

Some of this stuff is already IMHO industry-standard (the default libs people reach to). To streamline creation of new services, we have a tool which can scaffold your project with all these dependencies already set up.

desumeku|11 months ago

>job queues

In Go, these are called "channels".