Applicazione Mailgun for Rails

Question

Al momento sto lavorando all'implementazione di Mailgun nella mia applicazione rails ma mi sembra di essere confuso sul metodo migliore.

Il modo in cui ho già implementato è impostare le aree, aggiungere il file gem e quindi impostare il processore in background tramite Active Job. Non ho ancora impostato il processore in background perché non sono sicuro se questo è il modo migliore.

Ho visto altre risorse dire che dovrei semplicemente usare il componente aggiuntivo di Heroku e quindi la codifica aggiuntiva minima. Voglio anche menzionare che ho impostato Devise quindi non ho bisogno di e-mail inviate per le situazioni tipiche.

Come potete vedere, sono abbastanza perso a questo punto e sto solo cercando di capire quale metodo è il migliore. Se vi capita di conoscervi o di avere una buona risorsa da usare, fatemelo sapere =)

Nota a margine: mi è stato anche detto lungo la strada "Non attivare l'invio di e-mail da un callback di ActiveRecord - Fallo da il controller. " L'ho scritto per riferirmi a quando è arrivato il momento e qui sono = P Saresti d'accordo con questa affermazione?

posso aggiungere il codice se sarebbe d'aiuto, ma sono confuso su quale codice sarebbe davvero utile ...

grazie mille!

Joe

Modifica

Ancora una domanda: Idealmente mi piacerebbe essere in grado di inviare una e-mail personalizzata per tutti gli utenti per l'applicazione (es: Aggiornamenti settimanali, nuove funzionalità del sito, eccetera.). Mailgun sarebbe anche il metodo corretto per farlo?

Answer 1

Mailgun non è diverso da Sendgrid o Mandrill, quindi quando cerchi qualche indicazione, puoi anche prendere in considerazione queste soluzioni. Le mani in basso la migliore guida per il tuo caso d'uso è Sending Emails in Rails Applications. Puoi anche scegliere tra le gemme esistenti per l'API Mailgun Official gem o ActiveRecord integration.

Il modo in cui ho già implementato è impostare le aree, aggiungere il gemma e quindi impostare il processore in background tramite Active Job. I non hanno ancora impostato il processore in background perché non sono sicuro se sia il modo migliore.

Sì, questo è il modo corretto per configurarlo. Prima di Rails 4.2, e credo che la maggior parte di coloro che sono codificati senza l'esistenza di ActiveJob preferiscono ancora le cose come dj, sidekiq o resque e sono molto popolari e possono essere trovati in quasi ogni applicazione Rails . Puoi usarli con l'interfaccia di ActiveJob. Tuttavia, il concetto è lo stesso.

Per dare un'idea circa la parte mancante del codice, è possibile fare qualcosa di simile (dal 1 ° anello)

class ExampleMailer < ActionMailer::Base 

    def sample_email(user) 
    @user = user 
    mg_client = Mailgun::Client.new ENV['api_key'] 
    message_params = {:from => ENV['gmail_username'], 
         :to  => @user.email, 
         :subject => 'Sample Mail using Mailgun API', 
         :text => 'This mail is sent using Mailgun API via mailgun-ruby'} 
    mg_client.send_message ENV['domain'], message_params 
    end 
end 

Nota a margine: mi è stato anche detto lungo la strada "Don' t attivare l'e-mail inviando da un callback ActiveRecord - Fallo dal controller. " I ha scritto quello giù per riferirsi a quando è arrivato il momento per esso ed eccomi qui = P Sei d'accordo con questa affermazione?

Sono assolutamente d'accordo con la dichiarazione. Una cosa è che concatenare tutto ai callback di ActiveRecord potrebbe sembrare davvero pratico a prima vista, ma poi, man mano che l'applicazione cresce, ti vedrai mettere in dichiarazioni condizionali o usare cose come le macchine di stato da coprire. Il caso dietro è che potresti creare record nella tua applicazione da più fonti (registrazione utente, importazione amministratore, ecc.) E non in ogni caso desideri che l'email sia inviata. Inoltre per me e per i nuovi membri del team è più pratico vederlo direttamente nel codice del controller, piuttosto che passare attraverso i callback dei modelli. Alla fine questo può essere considerato anche come una preferenza personale.

Se si utilizza Heroku, quindi dare un'occhiata a questo Delayed Job guide. Su Heroku, dovrai eseguire questi processi in background nei lavoratori separati (che non sono gratuiti), perché alcune soluzioni convenienti prendono un bottino allo Running delayed jobs on Heroku for free.