Folio Technical Architecture
Technology has changed a lot since the inception of the eCPIC program in 2003. Standards and techniques that didn’t exist in 2003 are now mainstream best practices today. Knowing that change is constant, how do we ensure that we build the right technical architecture for Folio to support our agencies for years to come? One solution is to combine our years of support experience with the latest industry best practices in application design. The result—an architecture that provides agencies with the flexibility to customize, or integrate with other systems through an application programming interface (API).
Here’s a high-level architecture diagram of the new Folio application. Notice that there are many pieces that can be integrated in various ways. This contrasts with the “monolith” way that applications were built in the past, and allows for vastly improved performance and flexibility as Folio evolves and requirements change.
Here’s how the technical flow will work:
- An agency user logs into the Folio application and opens their investment.
- Folio accesses the API Gateway and calls the appropriate API operation.
- The API operation triggers the data collection microservice to pull investment data from the data store.
- The microservice processes the data and returns it to the API Gateway.
- The API Gateway returns the data to Folio, where it’s presented to the user through the user interface.
In case you’re not familiar with all these terms, here’s a brief explanation:
- API Gateway – This is the front door to the business and data layers. The Folio web application is completely decoupled from the API, meaning that external agency systems or custom applications could also use the API Gateway to access the same microservices and functionality that Folio uses. For example, when a user saves Folio data, they are using the same “Save Data” operation through the API Gateway that an external application would use to perform the same operation. The API Gateway can also integrate directly with the IT Dashboard to improve OMB submission capabilities.
- Microservices – This contains all the data manipulation and business rules. In the example of data collection, the microservice would retrieve Investment data from the database, then process the data the web application needs to display to the user. The main benefit of this approach is that the microservices are only loosely coupled to each other, meaning that they can be updated, maintained, and deployed independently. Since the data collection and submission microservices are separate, our development team can work on the submission microservice without affecting the data collection functions.
- Data Store – This is where your data lives. Folio uses a database technology that is flexible and efficient for processing large volumes of structured and unstructured data. The Folio data store is template driven, meaning that all data is stored in documents. Each document contains all the attributes and data points needed for ingestion by the API, and for determining the functionality, look, and feel that’s displayed to the user in the Folio application.
We hope you enjoyed this technical architecture summary. It’s ok if you still have questions (we’d be surprised if you didn’t). Stay tuned for future articles that describe the technologies we leverage to implement the ideas we introduced in this post. Reach out to us (folio.pmo@gsa.gov) if you’d like to discuss this post in more detail.
