Coder Social home page Coder Social logo

1c23-tp-1's Introduction

Hi there 👋

  • 🏳️‍🌈 Pronouns: he/him
  • 🔭 I’m currently working as .Net Web Developer at Okapii
  • 🌱 In my spare time I'd love to improved some of my skills on front-end or back-end or learn a new tech

mrti259's GitHub stats Top Langs

1c23-tp-1's People

Contributors

astrocinco avatar mdascan avatar mrti259 avatar sotlucas avatar tlofano avatar

Watchers

 avatar  avatar  avatar

1c23-tp-1's Issues

Separar en distintos archivos los controllers de cada endpoint

Esto es que desde el archivo principal, en la definición del router, se llame a un controller (que debe estar en otro archivo), para la ejecución del endpoint

Ej:

import { metarController } from './controllers';

router.get('/metar?station=<code>', metarController);

Solo crear la estructura, sin la implementación

Implementar endpoint: Space news

Space News

Endpoint: /space_news

Devolveremos solo los títulos de las 5 últimas noticias sobre actividad espacial, obtenidas desde la Spaceflight News API.

Ver documentación de la API

Métricas

Ya implementar esto con métricas

Métricas propias

Deberán generar las siguientes métricas, que se agregarán como gráficos adicionales a los que les damos en el dashboard:

  • Demora de cada endpoint en responder
  • Demora de cada API remota en responder

Pueden usar hot-shots

Táctica Rate limiting: Useless fact

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=rate_limit

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Rate limiting

Deberán experimentar con una solución que limite el rate de consumo de la API. Pueden ver express-rate-limit o cómo hacerlo con nginx. No es necesario que prueben ambas, alcanza con una.

Táctica Rate limiting: METAR

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=rate_limit

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Rate limiting

Deberán experimentar con una solución que limite el rate de consumo de la API. Pueden ver express-rate-limit o cómo hacerlo con nginx. No es necesario que prueben ambas, alcanza con una.

Crear informe base

Es responsabilidad de quien tome esta tarea debatir con el equipo con que herramienta vamos a hacer el informe (Google Docs, Markdown, etc)

Esta tarea es crear el archivo inicial del informe, con carátula, índice e introducción (o las cosas que fueran necesarias)

Táctica cache: Useless fact

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=cache

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Caché

Utilizarán Redis como caché (ver redis)

La idea es que elijan la estrategia más apropiada para llenar, conservar y vaciar la información del caché según estos criterios:

  • Aplicación: Esta información, ¿es cacheable?
  • Tamaño: Cuántos ítems almacenar en el caché.
  • Llenado: Decidir entre
    • Active population: Incorporar la información al caché antes de que la solicite el cliente.
      • ¿Se puede traer información cada cierto tiempo para tener algo que darle al cliente?
    • Lazy population: Incorporar la información cuando la pide el primer cliente.
  • Tiempo de vida: Cuánto tiempo debe permanecer el dato en el caché antes de ser eliminado. Depende de si la información que almacenamos expira (deja de tener validez por paso del tiempo) o puede estar permanentemente / hasta ser accedida por alguien.
  • Vaciado: Si tomo un ítem del caché, ¿debo eliminarlo o debe permanecer para otro pedido?

Implementar endpoint: METAR

METAR

Endpoint: /metar?station=<code>

Ejemplo: /metar?station=SAEZ (para el Aeropuerto de Ezeiza)

Un METAR es un reporte del estado meteorológico que se registra en un aeródromo. Se lo codifica en un string, por ejemplo:

KDEW 111218Z AUTO 20010KT 10SM -RA SCT012 BKN020 OVC033 06/05 A2981 RMK AO2 P0002 T00610050

Interpretación de algunos campos:

  • KDEW: Código del aeródromo (Deer Park Airport)
  • 20010KT: Viento de 10 nudos desde la dirección 200
  • 10SM: Visibilidad de 10 millas
  • -RA: Lluvia leve
  • SCT012: Nubes dispersas a 1200 pies
  • BKN020: Parcialmente nublado a 2000 pies
  • OVC033: Cubierto a 3300 pies
  • T00610050: Temperatura de 6,1 grados y punto de rocío de 5 grados

Nuestro servicio recibirá un código OACI de un aeródromo y delegará la consulta a la NOAA Text Data Server API (ver ejemplos). Solicitaremos la información en formato XML y la convertiremos a JSON para entregarla a nuestro cliente. Podemos hacerlo así:

//Importamos los componentes necesarios
const axios = require('axios');
const { XMLParser } = require('fast-xml-parser');
const { decode } = require('metar-decoder');

const parser = new XMLParser();

...

//Consultamos a la API de NOAA
const response = await axios.get(`https://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=metars&requestType=retrieve&format=xml&stationString=${station}&hoursBeforeNow=1`);
//Convertimos el XML obtenido a JSON, por conveniencia
const parsed = parser.parse(response.data);
//Decodificamos el METAR
decode(parsed.response.data.METAR.raw_text);

