Comment on Reality check: Our Go backend stack

spacedogroy@feddit.uk ⁨7⁩ ⁨months⁩ ago

To be honest, it doesn’t seem that bad. With clean architecture, you are going to end up with extra types and mappers. I would argue that what you have isn’t coupled, because a change in one place doesn’t have unexpected side effects elsewhere.

I haven’t used Goa or Gorm. Writing SQL by hand gets old quick so I get why you’d use Gorm - just less code to write in the end. I’ve used sqlc as it’s more a library than a framework, and it’s fine, but it can’t fulfill every use case. Goa looks too opinionated for me, on the face of it.

I’ve used wire. It takes some understanding but it’s definitely a lot to understand just to add a dependency. At work we’ve got our own template for doing dependency injection and although I was skeptical at first it strikes a really good balance between being understandable and abstracting away DI. If this is your pain point, I’d consider going back to basics and get rid of the framework.

If you decide to go with a framework like Laravel, Rails or Next.js and don’t build everything around the framework, you will deliver quickly at first, but you won’t have type safety and it particular point it will stop scaling because these frameworks have no consideration for clean architecture. You won’t necessarily be better off.

source
Sort:hotnewtop