Release 9.4.0 docs and changelog

- Update admin API events endpoint docs (See mockoon/mockoon#1807)
- Add plural req helpers docs (see mockoon/mockoon#1827)
- Add proxy decompression docs (see mockoon/mockoon#1577)
- Update cloud docs
- Add 9.4.0 changelog

Author: 255kb

components/footer.tsx

@@ -151,7 +151,7 @@ const Footer: FunctionComponent<{
               </li>
               <li className='mb-2'>
                 {/* Do not use <Link>, as routes with a dot inside get rewritten without trailing slash */}
-                <a href='/releases/9.3.0/' className='text-reset'>
+                <a href='/releases/9.4.0/' className='text-reset'>
                   Releases
                 </a>
               </li>

components/nav.tsx

@@ -381,7 +381,7 @@ const Nav: FunctionComponent<{
                             Blog
                           </Link>
                           <a
-                            href='/releases/9.3.0/'
+                            href='/releases/9.4.0/'
                             className={`dropdown-item ${
                               router.pathname === '/releases' ||
                               router.pathname === '/releases/[version]'

content/blog/introducing-new-issue-label-system-enhanced-transparency.md

@@ -27,7 +27,7 @@ For a long time, we believed that **every issue deserved a chance to stay open**
 
 We've designed a detailed labeling system that makes it **immediately clear where every issue stands**.
 
-![screenshot of the new labels design](/images/blog/introducing-new-issue-label-system-enhanced-transparency/new-labels-preview.png)
+![screenshot of the new labels design{617x232}](/images/blog/introducing-new-issue-label-system-enhanced-transparency/new-labels-preview.png)
 
 Our new labels are organized into several categories:
 

content/cloud-docs/api-mock-cloud-deployments.md

@@ -40,6 +40,29 @@ In the management dialog, you can **re-deploy** the environment or **delete** th
 
 ![deployment management dialog re-deploy or delete the instance menu{886x210}](cloud-docs-img:deploy-environment-management-menu.png)
 
+### Desktop/web apps and re-deployments
+
+Currently, the behavior of re-deployments is different depending on whether you are using the desktop application or the web application:
+
+- **Desktop application**: For historical reasons, the desktop application is still biased towards local development. Therefore, all changes made to cloud environments will only be applied to the cloud instances when you re-deploy them manually. This allows you to make changes to your environment without affecting the running instance until you are ready to update it.
+- **Web application**: In the web application, many changes are pushed to the cloud instance automatically without requiring a manual re-deployment. This is because the web application is designed to be more collaborative and real-time, allowing you to see the changes reflected in the running instance immediately. However, some changes may still require a manual re-deployment, depending on their nature.
+
+  The following changes are **applied automatically**:
+
+  - Some environment properties (headers, proxy headers, latency, etc.).
+  - Some route properties (response mode).
+  - Adding and removing callbacks.
+  - Route responses (headers, latency, status code, callbacks calls, rules, etc.).
+
+  The following changes still **require a manual re-deployment**:
+
+  - Route paths and methods.
+  - Adding or removing routes.
+  - Environment port, hostname, proxy and TLS options.
+  - Adding or removing data buckets.
+
+We plan to unify this behavior in future versions of Mockoon to provide a consistent experience across both applications.
+
 ## Instance URL and visibility
 
 The instance will be deployed on a shared cloud infrastructure and will be accessible using a unique URL in the form of `https://mock-abcd1234.{serverId}.mockoon.app`. The URL will be displayed in the management dialog and can be shared with your team, clients, or class. You can also customize the subdomain part of the URL when deploying the environment.

content/cloud-docs/data-synchronization-team-collaboration.md

@@ -116,5 +116,4 @@ These quotas and limits are subject to change. Please refer to your [account set
 Here is a list of limitations of the current version of the data synchronization feature:
 
 - External files linked to the environment are not synchronized (e.g. environment's certificates or files used in the "File" response body type).
-- The CLI and serverless package do not support access to cloud environments yet.
-- Team and Enterprise plans are currently not offering a personal cloud space for each user. All environments are shared across the team.
+- The CLI package cannot deploy cloud environments yet ([but it's on our roadmap](https://github.com/mockoon/mockoon/issues/1736)).

content/cloud-docs/web-application.md

@@ -27,14 +27,10 @@ The interface is the same as the desktop application, with a few differences due
 - [Cloud deployments unsupported features](cloud-docs:api-mock-cloud-deployments#unsupported-features) (file serving, custom TLS, etc.) are hidden to avoid confusion.
 - Desktop/local specific options and features are disabled or hidden (managing local environments, etc.).
 - Some interface elements were modified to fit the web application (e.g. the server start button deploys to the cloud instead of starting a local server).
+- The web application handles re-deployments differently than the desktop application (see [Desktop/web apps and re-deployments](cloud-docs:api-mock-cloud-deployments#desktopweb-apps-and-re-deployments) for more information).
 
 As this application is still in early access, we are working on improving the interface and adding new features. We welcome your feedback and suggestions to help us make it better.
 
-Also, some features are not yet available in the web application but will be added in future versions:
-
-- OpenAPI import/export.
-- JSON import/export.
-
 ## Web app version and migration
 
 The web application is always running the latest version of Mockoon. You don't need to worry about updating it, as it will always be up to date with the latest features and improvements.

content/docs/latest/admin-api/events.md

@@ -20,11 +20,13 @@ To subscribe to the events, call the following endpoint:
 
 - **Method:** `GET`
 - **URL:** `/mockoon-admin/events`
+- **Parameters:**
+  - `maxlogs` (optional): The maximum number of logs to retrieve upon connection. If not specified, all logs will be sent, limited by the server's configuration.
 
 **Example request:**
 
 ```http
-GET /mockoon-admin/events
+GET /mockoon-admin/events?maxlogs=100
 ```
 
 ## Events
@@ -77,6 +79,8 @@ Example of a log event:
 
 The data in the `transaction` property is following the [Transaction model](https://github.com/mockoon/mockoon/blob/main/packages/commons/src/models/server.model.ts#L61-L86) similar to the one used in the [`/mockoon-admin/logs` endpoint](docs:admin-api/transaction-logs).
 
+Upon connection, the server will send the last `maxlogs` transactions (if specified) and then continue to send new transactions as they are completed.
+
 ### Data buckets processed event
 
 This event is triggered when the data buckets are processed during the server launch. It contains details about the statuses of the data buckets in a `dataBuckets` property:

content/docs/latest/server-configuration/proxy-mode.md

@@ -37,3 +37,9 @@ Proxy specific headers can also be added, both to the forwarded request and the
 ![add proxy headers by filling the keys and values{1484x375}](docs-img:proxy-headers.png)
 
 > **Proxy request headers** will be automatically added to the request sent to the proxied server, while **proxy response headers** are added to the response received from the proxied server.
+
+## Decompression of proxied response bodies
+
+If the response body is compressed (e.g., with gzip, deflate, brotli or Zstandard) and the `Content-Encoding` header is set accordingly, Mockoon will automatically decompress the body before returning it to the client. The response body will be shown uncompressed in the Mockoon [Logs view](docs:logging-and-recording/requests-logging) and in the [Admin API `/logs` endpoint](docs:admin-api/transaction-logs).
+
+> ⚠️ Zstandard decompression support is available in the desktop application and cloud, but the availability in the CLI and libraries depends on the Node.js version used by your system and requires Node.js v22 or later.

content/docs/latest/templating/mockoon-request-helpers.md

@@ -16,9 +16,12 @@ Mockoon offers the following helpers which can return information relative to th
 - [`bodyRaw`](#bodyraw)
 - [`queryParam`](#queryparam)
 - [`queryParamRaw`](#queryparamraw)
+- [`queryParams`](#queryparams)
 - [`urlParam`](#urlparam)
+- [`urlParams`](#urlparams)
 - [`cookie`](#cookie)
 - [`header`](#header)
+- [`headers`](#headers)
 - [`hostname`](#hostname)
 - [`ip`](#ip)
 - [`method`](#method)
@@ -204,6 +207,28 @@ Get the **raw** value at a given `path` from the request's query string. Complex
 {{/if}}
 ```
 
+## queryParams
+
+Returns an object containing all query parameters from the request URL. This helper is useful for iterating over all query parameters.
+
+**Examples**
+
+```handlebars
+<!-- Iterate over all query parameters -->
+{{#each (queryParams)}}
+  {{@key}}:{{this}}
+{{/each}}
+
+<!-- Get all query parameters as JSON -->
+{{{stringify (queryParams)}}}
+
+<!-- Check if a specific query parameter exists -->
+{{#if (lookup (queryParams) 'page')}}
+  Page parameter provided:
+  {{lookup (queryParams) 'page'}}
+{{/if}}
+```
+
 ## urlParam
 
 Get a named parameter from the route `/:paramName1/:paramName2`.
@@ -218,6 +243,28 @@ Get a named parameter from the route `/:paramName1/:paramName2`.
 {{urlParam 'paramName1'}}
 ```
 
+## urlParams
+
+Returns an object containing all URL parameters from the route. This helper is useful for iterating over all URL parameters.
+
+**Examples**
+
+```handlebars
+<!-- Iterate over all URL parameters -->
+{{#each (urlParams)}}
+  {{@key}}:{{this}}
+{{/each}}
+
+<!-- Get all URL parameters as JSON -->
+{{{stringify (urlParams)}}}
+
+<!-- Check if a specific URL parameter exists -->
+{{#if (lookup (urlParams) 'userId')}}
+  User ID provided:
+  {{lookup (urlParams) 'userId'}}
+{{/if}}
+```
+
 ## cookie
 
 Get the content of a cookie or returns a default value if the cookie is not present.
@@ -248,6 +295,27 @@ Get content from any request header or returns a default value if header is not
 {{header 'Header-Name' 'default value'}}
 ```
 
+## headers
+
+Returns an object containing all request headers. This helper is useful for iterating over all headers.
+
+**Examples**
+
+```handlebars
+<!-- Iterate over all headers -->
+{{#each (headers)}}
+  {{@key}}:{{this}}
+{{/each}}
+
+<!-- Get all headers as JSON -->
+{{{stringify (headers)}}}
+
+<!-- Check if a specific header exists -->
+{{#if (lookup (headers) 'authorization')}}
+  Authorization header provided
+{{/if}}
+```
+
 ## hostname
 
 Returns the request hostname.

content/docs/v9.3.0/about.md

@@ -0,0 +1,65 @@
+---
+title: About the documentation
+meta:
+  title: Learn about Mockoon's documentation
+  description: Discover Mockoon's features and options, explore advanced topics and learn how to create fast and free mock API JSON servers.
+order: 10
+---
+
+# About the documentation
+
+---
+
+This documentation covers Mockoon's most used features and options to help you create the best mock APIs. These topics apply to the [desktop application](/download/), [CLI](/cli/), and [serverless package](/serverless/) which supports the same features.
+
+You will find a documentation for the most recent releases of Mockoon. Head over to our [releases section](/releases/) for more details about the changes in each version.
+
+If you find a mistake in the documentation, you can open an issue on the [website's repository](https://github.com/mockoon/mockoon.com).
+
+## CLI-specific documentation (flags, etc.)
+
+You will find the [CLI documentation](https://github.com/mockoon/mockoon/blob/main/packages/cli/README.md) in its dedicated readme file on the repository. It covers the CLI's specific features, like the available flags or how to use the Docker file.
+
+## Serverless-specific documentation (options, etc.)
+
+You will find the [serverless package documentation](https://github.com/mockoon/mockoon/blob/main/packages/serverless/README.md) in its dedicated readme file on the repository. It covers the package usage instructions and specific features.
+
+## Web application
+
+The [web application](cloud-docs:web-application) is a web version of the desktop application available for Mockoon Cloud customers. While based on the same codebase, it is not a direct replacement for the desktop application and does not support all the features. Please refer to the [web application documentation](cloud-docs:web-application#ui-differences) for more information about the differences.
+
+## Versioning
+
+Even if Mockoon is primarily a desktop application, we are following [semantic versioning](https://semver.org/). All the applications and packages **share the same version number** for each release.
+
+This allows you to migrate from one version to another without worrying about compatibility issues between the desktop application and the CLI or serverless package.
+
+### Major versions
+
+While the desktop application can easily **migrate from one version to another** (including major versions), this is not the case for the CLI or serverless package. When you are using one of your [data files](docs:mockoon-data-files/data-files-location) with the CLI or serverless package, or sharing it with your team, you need to make sure that the data file schema is compatible with the version you or your team is using.
+
+Every time we introduce a **breaking change** in the data file schema (e.g. new feature) we release a **new major version**. We recommend that you always migrate simultaneously to the same major version for all the desktop applications and packages you are using.
+
+> 📝 Note to our Cloud users: the same recommendation applies when you are using our **Cloud features**. Please have a look at the [team collaboration](cloud-docs:data-synchronization-team-collaboration#major-versions-migrations) and [cloud deployments](cloud-docs:api-mock-cloud-deployments#major-versions-migrations) documentations for more information.
+
+### Breaking changes
+
+When building libraries, the definition of a **breaking change** is usually straightforward. However, when building desktop applications, it's harder to define what a breaking change is.
+
+Also, as we have **multiple components** (desktop application, CLI, serverless package), we have to consider the impact of a change on all these components while avoiding a too-strict definition of a breaking change that would mandate a new major version for every release.
+
+Our definition of a breaking change is a change impacting the [**data schema**](docs:mockoon-data-files/data-files-location) and creating a **compatibility issue** between the applications and packages.
+
+Examples of **schema changes** that would require a **new major version**:
+
+- Adding a new feature requiring a new field.
+- Adding a new type in an enum field, like a new rule type.
+- Removing a feature that requires removing a field from the schema.
+
+The consequence of such a change is that the data file created with a recent version of the desktop application would not be compatible with an older version of the desktop application, CLI, serverless package, or a team Cloud workspace.
+
+What we do **not consider a breaking change**, even if it might impact the user experience and require a migration effort:
+
+- Changing the UI layout.
+- Changing the behavior of a feature (e.g. adding templating support to a field).
+- Changing the templating helpers' signatures or adding new ones.