Tabell for persistering av payload

[OleksandrChmyrNAV]

No description provided.

[kfh]

Er dette tabellen som smpt-transport skal skrive til ? cc/ @thburnett Hvis det kun er smtp som skriver til denne burde vel eierskapsforholdet ligge på smtp-transport siden. Altså, migrasjoner osv bør være i denne modulen.

[kfh]

Generell kommentar, har du sett på Hoplite som jeg presenterte for et par uker siden, @OleksandrChmyrNAV ? Jeg syntes koden blir mye ryddigere hvis du løfter alle disse miljø-variablene ut i konfigurasjonsfiler og leser inn et typesikra Config-objekt.

[OleksandrChmyrNAV]

@kfh Ja, det har jeg, og jeg synes at det å ha config filer i prosjektet, er en verdig bra ide.
Men jag tror at det blir en separat oppgave for å ta i bruk Hoplite i prosjektene våre for at det er mange ting i f. eks. ebms-provider som kan flyttes til confi filer.

[thburnett]

Er dette tabellen som smpt-transport skal skrive til ? cc/ @thburnett Hvis det kun er smtp som skriver til denne burde vel eierskapsforholdet ligge på smtp-transport siden. Altså, migrasjoner osv bør være i denne modulen.

Isolert sett kan man si at det burde være smtp-transport som eier den, ettersom den skriver til databasen. Men vi har vel ikke diskutert om det bare er denne modulen som skal skrive til databasen enda. På utgående meldinger sitter vi også med et behov for å mellomlagre både fagmeldingene vi får før de prosesseres, og de ferdige behandlede payloadene som skal sendes ut via smtp. Da skjer skrivingen fra henholdsvis sendout/sendin eller ebms-provider sin side. Det kan vel løses med en egen database for bruk på de interne fagmeldingene (noe som sannsynligvis er en god ide), eller ved at databasen eies et sted i midten. Men selv mellom smtp-transport og ebms-provider går skrivingen begge veier.

I tillegg trenger vi lagring av hendelsesinformasjon et sted, som naturlig eies av ebms-provider. Dersom smtp-transport skal ha sin egen database, trenger vi uansett databasekonfigurasjon, vault-integrasjon og flyway begge steder. Ellers gir det mest mening at akkurat den databasen det refereres til her, tilhører ebms-provider med tanke på navngivningen.

Men det er klart at dersom det virker fornuftig allerede nå, er det bare å opprette en ny database for bruk fra smtp-transport med en gang. Det er raskt og billig å komme i gang med.

Det viktigste tenker jeg er å få opp et sted vi kan begynne å persistere data, slik at vi får jobbet med databaseskriptene og meldingsflytene. Vi kan alltids optimalisere, utvide og splitte databaser, og flytte rundt på databaseskriptene etter behov.