News for hackers. Stuff that matters.
Re:Build API integrations with SQL and YAML – no SaaS lock-i... by tnolet on Friday May 30, 2025 @04:01PM (#44139445)
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.

Re:Build API integrations with SQL and YAML – no SaaS lock-i... by maxgrinev on Friday May 30, 2025 @09:02PM (#44141139)
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/JavaScript for JSON manipulation. We actually started with JavaScript since it's more natural for JSON work, but the difference was marginal. Do you have suggestions for a better approach to these two specific dynamic parts? We're open to ideas that would be simpler than Python but still handle the complexity generically.
Re:Build API integrations with SQL and YAML – no SaaS lock-i... by zarathustreal on Friday May 30, 2025 @09:10PM (#44141172)
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-i... by pan69 on Saturday May 31, 2025 @05:11PM (#44146938)
Just asking. Which problem? Which constraints?
Re:Build API integrations with SQL and YAML – no SaaS lock-i... by tnolet on Monday June 02, 2025 @07:07AM (#44157572)
> 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.