Clean Architecture and Social Networks

I'm currently reading Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin, which came out in 2017. It is a book about software architecture and design. And today I was able to put something that annoys me about social network and messaging services into new words.

A clean architecture consists of entities at the core. These are important business rules which would even exist if they are not implemented with a computer, but with a paper file system. Then around that are use cases. These manipulate the entities, but have no specific dependence on any implementation. Around those are components for user interface, data presentation and data storage. The dependencies are only inward, the core doesn't depend on any specifics. This is achieved by letting the inner layer control the interface, the outer layer implements it. A use case might need to store data, so part of that component will be an interface for data storage. A data storage implementation will implement that interface, but live in a different component. The implementation will just be one of many possible ones, the use case doesn't depend on anything specific.

Transfer that to content in social media. I have the text of my blog posts, I have the tracks I rode with the bike, I have taken images, and I want to send messages to friends. All these exist independent of the actual medium that I publish them on. The file formats (Markdown, JPEG, GPX) which I use are an implementation detail. And now I want to post them, that is my use case. And I want to post images to an image service, I want to post blog posts to a blog service, and GPS recordings to such a service.

With e-mail, I can just use whatever e-mail provider I wanted, they all implement the same interface, namely IMAP and SMTP. The interface is not controlled by the service provider, rather it is independent. My e-mail user agent only depends on that interface, but not on any particular provider. This way I can exchange the service provider at a whim.

But there is no such standardized protocol for posting stuff on social media. There is no common interface for sending messages in chat. There is nothing like IMAP or SMTP. Rather, all service providers provide their own interfaces. Few provide an API, but some just provide a graphical user interface. With Instagram one can only post content using their mobile app.

Applying the clean architecture mindset, I would need to define my own interface for picture posts, blog posts and track posts. Then I can have the content in any way which is convenient for me, and just use the interface I control. But then I would need to write adapters for all the services that I am going to use. They all have special features, which makes this really hard. And a bunch of them even makes it especially hard to use them in a cross-service way.

This of course is intentional, to lock people into the platform. For each platform the attention of the users is what brings them money via advertisements. If a platform can capture users longer, it is a win. And making it hard to move content to a different platform, or allowing people to have their content independent of the platform, makes it really to switch.

Say I wouldn't use Nikola for my blog, but rather just posted everything on Medium. I would not have much control over the content, and moving it to a different service provider would be really hard. I would depend on the service, but I actually want the service to depend on me. I mean “depend” in the sense that I don't want to care about the specifics of the service when I craft content. And if I ever wanted to use Medium, I could write an exporter from Nikola's Markdown files to Medium. And if I wanted to post on Facebook, I might be able to write this as well. But this is only possible because Nikola takes the data in a format which is rather neutral to me, and from which I can convert it to virtually anything. If one starts with any of the service providers, the lack abstractions means a lock-in.