quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.73k stars 2.67k forks source link

Create a DevService for the mailer extension #32894

Closed iocanel closed 1 year ago

iocanel commented 1 year ago

Description

It would be great if I could experiment with the mail sender without spamming emails through an actual provider. A DevService could possibly help.

Other DevServices might be able to benefit from this too. Out of my mind I can think of Keycloak that could use something like it.

Implementation ideas

No response

geoand commented 1 year ago

I think this has been proposed before, but I can't seem to find it

melloware commented 1 year ago

This would be cool it could start up MailHog which has a great web UI for inspecting emails sent during DEV mode.

https://github.com/mailhog/MailHog

  mailhog:
    image: mailhog/mailhog:latest
    container_name: mail
    logging:
      driver: 'none' # disable saving logs
    volumes:
      - 'mail_data:/var/opt/mail'
    ports:
      - '1025:1025' # smtp server
      - '8025:8025' # web ui

I guess it could technically use GreenMail as well which is a pure java based Mail Server.

https://greenmail-mail-test.github.io/greenmail/

GregJohnStewart commented 1 year ago

@gsmet I made a very similar proposal before, but similarly cannot find it for some reason.... It was before Quarkus3 and the dev ui rewrite, and was suggested that it wait for the dev ui rewrite.

I circled back today to poke that issue again but, again, seems lost?

Having a mail server instance sounds like a good idea for implementing, though in my initial issue I was thinking just displaying the emails sent by the server, as you don't need full e-mail service in devmode

GregJohnStewart commented 1 year ago

Nevermind, found it: https://github.com/quarkusio/quarkus/issues/28700

melloware commented 1 year ago

But @GregJohnStewart wouldn't it have to implement the mail server to respect the full RFC of what people are doing in their code?

GregJohnStewart commented 1 year ago

I'd agree with you there, at least from an integration-type test standpoint.

The current recommended way to write tests is to use the mocks, my suggestion in the other ticket was to extend the mocking to the dev ui essentially.

I think your take has merit though for sure. I definitely see a use case, and would like to see it for integration type testing, or at least an easy option for it.

GregJohnStewart commented 1 year ago

One could easily write their own test resource manager that would leverage testcontainers too, there is the generic testcontainer class. Not as nice as a full devservice, but to get that full integration test it checks the box

melloware commented 1 year ago

Yep I have not looked too far into it but most of the time when I develop locally I startup MailHog in Docker and I just set my quarkus mail server to point to localhost so it's captured by MailHog and I can inspect what is coming out of my real server to a real SMTP server.

# ------------------------------------------------------------------
# E-MAIL
# ------------------------------------------------------------------
quarkus.mailer.host=localhost
quarkus.mailer.port=1025
quarkus.mailer.from=${quarkus.application.name}@melloware.com
quarkus.mailer.mock=false
GregJohnStewart commented 1 year ago

https://github.com/dasniko/testcontainers-mailhog

Check that out, looks like a testcontainer exists for mailhog.

melloware commented 1 year ago

OK team! I decided to use MailPit instead of MailHog for a few reasons:

  1. MailHog looks like it is dormant: https://github.com/mailhog/MailHog/issues/442#issuecomment-1503680341
  2. Mailpit is based on MailHog but is a complete rewrite in Go using Vue as UI
  3. has the same features and more than MailHog
  4. Actively Maintained.

DevUI: image

And if you click on the Mailpit UI you can see the UI right in the Dev UI! So you can browse all your captured emails.

image

geoand commented 1 year ago

Very nice!

melloware commented 1 year ago

cc @gastaldi can we tag this ticket as "extension" request?

gastaldi commented 1 year ago

Done. That's awesome! I wonder if we should make it a DevService in the mailer extension or a separate Quarkiverse extension. Both seems to work but the former seems more intuitive, WDYT @geoand @gsmet @cescoffier ?

melloware commented 1 year ago

@gastaldi we talked about having me do this as an extension so we can burn it in and test it and then move it once its all solid and everyone likes it into the mailer Dev Service?

I designed it right now like it is the Mailer Dev Service and it actually uses the quarkus.mailer.port to determine how to map the Mailpit listening port!

But I am OK with whatever you guys want to do.

My next task is figuring out how we can plug in @Test so you can simply ask for your messages in testing without having to know the Mailpit REST API.

gastaldi commented 1 year ago

I created https://github.com/quarkiverse/quarkiverse-devops/pull/185 and made @melloware the extension lead. Let me know if that works for you

melloware commented 1 year ago

OK by me 👍🏻

melloware commented 1 year ago

Version 0.0.1 is in Maven Central if anyone is brave enough to test it.

https://github.com/quarkiverse/quarkus-mailpit