📮 Postmark integration

[andreascreten]

I have been working on an integration of Postmark with Ghost. Please provide your feedback before I continue.

To-Do

• Implement analytics
• Handle Postmark errors
• Add tests

[github-actions]

It looks like this PR contains a migration 👀
Here's the checklist for reviewing migrations:

General requirements

• Satisfies idempotency requirement (both up() and down())
• Does not reference models
• Filename is in the correct format (and correctly ordered)
• Targets the next minor version
• All code paths have appropriate log messages
• Uses the correct utils
• Contains a minimal changeset
• Does not mix DDL/DML operations

Schema changes

• Both schema change and related migration have been implemented
• For index changes: has been performance tested for large tables
• For new tables/columns: fields use the appropriate predefined field lengths
• For new tables/columns: field names follow the appropriate conventions
• Does not drop a non-alpha table outside of a major version

Data changes

• Mass updates/inserts are batched appropriately
• Does not loop over large tables/datasets
• Defends against missing or invalid data
• For settings updates: follows the appropriate guidelines

[markstos]

Hello @andreascreten, I'm not a Ghost core team member, but am someone who previously submitted my own PR to allow non-mailgun senders ( #14984 ), so I can give you some feedback from that perspective. (Ultimately, I ended up using Mailgun and abandoned that effort).

I don't think there's a lot of appetite for maintaining non-Mailgun code in the core with their small team, but I think there /is/ interest in implementing an adapter pattern for bulk-email and email-analytics so other options can be plugged in and, crucially, completely maintained by third-parties outside of the core.

So I think the ideal PR implements the adapter pattern and has Mailgun as the included, default solution implementing that package. There would actually be no references to Postmark in the PR, but the PR would enable you make the swap using the config file system and third-party modules that implement bulk-sending and analytics. The rest of your solution would in modules you maintain and possibly publish to NPM yourself.

I see you made some progress in that direction replacing explicit references to MailGun with more generic "Bulk Email" or "Email Analytics" language when that part of the code has multiple possible implementations.

References

• Adapter Manager README
• Adapter Manager Code
• Other Ghost adapters on NPM

What appears to be happening is that a path to where a custom solution is stored gets declared under the "adapters" section in the config file. If this is not present, the internal implementation in used.

Admin UX

I saw your PR also took care of getting some Postmark bits to appear in the admin UI. I'm not sure the current adapter pattern covers that. What's there so far may only cover purely backend tasks, like swapping out data storage. It's possible you need to extend the adapter system to allow modules that implement the adapter system to have bits appear in the admin UI when they are loaded.