Hoy os voy a explicar por qué vuestra API REST hecha en Go, optimizada a mas no poder, escalada y balanceada en AWS, con SLA de 389% tarda 475ms en responder, mientras que el cutre-api.php de @MarcosBL escupe JSONs en 7ms. Dentro hilo! ⬇
Todo empieza cuando vuestra página web le hace una petición a la API ™. Unos cuantos pobres bytes empaquetados que tienen por delante mas camino que Frodo.
La primera parada es el Internet Gateway de AWS. Majestuoso como Los Argonath, observando quién entra y quién sale.
Luego pasamos al WAF, puesto ahí por el CSO de la empresa. Ese WAF hace años que no filtraría ni el SQLi más básico porque el departamento de marketing consiguió meter un WordPress (con sus 93 plugins desactualizados), así que las reglas del WAF se tuvieron que aflojar (...)
(...) hasta el punto de convertirlo en un reverse proxy.
Pero oye, está ahi porque "es mejor eso que nada".
Aquí empieza lo bueno: Kubernetes! No podía ser de otra manera, pasamos por Træfik, el Ingress. Esto viene a ser otro reverse proxy, pero más chulo, porque puede (y debe) evaluar todas tus reglas metidas después de leerte fragmentos sueltos del Quick-HowTo de la documentación.
El Træfik nos manda a un nodo (Pod), que viene a ser otra maquina (porque claro, esta API está escalada en horizontal, vertical y en diagonal)...
Y dentro del nodo llegamos al Kubelet. Que a su vez nos manda al Container Runtime (que viene a ser un contenedor de Docker). Que a su vez nos redirecciona al "OS" dentro del contenedor. Que a su vez nos redirecciona a la API hecha en Go.
Y ahí esta, tu código en Go, majestuoso, nativo, potente, listo para exprimir hasta la última gota de todos los ciclos de CPU que puedan ofrecerle las 5 o 6 capas de virtualización sobre las que se está ejecutando.
"Ya hemos acabado?"
No, pequeño saltamontes. Todavía estamos empezando!
Ahora que la petición le ha llegado a la API, esta se tiene que conectar al Redis y a la base de datos para generar la respuesta.
Solo unos cuantos saltos en sentido contrario: OS del container ➡ Kubelet ➡ Nodo central de Kubernetes / Træfik. Y luego otros tantos para llegar a la máquina del Redis / base de datos. ... Y otras tantos saltos para traer de vuelta los datos.
Y ya por fin, hacemos el recorrido entero una última vez, en sentido contrario, hasta llegar al navegador de dónde salieron esos pobres paquetes en forma de petición. Si llegan a saber el recorrido que tendrían que recorrer, se habrían tomado Biodramina.
Ah, si. Casi se me olvidaba. El cutre-api.php de @MarcosBL es un VPS de 3€ en @OVH . Redis, base de datos y PHP, todo metido en el mismo sitio, a pelo.
Ni contenedores, ni balanceadores, ni escaladores, ni aceleradores, ni optimizadores, ni troceadores, ni filtradores. Haces la petición, el PHP la mastica y la escupe.
Y ya esta.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
"¿Para qué sirven los regex?" os preguntáis. Os lo explico con ejemplos prácticos! Hilo va ⬇
Los regex sirve para buscar cosas sin saber qué estas buscando exactamente. Es como cuando de pequeño jugabas al Lego y necesitabas una cosa que encajase en esa otra cosa, para poder juntar las 2 cosas; así que tirabas el cubo entero de lego y te ponías a buscar.
"Pero cómo voy a buscar algo sin saber qué estoy buscando?"
Es fácil. Tu ponte que tu jefe te dice "quiero que valides este campo de URL para que la gente no pueda meter otra cosa que no sea una URL".
Ahi tienes 2 opciones. Dejarle al usuario meter lo que quiera y luego (...)