ARCcore.filter automates the validation and normalization of JavaScript function request and response data using specially-formatted JavaScript objects called filter specifications.
The filter library exposes a software factory that "wraps" a developer-defined JavaScript function with automated
data validation, normalization (default values), and error handling logic. The factory returns an object with method
request
that is called just as one would call the now encapsulated developer-defined bodyFunction
.
This topic is discussed in depth in the filter API section.
The following ASCII diagram depicts the flow of control through a filter's request method. This topic is discussed in depth in the filter architecture section.
Filter.request
+----------------------------------------------+
| responseFilterSpec + |
| | |
request -> [iFSP] -> [bodyFunction] -> [rFSP] -> [oFSP] -> response
| | | | |
| | | | |
+--|---------|---------------------------|-----+
run-time | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
factory | | |
| +< bodyFunction |
+< in filter spec out filter spec >+
In the diagram above, the acronym "FSP" stands for Filter Spec Processor which is a generic subsystem
that is responsible for ensuring that the developer-defined bodyFunction
...
request
input (iFSP)response
(rFSP)response
's always contain either a valid error or result (oFSP)Typically filters are used to "bulkhead" critical public and private subsystem API's. For example, HTTP request handlers, database and storage layer I/O, client-side message handlers and routers... where correctness is essential for product security, stability, and both developer and end-user experience. And, where implementing and maintaining the equivalent functionality in hand-written JavaScript product and test code is error prone, time-consuming, and consequently very expensive.
$ node
> const arccore = require('arccore');
undefined
> arccore.filter
{ create: [Function] }
>