(This message has been automatically imported from the retired mailing list)
The Zato docs already provides some good advice on best practices for
using Zato in real life, e.g. here:
https://zato.io/docs/admin/guide/ha.html
https://zato.io/docs/progguide/logging.html
https://zato.io/docs/progguide/debugging.html
https://zato.io/blog/posts/hot-deploy-api-service.html
https://zato.io/blog/posts/apitest-start.html
Maybe we can collect some more tips and best practices here on the
mailing list.
Some of the issue that are still not fully clear to me:
-
How should a minimal productive environment look like? I guess I need
a test/development cluster, maybe a staging cluster and a productive
cluster? -
How should the relation between clusters and physical machines look
like to make things more redundant and performant? Should one cluster
always run on one machine? -
How should the development cluster be configured? I can imagine that
it is better to use only one server so errors appear in one log file,
and not to use a load balancer. -
How should I configure an IDE so that it sees all the packages that a
Zato service can access, e.g. to make use of IntelliSense features? -
How should I version control and backup all the config files,
credentials, start scripts, service module sources, and keep them
separate from the log and pid files? Maybe the quickstart command should
also provide ignore files? Where do I put my own libraries, SQLAlchemy
models and other support files? Changes in zato_extra_paths are only
picked up when the server is restarted, can this be avoided? -
How do I test my services? Are there alternatives or complementary
testing methods to apitest, maybe more like unit tests for service classes? -
How do I document and version my services? It would be great to have
Zato create a central ESB documentation based on docstrings in the
service classes, is something like that possible or planned?
Any advice or recommendations?