PricingBlog

OpenAI Assistant API - Can Do In bubble

  • mdxwired-1270849965362647140

    mdxwired

    1 year ago

    Hey all. Small question. Probably a big answer.

    I need to prompt and retrieve answers from OpenAIs Assistant API, not Chat Completion.

    Unlike standard Chat Completion, the Assistant API does not automatically just return a response from your POST.

    You need to prompt it, tell it to run the prompt(s), and then keep checking back at intervals to see if a response is ready or not, then grab it.

    Doing this in bubble.io is, if still a bit of a PITA, at least very well-documented but I can't figure out how to do it in toddle.

    Thoughts? Help?

    Team toddle
  • mdxwired-1270851650797436951

    mdxwired

    1 year ago

    OpenAI Assistant API - Can Do In bubble
  • lucasg-1270854828096094332

    Lucas G

    1 year ago

    I'll start by saying that this is ideally done on a backend as you'd be exposing your OpenAI keys
  • At least until the secrets manager rolls out
  • That said, it's actually relatively straightforward
  • lucasg-1270855263556997226

    Lucas G

    1 year ago

    If you're set on doing it from toddle, it's as simple as setting up the API calls to the appropriate end points (create message and run, etc) then for the return, you can either poll the run endpoint to see its status
  • Or simple use a sleep() action to set a delay for fetching the messages
  • lucasg-1270855633683615764

    Lucas G

    1 year ago

    Since assistants can take a lot longer than chat completions, the delay could be like 60secs or so to make sure it has the time
  • Polling the run's status would be more reliable
  • Again, I'd do all of this on a backend though
  • Especially if the use case case isn't something the user will wait around for
  • Since once they navigate away from the page, the process would be interrupted
  • mdxwired-1270947935831457884

    mdxwired

    1 year ago

    @Lucas G Thanks. Was not aware that toddle would expose my API key. Only using this, initially at least, to develop a closed beta PoC but that would still be an unacceptable risk.

    My current back end is just using supabase.

    Any ETA on the mentioned 'secrets manager' release?

    ...oh, DUH, not exposed at runtime. Exposed if it is still a public 'clonable' project!!! So, if I transition to a paid account this issue gos away, yes?
  • mdxwired-1270951065977884683

    mdxwired

    1 year ago

    Or... If I just store the API keys in a supabase table that requires authentication... Use a quick, fully auth 'd API call to grab the keys at runtime... Problem solved and I can keep my dev in toddle.dev without worry. Yes?

    Still need to upgrade my account though... Just to support toddle and to scale.
  • lucasg-1270956957506998424

    Lucas G

    1 year ago

    No
  • API calls can be seen in dev console
  • That’s just the nature of it
  • Secrets manager likely won’t be out for another 1-2 months at least
  • lucasg-1270957570621702219

    Lucas G

    1 year ago

    For your keys to be safe, the calls have to be made from a backend
  • Supabase could do it, but you’d have to code it
  • mdxwired-1270971911471366164

    mdxwired

    1 year ago

    OK. I get it. But doesn't that basically mean that the built-in API functionality in toddle is effectively useless? That seems like a pretty big miss, even for early days. Not trying to be overly critical, just sensible. Why even launch with dangerously insecure 'no-code' functionality that can only be fixed through extensive code on the back-end?
  • max.kayr-1270985717144883200

    Max

    1 year ago

    In short: No. The API functionality does exactly what it's supposed to do—it calls an API. Toddle is a frontend builder, and you should never store any secrets in the frontend, as they will be exposed. That's how the web works. The secret feature would be a microservice on the Toddle backend for developer convenience. However, in my opinion, this is only valid for proofs of concept or very simple use cases.

    For a robust setup, you always need a proper backend, and calls to other services should be proxied through that backend. Otherwise, you cannot implement any authentication and authorization. Imagine you have your API set up with Toddle and a secret store. Users can call this API from their browser without seeing the secret, which seems fine. However, you cannot control which user actually makes that call, how often they are allowed to do so, and so on.

    If you want to build a secure and reliable app, such functionality belongs in the backend.
  • mdxwired-1270987963848720415

    mdxwired

    1 year ago

    Understood. I'll build it as a set of Edge Functions in supabase and leverage Auth0/supabase auth to keep everything nice and secure.

    BTW: Love everything else that I am finding in toddle.dev! So much more intuitive than bubble.io.
    💪2
    🙌2
  • Tod-1270987964914077697

    Tod

    1 year ago

    Great energy @mdxwired! Your continuous contribution to the toddle Community just made you advance to Community Level 1!
  • lucasg-1271032405310050387

    Lucas G

    1 year ago

    Thank you @Max for the explanation
    💪1
  • I think toddle is doing it right and other platforms sometimes facilitate bad practices
  • It’s for the sake of convenience so I get it
  • But it’s good to know why