QuestionQ3
Designing APIs for reuse and governanceAn organization has developed a large monolithic application over time and is now seeking to move to a microservices architecture. During this transition, it has created several System APIs as Mule applications that expose access to different functionality within the monolithic application. The System APIs are deployed to Mule runtimes on a customer-hosted EC2 instance in AWS.
The System APIs connect directly to a single database used by the monolithic application. Currently, every project must include a Database connector and its connector configuration. There is a future plan to split this database into several smaller data stores.
What MuleSoft-recommended best practice should be used to share the connector and configuration information across the APIs?
- A Create an API proxy for each System API and share the Database connector configuration with all the API proxies via an automated policy
- B Build another System API that connects to the database, and refactor all the other APIs to make requests through the new System API to access the database
- C Build a Mule domain project, add the Database connector and configuration to it, and reference this one domain project from each System API
- D Build a separate Mule domain project for each API, and configure each of them to use a file on a shared file store to load the configuration information dynamically
Community Discussion