• 1. Preámbulo
• 2. Resumen del proyecto
• 3. Objetivos de aprendizaje
• 4. Criterios de aceptación del proyecto
• 5. Stack de tecnologías
• 6. Boilerplate
• 7. Pistas, tips y lecturas complementarias
• 8. Hacker edition

De acuerdo con Wikipedia, la internet de las cosas (IoT, por sus siglas en inglés)​ es un concepto que se refiere a una interconexión digital de objetos cotidianos con internet. Constituye un cambio radical en la calidad de vida de las personas en la sociedad, ofrece una gran cantidad de nuevas oportunidades de acceso a datos, servicios específicos en la educación, seguridad, asistencia sanitaria y en el transporte, entre otros campos.

En logística y manejo de flota, por ejemplo, se puede hacer seguimiento en todo momento de la ubicación y las condiciones de la carga y los activos mediante sensores inalámbricos conectados a internet que envían alertas en caso de eventualidades (demoras, daños, robos, etc).

La IoT también plantea retos como el almacenamiento, análisis y visualización de la gran cantidad de información que genera. Se calcula que para el 2025 los dispositivos IoT generen 79.4 zettabytes (1 zettabyte equivale a 1 trillón de gigabytes). Como desarrolladoras debemos estar al tanto de estos retos y contribuir para su solución desde nuestra experiencia, conocimiento y ganas de aprender.

En este proyecto construirás la API REST de un Fleet Management Software para consultar las ubicaciones de los vehículos de una empresa de taxis en Beijing, China.

Te entregaremos un poco más de 17 millones de ubicaciones de casi 10 mil taxis. Esperamos que como desarrolladora explores nuevas alternativas y técnicas para almacenar y consultar esta gran cantidad de información y puedas garantizar la mejor experiencia de usuaria en tu API REST.

ℹ️ Esta sección será automáticamente generada en el idioma pertinente, a partir de los objetivos de aprendizaje declarados en project.yml, al crear el repo del proyecto para un cohort en particular usando ./scripts/create-cohort-project.js.

Acá puedes ver una lista de todos los objetivos de aprendizaje que contempla nuestra currícula.

La empresa que nos ha contratado ha instalado dispositivos GPS en sus taxis. Estos dispositivos utilizan señales satelitales para determinar con precisión las coordenadas geográficas del taxi. Hasta el momento la información de ubicación se ha almacenado en archivos de texto, sin embargo, no es óptimo consultar la información con esta opción.

Nuestra clienta requiere:

1. Cargar la información de los archivos de texto a una base de datos Postgresql.
2. Desarrollar una API REST que permita consultar, mediante peticiones HTTP, la información almancenada en la base de datos.

El Product Owner nos presenta este backlog que es el resultado de su trabajo con el clientx hasta hoy.

Yo como desarrolladora requiero cargar la información, almacenada hasta ahora en archivos de texto, en una base de datos Postgresql para facilitar su consulta y análisis.

• Desarrollar una Interfaz de Línea de Comando (CLI) que cargue la información de los archivos de texto a la base de datos:

  En el caso de Java

  java UploadGPSData.java <path-to-files> 
  --type=taxis|trajectories
  --dbname=<dbname>
  --host=<hostname>
  --port=<port>
  --username=<username>

  En el caso de NodeJs

  node upload-gps-data.js <path-to-files> 
  --type=taxis|trajectories
  --dbname=<dbname>
  --host=<hostname>
  --port=<port>
  --username=<username>

  Donde los parámetros requeridos son:

  <path-to-files>: especifica el directorio de los archivos a cargar.

  --type=taxis|trajectories: indica el tipo de archivos a cargarse taxis o trajectories.

  --dbname=dbname: especifica el nombre de la base de datos a la que conectarse.

  --host=hostname: especifica el nombre del host de la máquina en la que se está ejecutando la base de datos.

  --port=port: especifica el puerto TCP en el que la base de datos está escuchando conexiones.

  --username=username: especifica el usuario para conectarse a la base de datos.

  Nota: el CLI debe solicitar la contraseña de conexión a la base de datos. Por segurisdad esta no puede ser un parámetro.

• El código de la Interfaz de Línea de Comando (CLI) debe recibir code review de al menos una compañera.
• El código de la Interfaz de Línea de Comando (CLI) debe estar cargado en un repositorio de Github.
• El código de la Interfaz de Línea de Comando (CLI) debe contar con test unitarios.

