Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs • Hacker News Board

Re: Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs

#21

Post by zarathustreal » Sat, May 31, 2025, 1:10 AM UTC

maxgrinev wrote: post #20

tnolet wrote: post #12

But, this is just leaky abstractions to the max. You replaced a python code base with adding a layer of YAML on top of it, but then still requiring you to write Python? My IDE will have a stroke parsing this.

You're right about the abstraction concern. The vast majority of the workflow stays in structured YAML - Python is only needed for two specific points: constructing HTTP request bodies and parsing JSON responses. These are inherently dynamic operations that need real programming logic. The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain than a few lines of Python/J…

I think you’re misunderstanding. This product doesn’t make sense because the problem itself is not solvable under your given constraints.

Re: Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs

#22

Post by pan69 » Sat, May 31, 2025, 1:25 AM UTC

captn3m0 wrote: post #7

This looks quite similar to Arazzo: https://github.com/OAI/Arazzo-Specification/

Looks interesting. Has someone done an implementation of this?

Re: Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs

#23

Post by chatmasta » Sat, May 31, 2025, 3:42 PM UTC

sscarduzio wrote: post #3

> Fuses API execution with SQL logic to provide an open, flexible platform (…) But there’s a gigantic multi line string in your yaml. Full of Python.

Scroll down and you’ll see the example with raw SQL.

Re: Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs

#24

Post by pan69 » Sat, May 31, 2025, 9:11 PM UTC

zarathustreal wrote: post #21

maxgrinev wrote: post #20

Earlier quoted context omitted.

You're right about the abstraction concern. The vast majority of the workflow stays in structured YAML - Python is only needed for two specific points: constructing HTTP request bodies and parsing JSON responses. These are inherently dynamic operations that need real programming logic. The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain than a few lines of Python/J…

I think you’re misunderstanding. This product doesn’t make sense because the problem itself is not solvable under your given constraints.

Just asking. Which problem? Which constraints?

Re: Build API integrations with SQL and YAML – no SaaS lock-in, no drag-and-drop UIs

#25

Post by tnolet » Mon, Jun 02, 2025, 11:07 AM UTC

maxgrinev wrote: post #20

tnolet wrote: post #12

But, this is just leaky abstractions to the max. You replaced a python code base with adding a layer of YAML on top of it, but then still requiring you to write Python? My IDE will have a stroke parsing this.

You're right about the abstraction concern. The vast majority of the workflow stays in structured YAML - Python is only needed for two specific points: constructing HTTP request bodies and parsing JSON responses. These are inherently dynamic operations that need real programming logic. The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain than a few lines of Python/J…

> The alternatives - proprietary DSLs or visual builders - would be far more complex to learn and maintain

that's where I disagree. Your YAML DSL is far harder to learn and maintain. My code can be tested, iterated, understood by my IDE etc. It's just code.