> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elata.bio/llms.txt
> Use this file to discover all available pages before exploring further.

# Rutas de integración

> Elija el paquete y el modelo de propiedad adecuados para la integración de un dispositivo.

Utilice esta página antes de escribir el código del adaptador.

El camino correcto depende de si la integración es ampliamente útil, si necesita SDK de proveedor o puentes nativos y si se mantendrá como una superficie de SDK pública.

<a id="recommended-default" />

## Valor predeterminado recomendado

Si es probable que el dispositivo sea útil para una audiencia más amplia del SDK de Elata, colóquelo en `@elata-biosciences/eeg-web-ble`.

Esto mantiene el comportamiento de transporte centralizado y evita adaptadores paralelos entre múltiples aplicaciones.

<a id="choose-by-outcome" />

## Elija por resultado

| Camino | mejor cuando | ¿Por qué? |
| - | - | - |
| Módulo de dispositivo ascendente en `eeg-web-ble` | El dispositivo es muy útil y funciona a través del navegador BLE. | El mejor valor predeterminado para la compatibilidad con SDK público |
| Paquete separado bajo `packages/` | Necesita un SDK de proveedor, una puerta de licencia o un puente local/nativo | Mantiene aisladas las integraciones más pesadas |
| Adaptador de aplicación local | Estás probando un concepto o enviando una integración privada. | Ruta más rápida cuando no se necesita ningún paquete compartido |

<a id="path-1-upstream-in-eeg-web-ble" />

## Ruta 1: aguas arriba en `eeg-web-ble`

Elija esto cuando:

* el dispositivo puede funcionar a través de Web Bluetooth en un navegador
* Es probable que la integración sea reutilizada por más de una aplicación.
* quieres una implementación compartida del comportamiento de transporte

Este camino suele significar:

1. agregar un módulo de dispositivo bajo el paquete BLE
2. reutilizar `BleTransport`
3. agregar pruebas simuladas
4. actualizar documentos del consumidor y notas del dispositivo

<Check>
  Este es el mejor camino para una integración pública y duradera que debería sentirse como una parte de primera clase del SDK.
</Check>

<a id="path-2-separate-package" />

## Ruta 2: paquete separado

Elija esto cuando el dispositivo necesite más que un flujo BLE de navegador limpio.

Razones típicas:

| Situación | Por qué ayuda un paquete separado |
| - | - |
| SDK de proveedor pesado o con licencia | Mantiene dependencias adicionales fuera del paquete BLE principal |
| Ayudante de localhost o puente nativo | Le permite enviar un transporte específico de un puente de forma limpia |
| Cadencia de lanzamiento independiente | Permite que el proveedor o socio sea propietario de las versiones y el soporte |

El paquete aún debería exponer un `HeadbandTransport`, o una envoltura delgada alrededor de uno, para que el código de la aplicación se mantenga consistente con el resto de la pila de Elata.

<a id="path-3-app-local-adapter" />

## Ruta 3: Adaptador local de aplicación

Elija esto cuando la velocidad importe más que la reutilización.

Esta es una buena opción para:

* una implementación de cliente privado
* una prueba de concepto rápida
* trabajo de evaluación antes de que exista un paquete público

Mantenga el contrato igual incluso si el código permanece privado. Eso hace que sea más fácil avanzar hacia arriba más adelante.

<a id="decision-order" />

## Orden de decisión

<Steps>
  <Step title="Preguntar si la integración debería ser reutilizable">
    Si varias aplicaciones se beneficiarían, comience por asumir una ruta ascendente.
  </Step>

  <Step title="Compruebe si hay bloqueadores BLE del navegador">
    Si Web Bluetooth no funciona, o si se requiere un puente nativo, cambie a un paquete separado.
  </Step>

  <Step title="Decidir quién posee el apoyo a largo plazo">
    El apoyo compartido suele pertenecer a las fases anteriores. Las líneas de lanzamiento propiedad de los proveedores a menudo encajan mejor en un paquete separado.
  </Step>

  <Step title="Mantenga estable el contrato de la aplicación">
    No importa dónde se encuentre el código, el contrato de la aplicación debería seguir siendo `HeadbandTransport` y `HeadbandFrameV1`.
  </Step>
</Steps>

<a id="paths-to-avoid" />

## Caminos a evitar

No elija un adaptador de aplicación local sólo porque sea fácil en la primera hora.

Esto normalmente genera trabajo extra más adelante si la integración se hace pública.

Tampoco impulse una integración pesada, basada en puente o con licencia en el paquete BLE compartido. Mantenga el paquete público reducido.

<a id="related-docs" />

## Documentos relacionados

* [EEG Introducción a BLE](/es/sdk/eeg-web-ble/getting-started)
* [Contrato de Transporte](./transport-contract)
* [Implementación del adaptador](./adapter-implementation)
* [Compatibilidad](/es/sdk/operations/compatibility)

<a id="next" />

## Siguiente

<CardGroup cols={2}>
  <Card title="Contrato de transporte" icon="arrow-right" href="./transport-contract">
    Revise las interfaces compartidas que la ruta elegida aún debe satisfacer.
  </Card>

  <Card title="Requisitos de protocolo" icon="arrow-right" href="./protocol-requirements">
    Reúna los detalles del protocolo que necesita antes de que comience la implementación.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.