API clients als plugin toevoegen
Denk bijvoorbeeld aan Facebook, Twitter/X, BlueSky en Mastodon.
Nu kan je op Packagist diverse API-clients voor Composer binnenhalen, maar nu ben ik benieuwd of er een bepaald systeem bestaat waarmee je dergelijke cliënts als een soort plugin kan installeren, zodat mijn verzend-cronjob niet teveel onderhoud nodig heeft, en dat je met minimale wijzigingen een nieuwe cliënt kan toevoegen. Uiteraard ben ik mij bewust van de autoloader van Composer, maar misschien kan het implementeren hiernaast makkelijker.
En ook vroeg ik me af hoe ik ervoor kan zorgen dat zodra een cliënt faalt dat de rest gewoon uitgevoerd wordt.
Iemand die wat tips heeft?
Gewijzigd op 20/10/2023 23:05:32 door - Ariën -
Gewijzigd op 21/10/2023 10:34:25 door Ward van der Put
Dat wil ik juist liever niet, want dan ben je weer afhankelijk van een platform die weer betaald is of zijn businessplannen omgooit. Plus dat ik mijn CMS mogelijk ook voor klanten in wil zetten.
Wil je zelf wel betaald worden voor je werk?
Het is kiezen uit twee kwaden: je vervangt de afhankelijkheid van één API van één partij door een heleboel kleinere afhankelijkheden van de API's van afzonderlijke social media-kanalen en alle subsystemen om die aan te roepen.
Ik zoek echt een oplossing in eigen beheer.
Ik kan natuurlijk alle api's via Composer inladen en achter elkaar aanroepen in mijn script, maar toch was ik benieuwd of er iets bestaat om nieuwe API's makkelijk in een handomdraai toe te voegen of uit te schakelen. Misschien een bepaald pattern ofzo die ik nog niet ken? Of een deftige OO oplossing?
Gewijzigd op 22/10/2023 11:09:23 door - Ariën -
Aantal resources die van belang kunnen zijn:
- https://symfony.com/doc/current/notifier.html
- https://github.com/symfony/twitter-notifier
- https://github.com/symfony/mastodon-notifier
Ik kan zo snel geen Bluesky/Facbeook bridge vinden, die zou je zelf nog kunnen tikken.
Anderzijds zou je je systeem anders op de bovenstaande manier ongeveer willen opzetten zodat je een abstractie laag hebt tussen de interface die jouw applicatie aan roept, en dan naar de downstream api "transports". Zo kun je de boel wel implementatie loos houden, maar kun je er makkelijk ook een bij toevoegen of weg halen.
Wil je minimaal onderhoudt, dan zou ik voor de suggestie van Ward gaan.
Maar mocht je een pseudocode opzetje hebben over je idee met de abstractielaag.
Graag.... :-)
Voor de ingebouwde API's maak ik allemaal losse classes of instances vanuit packages aan, zoals voor Mastodon, BlueSky, X en IFTTT.