LNTWOOL - So i cannot export a single API i hav...
So i cannot export a single API i have created in buildshipv2, what is going on, this has not been a great experience
9 Replies
Hi @LNTWOOL We have temporarily disabled the export API for v2 flows, we'll be bringing it back with improved and advanced features soon.
😦
Hi @LNTWOOL you can go to the Usage section of trigger and see how to use the APIs and easily copy over the API url etc in your frontend. Are you specifically looking for exporting in OpenAPI / yaml spec? that part will be added back soon, we are improving that experience as it was lacking in the previous version.
Yeah, i am the founder of https://www.naitive.cloud, we build agents, lots of them. Sometimes we build with the OpenAI nodes, sometimes not, but i basically always use build ship as the tool layer no matter what. We have tooling that builds all of our tools based off the open API spec, but we built it based on exactly how you export api's. Its just a huge time suck, and i have to say the V2 launch has been rough, we've been hit with disappearing inputs, all kinds of weird stuff. It happens, your growing startup we get it. Just the lack of documentation prior to launch has given me a bit of pause to be honest
Thanks for the feedback, we are working on making it a smooth experience. Rest assured openAPI spec export will be made available soon. Also, in the meantime, is there a specific documentation you are after? We have updated the docs with the latest info and are continuously updating it this week to get it 100% upto date. https://docs.buildship.com/
Welcome to BuildShip – BuildShip
A unified resource to start building your backend with low-code. Dive into triggers, nodes, and step-by-step guidance to jumpstart your workflow creation.
Well, just my opinion - how concurrency is handled, based on my testing its FIFO, the scope of the variables is unclear, for example a workflow variable, is that at the execution scope? or it simply persists for the workflow (which is what i found out). Is there any way to session scoped variables? or expose session information, akin to something like "threadId" from open AI. My use case was a token give from twilo, that every node needed, but only for the session, or i could have done execution. The user dual auth's through an AI agent that is not in build ship, the api fetches the token, then there are 3-4 api calls after that can vary but its not much longer than 3-4 min. So secrets manager seems silly, and writing to a table i just did not want to deal with that headache. So i still don't have a solution. well i do, i am sending the thread id (even though build ship is not hosting the agent) to hash it basically store the variable in the hashed state, then delete it. I can tell you, this is something you are going to need, the community is struggling with agents and authentication in general. There are frameworks coming out, but you could have a big win if you created something specifically for agent auth to services, access to the agent, ,etc
the trigger separation was a big change, and still unclear. I wanted to have multiple rest endpoint's, which i can do, but the schema for the rest endpoint affects the rest of them, and LOGGING, i need to understand what is happening if there is a failure at that trigger level... i did not look into this one too much, but as far as i can tell, but the trigger area is a black box, no clue if something is wrong there
you should add in the documentation, if you make ANY change to the INPUT on your main flow, byebye input value. No warning, nothing. I just randomly found them disappearing... turns out, if i change "required" to "not required" just deletes my variable within the node trigger input
theres also no documentation on the custom domain name. had to figure that out myself... you have the the tool tips but they show when your like on the step itself.... if your trying to get into enterprise, they need to know everything upfront to plan, usually there is at least 2 silo'd teams 3 with security that all have to cross communicate something like that
unlear if the nodes we always used, for example API call, i am just guessing thats a "v1" node, do they intermix with the newer nodes? what implications
Hi @LNTWOOL we have now improved the error handling and already linked a docs on setting up sub domain. We’ll add a video and buildship docs for it by the end of this week.
For nodes version, if you are creating a new flow or migrated the v1 flow to v2 all nodes used will be of v2. Also, example v1 API Call node (the one you copy from your old workflow) should also be compatible in your v2 flow as well.
Are you running it any issues with it? If you can share more we can expedite support.
not exactly, it's feedback for @Harini regarding documenting these things, however the question i had about concurrency or how to handle a token it my situation, i still have not had someone from buildship give me any solution