Resource Abstraction Concept
by andypotanin
JavaScript
/**
* Basic Concept of Module Abstraction
*
*/
// This is how the default AWS SDK works.
var AWS = new require( 'aws-sdk' );
var simpleworkflow = new AWS.SimpleWorkflow();
// I don't like they naming conventions.
simpleworkflow.describeActivityType({
"activityType": {
"name": "Test",
"version": "1.0" // I don't like that numbers must be strings for some reason
},
"domain": Veneer.cluster.name // I also don't like to ahve to declare by domain every time
}, function( error, data ) {
// Using callbacks in such a way is fairly standard - but becomes a big pain when used extensively, and becomes very messy when methods are nested.
// I also dislike catching errors in such a way
if( error && error instanceof Error ) {
/// Usually should have logic here to examine the error which gets very bulky
console.error( error );
}
// finally at this point we have the data we wanted and can start adding our business logic.
});
// Below is a rough example of what I envision as "Resource Abstraction".
// This essentially a JSON configuration that configures object structure that fits my needs and maps to other modules, and HTTP APIs, to aggregate the data. The abstraction also tries to solve some of the common issues related to callbacks, parameters, etc.
// The Abstract module returns the result to some object I specify
var Activity = new Abstraction({
// At the root level the configuration object declares properties that should be returned.
"describe": {
// For the "describe" property we want to integrate a call to the SWF.describeActivityType function seen above. We define it like so:
"call": SWF.describeActivityType,
// Any special settings may be set up like so to keep the root level relatively clean and standard.
// In this example the "no_errors" would supress any thrown errors
"settings": {
"no_errors": true,
"enumerable": true
}
// Here we...