2.9.1 - August 2024

This month's release contains a giant technical step called "No Downtime Deployment". As its name suggest, it allows project maintainers to use a blue/green strategy to deploy new version of their applications without causing downtime for their end-users.

You can learn more through

• The high level view in this release notes
• Our in-depth documentation page

If you're not deploying apps yourself you might be wondering if this release has something for you ? Well, the answer is a resounding yes ! Thanks to our latest hackathon we've been able to bring in some long-awaited improvements regarding the User Experience of Draw. Read-on to learn more.

Major changes

🫢 No Downtime Deployment

When you deploy an app used by hundreds or thousands of people, you want to do this as "hidden" as possible. You don't want to disturb your end-user by putting the app in maintenance. Starting from this version of the platform you can now deploy with a blue-green strategy which will

• Create a new version of the code-as-data, ready to be deployed in production
• Effectively deploy this new version on the cluster, but on separate pods labelled as "preview", without any impact on the currently deployed application
• Provides a new endpoint to "secretly" preview the new deployed version, check that everything is OK and if yes you'll be able to:
• Manually "promote" the preview version, which becomes the current one.
• Users on the "previous" version are notified with the following popup:

Here are a few important points to note:

1. No downtime is not automatic from 2.9, you'll need to opt-in for this feature following our documentation.

2. Users of your app are not "forced" to update. They are notified with the above popup and can decide to refresh immediately or finish what they are doing and refresh later

3. During a deployment, the "code-as-data" becomes readonly (for integrity of code purposes). A banner in Draw indicates to developers that a deployment is in progress and that they cannot change the "code" during this time. However, since the "no downtime" feature is designed to be used for production deployment, it should not impact your workflow since we discourage using the production environment for development.

4. If the production preview is not satisfying, you can roll back to the current version

5. You can override the behaviour of your application when the upgrade done event is triggered. This can be useful, for instance to force users to refresh their page, or to display a custom message with another look and feel. This is possible via the new "On Upgrade Done" handler available in the UI Application in Draw

   

Spec & Doc Editor for datatype: improve documentation of your Data Model

You are probably familiar with the "Spec & Doc" editor which allows to define the specification of a brick / component, etc... Now you can also define the specification for your Data Model with the new Data Type Spec & Doc editor.

info

In this section we will use the word "Data Type" to refer to both "Data Type" and "Config Data Type" which share the same features.

Open the Spec & Doc using the contextual menu on Data Types

Once opened you can:

• Write summary and description documentation
• Add / Remove properties and relations
• Document each property with their relative "Description" textfield
• Set the "Status" flag of the Data Type (Experimental, Stable or Deprecated)
• Set the "Visibility" flag of the Data Type (Private or Public)

This information is visible in the application inside the "Documentation Window" available by clicking the (i) icon of the datatype

The Documentation Window of a Data Type

Sort properties, relations, events, inputs and output with drag & drop and auto-sort alphabetically

In all Spec & Docs (Data Type, Bricks, Visual Component), you can now sort elements using drag & drop handles and if you prefer you can sort all items alphabetically with one click.

Ability to lock anonymous functions

Since the version 2.6 of the platform you can "lock" bricks to prevent non-maintainers to make changes in their implementation. This feature has been very well received by large teams where it helps with governance. It has been reported that a missing piece of this feature was the ability to lock "anonymous" bricks such as "On Click" or lambda like "Mapper" or "Iterator". This is now supported, and we hope it will continue to help team work effectively in Draw.

Use the shield icon in the toolbar to protect your brick, either normal brick or anonymous

Dynamic Config Parameters

Commonly, Olympe settings are passed to an application using the static oConfig.json file.

Now we have made some parameters dynamically reactive. In other words, these config parameters can be changed during the runtime of an application without restarting. This is used internally for the backend applications using the No Downtime Deployment feature, but can also be leverage on the frontend, especially for params such as

• logger.XXX: allows to dynamically enable or disable a specific logger
• defaultHost: allows to dynamically switch the environment of an application

From the Developer Tools Console you can now use the command

// Dynamically update a config value
updateConfig('<param_name>', <new_value>);

// Dynamically enable the communication logs
updateConfig('logging.communication', '1'); 

The consequence of that feature is that backends won't restart automatically after changing the configuration file (oConfig.json) in the config of the environment.

Split readiness and liveness checks

Since Draw 2.3 you can register health-checks to monitor the status of your backends (service apps). These checks used to only represent the "readiness" of the app to ensure that they would start properly and try to restart if something was wrong. We have improved the API of these checks to differentiate between

