MVP
According to the requirements Devox and Joynd teams shaped together, the MVP version had to feature the connector that would transfer the HR data from one system (the HR software) to the other (the Joynd platform itself as an assemblage point).
Bringing different software and a platform together
The key challenge around developing a system like Joynd was a physical embodiment. We had to unite two ingredients: a number of different software with its own unique user flow and a platform where all of it is unified like in a library.
Design
After conducting thorough UX research, our team of designers worked on the user path from scratch. We thought out a range of user identities, including different levels of access, and tuned their dashboards and user flows. In particular, we set up an admin side (with more default access) and a client side (with selected access).
Back-end integrations
After creating a platform, we created a system of back-end integrations to provide functionality and seamless integrations with suppliers’ software.
Access points: Federated Identity
The first approach we employ on the back-end is federated identity. This approach allows managing user’s data within different systems.
A federated identity is the means of linking a user’s identity information stored across different identity management systems. In Federated Identity Management, an arrangement is made between multiple organizations, such that users can use the same credentials to access networks of all the organizations in the group.
How it works
The user makes a request on the front-end. This request goes to two back ends: the service provider’s (the integrated solution) and the Joynd platform’s. The user’s identity is checked on both sides, which is how it’s federated from both angles.
As Joynd as a system offers access to multiple services that have to stay public as they are not united by a single category, the issue of security and secure connection arises. This is why we implemented permission-based authentication, where permissions are checked to be coming strictly from Joynd’s UI – not the related providers’ application or website. For such authentication, we use JSON Web Token.
Recently, we have implemented the Transit API: from token – user – called command chain, we switched to a different one in order to, first of all, upgrade the system’s security, and secondly, streamline the Joynd portal workflow regarding multiple accesses. Before, all the users used to call a single back-end, while now, each user gets their own unique JWT token. This token is preserved on the back-end and communicates with the Transit API when the log in happens: when the user tries to log in, the system sends their token via transit API along with their user name. It is generated upon the successful log in on the front-end and is destined for a Transit API to back-end communication
Architecture
We’ve chosen the approach of hexagonal architecture in order to separate the business logic from the external factors (databases, APIs, transit APIs). Hexagonal allows separating the inner core from different ports and adapters as ambassadors of business logic operating with other services. This approach allows us to leverage flexibility and agility of complicated sign-in operations, streamlining upcoming types of testing (end-to-end, integration, unit testing in particular) as well. This is how interchanging external services without major changes in the core business logic is possible.
Security Implementations within Hexagonal Architecture
Hexagonal architecture facilitates enhanced security measures:
First of all, it offers isolated security operations: for example, authentication and authorization are managed by dedicated security adapters, which helps to isolate these critical operations from the main business logic.
Secondly, this architecture ensures that data flows are secure and comply with regulatory standards by using adapters that encapsulate the logic for data exchange, minimizing risks of data leaks.
Scalability and Adaptation
The modular nature of hexagonal architecture allows Joynd to easily adapt to new requirements and scale up operations without significant rewrites of the core logic. As Joynd integrates more HR software tools, we’ve developed new adapters that plug into the existing architecture without impacting other system components. Also, to address scalability, we implemented adapters that manage different loads or by distributing requests across multiple instances of the same adapter.
Error Handling Strategies
We’ve ensured more effective error handling thanks to the decoupled nature of system components.
The first is resilience: we’ve designed adapters to handle failures in external systems gracefully, ensuring that the core application remains unaffected.
Error logging and recovery capabilities come next. We’ve made it so specific adapters are responsible for error logging and recovery processes, helping maintain the system’s reliability and integrity.
Performance Optimization
Dealing with multiple external interfaces requires fortified and optimized performance. For this, we implemented two approaches:
First is asynchronous communication. Using asynchronous adapters improves system responsiveness and reduces dependency on external services’ performance.
Second is caching mechanisms. We implemented caching strategies in data access adapters to reduce latency and load on the core system.
