Here's the best reason for using Read Write Serve
Extensibility
The Read Write Serve HTTP/2 server has an extensible architecture allowing you to develop chainable JavaScript plugins that work within the request/response cycle.
The modular architecture and plugin design of Read Write Serve HTTP/2 Server is all about extensibility. Making it happen with JavaScript is its raison d'être.
If you're evaluating RWSERVE for your next JavaScript project, here are a few things to help you understand what's possible.
HTTP Methods
Plugins can be directed to handle any combination of HTTP methods. The most typical ones being:
- Handling
GET
requests for database retrievals (multi-records listings and single-record pages). - Handling
POST
requests for typical form submissions, file uploads, and asynchronous Fetch. - Handling
PUT
requests when creating a database record through a REST API. - Handling
PATCH
requests when updating a database record through a REST API. - Handling
DELETE
requests when deleting a database record through a REST API.
Learn more about HTTP methods.
Plugin Tasks
Here are some typical tasks carried out by plugins.
- Honoring request values provided in query-string variables through the work order's
parameterMap
. - Accessing
x-www-form-urlencoded
values via the work order'sformDataMap
. - Accessing
multipart/form-data
to allow users to upload multiple files. - Accessing individual cookie values through the work order's
cookieMap
.
Check out this plugin catalog to learn more about plugin tasks.
Work Order Functions
Here are some of the more important work-order functions used by plugins to process the request/response cycle:
- Implementing the optional
startup
method for initialization. - Accessing plugin-specific variables declared in the configuration file.
- Adding a standard response header using
addStdHeader
. - Setting an empty response body with
setEmptyPayload
. - Setting the response status code with
setStatusCode
. - Implementing the optional
shutdown
method to save state.
Learn more about request/response work orders.
Processing Patterns
Here are some typical processing patterns that plugins follow for integrating their work within the request/response cycle.
- Following the chainable processing pattern by omitting any calls to
setStatusCode
. - Following the response-body processing pattern by calling
setOutgoingPayload
. - Following the empty-body processing pattern by calling
setEmptyPayload
. - Following the static file processing pattern when a resource request matches a file in the public document path.
- Following the terminal processing pattern by setting the status code to a value in the
400
to416
range. - Conditionally following the chainable processing pattern or the terminal processing pattern.
Learn more about plugin processing patterns.