Options for sharing frontend workflows across disparate applications

Question

I am working on a form building feature that will be used across different applications within our organization. Since each app has a slightly different stack we are planning to implement this feature as its own service. It will be hosted separately from our other applications with its own isolated database. I am pretty locked in on how I am going to design the backend and how the data will be shared from the service to the consuming applications. However, one part of my design I'm a little shaky about is how to share the frontend for the form builder across each application. I.e. what is the best way to expose the form building feature to other applications to integrate with.

1. Create a reusable and extensible React component combined with relevant Typescript APIs and helpers and release that as a private NPM package which each app can consume and extend as they need
   • Not every application uses a React frontend so sharing this component would not be trivial
2. Create a centralized form builder frontend that is built directly on top of the service and redirect as needed from the consuming applications to this app.
   • I am not sure if this is a good practice or idea or not. This doesn't seem the most straightforward to implement. Is this a bad idea or generally frowned upon practice?
3. I have looked a bit into Micro Frontends and it seems like it could be a workable solution here
   • I am not familiar enough to know how big of a lift that would be for consuming applications to support. I also don't know what the extensibility looks like here or if tethering a workflow onto an application is a good use case for Micro Frontends.
4. Just create APIs that other apps can build their own workflows on top of
   • Based on some of the complicated features we want to support with our form builder I don't think this is a really great idea and will not be the best experience for other teams to integrate with

I am new to posting here so if I'm not asking a great question or providing enough details for my question to be answered let me know.

Answer 1

From what you shared about the rest of your application's architecture, I think the first option may be the best approach, but I will try to list the pros and cons of each option you are considering.

1. Creating a reusable and extensible React component and releasing it as a private NPM package:

• Advantages:

  • Allows for maximum flexibility and reusability as each application can consume and extend the form building feature as needed.

  • Makes it easy to update and maintain the component across all applications.

  • The codebase can be shared and reused by multiple applications, reducing the overall development effort.

• Disadvantages:

  • It may require more effort to set up and configure the NPM package for each application.

  • It may be difficult to ensure consistency and compatibility across all applications that are consuming the package.

2. Creating a centralized form builder frontend that is built directly on top of the service and redirecting as needed:

• Advantages:

  • Provides a central location for all form building functionality, making it easy to maintain and update.

  • May be easier to set up and configure than the first option.

• Disadvantages:

  • It may not be as flexible as the first option, as it may limit the ability of each application to customize and extend the form building feature as needed.

  • It may make it more difficult to update and maintain the form building feature across all applications.

  • It may also require a more complex redirect logic

3. Following the Micro Frontends pattern:

• Advantages:

  • By dividing your frontend into smaller, more manageable parts you may increase the scalability and maintainability of the application.

• Disadvantages:

  • It may require more complex routing and communication between the different micro frontends.

4. Creating APIs that other apps can build their own workflows on top of:

• Advantages:

  • Allows for maximum flexibility and reusability as each application can consume and build their own workflows on top of the APIs.

  • The codebase can be shared and reused by multiple applications, reducing the overall development effort.

• Disadvantages:

  • It may require more effort to develop, document and maintain the APIs.

  • It may also require more effort to ensure consistency and compatibility across all applications that are consuming the API.