What is Changing?
The major difference in the Profound.js 6 framework is the change from Fibers to Promises. Starting in Profound.js 6, all framework APIs return Promises and applications run in a top-down manner using the async/await keywords. Profound.js 6 is largely, but not entirely, backwards compatible with Profound.js 5.
Profound.js 5 Fix Pack 8 (5.8.0), released on 3/4/2022, is the last feature update for the Fibers-based Profound.js 5 framework. Profound Logic will continue to support this release with fix updates for 1 year following the release of Profound.js 6. Profound.js 5 runs on Node.js 14, which is scheduled for end of life on 4/30/2023now EOL. New features will only be available in Profound.js 6, which runs on Node 14, Node 16, and future versions of Profound.js. These dates are coming up quickly, so you are strongly encouraged to migrate to Profound.js 6 as soon as possible.
Why This Change? Why Promises?
Development on Profound.js started in late 2015, using Node.js 4. A key goal of the framework from the beginning was to simplify Node.js programming and eliminate the notorious Callback Hell. But at that time, there was not a built-in way of coding asynchronous I/O in Node.js in a top-down manner.
...
So, this change is necessary to move Profound.js forward, support current/future Node.js versions, and keep in tune with the Node.js ecosystem.
What Does This Mean for My Existing Applications?
For the most part, existing applications written for Profound.js 5 will continue to work with Profound.js 6. However, top-down programming with Promises is very different than with Fibers and it’s not guaranteed that all existing applications will run as-is on Profound.js 6. Some applications may require minor modifications.
| Warning |
|---|
This means that you should not upgrade a production Profound.js 5 instance before thoroughly testing the application with Profound.js 6 and making any needed modifications. Testing should be done in a separate Profound.js instance, so that production applications are not affected. |
Modifications for Async/Await
Existing applications may need slight adjustments to add async and await keywords for Promises where Profound.js module transformation is not able to do so automatically. For details, see Coding With Promises in Profound.js and the section Limitations of Module Transformation. The scenario given on that page is just one example. There may be other cases where module transformation is unable to add async/await, depending on how the application is code.
Low Code Steps/Routines Converted to Code
Low Code applications which contain steps or routines that have been converted to code will need a slight adjustment if the converted steps/routines contain calls to other routines which were created by the Call Another Routine or Call Internal Routine plugins.
For example, the Call Another Routine plugin for Rich Display Files generates code like this:
...
The generated code needs to be adjusted to add await to the call, for example:
...
Similarly, the Call Internal Routine plugin for low code modules generates code like this:
...
The code needs to be adjusted like this:
...
Conversion of Start.js Files
When upgrading an existing Profound.js installation to version 6, the start.js file will be automatically adjusted to work with Promises. For example, a file like this:
...
The conversion process retains a copy of the original file as start.js.orig.TIME_STAMP
Removal of Built-in Auto-Restart
Prior versions of Profound.js included built-in functionality to automatically restart the server if it ended unexpectedly. This functionality has been removed in Profound.js 6, and auto-restart should be handled via external process management.
Suggested process management:
IBM i: It's recommended to use STRTCPSVR to manage your Profound.js servers by using the option to set up STRTCPSVR configuration when installing Profound.js. Instances started with STRTCPSVR will automatically restart if they end unexpectedly.
Other platforms: It's recommended to use PM2 for process management. PM2 includes functionality to automatically restart failed processes.
Running inside Docker/Kubernetes: It's recommended to use features of Kubernetes (i.e. Pod auto restart) or Docker to automatically restart failed processes.