Nowadays, the microservice pattern has become a common pattern and in high scale projects this way of organizing the project structure is always preferable. Of course, there are always new challenges when the infrastructure gets complex BUT there is always a workaround. Anyway, in this topic I don’t want to elaborate all microservice pros/contra or challenges BUT I want to focus more on a solution we did using WordPress’s REST API in a very complex API for a specific module.
CMS’s that are for a long time in the market have built & defined some behaviors for most developers on how to use them and these behaviors are not changing even though the CMS’s are providing new trends of Web Development. WordPress for example is providing many new opportunities to have a modern CMS (like headless, REST API’s) but the classic way is still followed (which I don’t think is entirely wrong or bad) from the developers but the new opportunities are not seen.
There are plenty more use cases where an existing CMS might be a good fit to have a faster, stable feature in your product or MVP. WordPress, for example, is a very good case for blogging, E-Commerce, and with some small workarounds, you might build something easy and fast using only the core features.
The use case around a fintech digital banking app
Lately, a part of our team has been working on a large enterprise project, which is basically a digital banking app similar to Revolut, N26, etc. Among the core banking functionalities, the product had some features that were mostly for user engagement like a gamified scoring system, a blog with different banking topics, and much more.
Creating a custom blogging system where the content writers might write good content and style it, users might read it and comment on specific topics was time consuming for us as we had to provide user management for the blog, the editor, and protect the content from non bank users and allow only bank users to write reviews on topics. On the technical side, we considered that providing a blog implementation in a architecture where we handled only the banking core services might not be a good idea because of the some reasons listed below:
The entire banking app has many users roles to support their clients and mixing them with blog writers is not a good idea
The people who write blogs might sometimes be external users which should not have the chance of accessing the internal system
Writing a blog requires a very good editor and other flexibilities for content reviewing, uploading images, embedding external content, etc. That of course impacts the complexity and the time-consuming of this feature.
In order to achieve this solution faster and cleaner on the tech side, we had to use an existing CMS that would provide us all the blogging features: Text Editor, Content review, User Management, Roles, etc.
Below is a high-level overview of the banking core features in combination with the Blog Service that actually doesn’t have a good fit in the business logic behind:
Keeping the architecture clean, implementing the blog service including all blogging requirements, providing the API that would provide the content for mobile apps, and keep the content secure and accessible only for the banking users were the conditions our team should have in mind and achieve by not spending that much effort.
As we have quite good experience with WordPress we decided to do this by using this CMS. We had only one blocking issue we had to solve: allowing only bank users to access the content!
As we’re using JWT Authentication for the banking ecosystem we had to create a bridge somehow from the WordPress Blog to the Banking Authentication Service which would verify the JWT token. For that, we followed the approach of a third party authentication service and we created a custom plugin that will handle this part.
As WordPress requires the user to be stored in their database in order to make the authentication work our plugin has these responsibilities:
Allow the WordPress Admin to define the third party authentication service API Endpoint which then will handle the JWT confirmation part.
When an API call is performed in the WordPress API the plugin has the responsibility to verify the authentication token provided in that request.
The plugin is responsible to keep in sync with users that are performing requests for the first time and store them in the WP database and for security matters, they should be only subscribers.
An high level architecture view if this approach would look like this:
As in some cases, there is not a good approach to share data between different services without anonymization, our approach gave the responsibility that the anonymization could be done entirely to the Authentication Service.
The plugin is reusable on each approach with the JWT token verification. All you need to do is create a separate API Endpoint that responds as asked from the plugin.
Suggestions & a plugin as a solution
As WordPress allows all the users to reset their passwords by email or username, we suggest that this data should be as generic as you can keep them. This would stop the users to access the web part BUT if that isn’t a problem for your business logic then you can keep the real data intact.
As the communication is done using HTTP Protocol we always suggest that you allow access to the API Endpoint of your Authentication Service only for specific IP or secure that with an extra token. This would avoid any attack from unknown sources in case there was a security bridge in your infrastructure.
For this purpose, we have created a Third Party API Authentication as a plugin for WordPress that allows the use of a third-party JWT Authentication service in order to allow users to access the Rest of API of your WordPress website/blog, e-commerce, etc. Check it out here: Third Party API Authentication
In this approach, we store the users always in the WordPress database. Which somehow would produce a redundancy of users' basic data in two different platforms. This is because the users in our case should have the possibility to comment on different topics. But in case there is only data read from the REST API then this could be modified and avoid the redundancy of user data by not storing it again to the WP Database.
Existing CMS’s have wide opportunities to be reused for different approaches which might save time and provide a good user experience to the clients. Our team is always building nice stuff and you are one click away from getting these professional services by reaching out to us and our team, via the dedicated contact sections.