Nothing Goes From Idea To Container Faster

Introduction to realMethods' Technology Stack Packaging

realMethods improves on the concept of a technology stack with we call a Technology Stack Package (Package). A Package not only includes all the concepts of a bundled technology stack, it also includes the template-driven abstractions, features, components, and services of a specific kind of application. Being template-driven is crucial to a package since it is the active tier between a technology stack and an entity model. Importantly, a package can accommodate an endless combination of technologies and application features that are the possible result of even a single entity model.

The Components of a Package

A package is a single compressed ZIP file containing both standard, required, and optional files. The optional files are usually the template version of the files targeted for the resulting application. The following standard files are required.

 

techstackpackage.xml

This required XML file contains the overall description of the package itself. It is most useful for
the sake of providing documentation as to what the package contains and the general intent of the

The following is taken from the AWS Lambda RDS package:

 

 

options.xml

This file contains the options used to make decisions that impact application generation, having implications on how an application is generated and likely how it is built, deployed and executed. It can contain general options specific such as the app name, author, app logo URL. It can also contain options related to such thing as AWS, Heroku, and other target platforms.

Each technology stack package has its set of options contained in multiple options.xml files.

These options are all modifiable, and often contain a default value per the author of the package.

The CLI and API client versions allow you to manage options as a single JSON structure. The browser-based client presents the options as a series of forms and form controls for simple
modification.

 

mappings.properties

This required file contains the declarations as to where to output a generated file. During code generation,
it provides the flexibility needed to separate where a template file is discovered versus where its generated output should be placed for the sake of coding convention, the build process, application deployment, etc.

The following are sample entries taken from the AWS Lambda RDS package mappings.properties file:

Entry Rules

The format of an entry in the mappings.properties file provides details on how the app generator should process and output the results.

Using the previous sample entries, here are an example of supported formats:

Procfile=Indicates to the app generator to process a file named Procfile and output it to the
root of the output directory.
pom*=Indicates to the app generator to process any file with a prefix of pom
and output it to the root of the output directory.
*xml=.src.main.resourcesIndicates to the app generator to process any file with a suffix of xml and output a sub-directory
/src/main/resources under the root output directory.
*__classes__.java=.src.main.java.$packageName.boIndicates to the app generator to process any file with a suffix of xml and output a sub-directory
/src/main/resources under the root output directory. The $packageName is directive to use the package name option value,
with . notation interpreted as a sub-directory. For example, a package named com.company would result in output of com/company/.
exclusions=bootstrap-*.js,bootstrap-*.cssThe word exclusions is reserved to indicate which files to exclude in the template processing. If listed as a file to handle,
the file will be moved according to the rules above, but will be ignored as a template file.

A template file is extremely generic, and can represent anything but has real purpose towards the overall intent of the package and the application it results in.

As of v1.1, realMethods ingests package template files and processes them using the Apache Velocity Template Engine.



A Velocity template file uses very easy familiar syntax. During generation time, realMethods makes available a standardized internal
version of your entire entity model along with a few helper classes, giving you complete programmatic flexibility and control
over what gets generated.

Key Generation Objects

Let us use a few excerpts from a template file within the AWS Lambda RDS package

Here is the breakdown of the example:

#header()

Calls a realMethods provided Velocity macro to output a standard file header (license/usage info, etc..)

#set( $className = $classObject.getName() )

The application generator makes available to the Velocity content the current
ClassObject ($classObject) being processed from the model. This statement is assigning the name of the current ClassObject
to a local Velocity variable called $className

package ${aib.getRootPackageName(true)}.#getDelegatePackageName();

The application generator makes available to the Velocity content an object name aib. This object gives access to
your entire model refactored into a well formed generation time model. This object contains a great number of helper
methods to better parse and query the model itself. This object also gives access to the entire set of application options
which were outlined above in explaining the usage of the options.xml file(s).

#foreach(
$assoc in $classObject.getSingleAssociations())

This is a Velocity looping directive over the current ClassObject’s set of single (one-to-one) associations.

Overview

As of realMethods version 1.1, the following packages are available to generate an application or download to customize.

Angular 7 -Material Design - MongoDB - Mongoose​

Choose this stack for full support from mobile and web app presentation to NoSQL storage using MongoDB and Mongoose schema mapping.​

Django - Python - Supported database options​

Generates all views, models, delegates, URL routings, and necessary project/configuration files for a fully functional application running on the Django Python web framework. Developed and tested on Django version 2.1.x using Python version 3.7.x.​

Google Functions - Hibernate - Spark MicroWeb​

Generates a fully functional layer of fine grained server-less Google functions for each discrete foundational service required of an application. Uses Hibernate to store to any RDBMS. Creates a RESTful API using the Spark Web Framework to eliminate known performance issues when a server-less function accesses an RDMBS.

Spark Microweb - jQuery - Hibernate​

Spark Java Micro Web Framework to faciltate the view/controller of an MVC framework, Fully functional front-end using Javascript, HTML5, JQuery, CSS, and Bootstrap, Hibernate for ORM​

AWS Lambda - MongoDB - Hibernate - Spark Microweb​

Generates an entire eco-system of fine grained server-less AWS Lambda functions for each discrete foundational service required of an application. ​

ASP.NET 2.0 - nHibernate - jQuery - cshtml​

Spark Java Micro Web Framework to faciltate the view/controller of an MVC framework, Fully functional front-end using Javascript, HTML5, JQuery, CSS, and Bootstrap, Hibernate for ORM​

Spring Boot, Hibernate, MongoDB​

Generates a fully capable RESTful API using the Spring framework for RESTless Web services, Spring-Boot for app deployment and container, and Hibernate for persistence to all populate databases.​

Apollo GraphQL, SQLite, Sequalize

Quickly stand up an Apollo Server with a fully functional query and mutation API based on your business model. Easily integrate any client or extend the API to support other means of persistence.

Struts2 - Hibernate - jQuery/Bootstrap​

Struts2 MVC Framework, jQuery/Bootstrap Javascript front end framework, and Hibernate for object-to-relational mapping for persistence to all popular databases.​
Click Here

Progress of Upcoming Stacks

Ruby on Rails
50%
Quarkus
25%
C/C++
15%
Play
10%
Go
10%
Ember.js
5%
Vue.js
5%
React.js
5%
Close Menu