Proposal for future zato: swappable http server?

Please consider this only a theoretical discussion.

I’ve had some time in late 2017 to experiment with Zato 2 and 3 i various contexts.

A I had an idea that it could be interesting to use zato core (services) more like a general python library for services to be used with python code in general, with web admin optional. And, also with gunicorn/gevent http and events optional.

The goal in the latter (making gunicorn/gevent http and events optional) could, at least from my perspective, make zato services as a framework usable in more contexts. It could be a stand alone system as zato is already now, with native python http server/events. Or it could interface with other http/event servers in some standard fashion. This could open up making zato able to leverage more performant http/event servers, and create some avenues for integrated with other SOA/Microservices systems. It could also potentially allow zato to be used in contexts like serverless computing (aws lambda, openwhisk).

Please consider these just ideas, and I can understand if they don’t seem like a good fit with vision and roadmap. Just sharing some thinking here at this point.

Hi @samuel.rose - where in particular would you like to deploy services on? Such a change would have to be tackled on a backend-by-backend basis, there is no standard fashion.

Most likely not using web-admin would be the easier part and the server side would need to be ported to each backend separately. But what backends were you thinking of particularly in addition to Lambda and OpenWhisk?