• readiness: returning the status of the application to indicate when it's "ready" to be used
• liveness: returning the status of the application to indicate whether the application is still in a good shape or should be taken down

You can leverage this difference both from code and from Draw:

1. New option on the registerHealthCheck API

   Process.onHealthCheck(() => {/* handler method */}, {type: "<type>"})

   onHealthCheck accepts now a second argument which can be provided with

   • ProbeType.ALL
   • ProbeType.LIVENESS
   • ProbeType.READINESS.

2. New input provided in the Register Health Check brick:

   

   The new Probe type input can be either All, Liveness or Readiness

New Comments behavior

From this version you can now add comments to your brick using the toolbar button instead of dragging them from the marketplace.

Better display of long string in Logic Editor

If you've ever use long string as brick input you know that they can take a very large space in the screen and become somewhat unreadable. Well now they will be shortened and you'll be able to better read them and copy with a nice tooltip. Let's have a look:

A nice long JSON input

When hovering the long input, JSON will be formatted and you can double-click to copy the value

A nice long URL input

Promisification of the File API

The public API exposes 3 asynchrounous methods to retrieve file content. Historically they worked by passing a callback and have now a Promise based implementation:

/**
 * Gets the file content as an ArrayBuffer.
 *
 * @return promise resolving with the content as a byte array
 */
getContentAsBinary():Promise<ArrayBuffer>;

/**
 * Get the content of this file and returns it as an UTF-8 string.
 * **Note:** this method should be used only when the file is a text file.
 *
 * @return promise resolving with the content as a string
 */
getContentAsString(): Promise<string>;

/**
 * Gets the URL that gives direct access to the file content:
 * - For files that are external to Olympe, gives the normal URL
 * - For the files stored by Olympe, provides a dataURL, with the content embedded in Base64
 *
 * @return promise resolving with the content as a string
 */
getContentUrl(): Promise<string>;

info

The callback version of these methods is still working but flagged as @deprecated. We strongly encourage you to migrate to the new Promise based API as soon as possible

ReactGrid extension

The Marketplace welcomes a brand new extension for the library ReactGrid.

It will allow you to display and edit data in a spreadsheet-like way!

This extension includes many features out of the box:

• Handling of data in a rich and an agnostic way
• Custom processing of changes made to the data with common processors included
• Excel-like fill handle with row, column and range selections
• Columns resizing, reordering, and custom configuration
• Possibility to mark rows and columns as sticky
• Row grouping to organize the grid in a powerful fashion

You need to add the package @olympeio-extension/reactgrid in your package.json and run a code as data upgrade of your instance to start playing with this new capability. The ReactGrid extension is located in DRAW at: Home > Olympe Libraries > Extensions > UI > Reactgrid

You will find there all the available bricks with their documentation included:

Bug fixes and minor improvements

Draw

• For "Object" type of inputs, the inline editor is now able to remember the type of input you choose (string, number, boolean, ...) and you'll be able to edit this value faster if need be.
• You can now move a Config Data Type or Data Type from a Folder to another (the Folder must be a Config Data Model for Config Data Types or Data Model for Data Types)
• Remote Actions can now correctly set the "Application Context". You can now safely use the "Set in Application Context" brick to interact with the context of a Service App.
• Improve the Documentation Window of bricks. You'll now find more information about a brick such as the path to its project and potentially a link to its code repository if the info is provided in the project.
• Keep the last selected model in the Runtime Dataset or Config Dataset editors.
• Fix zooming in editors, which was buggy sometimes depending on screen resolutions.

Breaking Changes

• The GetFromJson brick doesn't return null anymore for empty array, but effectively return the empty array []

Use v2.9.1

• Olympe DRAW v2.9.1 / CODE v9.9.1 / Extensions v2.9.2 / Orchestrator v7.4.1 / Toolkit v1.1.0

To check whether your Olympe environment is on v2.9.1: click on the top-right logo in DRAW; you'll see the current version you are using.

CODE update

If you are using coded bricks, please update your package.json file with the following dependencies:

danger

Some users are using the stable version of the toolkit in their pipelines to deploy their applications. This is not supported anymore and you MUST use the corresponding toolkit version in your deployment process. You can always refer to our stable versions page to ensure you are on the correct version. For this 2.9 release, the correct toolkit version is @olympeio/tookit@1.1.0.

// Dev dependencies:
"@olympeio/toolkit": "1.1.0",
"@olympeio/draw": "2.9.1",

// Dependencies
"@olympeio/runtime-web": "9.9.1",
"@olympeio/runtime-node": "9.9.1",

// Olympe Extensions
"@olympeio/core": "2.9.2"
"@olympeio-extensions/...": "2.9.2"