OpenAI Assistant & Bubble.io API Connector Part 3

Introduction to OpenAI Assistant API and Bubble.io

Welcome to part three of our Bubble tutorial series looking at the OpenAI assistant API with threads and the Bubble API connector. Now part three begins with a bit of a caveat which is that we've had requests coming in for where is part three all throughout this week and I've been waiting until I could find what I would term an elegant and simple solution to how do we check to see when the message is ready in OpenAI and I've wasted a couple days and mulled on it and I haven't found what I would call a perfect solution and I'm going to explain all the pitfalls but I really want to demonstrate a working solution to you in this video.

Demonstrating the Working Solution

So if I go onto my demo here and I say new chat I can say what is your role I get my message I then get the OpenAI message coming back. Now there is a really serious question here because I think that the assistant API in Bubble has got a lot of shortcomings so if your application is working fine without using the assistant where you basically get the response back from your API call immediately then I would seriously consider just sticking with that unless you've got a really good reason why you need to hand over the thread management OpenAI simply because like I say at the start of this video this is not elegant because what I've got going if I go into my editor is simply a do every one second refresh the contents of the repeating group because an issue with using the assistant API with the run with the let me let me just show you what I'm referring to so we're having to we're creating messages we're putting them into threads and we're running the AI on our thread of messages and then that's what generates our response check out parts one and two for more details on that but the issue is we don't receive a notification when run has completed we have to either keep checking the run object in which case we can use this API call here and we're looking to see whether the status has changed to completed and I tried that because again I say I want an elegant solution and the fact that I'm just having to run a work for every second the whole time and use was on the page I would describe as as you know this is where the big caveat comes in of what your workload units because this could easily escalate but in my brief period of testing if I go into my logs this is the workload units on the page where I tried to add in a load of checks and balances I basically set up a conditional statement on here to say only run this when you've checked the run object has gone on to status completed but as you can see it's actually the the most workload units for the page these are the ones here these are simply where it's running every second and I think and you know do your own testing be careful with this I think that's because here I'm just doing an API call once every second but if I was to put in some checks and balances here I'd have to be doing an API call still every second to check the run object and then if the run object has gone to completed I'd still have to run this API call here to list through all of the messages up while I'm on this just to point out if you are going to use this message method which I'd say is suboptimal then there's an important bit I've added in here which is that when you run a get data from external API Bubble has I suppose you could call it cache it caches the results which means that if you run it repeatedly very quickly Bubble may not actually update it you have to signal to Bubble somehow that the data has changed and the way you do that and there was a really helpful forum post on this topic which is to effectively on my list messages is I've added in a header called date and all this is doing is allowing me to put a new value into the API call so that Bubble record sees it as a unique call rather than a repetition of a call it did immediately before and so in the date field I'm simply inserting current date formatted as simplified extended ISO that just means that every second it runs I get a unique piece of data in there so Bubble makes it a unique call so that's basically the guts of it and I don't think that this is ideal and I'd love to hear your comments and what you think about it do you think that offloading the nature of threads where bubbles where OpenAI stores your messages for you is that really worth the fact that this is much more complicated process than what we've demonstrated in our previous videos if you were simply just to use the chat endpoint where you where when you send a request to OpenAI Bubble waits for a response you get a response back from that call and then and then then you can display it to your users and you can save it yeah I think there's a lot of shortcomings with currently using the assistant API in Bubble and we got remember we look here the assistant API is in beta I mean I'd say that they're not going to change everything that would be very unlikely but they could always change how it works what we would desperately need in order to make this work really well is that when you do when you submit the run command create a run here is that there's a field to put a webhook URL and so that way and many services for example I think assembly AI which is a speech to text API which you know the nature of speech to text it takes a little while to process is that you supply an endpoint so that when their process is completed they basically ping your Bubble app to say this is this is complete and then you can request the text that they've generated based on the audio that you've uploaded to their service that the similar thing is ideally what we need from OpenAI but you know I wouldn't count on it so I would would have some serious questions about whether you go down the route of using assistants threads and run or whether you simply stick to chat I say if you were handling really large conversations if you're experiencing an issue with timing out because you're submitting a large amount of data then that may well justify this but I'd say it's very early days to truly know if I refresh this let's see what we get to truly know the cost of workload units from simply saying that there we go this is basically six yeah six workload units that's what it takes per minute to run the page you do the maths is that worth it any thoughts on this anything I've missed I like as I say I sat on this for a few days and I really hoped to come up with an elegant solution to it I've noticed that some other people on YouTube are basically kind of bouncing between two custom events I'd be interested to see the impact that hasn't workload units because as far as I'm concerned checking one every second a single API call seems to me to be less intensive than running a series of checks only to then run that API call once those checks are complete that's it yeah yeah this is less than elegant this is not the sort of video that I'd normally put up but I wanted to show a working solution as I know that lots of you have been watching part one and part two and so I'd say that it's a beta stay tuned hopefully we can release an update once an OpenAI updates their API and we can show a better solution to using their latest features.