Yo como clienta de la API REST requiero un endpoint para consultar la última ubicación reportada por cada taxi.

• El endpoint responde para cada taxi la siguiente información: ID, placa, latitud, longitud y fecha y hora.
• El endpoint paginamos los resultados para asegurar que las respuestas sean más fáciles de manejar.
• El endpoint resuelve la solicitud en tiempos de respuesta óptimos que no afectan la experiencia de la usuaria. Nota: debido a la gran cantidad de información, se espera con seguridad tiempos de respuesta lentos si no se plantea una estrategia de optimización la base de datos.

• Se cuenta con una documentación para el endpoint desarrollado especificando método HTTP, url, parámetros, encabezados, códigos HTTP de respuesta y cuerpo.
• El código del endpoint debe recibir code review de al menos una compañera.
• El código endpoint debe estar cargado en un repositorio de Github.
• El código endpoint debe contar con test unitarios y e2e.

Yo como clienta de la API REST requiero un endpoint para consultar todas las ubicaciones de un taxi dado el ID del taxi y una fecha.

• El endpoint responde para el ID del taxi consultado la siguiente información: latitud, longitud y fecha y hora.
• El endpoint paginamos los resultados para asegurar que las respuestas sean más fáciles de manejar.
• El endpoint resuelve la solicitud en tiempos de respuesta óptimos que no afectan la experiencia de la usuaria. Nota: debido a la gran cantidad de información, se espera con seguridad tiempos de respuesta lentos si no se plantea una estrategia de optimización la base de datos.

• Se cuenta con una documentación para el endpoint desarrollado especificando método HTTP, url, parámetros, encabezados, códigos HTTP de respuesta y cuerpo.
• El código del endpoint debe recibir code review de al menos una compañera.
• El código endpoint debe estar cargado en un repositorio de Github.
• El código endpoint debe contar con test unitarios y e2e.

Yo como clienta de la API REST requiero un endpoint para listar todos los taxis.

• El endpoint responde para cada taxi: ID y placa.
• El endpoint paginamos los resultados para asegurar que las respuestas sean más fáciles de manejar.
• El endpoint resuelve la solicitud en tiempos de respuesta óptimos que no afectan la experiencia de la usuaria. Nota: debido a la gran cantidad de información, se espera con seguridad tiempos de respuesta lentos si no se plantea una estrategia de optimización la base de datos.

• Se cuenta con una documentación para el endpoint desarrollado especificando método HTTP, url, parámetros, encabezados, códigos HTTP de respuesta y cuerpo.
• El código del endpoint debe recibir code review de al menos una compañera.
• El código endpoint debe estar cargado en un repositorio de Github.
• El código endpoint debe contar con test unitarios y e2e.

Puedes implementar este proyecto en JavaScript o Java.

Si eliges JavaScript, el siguiente es el stack de tecnologías recomendado:

• Express: como librería para implementar un servidor HTTP.
• Prisma: cómo ORM para facilitar consultas a la base de datos.
• Jest: como framework de pruebas unitarias.
• Superagent: como framework de pruebas e2e.
• Postgresql: como base de datos.

Si eliges Java, el siguiente es el stack de tecnologías recomendado:

• Spring Boot: para crear aplicaciones Java
• Spring Boot Test: para pruebas de integración.
• JUnit: para pruebas unitarias.
• Hibernate: cómo ORM para facilitar consultas a la base de datos.
• Postgresql: como base de datos.

El boilerplate contiene una estructura de archivos como punto de partida:

.
├── .gitignore
├── README.md
└── data
└── docs
└── server

En esta carpeta debes almacenar tanto la data cruda como los scripts que desarrolles para cargar la información de taxis y ubicaciones a la base de datos de tu aplicación.

Acá puedes descargar los archivos con la data cruda:

• fleet-management-software-data-part-1.zip
• fleet-management-software-data-part-2.zip

Los archivos fleet-management-software-data-part-1.zip y fleet-management-software-data-part-2.zip contienen la información de taxis y ubicaciones. Al descomprimirlos se crearán dos carpetas: taxis y trajectories.

En la carpeta taxis encontrarás el archivo taxis.txt. En cada línea del archivo, encontrarás el identificador (ID) y placa de un taxi. La información esta separada entre sí por comas.

