Version 3.2 Documentation
 

Flux de travail de développement avec Zato

Zato est une plateforme d'intégration et un serveur d'applications backend, ce qui signifie que, dans la plupart de leurs projets, les développeurs qui utilisent Zato s'intéressent à quelques questions spécifiques. projets, les développeurs utilisant Zato s'intéressent à quelques questions spécifiques.

La plate-forme se concentre sur la réponse à ces questions clés, quotidiennes, que les développeurs de backend Python posent couramment :

  • Comment puis-je me connecter à des systèmes externes ou à des bases de données pour stocker ou extraire des données ?
  • Comment faire correspondre des messages d'un format à un autre ?
  • Comment puis-je automatiser mon travail afin qu'il soit reproductible dans tous les environnements ?
  • Comment puis-je me concentrer sur mon travail au lieu de penser à des détails triviaux de bas niveau ?
  • Comment puis-je déboguer mon code ?
  • Comment puis-je réutiliser les compétences et les connaissances que j'ai acquises ailleurs et comment puis-je m'améliorer ?
  • Comment gérer la complexité de l'intégration d'au moins plusieurs systèmes et de dizaines ou centaines d'API ?

Le flux de travail typique

Dashboard

  • Dashboard est une console d'administration basée sur le Web qui vous permet de définir tous les différents pools de connexion, Dashboard est une console d'administration web qui vous permet de définir les différents pools de connexion, les types de sécurité, les tâches du planificateur ou d'autres ressources d'intégration que vous utiliserez plus tard dans vos services API basés sur Python.

  • Lorsque vous installez Zato, il est facile d'utiliser son Dashboard pour définir des ressources telles que les pools de connexion REST, MongoDB ou SOAP, car cela ne nécessite aucune programmation. Il suffit de remplir un formulaire et la ressource est créée.

Python

  • Tout votre code est en Python, ce qui facilite la manipulation de tout type de données que vous recevez ou auxquelles vous pourriez avoir besoin d'accéder.

  • Dans votre code, vous ne vous occupez que de la logique métier - si votre service est invoqué, cela signifie que toutes les couches de sécurité, les sérialiseurs et autres parties de bas niveau ont déjà accompli leur travail et que vous recevez un bel objet métier en Python qui représente votre entrée. Sur la base de ces informations d'entrée, vous créez la sortie que votre logique commerciale vous dicte, tout en travaillant purement sur un haut niveau d'objets Python, sans aucun détail de bas niveau.

  • Le typage statique est encouragé par l'utilisation de classes de données pour vos modèles de données.

  • Votre code est déployé à chaud depuis votre IDE, quel que soit l'emplacement de vos serveurs, par exemple si vous travaillez sur Mac mais que le serveur est une instance Linux distante.

  • Vous pouvez également déboguer vos services à partir de votre IDE et, là encore, le serveur peut être distant.

# -*- coding: utf-8 -*-

# stdlib
from dataclasses import dataclass

# Zato
from zato.server.service import Model, Service

@dataclass(init=False)
class GetClientRequest(Model):
    client_id: int

@dataclass(init=False)
class GetClientResponse(Model):
    name:    str
    email:   str
    segment: str

class GetClient(Service):

    class SimpleIO:
        input  = GetClientRequest
        output = GetClientResponse

    def handle(self):

        # Enable type checking and type completion
        request = self.request.input # type: GetClientRequest

        # Log details of our request
        self.logger.info('Processing client `%s`', request.client_id)

        # Produce our response - in a full service this information
        # will be obtained from one or more databases or systems.
        response = GetClientResponse()
        response.name    = 'Jane Doe'
        response.email   = 'hello@example.com'
        response.segment = 'RNZ'

        # Return the response to our caller
        self.response.payload = response

Un tel service peut être attribué à un ou plusieurs canaux REST et nous pouvons l'invoquer maintenant:

$ curl localhost:17010/api/v1/client -d '{"client_id":123}'
{"name":"Jane Doe","email":"hello@example.com","segment":"RNZ"}
$

