4 ms·
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: construc
by maxgrinev 1y ago
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.
- zarathustreal 1y agoI think you’re misunderstanding. This product doesn’t make sense because the problem itself is not solvable under your given constraints.
- pan69 1y agoJust asking. Which problem? Which constraints?
- tnolet 1y ago> 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.