(Migrated) Zato as application server?

(This message has been automatically imported from the retired mailing list)

Here is another conceptual question about how best to apply Zato.

Suppose I’m writing a new backend application from scratch - for the
sake of argument, let’s say it’s customer management. So I start by
designing and implementing new APIs for “create customer”, “retrieve
customer”, “update customer” etc. And I’ve decided I want to write it in
Python.

Having seen Zato, my natural inclination is to write the code directly
within the corresponding Zato handlers. I can open a database connection
within a handler^1, so I can implement all the application logic there
(validation, database queries etc). I could abstract this a bit by
putting the code in a ‘libcrm’ python package, and have the Zato
handlers call this; then libcrm is testable separately from Zato.

My question is: is this a sensible use of Zato? Or should I be deploying
a completely separate CRM application in its own server process?

In the former case, I get a bunch of Zato features for free like
hot-deploy, HA load balancing and query statistics; Zato becomes an
application server. Potentially multiple apps can be deployed on it. In
the latter case I have to handle the application deployment myself, and
if I front it with Zato, Zato is little more than a proxy.

In both cases I believe I can compose higher-level APIs, since Zato is
able to invoke local services^2 as well as make outgoing connections^3

Is there a ‘best practice’ in this area?

Thanks,

Brian Candler.

https://zato.io/docs/progguide/patterns/invoke-retry.html

Aside:
https://zato.io/docs/progguide/service-dev.html#progguide-write-service-invoke
says " The service is invoked in the same operating system’s process and
thread the current service is in", so presumably it’s a direct method call.

This is as opposed to AnyServiceInvoker which uses HTTP.
https://zato.io/docs/progguide/clients/python.html

Hi Brian,

Based on my experience as a user, not only is Zato a reliable choice
when building a backend, but actually a smart one.

And the reason is its SOA nature: a part from being able to offer
Services to the outside in a “cross-system architecture”, its internals
based on services make it also possible to design and implement the
functionalities in a service orchestration fashion.

So, at least in my case, this has several advantages, such as being able
to easily reuse parts of code, having parallel and distributed computing
"out of the box" as well as the ability to spawn new threads to finish
processing inputs asyncronously, the centralized configuration
management, etc.
On top of that, I also coupled it with detailed statistics being
inserted into MongoDB (a part from the ones that zato natively inserts
into Redis), so the result is a very robust system, where I can track
any error in minutes, since I know exactly for every request which steps
it did inside our system, what the exact request and response were, the
response times for each service invoked, etc.

And regarding drawbacks, I found none (yet) :slight_smile:

I hope this helps!

Regards,
Carles

El 12/02/15 a les 11:30, Brian Candler ha escrit:

Here is another conceptual question about how best to apply Zato.

Suppose I’m writing a new backend application from scratch - for the
sake of argument, let’s say it’s customer management. So I start by
designing and implementing new APIs for “create customer”, “retrieve
customer”, “update customer” etc. And I’ve decided I want to write it in
Python.

Having seen Zato, my natural inclination is to write the code directly
within the corresponding Zato handlers. I can open a database connection
within a handler^1, so I can implement all the application logic there
(validation, database queries etc). I could abstract this a bit by
putting the code in a ‘libcrm’ python package, and have the Zato
handlers call this; then libcrm is testable separately from Zato.

My question is: is this a sensible use of Zato? Or should I be deploying
a completely separate CRM application in its own server process?

In the former case, I get a bunch of Zato features for free like
hot-deploy, HA load balancing and query statistics; Zato becomes an
application server. Potentially multiple apps can be deployed on it. In
the latter case I have to handle the application deployment myself, and
if I front it with Zato, Zato is little more than a proxy.

In both cases I believe I can compose higher-level APIs, since Zato is
able to invoke local services^2 as well as make outgoing connections^3

Is there a ‘best practice’ in this area?

Thanks,

Brian Candler.

https://zato.io/docs/progguide/patterns/invoke-retry.html

Aside:
https://zato.io/docs/progguide/service-dev.html#progguide-write-service-invoke
says " The service is invoked in the same operating system’s process and
thread the current service is in", so presumably it’s a direct method call.

This is as opposed to AnyServiceInvoker which uses HTTP.
https://zato.io/docs/progguide/clients/python.html

This is a most interesting line of thinking. Thank you both for sharing
this!

On Thu, Feb 12, 2015 at 12:18 PM, Coeuz coeuz@coeuz.net wrote:

Hi Brian,

Based on my experience as a user, not only is Zato a reliable choice
when building a backend, but actually a smart one.

And the reason is its SOA nature: a part from being able to offer
Services to the outside in a “cross-system architecture”, its internals
based on services make it also possible to design and implement the
functionalities in a service orchestration fashion.

So, at least in my case, this has several advantages, such as being able
to easily reuse parts of code, having parallel and distributed computing
"out of the box" as well as the ability to spawn new threads to finish
processing inputs asyncronously, the centralized configuration
management, etc.
On top of that, I also coupled it with detailed statistics being
inserted into MongoDB (a part from the ones that zato natively inserts
into Redis), so the result is a very robust system, where I can track
any error in minutes, since I know exactly for every request which steps
it did inside our system, what the exact request and response were, the
response times for each service invoked, etc.

And regarding drawbacks, I found none (yet) :slight_smile:

I hope this helps!

Regards,
Carles

El 12/02/15 a les 11:30, Brian Candler ha escrit:

Here is another conceptual question about how best to apply Zato.

Suppose I’m writing a new backend application from scratch - for the
sake of argument, let’s say it’s customer management. So I start by
designing and implementing new APIs for “create customer”, “retrieve
customer”, “update customer” etc. And I’ve decided I want to write it in
Python.

Having seen Zato, my natural inclination is to write the code directly
within the corresponding Zato handlers. I can open a database connection
within a handler^1, so I can implement all the application logic there
(validation, database queries etc). I could abstract this a bit by
putting the code in a ‘libcrm’ python package, and have the Zato
handlers call this; then libcrm is testable separately from Zato.

My question is: is this a sensible use of Zato? Or should I be deploying
a completely separate CRM application in its own server process?

In the former case, I get a bunch of Zato features for free like
hot-deploy, HA load balancing and query statistics; Zato becomes an
application server. Potentially multiple apps can be deployed on it. In
the latter case I have to handle the application deployment myself, and
if I front it with Zato, Zato is little more than a proxy.

In both cases I believe I can compose higher-level APIs, since Zato is
able to invoke local services^2 as well as make outgoing
connections^3

Is there a ‘best practice’ in this area?

Thanks,

Brian Candler.

https://zato.io/docs/progguide/patterns/invoke-retry.html

Aside:

https://zato.io/docs/progguide/service-dev.html#progguide-write-service-invoke

says " The service is invoked in the same operating system’s process and
thread the current service is in", so presumably it’s a direct method
call.

This is as opposed to AnyServiceInvoker which uses HTTP.
https://zato.io/docs/progguide/clients/python.html