O brother where art thou?
I don't know where you will read this, but I would like to tell the story about how this very content came about.
Right now, I am writing in the editor of blua.blue trying out the dev.to plugin I wrote. If everything goes to plan, you will read this post as a guide on what I did while at the same time it is the first live test of the functionality itself.
A little backstory
Blua.blue is a project facillitating content distribution as a hybrid CMS capable of
- decoupled CMS
- coupled CMS
- headless CMS
This effectively means that it ships with a frontend, a RESTful API and webhooks. What it can't do is formatting the webhook in order to target particular APIs. As with all headless CMS' it expects the endpoints to be under the control of whoever wants to publish content at a certain website or app. Unfortunately, this is simply not the case with dev.to ( At least right now, dear dev.to team: with the successful funding round in mind, do you need any additional developers? ).
The solution
The idea is pretty simple: what if a plugin received the webhook, transformed the request according to the api specs of dev.to and then sends it on?
blua.blue ---> webhook to blua.blue/dev-to ---> dev.to
The prerequisites are quite simple, I needed to convert html into markdown ( shoutout to "the league" https://github.com/thephpleague/html-to-markdown ) and then simply restructure the blua.blue payload to the dev.to format. But three things bothered me. First, I did not want to rely on the events of blua.blue (created, updated, deleted) as I wanted to acount for edge cases (like what if you install the plugin to your blua.blue instance and update articles that exist there but not yet on dev.to). The second problem was finding a way to reliably match articles on blua.blue with articles on dev.to. Thankfully, the article object of blua.blue contains a store object where I could simply save the dev.to ID. This solves for both of the problems as I know now
a) which article is already exists at dev.to ( and therefore needs to be updated rather than created ) and
b) how to reliably identify the relationship between the blua.blue ID and the dev.to ID.
But what about security? The last problem was that I effectively created an endpoint where anybody can send an object in the right format to the plugin endpoint and that object will be published to dev.to in my name. Well, when setting up the webhooks in blua.blue, I have the ability to set up a token. So for now, I use a combination of the `neoan3 credentials` operation and the token to ensure that only my articles are processed. But of course, this means that this plugin can only be used by one user of the blua.blue installation (here me).
In order to securly facilitate plugin use like this changes to the way blua.blue stores tokens needs to be revisited, and as usual, help is appreciated (https://github.com/blua-blue/blua-blue). However, a good solution would go a long way as it opens up the possibility for a wide range of self-contained plugins for blua.blue.
If you are interested in the progress: https://github.com/blua-blue/devTo
