08. Run locally oyster

Run Locally with the Oyster Framework

To switch back to the Oyster runtime, modify the runtime parameter in the extension's package.json file from "debug" to "oyster":

"cds": {
  "requires": {
    "code-extensibility": {
      "runtime": "oyster",
      "maxTime": 1000,
      "maxMemory": 4
    }
  }
}

The additional parameters in the code-extensibility section (maxTime and maxMemory) define restrictions imposed by the Oyster sandbox.
In this example, the execution time is limited to 1 second, and the memory usage is capped at 4 MB.

If you try to debug code extension handlers now, you'll notice that breakpoints can no longer be hit.
The code snippets are executed inside the Oyster sandbox using the JavaScript engine Javy, which behaves differently from the Node.js engine.

For example, the Buffer object is available in Node.js but not supported in Javy.

However, you can still write console output during execution within the Oyster Framework.
This can help with debugging while running locally.

To try it out, add the following line to on-promoteCustomer.js:

console.log('some output')

Make sure that the console output appears — this is one of the few debugging tools available in the local environment for code executed inside the Oyster sandbox.
Note: This option is not available when running in production mode or when using the Java-based runtime.

Playing Around

Node.js is built on Chrome’s V8 engine, so it generally inherits V8's ECMAScript support.
In contrast, the Javy engine uses QuickJS under the hood — a more lightweight JavaScript engine, which currently implements the ECMAScript 2020 (ES11) standard.

Try searching online to explore the differences between ECMAScript 2020 and newer versions (e.g., ES2022 or ES2023),
and find out which features are available in Node.js but not supported in Javy.

This understanding will help you write compatible code when working with the Oyster sandbox.

In the Ninth exercise — Deploy, we finally are multi-tenant with Oyster