Prismatic Changelog

We've continued to expand our built-in component offering. A full catalog is available here. This month, we added:

• Airtable - List, create, delete, and update records in an Airtable Base
• Amazon SES - Send email through Amazon's Simple Email Service (SES)
• Google Drive - Manage files that are stored in a Google Drive account
• Google Sheets - Create, read and modify spreadsheets in a Google Drive account
• Mongo DB - Create, read, update and delete documents inside a NoSQL MongoDB collection
• Microsoft Power BI - Interact with datasets and data schemas within Microsoft's data visualization and business analytics service
• MySQL - Query and manage data in a MySQL database
• Shopify - Interact with Shopify's Access Service API
• Stripe - Interact with Stripe's payment platform

The Shopify and Stripe components were both generated from OpenAPI definitions using Prism's component generator tool.

You can now configure authorization settings per action (as opposed to per component). This is helpful if you are building a component with multiple actions and only some of your actions require authorization.

Read about how to upgrade your component to use per-action authorization on our Spectral 3.x Upgrade Guide.

Several new components have been added to our catalog of built-in components:

• Amazon DynamoDB - Create, update, fetch, or delete items in an Amazon DynamoDB database
• Amazon SNS - Manage subscriptions, topics, and messages within Amazon SNS
• Amazon SQS - Send, receive and manage messages within an Amazon SQS queue
• AMQP - Send and receive messages on an AMQP-based message broker
• Apache Kafka - Publish messages to an Apache Kafka event stream
• Customer.io - Manage customers on the Customer.io platform
• Microsoft SQL Server - Query and manage data in a Microsoft SQL Server Database
• MQTT - Send and receive messages on an MQTT-based queue
• PostgreSQL - Query and manage data in a PostgreSQL database

Prismatic's custom component TypeScript library, @prismatic-io/spectral, has been expanded and updated to improve the developer experience for building custom components. Updated syntax for creating components, actions, and inputs helps to catch common errors at compile time (rather than runtime), and new utility functions help to guarantee that you pass the correct variable types to third party SDKs and APIs.

For info on upgrading an existing 1.x custom component to 2.x, see our Upgrade Guide. You can dive in to the Spectral code on GitHub.

Versioning has been improved for components, integrations, and instances to give you more fine-grained control over exactly what code is deployed to customers.

Components are now assigned an integer version that increments each time the component is published. If a custom component is at "version 3" and you publish a new component definition, that new definition gets "version 4". This allows you to update or extend components without unintentionally impacting existing integrations that use them, ensuring your integrations remain stable. Integration builders can then update the component versions used in their integrations, or roll back to a previous versions when desired, and will be notified when newer versions of components are available.

Read more about Versioning of Components and Choosing Components Versions in Integrations.

Integration versioning has been improved, giving you more control over what versions of integrations you deploy to customers. When you publish new changes to an integration, similar to components, your integration is assigned a new version number. Then, when you deploy an instance to a customer, you can choose which version of the integration to use. That means you can have some customers on version 1, and others on version 2 as needed, giving you control over which customers have what, and allowing you to test a new integration version with a small subset of your customer base before deploying it broadly.

Rolling back an instance deployment is a breeze - if you deploy a new version of an integration to a customer and something seems off, you can easily roll back your instance to a known working version of the integration with a couple of clicks.

As always, updating customers' instances can be scripted, so you don't need to manually deploy a new version of an integration to each customer.

Read more about Publishing an Integration.

APIs often have hundreds of unique endpoints that you can interact with. With the release of Prism version 1.0.8, you can now generate a custom component from a WSDL or OpenAPI file. That means you can have a custom component for a third-party service with hundreds of actions with a single CLI command.

Read more on our Writing Custom Components article.

Organizations with an enterprise plan can now create a custom theme for the Prismatic web application. This takes Prismatic's white-label capabilities to the next level by allowing you to customize the color scheme and other UI elements to match your branding. Once you apply a custom theme, it will be displayed for both your team members and customers.

For more information, see our custom theming docs.

It's now easier for your customers to manage instances of integrations that have been deployed to them. Customer users with admin permissions can update config variables and credentials that are associated with their instances. So, if their config or credentials for a third-party service change, they can log in and make the change without needing your help.

For more information on customer user roles and permissions, see the users article.

It's now much easier to configure instances of your integrations to run on a unique schedule for each of your customers. For example, Customer A could be set up to run the integration each day at 4:00PM, while Customer B could be set up to run the integration hourly, depending on their needs.

For more information, check out our integrations article.

Significant improvements have been made to credentials, integration configuration and instance deployment.

Integration builders now have the ability to create an easy-to-use configuration page for customer-facing teams. Builders can define config variable names, give hints as to what sort of data is expected, add headers, etc., giving their customer-facing teams an intuitive experience when it comes to deploying an integration.

This ultimately makes for easier and faster deployment of integrations, without the need for developer intervention. Read more about setting up config variables on our integrations article, and about the new instance configuration experience on the instances article.