RTVIClient Migration Guide for JavaScript
A Guide to migrating from a JavaScript RTVIClient to PipecatClient
This guide covers migrating from RTVIClient to the new 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
Old
New
2. Client and Transport Configuration
The core difference here is that the client no longer accepts a params
field. The configuration that used to be provided here is no longer supported and endpoint information is now provided directly in the connect()
method.
Old
New
3. Connection Method
Previously, connect()
was called on the client instance without parameters. Now, you provide connection parameters directly in the connect()
method. This allows for more flexibility and customization of the connection process. For ease of use, you can either provide an object that contains the connection parameters your Transport
requires or a REST endpoint that returns the connection parameters.
Old
New
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 the PipecatClient
instance.
Old
New
5. Pipeline Configuration Initialization
Previously, you could provide a pipeline configuration as part of the RTVIClient
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
New
Check out this section of docs for an example, complete with server-side code showing how to initialize the pipeline configuration at connection time.
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.
Old
New
Check out this section of docs for a more complete example, along with an example on making a request (sendClientRequest()
) 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 the appendToContext()
method on the PipecatClient
instance. This allows for easy, built-in support for text-based context updates without needing to implement custom messaging.
Old
New
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 connect() method
- Replace any helper classes with corresponding
PipecatClient
methods or custom messaging - Update any TypeScript types referencing old names