But is it performant? People use and do many things that are awful in production, so that's not really an objective plus. Also; not that many systems need that much optimised performance, so it might be ok to be slow if there are many nice features that are more important.
In real-world, business and enterprise situations, which is where Zato is used, about 99% of latency comes from the backend systems that your API integration platform integrates.
These are all the databases, CRMs, IoT, cloud and other software or hardware components that you'll be integrating.
Whether you use Python or not, they're always going to be the culprits.
That it's very convenient to integrate complex systems in Python is what does matter though.
Consider that a network of hospitals, an airport, or a telecommunications operator will have at least 50-500 different sorts of systems to integrate, and to do it properly you need to have a team of at least 6-10 people working for several years.
Looking at it from that perspective, taking the whole enterprise into account, Python is the only choice.
It's easy to find people with backend experience who will be eager to work on API-heavy projects, new people leaving universities know primarily Python, and the kinds of complex business logic that is needed to handle such scenarios are best expressed in a very high-level language.
Here's a few articles for you to explore this subject further:
Asking about performance, “production”, fast/slow/okay, etc is all relative and whole depends on what volume of traffic you get in production and your latency demands; without including a few ballpark numbers the conversation is pointless.
A lot of people on HN say things like “for 99% of production apps Postgres is perfect”, but I consider Postgres a bit lackluster because above that scale it’s more annoying to manage than “worse” dbs like MySQL. The difference in our takes is because my “production” needs look very different from their “production” needs.
(I personally wouldn’t put an interpreted GC language in the request pathway for my production app; we sometimes use Cloudflare functions which are JS, but a very heavily optimized JS runtime and even that is a bit concerning)
I agree with you, and also about the Postgres part. And that was my point: if it's performant enough or not depends on the use case; it's just here on HN everyone thinks they 'will make it' (something something facebook/google etc scale) while they won't. So then anything works fine, because you have got no traffic or data at any significant volume.
To be honest, I don't want to make a career out of it and I didn't plan it for this project, I just needed a tool like this, so I wrote it because I was tired of configuring Apache :) I thought it might be useful to someone else, so I published it here. Thanks, I just had to say it
Request Time: The average request time in all tests is about the same, ranging from 0.006 to 0.007 seconds. Max request time does increase with more requests; it peaks for the most substantial test of 100,000 requests at 0.136 seconds, which does show that some requests take much longer.
Requests per Second: The number of requests per second is highest in the smaller tests, around 143 RPS for the 10 requests, whereas for 100,000 requests it goes down to about 122 RPS. A probable conclusion in this case could be that while increasing the number of requests, some little slowdown starts to develop in the system.
Percentiles: The median, which usually stands at approximately 0.0035 seconds, essentially means half of the requests are done in under that time. The far higher values of the 90th and 99th percentiles just prove that while most of the requests may be fast, the others take considerably longer.
In general, it performs quite well under a reasonable load but biffs a bit if the number of requests is increased.