WASM builds
Build automat applications into WebAssembly (WASM) to run them in web browsers. This allows you to create wasm applications with the same codebase as your web applications.
There are some limitations to be aware of when building for WASM:
- JS loading by default in ‘blob’ mode, which means that all js code is loaded in a single blob, and it does not change in an already loaded wasm application. This behaviour can be changed to ‘per-template’ in the builder settings, but it is currently experimental and may cause issues with already built applications that were built for the blob style mode.
- B2B features work differently as it cannot contact used API’s directly (no access to erply session key). It uses a special proxy on the server to handle the request. This also means that the applications needs to be installed on the server as well for authentication and security purposes.
- Severe bottleneck for asynchronous operations. Too many async operations may cause the application to behave erratically.
- Some features are not yet supported in WASM builds (ex: helpers, tools etc). Create a feature request if you want to see a specific feature in WASM builds (and see the error in the console for a missing feature).
Build options
When building wasm applications there are multiple fields that can be set. Note that the initial values can be left as is, none of the fields need adjusting to create a build. Some fields just set default values to the application and can be overwritten by url parameters on open time.
| Name | Description | Can be altered with url parameter or post build session alteration |
|---|---|---|
| Version addition | Adds a unique suffix next to application build version. {version}-{version addition} | No. Used on build time only. |
| Client code | Adds a default client code to the build. Used when the link does not contain any client codes. Only use if the build is meant for a specific client otherwise leave empty. | Yes. Should be passed when opening the application. |
| Select JS serve method | Changes the way JS is being served from the wasm application. - Blob will compile all js to a single blob and serve it on startup. - Per template works like the server and js files are served as marked on template. |
No. Used on build time only. |
| Select WASM api mode | Defaults to live. Offline is currently depracated as this mode directs all calls to the old offline ms. app_users is also deprecated as its replaced by app_users_v2. app_users_v2 when the application is using app users in b2b mode. |
Yes. The mode can be changed at any time of the application. Leave empty for default live (regular bo users) |
| Select WASM cart mode | Switch cart mode to either the inv docs api or the internally built version. Only needed if the application actually uses cart functionality. Default is server where all inv docs cart calls contact the server. Internal will use the built in version instead. | Yes. This mode can be changed at any time of the application. Leave empty for live. |
| Use internal cart backup | Only shown and used when cart mode is internal. When selected then wasm will backup the cart to kvs and reload it when it starts. | Yes. This mode can be changed at any time of the application. |
| Additional applications | With this we can add extra applications (module v2 or even full applications) to the same wasm build. This is the way to make V2 modules available to the build, use the checkbox to set the module to enabled/disabled on application load. | No. Used on build time only. |
Note that if we set default modes here during build time, then we do not need to select these values with the open link.
Builder updates
Check the changelog area for the information on major updates. Changelog