New App Development Application Refactoring Refactor @ Scale Continuous Generation

Built For Today's Important Development Scenarios

Designed from the ground up for the most compelling use cases

We all have some exposure to code generation, but this is different. realMethods is not a code generator. It is an application generation platform with a focus on both new applications AND application refactoring.

We strive to make application generation a seamless experience in your current development process. Choose the right use case that suits your needs to learn how best to leverage realMethods.

Use Cases:

New App Development

No need to start from scratch

You have enough to do and consider with the start of a new application. Leverage application generation as a catalyst to give your project the jump-start it needs. Let realMethods remove the normal burden found in writing core services.

Consider the following steps:

Step 1: create a model

realMethods is a model driven, so you need a model. Your entity entity model should describe your business entities, their attributes (data), and the relationships the entities have with one another.

When creating a new model, consider using a tool that supports XMI or UML. If you use Eclipse as an IDE, it has its own modeling framework (EMF) for easily creating an entity models. You can also create a model using JSON by following our guide for creating a JSON entity model

Step 2: choose a technology stack

When reviewing the available technology stacks, you should consider the following:

  • What software language best aligns with the skill set of my team?
  • What architecture type is most appropriate?
  • Does the application require a user interface?
  • Is either GitHub or Bitbucket used as a repository?

Step 3: apply options

Each realMethods Technology Stack Package (Package) contains a set of options that allow you to tailor certain aspects of the resulting application. Examples are:

  • Application name, logo url, etc...
  • Database connectivity settings
  • Git (source code) settings
  • Heroku settings

Step 4: generate

Regardless of how you are interacting with the realMethods platform (web client, CLI, or API), application generation is a simple process. Steps 1, 2, and 3 were in preparation to provide realMethods with the information to generation the application.

As an example, if using the command line interface (CLI), you would take the following steps.

  • - Publish your model and note the return value which is the id of the model
  • model_publish [yaml_file] [scope]
  • - Review the list of available technology stacks
  • realmethods_cli stack_list public --output pretty
  • - Select a technology stack and download it's options as a JSON file and redirect into a file
  • realmethods_cli stack_options --quiet true [the_stack_id] > app.options.json
  • - Modify the options as needed
  • Be your modifications maintain the integrity of a JSON structure.

  • - Generate the application
  • app_generate [the_stack_id] [your_model_id] [path_to_options_file]

The End Result

If using a Git service, all generated files should be committed to the designated repository. Each technology stack package creates different files so review a package's documentation (or download/extract) to learn more.

As another option, you can also download the generated files as a single archive file by issuing the following command:

app_download [app_id] [output_file_path]

Application Refactoring

Refactor core functionality first

We understand deciding to refactor an application is never taken lightly without first considering other options. Refactoring is complicated, time consuming, and expensive. While others take a process centric approach, realMethods takes a technology centric approach with a focus on first refactoring functionality. It is a huge win to move existing core capabilities to a better open flexible better technology stack running on a superior platform. Not only does this help simplify refactoring the application, it opens the door to repurpose those services for other scenarios.

Consider the following steps:

Step 1: using an existing model

The easiest place to start is at the database. If the application leverages any of the popular relational database systems, follow these instructions to export the database schema into a SQL script file.

If it is not possible to provide a SQL script file, you will have to follow Step #1 from the New Application Development Use Case.

For subsequent steps, follow Steps 2, 3, & 4 from the New Application Development Use Case.

The End Result

Although the results from the New Application Development Use Case apply here, if you decided to refactor the application to one of the technology stack packages that supports server-less functions or a RESTful API, you now have a ready-to-use scalable API layer ready to service the many different aspects of your business.

Refactor @ Scale

Making factory migration a reality

Major system integrators and cloud provider professional services claim they can accomplish factory migration. App rehosting has been solved and is offered by many while application refactoring is left out or deferred.

realMethods was developed to be the catalyst to true application migration, and since it is scalable technology, it can handle refactoring 1, 100s, or 1000s of applications. With the right up-front preparation and co-ordination, realMethods give you control of your migration journey.

