Files
Alvar San Martin fdd1de37d7 Los precios ahora son coherentes
El precio segun divisas corresponde con el total, la divisa del SET es
la del origen siempre
2026-01-02 11:42:37 +01:00

135 lines
3.5 KiB
Markdown

# Proyecto de automatizacion de desarrollo
Tiene como objetivo levantar un servidor de Webhooks para servir al
desarrollo de shopify de forma local.
Componentes:
- Servidor de webhooks que emite peticiones
- Cliente (servidor express) que escucha al servidor para desarrollo
Objetivos:
- [x] Generar eventos por API REST
- [x] Subscripción a topics por API REST
- [x] Documentación de la API REST con Bruno
- [x] Firma de mesajes con HMAC sha256
- [x] Generar eventos periodicos
- [ ] Generar ordenes de shopify proceduralmente
- [ ] Generar ciclos de vida realistas create -> update -> delete
- [ ] Dockerizar
- [x] Añadir clientes iniciales
Webhooks Soportados:
- [ ] orders/create
- [ ] orders/update
- [ ] orders/delete
Propuestas:
## Requisitos
- Docker (linux) o Docker desktop (widows - WSL)
- Ubuntu 24 o similar
- Terminal bash, zsh, sh o compatible
## Introduccion
El objetivo es tener un grupo compose con
- Una BDD para almacenar ejemplos
- Un servicio que envie peticiones periodicamente
### Docker
Este grupo tiene definida una red externa en el `docker-compose.yaml` que
tiene que coincidir con la red de los demás compose ejecutados, por ejemplo:
```yaml
# Esto tiene que aparecer en el yaml del simulador
name: p-simulador-webhooks
networks:
default:
name: network-test # Tiene que coincidir con el compose objetivo
external: true
```
```yaml
# Esto en el yaml del microservicio
name: sf-shopify-orders
networks:
default:
name: network-test
```
### Ejecución
Para lanzar los contenedores se ejecuta el script `run.local.sh` que va a lanzar
el compose de la carpeta `/development/local`. Habrá que ver para los demás entornos.
### Configuración de envío periódico de webhooks
La configuración de los webhooks se hace en `/src/config/initial_hosts.ts`.
En la constante `INITIAL_EVENTS` están los eventos que se van a emitir periodicamente.
Tienen la estructura:
```ts
export type ScheduledEvent = {
topic: string;
numberOfMessages?: number;
periodMs?: number;
};
```
Un ejemplo sería:
```ts
{
topic: "order/create", // Emite mensajes de tipo order/create
numberOfMessages: -1, // Un numero negativo o indefinido de mensajes, indica que se mandan ilimintados
periodMs: 5000 // 5s entre mensajes, si fuese indefinido el predefinido es 1s
}
```
> El periodo indica el mínimo entre mensajes, puede pasar mas tiempo si la maquina se
> realentiza o si el event loop queda bloqueado.
### Configuración de los host que reciben webhooks
Para añadir un host nuevo se crea un nuevo objeto en la constante `INTIAL_HOSTS` tal que:
```ts
type InitialHost = {
topic: string;
host: string;
port: string;
endpoint: string;
method: "POST" | "PUT" | "DELETE";
secretkey: string;
};
```
Por ejemplo si corremos el servicio en un contenedor llamado `cliente-webhooks`
se tiene que añadir un objeto:
```ts
{
topic: "order/create",
host: "localhost",
port: "3500",
endpoint: "/order/create",
method: "POST",
secretkey: webhooksConfig.apiSecret || "1234",
}
```
Esta configuración implica que ese host va recibir una petición HTTP cada vez que
se emite un mensaje con el topic `order/create`, se va a enviar al puerto `3500`
y al endpoint `order/create` mediante el método `POST`. Tiene un campo
"opcional" para la clave para la firma HMAC, si se quiere usar tiene que
coincidir en el cliente y el servidor, la clave del servidor se puede guardar
en el .env o directamente en el objeto **NO SE DEBEN USAR CLAVES REALES DE PRODUCCIÓN**,
con poner "1234" en los dos servicios la firma ya se hace correctamente.