How Scripting as a Service Streamlines Legacy App IntegrationsAug 17, 2020
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:
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.
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.
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.