Aller à la documentation
Ruby

Installation

Une gem, aucune dépendance d'exécution, Ruby 3.2 et versions ultérieures.

Installation

La version actuelle est 0.0.1. Elle a une méthode pour chaque méthode du SDK TypeScript, sous le même nom en snake_case, et la vérification de parité de la gem fait échouer le build quand l'une d'elles manque ou envoie une requête différente.

bundle add openemail
send_email.rb
require "openemail" OpenEmail.init(api_key: ENV.fetch("OPENEMAIL_API_KEY")) email = OpenEmail.emails.send(  from: "Acme Billing <[email protected]>",  to: "[email protected]",  subject: "Your September invoice",  html: "<p>Invoice attached.</p>") puts email[:id], email[:status]

OpenEmail.init configure le client partagé une fois, et à partir de là OpenEmail.emails, OpenEmail.threads et tous les autres espaces de noms l'utilisent, dans chaque fichier. Sans cet appel, le premier appel construit le client à partir de OPENEMAIL_API_KEY.

Une réponse est le JSON analysé sous forme de Hash à clés Symbol : email[:id] lit donc l'id. Les clés gardent les noms de l'API, c'est pourquoi un champ comme scheduledAt reste en camelCase alors que les méthodes et leurs options sont en snake_case.

Le retour de send ne signifie pas que le message est parti. Un envoi planifié ou annulable revient en queued ou scheduled et se règle plus tard. Lisez status, pas le fait que l'appel a retourné.

Où il s'exécute

Ruby 3.2 et versions ultérieures, sans dépendance d'exécution. Le client HTTP est Net::HTTP, de la bibliothèque standard, avec un pool de connexions maintenues ouvertes : une deuxième requête vers l'API réutilise la connexion ouverte par la première.

Un même client peut être partagé sans risque entre threads : un processus Puma ou Sidekiq n'en a donc besoin que d'un. Après un fork, comme en mode cluster de Puma, avec Unicorn ou Resque, le processus enfant ouvre ses propres connexions au lieu de réutiliser celles du parent.

Le client porte une clé d'API d'espace de travail capable d'envoyer du courrier et de lire la boîte : sa place est donc sur un serveur, dans un job ou dans un outil qui s'exécute sur votre propre machine. Conservez la clé dans Rails.application.credentials ou dans une variable d'environnement, jamais dans le code.