The application development toolchain is full of tools for all stages of the development cycle. Tools for pre-development including project planning, architecture artifact definition, design, and more. Likewise, tools for in-flight development including IDES, source repositories, testing platforms, CI/CD, and so on. What has been missing is an effective means of bridging the development gap between preparing and execution. Using scrum terminology, typically Sprint Zero has been defined as this gap, usually designated as a time for team preparation, resource allocation, and general Sprint 1 preparation.
The goFramework takes a better approach. Sprint Zero is the perfect opportunity to kick-start the application development process, leading into Sprint 1 with hundreds to thousands of lines of code that are fundamentally needed, but most do not want to develop. This allows more time to be focused on the design, implementation, and testing of the critical business services that truly are differentiating.
If you have not yet installed the application using the realMethods goFramework Machine Image found on AWS, please Click here visit the AWS Marketplace.
Contact firstname.lastname@example.org with a request for pull access to the latest Docker image of the platform.
The wizard provides a self-guided tour through the required steps to select a Templatized Tech Stack Package (TTSP), load a model, modify application options, and finally create the application.
Clicking the chevron in the upper left-hand corner will reveal the control panel to view the options available to generating an application.
For the sake of this discussion, we will briefly state that a technology stack is an ideal whereby a software application leverages a well defined and understood set of distinct technologies. In practice, experience often shows the technologies in the stack are well known, most trusted, serve a well defined purpose, and co-exist well with others in the stack. Often a tech stack is an abstract concept, only effectively defined because an application “uses” each of the technologies. However, often a technology stack is “bundled” as a single deliverable whereby the bundle handles the stacking, integration, and delivery of the technologies in the stack.
The realMethods concept of a Templatized Technology Stack Package (TTSP) improves on the tech stack concept, picking up where it leaves off. A TTSP not only includes all the concepts of a bundled tech stack, but includes the template-driven abstractions, features, components, and services of a specific kind of application. Template-driven is crucial to a TTSP because it is the tie between a tech stack and an entity model. Importantly, a TTSP accommodates the endless combination of technologies and application features with even a single business model.
Based on the target requirements of the resulting application, choose which TTSP best meets those requirements. The list shown in this document is likely not up to date. If you do not see a TTSP in the realMethods goFramework run-time that adequately meet the application requirements, contact email@example.com.
If a suitable TTSP is not available, determine which of the available TTSPs is closest to the required application stack, download that TTSP, make modifications as required, then upload the new TTSP as a single Zip file. The following components of a TTSP should be understood.
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 TTSP’s components.
Click here to review the contents of a frameworkpackge.xml file
This required XML file contains the global options for each application created regardless which TTSP is
It contains general level options specific to any application such as the app name, author, app logo URL, GitHub parameters, etc.. This is the place to add an option to be applied to all applications being created. Adding options is encouraged, but be aware that removing options may impact how the application is created and how it behaves at run-time. The TTSPs the realMethods goFramework includes often have more than one options.xml file found in a multiple sub-directory containing template files related to a specific framework or toolkit. For example, template files related to the Hibernate ORM framework require configuration input from the user, and these configuration parameters would be placed in the options.xml file also found in the sub-directory of the template files.
The support options types and the corresponding form field are as follows:
type=”input”, form field : “text”
type=”word”, form field : “password”
type=”select”, form field : “selection”, selections correlated to form field : “options”
type=”boolean”, form field : “checkbox”
Each option field can include the following fields:
modifiable : “true/false”
required : “true/false”
description : placeholder
Click here to review the contents of a options.xml file
This required file contains the declarations as to where to output a created file. This provides the flexibility needed to separate where a template file is found as opposed to where its created output should be placed for the sake of coding convention, the build process, application deployment, etc…
Click here to review the contents of a mappings.properties file
If starting with a new idea without an existing application, this is the place to start. The goFramework supports loading a model definition from an appropriately structured JSON file, or an XMI file containing standard UML.
The goFramework installs with examples of supported models accessible from the Catalog option. Optionally, a newly loaded model can be saved to the Catalog for future reference.
Once a model is loaded, observe how t interpreted it. It is important to browse the tree control representation to ensure the intended model has been captured. The goFrameworksupports the models composed of containers, classes, attributes (long, double, string, date, time, etc..), associations (one-to-one, one-to-many, many-to-one, many-to-many), interfaces, and enumerated types.
The goFramework can deduce an existing application model from a JAR file of POJOs, a SQl script, or direct connect to a database’s schema. This feature means fundamental application migration can begin without having complete knowledge of the originating application. This includes migration cases that cover refactor, rewrite, and replatform. This means an existing app written in an older language on an obsolete platform can quickly have its core recreated using a more prevalent language using today’s popular technology stacks. This includes creating layers for the presentation, business, data, caching, and persistence.
A TTSP can provide any number of options that are dynamically loaded when selected in the list of TTSPs. If you are unfamiliar with a TTSP, select each tab to see what fields need data applied. If the goFramework will be directed to push the application files to GitHub, select the tab and apply the required fields including:
host (where is GitHub hosted)
repository (where on GitHub is the project to be pushed to)
username and password (to access the GitHub host securely)
tag (how to distinguish this project push)
Each time code is generated, all the generated files, along with the TTSP and model used, are archived. An archive can be downloaded as a single zip file by clicking the down arrow next to the listing.
Once a Technology Stack Package has been selected, an entity model has been provided, and application options have been reviewed, and application can now be created. Pay attention to the GitHub options if a push of the source code is required.
Once the application is created, revisit the TTSP page to learn more about the app, how to build it, deploy it, etc..
Click here to review the Restful API documentation
By default, your app files will be located on GitHub assuming you have provided the correct GitHub details. The selected TTSP will display instructions to explain what Maven instructions to use to build the application. Of course, you can edit the Maven POM file(s) to accommodate any build process.
Whether using the option to push to GitHub or not, all the generated app files are on the machine under a timestamped directory. The details below will help you locate the files.
If you are using an AMI on AWS, you will have to ssh onto the remote machine. AWS has instructions on how to access a remote machine as an ec2-user. Learn more here…
The AMI itself not only contains the the goFramework platform, but it also contains Docker. The goFramework, along with its dependencies (Java, Maven, MySQL, et al ), are packaged in a Docker container that is automatically run upon machine boot up.
In order to access the running Docker image, and access a shell running goFramework, issue the following commands
docker ps – locate realmethods/goframework:latest and note the Container ID
docker exec -it /bin/bash – use the CONTAINER ID listed during docker ps
This will create a /bin/bash shell that will land in the root the goFramework directory.
Next, change to the following directory:
Once here, note the following sub-directories:
app.creation.output – contains sub-directories named with the app creation timestamp, that
contain all the files for each application created
tech.stack.packages – installed technology stack templates
archive – zip archive for each application creation session
Within each sub-directory of a created application, there is a Maven POM file. A selected technology stack package within the goFramework displays how to run the Maven POM. For instance, within the AWS Lambda RDS tech stack package, issue the following Maven directives:
mvn package – builds all required packagings, pushes sources to GitHub (if selected),
creates Swagger file
mvn lambda:deploy-lambda – to deploy the packaged AWS Lambda functions to a related AWS S3 bucket
For the AWS Lambda teck stack package, locate the Swagger file under the \generated\swagger-ui directory. Use this file if using an AWS API Gateway to define a set of secure APIs to the generated Lambda Functions.
Yes and no. While ingesting a model, the goFramework will acknowledge the existing of each element of a primary key and will create a related class to encapsulate the use of multiple keys. However, existing tech stack packages only leverage the first of the discovered keys. It is suggested to coerce any model with entities declared with more than single keys to have just a single key.
Yes. The code and files generated are expected to build as is, so it is safe to include into any traditional CI/CD process.
Always. ReactJS, BackboneJS, Ruby, and Python tech stacks are on our radar. If you are interested in creating a TTSP and receiving a free enterprise license, contact us
Absolutely. You can modify any file within a package, along with including new files. Pay attention that any new files may need to be added to the mapping.properties of the package.
Yes. Your package will be validated and tested as any of the existing packages. If it passes validation and testing, you will be notified of its inclusion within our next release and receive a free enterprise license. Shortly, the goFramework will have a TTSP Community area where such packages will be validated, tested, and made publicly available.
Yes it is. Contact firstname.lastname@example.org with a request for pull access to the latest Docker image of the platform.
Each TTSP contains an overview.html file, which is displayed when the tech stack package is selected in goFramework. The content of the file contains the build/packaging instructions using Maven. Each package will have different build/package instructions so it is important to pay close attention to follow the package’s instructions. These build/package commands can be included in a CI/CD process