Zuplo Changelog

This release includes improvements to the local development experience with increased body size limits in the route designer and bug fixes.

New Features 🎉#

• Increased body limit in local route designer - The maximum request body size limit has been increased in the local route designer, allowing developers to test APIs with larger payloads during development.

Bug Fixes 🐛#

• Project template creation improvements - Fixed an issue where creating a project from a template would fail if the source control access token was not properly validated. The system now correctly checks for and handles access token availability during template-based project creation.

This release includes improvements to logging stability and performance.

Bug Fixes 🐛#

• Fixed OpenTelemetry fetch instrumentation issue - Resolved an issue with OpenTelemetry outgoing fetch instrumentation that could cause unexpected behavior in distributed tracing. This fix ensures proper trace context propagation for outgoing HTTP requests.

• Improved log ordering - Fixed an issue where logs could appear out of order in certain scenarios. Logs now maintain their correct chronological sequence for better debugging and monitoring.

When your API throws an error in local development, you will now see a formatted output that includes the error message and stack trace in a more readable format. This will help you quickly identify the issue and debug your application.

We have overhauled the local development logs to provide a cleaner and more useful output. The new logs make it easier to see the HTTP method, route, and status code for each request. This will help you quickly identify issues and debug your application.

The logs are now color-coded to make it easier to distinguish between different HTTP methods and errors are highlighted in red. Additionally, the logs are now formatted in a more readable way, making it easier to scan through the output.

We have made a number of improvements to the create-zuplo-api package to make it even easier to start a Zuplo API project locally. The updated package includes the following enhancements:

• Option to include ESLint and Prettier configuration files in the project
• Improved error handling and messaging
• Automatically installing dependencies after project creation

The Zuplo Identity Token is a new feature that allows developers to create a JWT token that uniquely and securely identifies their Zuplo API. This token can be used to authenticate downstream services or third-party APIs, enabling secure communication between services without the need for additional authentication mechanisms or sharing of sensitive credentials.

The Zuplo Identity Token is a JSON Web Token (JWT) that contains information about the Zuplo API that it represents. This token is signed by Zuplo and can be verified by downstream services or third-party APIs to ensure its authenticity and integrity.

The token contains claims for the Zuplo account, project, and deployment that can be used to uniquely identify the API and its associated resources. See the Zuplo Identity Token documentation for more information.

Using the Token#

Developers can access the Zuplo Identity Token in their code by calling the ZuploServices API. A custom audience can be provided to the token to ensure that it is only usable by the intended downstream service. Multiple tokens with different audiences can be created and caching is managed by Zuplo to ensure high performance.

import { ZuploServices, ZuploContext, ZuploRequest } from "@zuplo/runtime";

export default async function handler(
  request: ZuploRequeset,
  context: ZuploContext,
) {
  const idToken = await ZuploServices.getIDToken(context, {
    audience: "https://my-api.example.com",
  });

  const response = await fetch("https://my-api.example.com", {
    headers: {
      Authorization: `Bearer ${idToken}`,
    },
  });
}