Backend-for-Frontend with Solid

Many examples of Solid applications you might find on the open web are wholly client-side browser applications, which interact directly with the user’s Pod and identity provider. This makes things simple and easy for developers who just want to try things out, but this pattern does not support many of the use cases being considered by large organizations.

Backend-for-frontend (BFF) is a well-used pattern that puts in a server-side ‘middle’ layer to support a user-facing browser or mobile application, which in turn accesses the APIs and data stores the application needs to make it work. 

At Inrupt, we frequently see the need for this pattern in large enterprises, especially those with existing infrastructure that are creating a managed ecosystem of applications and Pods. This pattern helps these organizations deploy Solid in a way that better fits their existing technology governance and security policies, and it allows for simpler integrations.

There are many reasons an organization would want to opt for this pattern. 

• Adding Solid capability to existing applications: An organization might want to add Solid capabilities to existing applications. Sometimes this needs to be a more gradual process, bringing in capabilities slowly to ensure there is no degradation in service or user experience. Many of the applications we see already have backend components, and so adding Solid capabilities to these backend components allows the frontend user interfaces to remain unchanged while Solid is integrated. ‍
• Universal reach & accessibility: Some operators, such as governments, need to cater for an extremely wide array of devices, both new and very old, to ensure they meet their commitment to provide services to all citizens. Having heavyweight client applications, either web or native, that only run on the most modern devices will not suffice, so using BFF allows these operators to use Solid to improve the experience for their users whilst retaining universal reach. ‍
• Security: Solid relies on non-opaque tightly scoped access tokens, as well as an extremely strong preference for modern security measures such as DPoP and PKCE. There may be existing systems outside of the Solid infrastructure that rely on these tokens that cannot support DPoP, PKCE, or other newer security measures. As such, they need to ensure that access and identity tokens do not leave the servers of the organization where they may be susceptible to interception. There may also be custom claims inside access tokens used by existing systems that contain sensitive information that is not suitable for release to the client. ‍
• Access to supporting services: The application may need to access other supporting services that are not open to the internet. Using BFF allows existing apps to use Solid capabilities with minimal impact to existing dependencies.
• ‍Performance: If an application needs to do a lot of analysis of the data stored on the Pod, or make many simultaneous parallel requests, either within the same infrastructure or elsewhere, a fast server-side connection may be preferred. Not all devices have a fast broadband or 5G mobile connection, or the capacity to do complex computation required for some operations.
• ‍Data integrity & filtering: Many applications may want to verify information that is being put into the Pod, or the requests being made to the Pod to ensure data integrity. There are also instances where service providers must be sure, by law, that there is no illegal or inappropriate content being stored in the Pods they provide to their users. In this case, the BFF pattern could mediate and check all content before being stored in the Pod.

This common pattern may raise questions about its compatibility with the philosophy of Solid, especially in the area of Pod-client mediation, but it is absolutely compatible. In fact, in future, we may see far more server-to-Pod interactions than we do browser-to-Pod.

The demands of large enterprises can be more readily satisfied by employing the BFF pattern, because it preserves the necessary controls and integrations with existing systems, and separates governance, security and audit concerns from the user interfaces that use the data.

There is also nothing about this pattern that means the application and the Pod have to be running in the same infrastructure, or even the same organization. As we have seen, deployment of these sorts of patterns can increase trust between members of the ecosystem by assuring data-integrity and security according to familiar best practices, which in turn allows ecosystem governance to be applied in a more effective way.

We also see the need more generally for server-side agents to have access to Pods to perform calculations on the users behalf, including in the emerging realm of machine learning for personal AI assistants. It is not expected (nor most times even feasible) to execute massive computations in resource-constrained environments like a web browser. In such cases, processes that run algorithms on data from Pods, potentially many Pods, are better done in the backend, reserving the frontend for data visualization and decision making.

Solid is about the decoupling of applications from data and identity providers via interoperable standards, and fine-grained access control to decide who can see what data. By using patterns such as BFF, organizations can use Solid alongside their existing governance structures and infrastructure, and get Solid-based applications into production faster with the security and performance assurances they need to satisfy their Data Protection Officers (DPOs) and Product teams.