Note - This post is intended to look for feedback in a tool that solves a problem we have been seeing (around API clients not supporting Python) - and hopefully help Python folks (like it helped us when building it).
So, a bit of a backstory - Something I noticed while we were building our internal tool for API testing: A lot of developer tools assume JavaScript scripting by default. API clients are a good example of this.
scripting = JavaScript
And yes it might not be always a huge problem, but it adds constant friction.
Eventually we realized the real issue was not just JavaScript. The issue was and is that many tools force a single language.
So when we started building our own API client (link below), we decided to approach scripting differently: Pre-request and post-request scripts support multiple languages and runs on real interpreters, not a limited sandbox like most Clients do.
So we built this to support Python and JS from day 1 and now releasing shell script + more coming (perhaps Go would be the next??)
The idea is simple: Your API tool should adapt to your stack, not the other way around.
Some developers think in JS, some in Python, some in Go or Rust.
The tool shouldn’t care.
Q: Would you actually use Python for request automation inside an API client, or do you prefer handling that logic outside the tool?
In a heartbeat. I hate writing JS.
thats true right? we are also coming from the same boat.
btw now we are adding shell script as well…different devs need different capabilities.
so did you try Voiden? anything interesting or any feedback to share ?
Yes, I would prefer Python over JS, but both are on the very bottom of what I would like to use or what is even preferable for my IRL projects at work.
cool - what would then be on the very top of what you would like to use? :)
I would prefer Java, bash or for my projects at work PHP, but I understand some ppl prefer JS, because their app will use JS to use the API.
you can keep an eyes on our github issues cause these languages will come soon!
thanks for sharing!
It sounds like you’re coming up against the classic SDK problem. You’ve got something that you want to integrate with someone else’s stuff, and you can’t assume that they’re working in the same language as you are. If you want adoption by
${LANGUAGE}developers, you have to support${LANGUAGE}programmatically.Personally, if a tool is Javascript-only that’s a hard pass for me cause Javascript and I have known each other for nearly 30 years and we hate each other with considerable fire. Support for Python on the other hand scores serious points for me.
Honestly, if you’re developing a product that’s targetting local platforms, favouring Python is really your best choice because there’s a very large portion of the world that has some version of Python on their machine. Even the poor bastards running Windows can have it on there sometimes. Moving up to the compiled languages like Rust, Go, and C/C++ are likely to get less traction 'cause frankly doing even small things in these languages is more complicated than doing it in Python, Ruby, Javascript, or even Bash. Given that these pre/post running scripts are likely to be in the form of “parse this response string and do
${thing}” languages that favour “quick & dirty” over “performant and correct” are a good first choice for support. If you have a lot of Windows users, you may even want to support… whatever it is they do in Windowsland.If however your users are likely to want to do something grander, like hook your project directly into their Very Large Codebase Doing Interesting Things, then building in support for those more demanding languages may be worthwhile… though this seems unlikely for a project like this.
One idea that could save you a lot of pain might be to establish a local file-based API and be done with it. Say for example that you could set it up so that before a request is initiated, Voiden will always execute every script found in
/path/to/some/dirand pass into it a series of arguments. Similarly when a response is received it’ll trigger every script found in/path/to/some/other/dirand pass into it the response data. Now, even if the user wants to write these handlers in Haskell, you don’t care. The API is the same: “we call your script and pass it these arguments”.
