Feedback mechanism as an independent application:

 Requirements for feedback collection system as a stored application: 

Problem statement: Feedback is not the onus of component owners. It is a utility that spans components and features.  While they may choose to collect feedback at specific scopes, a utility can bring drag and drop ease of use while permitting those features to view the reports only later. How do we write an application for feedback collection? 

Solution: Since the feedback system does not take away any of the functionality of the underlying system and merely adds an option to the user, it can be packaged as an application that gives this option to the user. If it is part of the toolbar or available as a floating action button, it will be tiny as well as ubiquitous. All components expect a like or a quantitative rating or a qualitative input or a file attachment as convenient forms of user feedback. The scoped application merely collects them in a table that is unobtrusive to others in terms of functionality, performance, and security. Let us take a closer look at this feedback design system from the collection point of view. 

When the feedback collection is consistent across all components, it tends to have a schema. This data can be collected in a table and the size of the table can grow arbitrarily. Creating instances of the table scoped to the component, feature, or product for which the feedback is provided allows the number of such feedback tables to be finite and each allowed to grow as much as their usages. But when it is part of a scoped application, the size can grow considerably.  

The table itself must be generic to hold the most frequent forms of input. Extensions can allow customizations to be stored. The source information such as a Uniform Resource Locator of the page on which the control was displayed along with the query parameters become useful to track. A binary outcome might be sufficient for machine learning-based analysis later. 

The data from the transactional database can be rolled from the database to a data warehouse for periodic rollover of transactional tables. The feedback service would be rolling up the feedback and inserting it as a new record while deleting the archived ones. The historical information on the feedback is also useful for analytics which can independently be implemented with read-only reporting stacks.  This calls for a warehouse that can support a variety of reporting stacks. Archival of transactional records to keep the size limitation for the online transactional feedback system is sufficient even if the warehouse does not exist. The warehouse merely helps with the reporting stack to be read-only and independent from the online transactional tables. 

The front-end can be a JavaScript floating action button or a toolbar button. It can be written with Vue as JavaScript reactive framework. It could adopt the same theme as the overall theme of the application where the control is displayed.  

Conclusion: Separating the functionality of a feedback loop into an application and deploying it with other components and features of a web application is possible and beneficial to their focus.