Skip to content

Flujo de Creación de Shifts en Switchain

Resumen General del Flujo (Común a V1, V2, V3)

Independientemente de la versión, la creación de un shift sigue estos pasos generales, orquestados principalmente por ShiftsHelpers.create:

  1. Recepción de Datos: La API recibe los datos del shift (par, direcciones, monto, etc.).
  2. Validación: Se validan los datos de entrada, incluyendo las direcciones de criptomonedas.
  3. Cálculo de Tarifas/Tasa: Se determina la tasa de cambio y las tarifas aplicables (spread, partner, minero). Aquí es donde radican las diferencias principales entre versiones.
  4. Validación de Límites: Se comprueba que el monto está dentro de los límites permitidos.
  5. Obtención Dirección Depósito: Se genera o asigna una dirección única para que el usuario deposite los fondos.
  6. Comprobación KYT: Se evalúa el riesgo de las direcciones involucradas.
  7. Creación en BD: Se guarda el nuevo documento "Shift" en la base de datos con estado inicial.
  8. Inicio Supervisión: Se lanza un proceso/trabajo para monitorizar el depósito y el resto del ciclo de vida del shift.
  9. Respuesta: Se devuelve la información del shift creado a la API.

Desglose por Versión y Archivos Clave

Creación V3

  • Punto de Entrada API: POST /rest/v3/order definido en interface/imports/api/restapi/server/restApiV3.js.
  • Lógica Intermedia: Llama a Resolvers.createOrder (en interface/imports/api/restapi/server/generalApiResolvers.js) pasando explícitamente apiVersion: 'v3'.
  • Lógica Central: Resolvers.createOrder llama a ShiftsHelpers.create (en admin/imports/api/shifts/server/shiftsHelpers.js) con apiVersion: 'v3'.
  • Comportamiento Clave V3: Dentro de ShiftsHelpers.create y las funciones que llama (como calculateRateFeesByAppIdV2 en lambdas/common/profitability/profitabilityHelpersCommon.js), se utiliza una clave compuesta (pair:chainPair) para buscar configuraciones específicas (como el spread/ownFee), permitiendo tarifas dependientes de la cadena.

Creación V2

  • Punto de Entrada API: POST /rest/v2/order definido en interface/imports/api/restapi/server/restApiV2.js.
  • Lógica Intermedia: Llama a Resolvers.createOrder (en generalApiResolvers.js) sin pasar apiVersion, por lo que createOrder usa su valor por defecto 'v2'.
  • Lógica Central: Resolvers.createOrder llama a ShiftsHelpers.create (en shiftsHelpers.js) con apiVersion: 'v2'.
  • Comportamiento Clave V2: Dentro de ShiftsHelpers.create y las funciones llamadas (como calculateRateFeesByAppIdV2), se utiliza una clave simple (pair) para buscar configuraciones (spread). Introduce la lógica para aplicar minerFee personalizadas por appId (leída desde la colección Applications).

Creación V1 (Basado en análisis previo)

  • Punto de Entrada API: Probablemente una ruta más antigua (no en un archivo restApiV1.js dedicado) que llama a Resolvers.createSWOrder.
  • Lógica Intermedia: Resolvers.createSWOrder (en generalApiResolvers.js). Esta función no parece manejar apiVersion.
  • Lógica Central: createSWOrder probablemente llama a ShiftsHelpers.create (en shiftsHelpers.js) sin pasar apiVersion, por lo que ShiftsHelpers.create usa su valor por defecto interno 'v1'.
  • Comportamiento Clave V1: Similar a V2 en usar la clave pair para buscar configuraciones, pero probablemente utiliza funciones de cálculo de tarifas más antiguas (como calculateRateFeesByAppId en lugar de calculateRateFeesByAppIdV2 directamente desde createSWOrder), lo que implica que no tendría la lógica de minerFee personalizada por appId.

Archivos Esenciales para Migrar la Creación de Shifts

Para replicar la funcionalidad de creación de shifts, deberías centrarte principalmente en estos archivos y sus dependencias:

  • admin/imports/api/shifts/server/shiftsHelpers.js: El corazón absoluto. Contiene la función create con la lógica principal de validación, cálculo (aunque delega partes), obtención de dirección, KYT y creación en BD.
  • lambdas/common/profitability/profitabilityHelpersCommon.js: Esencial para V2/V3. Contiene calculateRateFeesByAppIdV2, getSpreadV2, getMinerFeeV2, etc., que encapsulan la lógica de cálculo de tarifas y spread específica de estas versiones.
  • interface/imports/api/restapi/server/generalApiResolvers.js: Contiene los "resolvers" o funciones intermedias (createOrder, createSWOrder) que son llamados por las rutas API y que a su vez llaman a ShiftsHelpers.create. Adapta los parámetros entre la API y el helper.
  • interface/imports/api/restapi/server/restApiV[2/3].js: (Según la versión que migres) Definen las rutas HTTP exactas y cómo conectan con los resolvers del punto anterior.
  • admin/imports/api/shifts/shifts.js: Define el esquema de la colección Shifts en la base de datos. Necesitarás replicar esta estructura.
  • admin/imports/api/pairs/offeredPairs.js: Define el esquema de la colección OfferedPairs, usada para verificar si un par está activo y obtener límites (getLimits llamado desde shiftsHelpers.js).

Dependencias Adicionales Importantes

Necesitarás entender y potencialmente migrar partes de:

  • Validación de direcciones: CoinsHelpers, AssetsHelpers, BlockchainsHelpersCommon.
  • Generación de direcciones de depósito: WalletAddressesHelpersCommon.
  • Comprobaciones KYT: KytHelpersCommon, Kyt.
  • Supervisión post-creación: ShiftsSuperviseHelpers, JobsHelpers.
  • Acceso a datos cacheados/configuraciones: RedisHelpers (spreads, ofertas precisas, etc.).
  • Modelos/Colecciones: Applications (para tarifas personalizadas V2/V3), Assets, Blockchains.
  • Utilidades generales: utils.js (manejo de pares, direcciones, UUIDs, etc.).
  • Constantes: Definiciones de cadenas, mercados, etc.

Resumen Final

Empieza por shiftsHelpers.js y ve siguiendo las llamadas a funciones hacia profitabilityHelpersCommon.js (para tarifas V2/V3) y los helpers de validación, direcciones, KYT, etc. Necesitarás la estructura de datos (shifts.js, offeredPairs.js) y entender cómo se configuran las tarifas y límites (probablemente vía Redis o BD).

Estos archivos han sido copiados en lib-docs/switchain/files/