3 ms·

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 li

by kgeist 2y 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.

tgv 2y ago
> email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)
- deleted 2y ago
  [deleted]
- 9dev 2y ago
  It’s not. One thing is sending batches of transactional mail to thousands of recipients in a production web application running on a bunch of replicated containers on ephemeral machines, the other is proof that SMTP theoretically works in your programming language.
  - desumeku 2y ago
    It does not take more than 10 lines of code to launch a goroutine (or two, or more, due to how easy worker pools are in Go) that receives email requests and sends them in batches.
    - 9dev 2y ago
      And some more to add retries. And then another few to handle attachments. And just some more to generate previews. And multipart messages. And testing. And just like that, you spent a whole lot of time to reinvent something frameworks like Laravel include out of the box, right now. And did I mention it is documented and any other developer familiar with the framework can immediately use, without having to waste time reading library code?
      - desumeku 2y ago
        "A little copying is better than a little dependency."
9dev 2y ago
Im not saying all of this isn’t possible in Go, or somehow worse. My point is that using eg. Laravel, you don’t even need third-party libraries for these things, just the framework. And all of it is built on the same conventions, documented in the same place, with the same API. Scaffolding is built-in too. All of the time you spent on building your scaffolding tool, researching on the libraries, checking and updating their version regularly; all of that isn’t necessary with a full-stack framework. Once more: I’m not dismissing Go, or your way to set up projects, I’m just surprised someone would make the comparison to the Go std lib, which is so obviously not on the same level of integration and battery inclusion.

by kgeist 2y ago

tgv 2y ago

> email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)

deleted 2y ago
[deleted]
9dev 2y ago
It’s not. One thing is sending batches of transactional mail to thousands of recipients in a production web application running on a bunch of replicated containers on ephemeral machines, the other is proof that SMTP theoretically works in your programming language.
- desumeku 2y ago
  It does not take more than 10 lines of code to launch a goroutine (or two, or more, due to how easy worker pools are in Go) that receives email requests and sends them in batches.
  - 9dev 2y ago
    And some more to add retries. And then another few to handle attachments. And just some more to generate previews. And multipart messages. And testing. And just like that, you spent a whole lot of time to reinvent something frameworks like Laravel include out of the box, right now. And did I mention it is documented and any other developer familiar with the framework can immediately use, without having to waste time reading library code?
    - desumeku 2y ago
      "A little copying is better than a little dependency."

9dev 2y ago

Im not saying all of this isn’t possible in Go, or somehow worse. My point is that using eg. Laravel, you don’t even need third-party libraries for these things, just the framework. And all of it is built on the same conventions, documented in the same place, with the same API. Scaffolding is built-in too. All of the time you spent on building your scaffolding tool, researching on the libraries, checking and updating their version regularly; all of that isn’t necessary with a full-stack framework. Once more: I’m not dismissing Go, or your way to set up projects, I’m just surprised someone would make the comparison to the Go std lib, which is so obviously not on the same level of integration and battery inclusion.