Architecture d'une application avec plusieurs "sous-applications"

Bon, je me doute que le titre n’est pas clair, mais c’est vraisemblablement parce que c’est pas clair non plus dans ma tête.

Le contexte

Je suis en train de mettre en place un système de commandes par e-mail. Pour faire simple, j’ai une adresse mail principale et j’y colle des alias pour les “applications spécifiques”. Ca permet de ne gérer qu’une seule boite mail.

J’ai donc une parte du bousin qui s’occupe de la partie “aller lire les mails”. Ce morceau là recrache les mails un par un après les avoir retravaillé un peu.

Ensuite, certaines commandes sont globales et font le même boulot quel que soit l’alias mail utilisé, si une de ces commandes est rencontrée, je fais mon taf et c’est tout, je n’exécuterais pas plusieurs commandes. Donc le mail est considéré comme traité et sera supprimé à la fin.

Si aucune commande globale n’est trouvée, je me base sur l’alias utilisé pour connaitre l’application utilisée et là je peux exécuter plusieurs commandes à la suite. Idem, le mail sera supprimé à la fin.

Le problème

La partie gestion des e-mails est traitée à part, et la partie “commandes globales” est la même pour tous les alias. Par contre, la partie “application spécifique” peut être lourde et comporter plein de trucs. Chaque application possède ses propres templates de réponses également et ses propres règles.

Les solutions que j’ai déjà envisagé

Faire une “lib” pour la gestion du mail et des commandes globales.

  • Avantages
    • Ca permet d’avoir un truc bien propre dans son coin
  • Défauts
    • L’accès au mail est fait plusieurs fois
    • Je pensais avoir un seul crontab à gérer qui traiterait tous les mails, là, potentiellement j’en ai un par application

Faire un truc unique qui gère toutes les applications directement.

  • Avantages
    • J’ai un seul crontab que je peux donc appeler régulièrement
  • Défauts
    • Je dois fournir le message à la bonne application, donc faire des imports dynamiques ou bien tout importer (et donc modifier la partie “commune” à chaque ajout d’application)
    • Les réponses doivent être stockées au fur et à mesure, utilisation d’un truc genre singleton ?

Faire un truc unique qui transmets les mails via un bus de message (rabbitMQ ?).

  • Avantages
    • Chaque morceau est bien indépendant
  • Défauts
    • Le crontab est ok pour la récup ou l’envoi des mails, mais les applications doivent être lancées tout le temps pour réagir ?
    • Les réponses sont renvoyées par le même bus pour être traitées par le morceau commun ?
    • Je voulais un truc simple :smiley:

Ma question est donc : Comment vous organiseriez le code ?

Bon, je me réponds à moi-même, j’ai p’tet une solution…

Je ne répond qu’à cette sous-partie pour le moment puisqu’il semble que tu aies peut être trouvé ta solution : en Python un singleton c’est un module (ou un module c’est un singleton, tu lis comme tu veux).

Bon aller je répond quand même à la partie archi : le programme principal appele (fork puis exec) le sous-programme, en lui filant le mail dans stdin, c’est tout.

Avantages :

  • tu peux implémenter tes sous-programme dans le langage que tu veux.
  • le processus principal n’a pas besoin d’attendre qu’un sous-programme ai terminé pour traiter un autre mail.
  • tu peux tester tes sous programmes à coup de cat test.eml | sous-programme

Je vais jeter un oeil, mais comme j’ai besoin d’avoir les réponses pour les renvoyer, le second avantage n’en est pas forcément un : je dois récupérer les réponses du sous programme.

Merci pour les sugestions en tout cas !

Ton sous-programme peut répondre sur stdout, mais en ce cas il faut en effet construire quelque chose d’un peu plus robuste pour le lire de manière asynchrone.

J’ai un exemple ici si tu veux :

Pourquoi ne pas avoir un boucle de lecture des mails, pour les insérer en base de donnée, du type redis.
ensuite tu te fais un pub sub avec redis, et le dernier programme à tourner, lance un commande de suppression.

Parce que c’est “tout” sauf “smiple” ? :smiley:

ça peut être un poil complexe,
mais tu pourrais ajouter autant de composant que tu veux.
les applications seraient scindées, et pourrais tourner dans des thread séparés.

Pour un “premier jet” je vais tâcher de rester sur du basique. Sans devoir importer la moitié de la planète ;o)

Bonjour,

En supposant que c’est bien le traitement lourd de certains sous-tâches qui sera dimensionnant et non pas la lecture des mails je suis attiré par la simplicité de la première option : lire les mails plusieurs fois pour pouvoir simplifier le code.

Ca me semble ua contraire assez contre-productif. En gros, je veux pouvoir répondre rapidement à chaque mail (l’ordre de la minute) et une seule boite mail est utilisée (chaque appli n’est qu’un alias).

Cela voudrait donc dire faire plusieurs crontab (un par application) et accéder et traiter plusieurs fois un même mail.

Cela dit, j’ai avancé sur ma solution : je ne fais qu’un seul passage et suivant l’adresse mail utilisée (toto@foobar.com => application toto), j’appelle une fonction “process” en lui filant le message.

1 J'aime

Tu pourrais peut être essayer un pattern State.