Automatisation

  • L'utilisation de Dashboard est très pratique, et, une fois que vous êtes satisfait de ce que vous avez créé en l'utilisant, les ressources peuvent être exportées à partir de la ligne de commande en utilisant un outil intégré appelé enmasse - le résultat est un fichier YAML régulier qui décrit chaque ressource que vous avez créée en utilisant Dashboard.

  • Dans l'étape suivante, un fichier emasse peut être importé dans un nouvel environnement, également à partir de la ligne de commande. Par exemple, vous pouvez continuer à ajouter de nouvelles définitions de connexion au fichier d'exportation chaque jour et elles peuvent être importées dans un environnement de test séparé par les processus de test de régression CI/CD.

  • Grâce au cycle d'exportation et d'importation d'enmasse, vous n'avez pas besoin de recréer manuellement les ressources que vous avez initialement créées dans votre environnement de développement. De plus, comme les fichiers enmasse sont de simples fichiers YAML, vous pouvez scénariser leur utilisation de la manière requise lors de leur importation, par exemple en remplissant les informations d'identification ou d'autres détails par lesquels chaque environnement peut différer.

  • De même, avec votre code Python, vous pouvez commiter votre code dans git et configurer chaque environnement pour le déployer à chaud directement à partir d'un checkout git. Alternativement, le code Python peut être déployé de manière statique, ce qui nécessite un redémarrage du serveur. Cette dernière approche est utile lorsque vous préparez, par exemple, une AMI AWS avec votre solution à partir de laquelle vous créez de nouvelles instances d'exécution, car elle vous permet d'intégrer l'ensemble de votre définition d'enmasse et de votre code directement dans vos AMIs.

OpenAPI

  • Les définitions de vos services peuvent être exportées vers OpenAPI.

  • Notez que, par défaut, vos services peuvent être multi-protocoles - cela signifie que vous pouvez avoir un service qui utilise uniquement des WebSockets, ou peut-être un service d'arrière-plan qui n'a pas de endpoint REST du tout, et pourtant, vous serez toujours en mesure de l'exporter vers OpenAPI.

  • Cela signifie que vous pouvez utiliser n'importe quel outil compatible OpenAPI, tel que Postman, pour accéder et tester vos services API, qu'ils utilisent REST ou non.

  • Vous pouvez également générer un site HTML statique complet qui comprendra l'OpenAPI ainsi que des pages statiques décrivant vos API - ce qui est utile, par exemple, lorsque vous devez partager avec vos partenaires techniques non seulement une définition de l'OpenAPI, mais également un site de documentation de l'API de belle apparence.

Générons une définition OpenAPI pour le service GetClient ci-dessus :

$ zato openapi /path/to/server/server1 \
    --include "client*"                \
    --file /tmp/openapi.yaml

Maintenant, nous pouvons importer la définition OpenAPI dans Postman et invoquer nos services à partir de celle-ci:

Python encore une fois

  • Python est au cœur de Zato et la plateforme vous permet de tirer parti de vos compétences existantes et de votre connaissance des bibliothèques tierces.

  • Par exemple, le code ci-dessous est un programme autonome qui se connecte à Redis pour insérer une clé et la lire :

# -*- coding: utf-8 -*-

# Redis
import redis

# Connect to the database
conn = redis.Redis(host='localhost', port=6379, db=0)

# Set a key ..
conn.set('key', 'value')

# .. read it back ..
result = conn.get('key')

# .. and log what we received.
print('Result', result)
  • Maintenant, la même chose qu'un service basé sur Zato :
# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

class MyService(Service):
    def handle(self):

        # Set a key ..
        self.kvdb.conn.set('key', 'value')

        # .. read it back ..
        result = self.kvdb.conn.get('key')

        # .. and log what we received.
        self.logger.info('Result %s', result)

  • Dans les deux cas, il s'agit exactement de la même quantité de code, mais quelques différences sont notables.

    • Premièrement, parce que la configuration a été créée plus tôt en utilisant Dashboard ou enmasse, votre code n'a pas besoin de se préoccuper de l'emplacement de Redis, il l'utilise simplement.
    • Deuxièmement, déjà à ce stade, votre code Zato est un service API évolutif qui peut être déployé à chaud sur des clusters pour que d'autres systèmes puissent l'invoquer.
    • Pourtant, la logique commerciale réelle, l'utilisation de Redis, est la même, ce qui signifie que vous pouvez réutiliser ce que vous savez déjà et vous appuyer dessus tout en développant avec Zato.

  • Redis n'était qu'un exemple et le même principe s'applique à tout le reste. Qu'il s'agisse de SQL, MongoDB, ElasticSearch, IBM MQ ou de tout autre type de connexion, vous pouvez prendre votre code existant et l'intégrer simplement dans les services Zato.

  • Cela signifie également qu'il est facile de trouver des exemples de programmation spécifiques à un système particulier car, en fin de compte, lorsque vous vous connectez à un tel système externe par le biais de Zato, vous émettez des requêtes en utilisant une bibliothèque qui est déjà largement populaire parmi les programmeurs Python, comme redis-py dans cet exemple ci-dessus.

  • De même, en tant que spécialiste des données, vous avez peut-être déjà développé du code Pandas ou Spark - le même principe s'applique, vous pouvez l'intégrer dans vos services ou l'importer de vos bibliothèques, comme avec du code Python ordinaire.

En savoir plus