Integration Overview

In order to meet the various requirements regarding social media functionalities and the associated adjustments to the related services, certain parts of the codebases have been identified as redundant. The domains for account management, post creation, and insight retrieval became conceptually solidified in such a way that they existed in almost identical form as code in multiple services. As a result, maintaining this functionality across multiple microservices proved impractical, and the social media services were consolidated into a single service with different strategy implementations.

Social Media Integration

Originally, each social media platform was integrated in Newsmind Stories via a dedicated microservice exposing two main functionalities: social profiles management (or account management) and publication (posts) management.

Account Management

The main goal of the integration is to make it possible for a Newsmind Stories user to connect to their social media profile in order to publish to it later. To do that, each microservice used its own data model. The main entity for account management is Account, carrying accessToken, refreshToken and socialProfileId, allowing actions to be performed on behalf of the user who connected the account. Each account then has a list of Instagram Business accounts (social profiles) for the Instagram service, or a list of managed pages for the LinkedIn service.

Conceptually, social profiles and managed pages have the same role in the application: they keep track of all the different profiles the authenticated user can post to.

Since social profiles and managed pages are conceptually the same, and since account also has the same functionality across all the different microservices, these concepts were consolidated into generic ones reused by every service.

The AccountManagement interface already implemented in the LinkedIn and Instagram microservices contained every operation needed for account management, so the same interface is used in the refactored application.

Publication Management

Every integrated microservice had a Post entity containing information about a post. Despite different names for certain attributes, the post entity was conceptually the same across all microservices, and was therefore unified into a single Post model.

How is the project organised?

The main objective is to have a solid foundation that makes the integration of further social media providers seamless. The application uses a hexagonal architecture style for code organisation.

• AccountManagement — implemented in a generic way using only AccountRepository, OAuth2Adapter and ProfileRepository.
• AccountRepository — retrieves and persists information about accounts.
• ProfileRepository — same as AccountRepository, for profiles.
• OAuth2Adapter— implements OAuth2 related requests:
  • create authorisation URL
  • exchange token
  • get user info
  • get user's profiles
• PublicationManagement — implemented in a generic manner, using only ContentPublicationAdapter and PostRepository.
• PostRepository — retrieves and persists information about posts.
• ContentPublicationAdapter — publishes on a social media platform and retrieves results.

The infra package is where the implementations of all those interfaces reside.

The main advantage of this architecture is that it makes the application easy to unit test, since a lot of code can be reused.

Which framework is used?

This is an opinionated choice. Since Dropwizard and the current Convit base library use Java 8 and upgrading them was not an option, a modern framework was chosen: Spring Boot, for which the team already had experience.

How is existing data handled?

Because applications were already in production using the isolated microservices, existing data had to be integrated into the new architecture. Three strategies were considered:

• Strategy 1 — Reuse the existing databases via Spring Boot's database resolver (multi-tenancy support). The databases can be reused immediately without additional cost on the database side.
• Strategy 2 — Almost the same as strategy 1, but on a schema level. Here there is a cost of moving data from the current databases to the new one and into their respective schemas.
• Strategy 3 — Change the data model to add a social_media_type column on every single table, and keep doing so for all new tables.

Useful references on how Spring Boot handles multi-tenancy:

• Multi-tenancy support with Spring Boot, Liquibase and PostgreSQL
• Multitenancy with Spring Data JPA

Tagging, @-mentions and collaboration

When working with social media, the concepts of tagging, mentions and collaboration are very important, since they allow a user to engage with other users and allow the provider to notify them.

• Collaboration allows a user to create a post together with other users. The same post appears identically on the feed of every user who is part of the collaboration. LinkedIn and X do not seem to support co-authored posts. Instagram, however, has good support for collaboration — see Instagram Help.
• Tagging allows users to assign a post to a certain category, using the #tag pattern in the post content. This functionality is the same across all providers.
• Mention allows users to reference another user in their post.

Limitations: LinkedIn and X provide endpoints to search users by their username (see the LinkedIn Profile API and the LinkedIn @-mention search API). It is therefore possible to offer suggestions while writing a post. Instagram, however, has no endpoint to retrieve users by username, so the same experience cannot be provided for Instagram posts.

Constraints

instagram and linkedin can be merged without much effort since they behave almost identically. The X (former Twitter) service, however, has some particularities.

1. X account / publication management

From a domain point of view, account and publication management work in X exactly as in instagram or linkedin, with the following restriction: accounts on X do not have managed pages (like LinkedIn) or business accounts (like Instagram). Therefore each account created for X will have exactly one profile. Publication works exactly the same as for LinkedIn and Instagram.

2. Search of tweets

The X service also supports searching tweets, which is not part of the domain described above. During the refactoring, all the code necessary for account and publication management is extracted from the existing service, and only the search code remains. After the refactoring, the social media microservice manages accounts and publications, while the X microservice scrapes/searches tweets.

Summary

Having a single app to manage all social media business processes is essential for several reasons:

• Reduced maintenance cost. Maintaining one app is easier than maintaining five. Using a single framework also reduces the cognitive effort needed to comprehend the code.
• Standard behaviour. Functionality works exactly the same across all integrated social media providers.
• Modern language and framework. Writing the application from scratch is an opportunity to upgrade the language version and adopt a modern framework.