1 | # Basic Platform Features
|
2 |
|
3 | This document outlines the basic features of the Bedrock software platform.
|
4 | Generally speaking, Bedrock is an application framework that allows
|
5 | Web technology-based products to be built on top of it. The framework removes
|
6 | the need to build and maintain common application subsystems that deal
|
7 | with things like logging, application auto-scaling, database access,
|
8 | online attack mitigation, system modularity, login security, role-based
|
9 | access control, internationalization, and production-mode optimization.
|
10 |
|
11 | ## Core Subsystems
|
12 |
|
13 | The core subsystems are foundational to the Bedrock framework and provide
|
14 | the foundation on which other subsystems are built.
|
15 |
|
16 | ### Config System
|
17 |
|
18 | A flexible configuration system that provides a robust web server
|
19 | framework. The config system is customizable so that core
|
20 | configuration rules have good defaults, but can be overridden. The
|
21 | system is also extensible so that new config values can be added easily to
|
22 | any subsystem. All config parameters are overwritable, so that projects that
|
23 | use the framework can overwrite the defaults. The config system is also
|
24 | multifile so that subsystems can contain their own logical
|
25 | configuration without having to scan through a large configuration file.
|
26 |
|
27 | ### Modular Extension Mechanism
|
28 |
|
29 | There is a modular design for extending core functionality and web
|
30 | services. Extending the core framework is as easy as overloading a
|
31 | method. Adding functionality on top of the framework is as easy as
|
32 | adding a module to a configuration file and re-starting the system.
|
33 |
|
34 | ### CPU Autoscaling and Restart
|
35 |
|
36 | The web server framework is capable of automatically scaling up to
|
37 | the number of CPUs available on the system. The cluster module in node.js
|
38 | is utilized to provide this scaling. Worker processes have the capability
|
39 | of being auto-restarted in the event that a worker crashes to ensure that
|
40 | the system can recover from fatal errors.
|
41 |
|
42 | ### Distributed Event API
|
43 |
|
44 | There is a modularized event API and subsystem that allows the
|
45 | system to publish and subscribe to events across multiple CPU
|
46 | cores/processes.
|
47 |
|
48 | ### Logging Subsystem
|
49 |
|
50 | A logging subsystem is available that is capable of category-based
|
51 | logging (info, log, debug, mail, etc.). The log files follow typical log
|
52 | rotation behavior, archiving older logs. There is also the ability to
|
53 | have a shared log file w/clustered systems and support for multi-file logging.
|
54 |
|
55 | ## Persistent Storage Subsystems
|
56 |
|
57 | The persistent storage subsystems are used to store system state between
|
58 | system restarts.
|
59 |
|
60 | ### MongoDB database abstraction layer
|
61 |
|
62 | The system has a simple database abstraction layer for reading and writing
|
63 | to MongoDB.
|
64 |
|
65 | ### Redis database abstraction layer
|
66 |
|
67 | Included is the ability to connect to Redis for simple reading and writing
|
68 | of values to a fast in-memory database.
|
69 |
|
70 | ### Distributed GUID generator
|
71 |
|
72 | The ability to create guaranteed unique global IDs (GIDs) is useful when
|
73 | deploying the web server framework on multiple machines in a cluster
|
74 | setting. This allows systems to generate unique IDs without having to
|
75 | coordinate through a central communication mechanism.
|
76 |
|
77 | ## Communication Subsystems
|
78 |
|
79 | The communication subsystems are used to send communication external to the
|
80 | system.
|
81 |
|
82 | ### Email Subsystem
|
83 |
|
84 | The email subsystem is capable of sending emails via typical SMTP. The
|
85 | emails are template driven in order to support easy customization of
|
86 | email content. The sending of emails is event driven to ensure
|
87 | proper non-blocking operation in node.js.
|
88 |
|
89 | ## Security
|
90 |
|
91 | The security subsystems protect the application against attack or
|
92 | developer negligence.
|
93 |
|
94 | ### User/Password Authentication
|
95 |
|
96 | A simple, pluggable user authentication system is available. A good
|
97 | password-based authentication mechanism is built in. All passwords
|
98 | are salted and hashed using bcrypt password hashing and
|
99 | verification. Logins is session-backed with session state stored in
|
100 | a persistent database (like MongoDB), or in memory if a database subsystem
|
101 | is not available.
|
102 |
|
103 | ### Role-based Permission System
|
104 |
|
105 | An extensible permission and roles system for managing access to resources
|
106 | is available so that there can be a clear delineation between
|
107 | administrator roles, management roles, and regular roles. Each role
|
108 | definition should only be able to access resources associated with that
|
109 | role.
|
110 |
|
111 | ### JSON Schema-based validation
|
112 |
|
113 | Incoming data can be validated before being passed off to subsystems.
|
114 | This protects against garbage/fuzzing attacks on REST API endpoints.
|
115 | JSON Schema is a particularly useful strategy when attempting
|
116 | to prevent bad data injection and basic parameter checking.
|
117 |
|
118 | ### Public Key Service
|
119 |
|
120 | A public key service is provided that allows the storage and publishing of
|
121 | public key data. This service enables a distributed public key infrastructure
|
122 | for the system, enabling remote websites and programs to receive messages
|
123 | created by the system and then verify the validity of the messages by
|
124 | checking the digital signature on the message. Verifying agents must
|
125 | access the public key service to fetch the key information needed for the
|
126 | verification step.
|
127 |
|
128 | ### HTTP Signature Authentication
|
129 |
|
130 | Strong protection of REST API resources is possible using
|
131 | asymmetric keys (digital signatures). This is in addition to something
|
132 | like an API key used over HTTPS. There is support code for creating
|
133 | and storing x509 public/private key pairs.
|
134 |
|
135 | ### DoS and DDoS Protection
|
136 |
|
137 | There is a simple rate limiter for protecting against Denial of
|
138 | Service and Distributed Denial of Service attacks.
|
139 |
|
140 | ### Secure Messaging support
|
141 |
|
142 | The ability to digitally sign and encrypt JSON data and publish it in a
|
143 | way that can be easily verified via the Web or intranet.
|
144 |
|
145 | ## Linked Data
|
146 |
|
147 | Linked Data is a way to create a network of machine interpretable data
|
148 | across different documents and Web sites. It allows an application to start
|
149 | at one piece of Linked Data, and follow embedded links to other pieces
|
150 | of Linked Data that are hosted on different sites across the Web. The
|
151 | Linked Data formats used by the system include JSON-LD and RDFa.
|
152 |
|
153 | ### Linked Identity Data
|
154 |
|
155 | A Linked Data identity system is provided to assign URL identifiers to
|
156 | the people and organizations that use the system. The public portion of
|
157 | the identities, such as names, and publicly available cryptographic public
|
158 | key data, is published in a machine-readable way. Access to the identity
|
159 | information is based on a role-based access control system that also allows
|
160 | private data to be read by authorized agents.
|
161 |
|
162 | A single identity in the system may be associated with multiple other
|
163 | identities for separate purposes, such as a personal identity and a business
|
164 | identity.
|
165 |
|
166 | ### RDFa and JSON-LD Support
|
167 |
|
168 | Parsers to read in and convert both RDFa and JSON-LD to native data formats
|
169 | and modify, translate, and process the information are included. Converters
|
170 | are included to translate from RDFa to JSON-LD and vice-versa.
|
171 |
|
172 | ### Digital Signatures for Linked Data
|
173 |
|
174 | Subsystems are provided that implement the Secure Messaging specification
|
175 | enabling JSON-LD to be normalized, hashed, and digitally signed. The subsystem
|
176 | also enables the verification of any RDF data that has been digitally signed.
|
177 |
|
178 | ## Customer Experience Subsystems
|
179 |
|
180 | The customer experience subsystems are designed to ensure that the customers
|
181 | that use the system have a pleasant experience. This involves ensuring that
|
182 | the interface is elegant, responsive, and works across a variety of mobile,
|
183 | tablet, and desktop devices.
|
184 |
|
185 | ### Extensible HTML5/CSS3 Templating System
|
186 |
|
187 | A front-end HTML5 templating system is provided that supports
|
188 | dynamic views and compiled view caching. The static or dynamic pages of a
|
189 | site is able to be overridden, allowing for the core web server
|
190 | framework to provide basic pages while the product pages override certain
|
191 | aspects of the basic page. This is useful for DRY-based design in template
|
192 | code, allowing pages to be layered on a case-by-case basis. Rich support
|
193 | for scalable icons should also be included.
|
194 |
|
195 | ### Internationalization Support
|
196 |
|
197 | Preliminary internationalization support is included such that particular
|
198 | parts of an interface could be translated to other languages.
|
199 |
|
200 | ### Minimization of HTML/CSS/JavaScript in Production Mode
|
201 |
|
202 | Many Web applications (HTML + CSS + JavaScript + Fonts) can grow to be a
|
203 | megabyte or more in size per page hit. Bedrock contains a good
|
204 | minification subsystem which provides good debugging support in development
|
205 | mode and optimized HTML+CSS+Javascript in production mode.
|
206 |
|
207 | A RequireJS-based frontend with auto-dependency determination is also
|
208 | provided. The RequireJS-optimizer concatenates and minifies
|
209 | all Javascript for optimized production sites. AngularJS and Bootstrap-based
|
210 | frontend with stackable modals and customizable popovers are also
|
211 | provided. An AngularJS-template compiler w/ Javascript and HTML minification
|
212 | for single connection load for production sites is available. Grunt-based CSS
|
213 | concatenation and optimization for production sites makes it easy to
|
214 | deploy production sites w/ no manual build process necessary.
|
215 |
|
216 | ### AngularJS UI Widgets
|
217 |
|
218 | Basic Angular UI widgets are available: stackable modals, popovers,
|
219 | navbar hovercard, duplicate ID checker, generic modal alert, common
|
220 | alert display, tabs, bootstrap-styled form inputs, and help toggle.
|
221 |
|
222 | A lazy-compilation widget is also available; it can drastically
|
223 | improve initial page and widget-readiness for complex UIs by
|
224 | delaying AngularJS-compilation until it's needed.
|
225 |
|
226 | ## Developer Tooling
|
227 |
|
228 | The developer tooling allows software engineers to easily build new
|
229 | applications on top of the framework, debug the system when problems arise,
|
230 | generate good testing code coverage for the system, and ensure that bug
|
231 | regressions are caught before deploying the software to production.
|
232 |
|
233 | ### Testing and Continuous Integration Subsystem
|
234 |
|
235 | A modular testing subsystem that is capable of running both backend unit
|
236 | tests and browser-based frontend tests. The tests are designed to be run
|
237 | inside continuous integration frameworks to provide constant feedback on
|
238 | code coverage and test status as new changes are made to the software built
|
239 | using Bedrock.
|
240 |
|
241 | ### Chained Exception/Error Reporting
|
242 |
|
243 | An exception reporting system is useful when errors happen in the depths
|
244 | of a module and you want them to bubble up to the REST API. The error
|
245 | system supports chained exception reporting to aid tracing/debugging
|
246 | the system in development mode. In production mode, the detailed errors are
|
247 | not shown because sensitive data about the system may be surfaced.
|
248 |
|
249 | ### NPM Integration
|
250 |
|
251 | The web application framework is contained in a typical npm package
|
252 | that can be installed as a dependency. The framework is able to be
|
253 | extended by the project using it via an extensible configuration system
|
254 | and a layered front-end design.
|
255 |
|