PipecatClient
in a JavaScript application. The new client introduces simplified configuration and improved client-server messaging. For an overview of the changes, see the top-level RTVIClient Migration Guide.
Key Changes
1. Package and Class Names
Old2. Client and Transport Configuration
The core difference here is that the client no longer accepts aparams
field. The configuration that used to be provided here is no longer supported and hitting a /connect
endpoint is now an explicit step and provided directly to either the startBot()
or startBotAndConnect()
method.
Old
3. Connection Method
Previously,connect()
was called on the client instance without parameters. Now, you provide connection parameters directly to the connect()
method. This allows for more flexibility and customization of the connection process. For ease of use, we’ve also introduced a startBot()
and startBotAndConnect()
method where you can provide an API endpoint that returns the connection parameters.
Old
startBotAndConnect()
):
- Direct Connection: Provide the connection details directly to
connect()
.
- Using startBot(): Fetch connection details from an API endpoint and pass them to
connect()
.
- Using startBotAndConnect(): Fetch connection details and connect in one step.
4. Function Call Handling
Previously, you would use a helper class to handle function calls and provide a single callback to handle any/all function calls. Now, you can register a callback for each function call by name directly on thePipecatClient
instance.
Old
5. Pipeline Configuration Initialization
Previously, you could provide a pipeline configuration as part of theRTVIClient
constructor and it was expected to be in a specific format. Now, if you would like to pass any initial pipeline configurations, you do so as requestData
added to the endpoint you provide to connect()
. In both cases, you would need server-side code to parse and apply these settings, but now you can define the structure and what pieces of configuration you want to send.
Old
6. Pipeline Configuration Updates
Previously, the client supported updating the pipeline configuration using a specific method that took a configuration object in a generic format. Dynamic and predifined configuration updates, however, are a security concern, allowing clients to override settings and potentially abuse API keys. For this reason, it has been removed and most configuration updates need to be handled custom by your application. To do so, you should take advantage of the client-server messaging system, which allows you to send messages to the server and handle responses. This way, you can implement your own logic for updating configurations securely. OldsendClientRequest()
) to wait for a response.
7. LLM Context Updates
Previously, you would use a helper class to update the context. This could be a security concern for the same reasons as mentioned above and should now be done using the client-server messaging system. However, in the case where you simply wish to add to the user’s or assistant’s context, you can use theappendToContext()
method on the PipecatClient
instance. This allows for easy, built-in support for text-based context updates without needing to implement custom messaging.
Old
Breaking Changes
- Configuration Structure: Connection parameters are now passed to connect() instead of constructor
- Helper System: Removed in favor of direct
PipecatClient
member functions or client-server messaging.
Migration Steps
- Update package imports to use new names
- Move connection configuration from constructor to startBot()/startBotAndConnect()/connect() methods
- Replace any helper classes with corresponding
PipecatClient
methods or custom messaging - Update any TypeScript types referencing old names