Importante: El ejemplo anterior es solo una manera de hacerlo, pueden utilizar la que prefieran. No se están contemplando situaciones de error (METAR vuelve vacío, error de conexión a NOAA, error de parseo, etc.), que sí deberían ser contempladas por ustedes, devolviendo un error apropiado al cliente.

Métricas

Ya implementar esto con métricas

Métricas propias

Deberán generar las siguientes métricas, que se agregarán como gráficos adicionales a los que les damos en el dashboard:

  • Demora de cada endpoint en responder
  • Demora de cada API remota en responder

Pueden usar hot-shots

Táctica cache: Space news

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=cache

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Caché

Utilizarán Redis como caché (ver redis)

La idea es que elijan la estrategia más apropiada para llenar, conservar y vaciar la información del caché según estos criterios:

  • Aplicación: Esta información, ¿es cacheable?
  • Tamaño: Cuántos ítems almacenar en el caché.
  • Llenado: Decidir entre
    • Active population: Incorporar la información al caché antes de que la solicite el cliente.
      • ¿Se puede traer información cada cierto tiempo para tener algo que darle al cliente?
    • Lazy population: Incorporar la información cuando la pide el primer cliente.
  • Tiempo de vida: Cuánto tiempo debe permanecer el dato en el caché antes de ser eliminado. Depende de si la información que almacenamos expira (deja de tener validez por paso del tiempo) o puede estar permanentemente / hasta ser accedida por alguien.
  • Vaciado: Si tomo un ítem del caché, ¿debo eliminarlo o debe permanecer para otro pedido?

Caso base: Useless fact

Esto es recopilar información del caso base para poder tomarlo como punto de comparación de las tareas siguientes.

Caso base
El caso base existe solo para tomar como referencia y poder verificar si hay mejoras con las tácticas aplicadas.

Caso base: Space news

Esto es recopilar información del caso base para poder tomarlo como punto de comparación de las tareas siguientes.

Caso base
El caso base existe solo para tomar como referencia y poder verificar si hay mejoras con las tácticas aplicadas.

Implementar endpoint: Useless fact

Useless fact

Endpoint: /fact

Devolveremos 1 hecho sin utilidad por cada invocación a nuestro endpoint, obtenido desde uselessfacts. Debe evitarse entregar el mismo hecho cada vez (salvo que lo repita la API remota).

Métricas

Ya implementar esto con métricas

Métricas propias

Deberán generar las siguientes métricas, que se agregarán como gráficos adicionales a los que les damos en el dashboard:

  • Demora de cada endpoint en responder
  • Demora de cada API remota en responder

Pueden usar hot-shots

Táctica Rate limiting: Space news

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=rate_limit

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Rate limiting

Deberán experimentar con una solución que limite el rate de consumo de la API. Pueden ver express-rate-limit o cómo hacerlo con nginx. No es necesario que prueben ambas, alcanza con una.

Táctica cache: METAR

Quizás podamos agregarle un query param más al endpoint que nos permita elegir esta táctica sobre las otras. Ej:

/metar?station=<station_code>&tactic=cache

Está tarea es la implementación de dicha tactica, tal cual como pide la consigna. Es responsabilidad de quien tome esta tarea plasmar las conclusiones en el informe, o crear una tarea para luego escribir las conclusiones y análisis correspondientes

Caché

Utilizarán Redis como caché (ver redis)

La idea es que elijan la estrategia más apropiada para llenar, conservar y vaciar la información del caché según estos criterios:

  • Aplicación: Esta información, ¿es cacheable?
  • Tamaño: Cuántos ítems almacenar en el caché.
  • Llenado: Decidir entre
    • Active population: Incorporar la información al caché antes de que la solicite el cliente.
      • ¿Se puede traer información cada cierto tiempo para tener algo que darle al cliente?
    • Lazy population: Incorporar la información cuando la pide el primer cliente.
  • Tiempo de vida: Cuánto tiempo debe permanecer el dato en el caché antes de ser eliminado. Depende de si la información que almacenamos expira (deja de tener validez por paso del tiempo) o puede estar permanentemente / hasta ser accedida por alguien.
  • Vaciado: Si tomo un ítem del caché, ¿debo eliminarlo o debe permanecer para otro pedido?

Métricas: Space news

Métricas propias

Deberán generar las siguientes métricas, que se agregarán como gráficos adicionales a los que les damos en el dashboard:

  • Demora de cada endpoint en responder
  • Demora de cada API remota en responder

Pueden usar hot-shots

Caso base: METAR

Esto es recopilar información del caso base para poder tomarlo como punto de comparación de las tareas siguientes.

Caso base
El caso base existe solo para tomar como referencia y poder verificar si hay mejoras con las tácticas aplicadas.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.