How Scripting as a Service Streamlines Legacy App Integrations

Whether migrating to a new content management system (CMS) or connecting a frontend application to a CMS, one of the most significant costs in both time and money is development.

While an API-first CMS like dotCMS has REST APIs to create, read, update and delete (CRUD) content, often this is not enough for existing frontend applications. If that's the case, integration would require rewriting of legacy code.

However, according to Forbes, enterprises are embracing low code environments to better serve their non-technical departments (at dotCMS, we call the initiative NoCode—since our vision is to provide a codeless environment for marketers and business users)

But as well as catering for the non-technical crowd, there’s also work to be done when it comes to streamlining a developer’s to-do list. As the Forbes article mentions, in a low-code environment, developers can streamline and simplify their work to implement systems at a fraction of the price and in a fraction of the time. In line with this, Scripting as a Service—yet another dotCMS feature rolled out as part of dotCMS 5.x—is a powerful low-code tool that allows developers or even less technical users to build APIs using simple Velocity scripts that are customized to match existing frontend API requests. Let’s dive into how it all works.

How does Scripting as a Service work?

Scripting as a Service is the ability to pass velocity code within the JSON body of HTTP requests. The example below uses a POST request to the dotCMS dynamic endpoint to create a “Movie” contentlet from a JSON object at runtime. Note that images, taxonomies, relationships, and workflow actions can all be included in a simple POST:

Scripting as a Service

With just three lines of Velocity, the JSON object is saved in the content repository in dotCMS at a specific workflow step. This code snippet can easily be modified for additional content types and workflows.

Along with the JSON body, Velocity has access to path parameters and query parameters in the request, the response headers, and HTTP session attributes. Scripted endpoints also follow the same permission and authentication rules as built-in APIs. There are a variety of Viewtools available to use with Velocity such as the workflow tool for updating the content repository and the JSONTool for building JSON responses. If the Viewtools available are too limiting, it's also possible to create custom Viewtools in Java that could save more time than writing a full custom API.

See Scripting as a Service In Action: Scripting as a Service: A Look at dotCMS’s Scriptable API Builder.

Faster Migration

Utilizing Scripting as a Service, it's possible to integrate a frontend application with dotCMS without modifying any JavaScript code or back-end code like Java. Instead, semi-technical users can add velocity scripting to the JSON body of requests and change the endpoint to the dynamic API endpoint dotCMS provides. Without using Scripting as a Service, frontend developers would need to modify their requests and responses to match the default REST APIs, which could require substantial code changes. The other alternative would be to write custom endpoints in Java, but neither is an efficient solution for existing frontend applications. Scripting as a Service, therefore, can significantly reduce the development time needed to get dotCMS ready for production with simple Velocity scripts.

Lower Costs

Along with the time saved, there is a higher return on investment by using Scripting as a Service for integration. For one, Velocity scripts are much easier to understand than traditional programming languages like JavaScript and Java. The simplicity of Velocity means less-technical users can make the required changes without utilizing an expensive development team. Further, with reduced development time, there are naturally lower costs involved.

Minimize Vendor Lock-in

When it comes to developing APIs, it could be tempting to use proprietary frameworks that promise faster and cheaper development of APIs, but reliance on specific vendors has its drawbacks as well. In the long run, locking in with one particular vendor can have significant migration costs. By switching to an open-source platform like dotCMS, companies can minimize vendor lock-in now and in the future. Velocity decreases the difficulty in integration, which means there is less reliance on any particular third-party for API support. Further, using Scripting as a Service empowers frontend developers or even less technical users to have control over application integration with dotCMS. This virtually eliminates future vendor lock-in.

Better Performance

Scripting as a Service could be beneficial for the performance of legacy applications as well. With the simplified ability to customize requests and responses with Velocity, it's easier to fit APIs to the exact needs of the existing frontend application. The default APIs, while useful for designing new applications, may have extraneous data that wastes bandwidth for existing applications. With Velocity scripts, the responses can be limited to only the data or content that's necessary so that payloads can be as small as possible. Along with reduced payloads, including additional data can result in fewer APIs calls and therefore improved latency. Smaller and less frequent payloads translate to better user experiences because websites will have better performance, especially on lower resource mobile devices.

dotCMS: Faster Integration with Legacy Apps

Although dotCMS offers a full set of REST APIs to pull content, it's often quicker to integrate with existing applications by creating custom endpoints. Using Velocity with (dotCMS), it's possible to create custom APIs without having to develop them in a backend language like Java. Velocity scripts are much easier to understand than Java, and therefore, can be created without a full development team. Legacy applications will also offer better performance and enhanced user experiences by retrofitting APIs using Velocity to the most efficient payloads possible.

Scripting as a Service streamlines the process of connecting a frontend, and thus reduces the time to market of dotCMS. The LeBron James Foundation, for example, together with dotCMS partner Ethode, was able to migrate to dotCMS and build a Single Page Application in just three weeks. The foundation embraced the dotCMS NoCode philosophy to implement and deliver its new Single Page App (SPA) on time, despite the tight deadline.

Streamlining software implementations with low code tooling is the future of efficient enterprise technology. Migrating a legacy application to dotCMS is painless with Scripting as a Service. You can leverage the work already done in creating the app, and reduce the time and costs in implementing a headless CMS by taking advantage of the no code/low code philosophy.

August 17, 2020

Recommended Reading

Headless CMS vs Hybrid CMS: How dotCMS Goes Beyond Headless

What’s the difference between a headless CMS and a hybrid CMS, and which one is best suited for an enterprise?

Why Global Brands Need a Multi-tenant CMS

Maintaining or achieving a global presence requires effective use of resources, time and money. Single-tenant CMS solutions were once the go-to choices for enterprises to reach out to different market...

14 Benefits of Cloud Computing and Terminology Glossary to Get You Started

What is cloud computing, and what benefits does the cloud bring to brands who are entering into the IoT era?