Consider the following steps:

Step 1: Identify initial candidates to refactor

Rather than tackle the most complex applications, consider a minimal set of applications to create momentum. Ideally, each will meet these qualifications.

  • - Small user base
  • - No to low business disruption
  • - Current functionality is acceptable as-is
  • - Uses a standard relational database
  • Step 2: choose one or more technology stacks

    For each application to refactor, see Step 2 of the New Application Generation Use Case

    Step 3: apply options

    For each application to refactor, see Step 3 of the New Application Generation Use Case

    Step 4: generate

    This step is different than the other scenarios, but it is what makes realMethods the most unique technology in the migration space.

    The ability to generate multiple applications is available in the CLI and API versions. You can start by editing a sample YAML file found in the the ./samples/yamls/apps.generate.yml. You can provide a generation instruction set for each application to generate.

    The following explains the contents of this YAML file which generates 3 different applications:

    - techStackId:       Django                               # name of the technology stack
      modelId:           1                                    # unique identifier of a registered model
      appOptionsFile:    ./samples/options/django.json        # options to apply to the application
         entry:          bitbucket_tests                      # entry name of the following YAML file
         file:           ./samples/github/demo.git.params.yml # A YAML file containing git
         name:           Customer Care v0.01
         description:    Initial version of a Django based application
    - techStackId:       3                                    # unique identifier of a published tech stack
      modelId:           2
      appOptionsFile:    ./samples/options/aws.lambda.rdbms.options.json
         entry:          app-2-params
         file:           ./samples/github/demo.git.params.yml
         name:           Help Desk Services v0.01
         description:    Initial version of a AWS Lambda server-less layer
    - techStackId:       AWSLambdaRDS
      modelId:           5
      appOptionsFile:    ./samples/options/aws.lambda.nosql.options.json
         entry:          app-3-params
         file:           ./samples/github/demo.git.params.yml
         name:           Portfolio Services v0.01
         description:    Initial version of a AWS Lambda server-less layer using MongoDB

The End Result

realMethods truly offers an automated way to refactor and create applications. The platform offers all the flexibility needed to give you full control over the process.

Continuous Generation

Not just to get started, but as needed

If everything else in the DevOps tool-chain is involved in a continuous process, why isn't coding? As with development and integration, with enough planning and preparation, continuous generation of code can be accomplished.

Other tools that attempt to handle round-trip generation usually convolute the code base. In our experience they eventually fall short. With the right design up front, round-tripping is not necessary. View each application generation cycle as a new version of your core services. Any coding changes made to this layer should be done through encapsulation, inheritance, etc.. rather than directly to the generated code.

Consider the following steps:

Step 1: design for a separate services layer

Loosely decoupled layers are part of any sound design practice. Among those layers, is a services layer. A well designed services layer is sits between the service consumer and data store. Often, a service consumer is a presentation layer such as web, mobile, etc, but it could be another service layer. It abstracts business logic and data access.

Step 2: model modifications for each new generation

Being model driven, the only reason to regenerate an applicaton's service layer is due to a requirement that caused a change in your entity model.

Step 3: extending the services layer

If it is necessary to extend a generated service layer, it is highly recommended to do so through extension or encapsulation. This will lower the dependency between the a client which required the un-generated service, and the service layer. If the service layer is regenerated, it will negate or reduce the need to modify any un-generated service code.

Step 4: technology stack package revision (optional)

If the generated code consistently lacks a feature you require, you can:

  • - Download the technology stack package
  • stack_download [app_id] [output_file_path]

  • - Modify the relevant template file(s)
  • - Publish the package as a new package
  • stack_publish [yaml_file] [scope]

    where the YAML contents look like:

    version:          1.0
        name:         Trading System API
        description:  Services layer AngularJS w/ Django
    stackPath:        ./techstacks/downloads

    Step 5: regenerate

    Regeneration should be treated as a new version of the services layer. You should consider creating a new appropriately labelled branch in the repository.

The End Result

If you follow the steps above, you can safely and efficiently use application generation to bootstrap any phase (Sprint) of your development process.