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.
[ Parent
| on HN ]
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.