En la carpeta trajectories encontrarás 10.357 archivos con extensión txt. Cada archivo contiene las ubicaciones de un taxi. El nombre del archivo corresponde al identificador del taxi. Por ejemplo, el archivo 9557.txt contiene las ubicaciones del taxi con identificador 9557. En cada línea de estos archivos, encontrarás el identificador del taxi (ID), la fecha y hora, latitud y longitud de la ubicación. En una línea, la información está separada entre sí por comas.

La información de taxis y ubicaciones ha sido extraída del proyecto T-Drive: Driving Directions based on Taxi Traces de Microsoft.

En esta carpeta debes almacenar todos los archivos correspondientes al API REST.

La base de datos recomendada para tu aplicación es PostgreSQL. Te recomendamos usar vercel Postgresql para que no tengas que instalar PostgreSQL en tu computadora.

Una vez tengas acceso a una instancia de PostgreSQL, deberás crear tablas en tu base de datos para almacenar la información entregada. Te recomendamos entonces crear dos tablas, una para almacenar la información de taxis y otra para almacenar la información de ubicaciones. Deberás definir las columnas de cada tabla de acuerdo a la información entregada.

Puedes crear una tabla en PostgreSQL usando SQL o Prisma Client si estás usando Prisma.

Una vez hayas creado las tablas en tu base de datos, deberás almacenar en ellas toda la información entregada en archivos TXT. Para ello te recomendamos escribir un CLI en JavaScript o Java. Sin embargo, ten en cuenta que en este proyecto procesarás más de 10 mil archivos y tendras una base de datos con conexiones limitadas. Discute con una coach que estrategias puedes implementar para que ni computadora ni la base de datos mueran en el intento de cargar la información.

Deberás definir y documentar los endpoints de tu API. Debes usar Swagger para esto.

Para una API REST debes definir para cada endpoint entre otras cosas el método HTTP, url, parámetros, encabezados, códigos HTTP de respuesta y cuerpo.

Por ejemplo, en la siguiente figura se define un endpoint para consultar la información de los taxis en la aplicación. El método del endpoint es GET, la url es /taxis. Recibe un parámetro query, retorna la información con código HTTP 200 en formato json gracias al header Content-type con valor application/json.

Consultar las 780 ubicaciones del taxi con placa ABGB-4538 para el día 2008-02-02 puede tardar alrededor de 10 segundos. Para una usuaria de tu API REST este tiempo es toda una eternidad. ¿Qué estrategias puedes implementar para reducir los tiempos de respuesta y mejorar la experiencia de usuaria?

Algunas estrategias que podrías intentar son:

• Crear índices sobre la tabla de ubicaciones.
• Implementar un esquema de particionamiento sobre la tabla de ubicaciones.
• Consultar y visualizar progresivamente la información en lotes.

Discute con una coach cada una de estas estrategias y encuentra otras que puedas usar para mejorar el performance de tu aplicación.

Para la hacker edition de este proyecto te invitamos a agregar la funcionalidad la siguiente historia de usuaria:

Yo como clienta de la API REST requiero un endpoint para exportar en formato Excel todas las ubicaciones de un vehículo en una fecha específica.

• El endpoint proporcia un archivo en formato excel con la siguiente información: ID, placa, latitud, longitud y fecha y hora.
• El endpoint resuelve la solicitud en tiempos de respuesta óptimos que no afectan la experiencia de la usuaria. Nota: debido a la gran cantidad de información, se espera con seguridad tiempos de respuesta lentos si no se plantea una estrategia de optimización la base de datos.

• Se cuenta con una documentación para el endpoint desarrollado especificando método HTTP, url, parámetros, encabezados, códigos HTTP de respuesta y cuerpo.
• El código del endpoint debe recibir code review de al menos una compañera.
• El código endpoint debe estar cargado en un repositorio de Github.
• El código endpoint debe contar con test unitarios y e2e.

Tal vez la primera alternativa que se te ocurra sea agregar un endpoint a tu API que reciba como parámetro el vehículo y la fecha y retorne un archivo de Excel para descargarlo desde el navegador web. Sin embargo, esta opción suele ser muy lenta. Por ejemplo la generación y descarga del archivo de Excel con las 33 mil ubicaciones del vehiculo DHOA-9863 para el día 2008-02-27 puede tardar varios segundos, afectando la experiencia de las usuarias que usualmente son impacientes.

Los tiempos de respueta de esta funcionalidad puede mejorarse si el archivo de Excel no se descarga en línea sino que se envía a un correo electrónico. Discute con una coach como podrías implementar esta alternativa y que otras estrategias existen.