Header Ads Widget

Ticker

6/recent/ticker-posts

Haciendo API rápidas: lecciones aprendidas de 40 años de SQL


 SQL es antiguo , de hecho, tiene unos 40 años . En el mundo de la tecnología, donde un nuevo marco o lenguaje aparece aparentemente todos los días, 40 años se sienten francamente arcaicos. ¿Por qué un lenguaje tan antiguo es relevante para la creación de API en 2018?

Debido a que SQL es tan antiguo, tiene una larga historia de la que aprender. Joakim Lundborg , científico de datos e ingeniero, señala que “SQL es un lenguaje de cuarta generación. Le da al usuario de esta 'API' (si la considera una API) control total sobre qué datos están obteniendo. Y si observa lo que ha estado sucediendo en el espacio de la API durante los últimos dos años, tanto con GraphQL como con otras cosas como una API JSON ... obtendrá más control sobre los campos que está obteniendo ".

Para Joakim, los paralelismos entre SQL y las tendencias actuales de desarrollo de API son claros. Las API están dando más control a las aplicaciones y a los consumidores de API. Hay menos dependencia de las definiciones estrictas de API, como lo han proporcionado históricamente las API REST. En cambio, los consumidores pueden elegir exactamente lo que desean obtener en función de sus necesidades particulares. Esto es muy similar a los patrones de acceso que se utilizan al acceder directamente a bases de datos SQL. Esto significa que esos 40 años de SQL tienen mucho que enseñar a los desarrolladores de API actuales en términos de velocidad y rendimiento, independientemente de las bases de datos reales en uso.

Esta publicación se inspiró en la presentación de Joakim Lundborg en la Platform Summit 2017:

¿Qué hace que algo sea rápido ?

Es importante estar en la misma página acerca de lo que realmente significa rápido cuando se trata de diseño de API. Esto es difícil de definir, pero en última instancia se trata de pensar en el usuario y seguir algunas reglas simples.

Regla 1 - Nunca dejes que los humanos esperen

Según Lundborg, "lo principal en lo que hay que pensar cuando se diseña para el rendimiento es pensar en las personas que estarán expuestas a los resultados de su API". Estas personas variarán de un proyecto a otro. Pueden ser los usuarios finales o los propios desarrolladores de aplicaciones.

Independientemente, el diseño de API siempre debe considerar al ser humano . Recuerda que los humanos somos criaturas impacientes. Quieren que las cosas sucedan de inmediato y buscarán servicios de API alternativos si el rendimiento es demasiado malo. No los hagas esperar.

Regla 2 - Latencia> Rendimiento

En el caso de los humanos, cuando se trata de velocidad, lo importante no es el rendimiento bruto. Una medida típica y absoluta de velocidad podría ser la cantidad de GB de datos que se envían a través de la API por segundo. Sin embargo, para el ser humano promedio, eso es una gran cantidad de datos .

Lo que realmente importa es cuánto tiempo pasa desde que se hace clic en un botón hasta ver lo que quieren en la pantalla. Las API deben diseñarse teniendo esto en cuenta y priorizar la latencia (tiempo de espera de los datos) sobre el rendimiento (la cantidad de datos sin procesar).

Números de latencia que todo programador debería saber: 2018 ( fuente / bifurcación )

El gráfico anterior ilustra el orden de magnitud de la diferencia al acceder a los datos en varias ubicaciones. Los datos almacenados en caché local están a la izquierda, con los servidores en la parte inferior derecha. Las API comienzan en esa sección final con la mayor latencia, lo que les da una desventaja, particularmente según la perciben los humanos. Es esencial para un buen diseño de API considerar mejoras de velocidad que ayuden a mitigar esta latencia.

Relacionado: Optimización de API para entornos móviles

El movimiento NoSQL

Antes de considerar lo que SQL puede enseñar directamente a los desarrolladores de API, hay mucho que extraer de las debilidades de SQL . todo el movimiento fue iniciado por los que se siente frustrado con SQL pero no se conformaban ser infeliz. En lugar de quedarse de brazos cruzados, decidieron mejorar el status quo adoptando nuevos enfoques para las tecnologías de bases de datos. Hay varias lecciones de estos métodos que pueden ayudar a cualquier aplicación que requiera acceso a datos.

Lección aprendida: datos del modelo después de sus patrones de acceso

Cuando se liberaron del marco de SQL, los tecnólogos de NoSQL descubrieron una nueva flexibilidad en la estructuración de datos . En lugar de estar vinculado a una estructura tradicional de tablas, NoSQL aboga por estructurar los datos de una manera que refleje cómo el usuario accede a ellos. Si el usuario obtiene pares clave / valor, un almacén clave / valor tiene sentido. Del mismo modo, si el usuario está recuperando una gran cantidad de datos de gráficos, utilice un almacén de datos que pueda manejar fácilmente los datos de gráficos.

Lección aprendida: vale la pena mantener las cosas simples

SQL puede dificultar la comprensión de lo que sucede en el backend , ofuscando los métodos mediante los cuales se recuperan los datos. Cuando la base de datos causa errores o problemas de rendimiento, la depuración es difícil y, a veces, los problemas simplemente no se pueden resolver.

Por otro lado, una base de datos simple que solo permite el acceso de clave / valor no tiene mucho margen para errores. Si bien SQL no admitiría esta estructura simple, NoSQL ofrece la capacidad de mantener los datos mínimamente estructurados. Esta simplicidad puede dar grandes frutos en términos de velocidad, escalabilidad y depuración .

Lección aprendida: coherencia> Velocidad mínima

Las bases de datos NoSQL aportaron una nueva consistencia a la velocidad de acceso, algo que es crucial para la experiencia del usuario final. Con SQL, los tiempos de respuesta son inconsistentes y es un desafío comprender las discrepancias sin un nivel muy alto de experiencia.

La consistencia es más importante para los usuarios que las velocidades más rápidas (o más lentas) posibles. Los usuarios anhelan la coherencia , no quieren valores atípicos. Quieren que las cosas funcionen exactamente de la misma manera, siempre, para que los resultados sean fiables. Esto es válido para cualquier método de acceso a datos.

Relacionado: ¿Qué hace que una API sea ágil?

Cómo hacer una API rápida

Al final del día, cuando realmente se trata de eso, ¿cómo se hace una API rápida ? Algunos temas ya han surgido de las debilidades de SQL, pero hay muchos más pasos concretos que se pueden tomar para mejorar la velocidad de cualquier API. Estos provienen de lecciones extraídas de décadas de acceso a datos y tienen un gran impacto en la velocidad percibida y en el rendimiento medido.

1. Otorgue a los consumidores de API el control de lo que obtienen

SQL hace posible recuperar exactamente los datos deseados de una sola vez. Con combinaciones y otros trucos sofisticados, los datos se pueden agregar en tablas y devolver sin ninguna información adicional. Desafortunadamente, las API a menudo eliminan esta capacidad y requieren que los usuarios soliciten colecciones de datos predeterminadas.

Darle al consumidor un control total mejorará el rendimiento de la API al reducir el peso de los datos devueltos, gracias a solicitudes muy específicas de campos de datos. También puede minimizar el número de solicitudes, si el consumidor o la aplicación pueden obtener todos los datos necesarios de una vez. Esto es algo que ya está comenzando a despegar en las tendencias de desarrollo actuales, impulsadas por tecnologías como GraphQL .

Lea más sobre GraphQL en nuestro libro electrónico gratuito: GraphQL o Bust

2. Ayude a los consumidores de API a comprender lo que es lento

Un peligro de dar a los consumidores de API más control sobre los datos que obtienen es que pueden crear situaciones en las que el rendimiento de la API sea bastante deficiente. Esto significa que la planificación de consultas ya no puede ser una ocurrencia tardía: los usuarios finales deben poder comprender lo que han hecho y por qué está ralentizando las cosas.

La solución propuesta por Joakim en su charla es robar el método EXPLAIN de SQL. En SQL, colocar el comando EXPLAIN delante de cualquier consulta devolverá datos que explican el plan de la base de datos para ejecutar la consulta. Los datos incluyen información como qué tablas se consultarán, qué agregaciones funcionarán, qué planes se consideraron pero descartaron, etc.

En este momento, no existe realmente un equivalente de API completo. Los consumidores de API, especialmente aquellos que usan API GraphQL, realmente podrían usar esta solución. Algunas herramientas van en la dirección correcta, como el trazado de tuberías, pero esta es un área bastante madura para mejorar.

3. Conozca los patrones de acceso a datos

Si no es posible dar a los consumidores de API el control total de lo que obtienen, la API ciertamente se puede optimizar para patrones comunes de acceso a datos . Estos se descubren al registrar las acciones del usuario y, en realidad, tomarse el tiempo para leer los registros. A partir de aquí, se puede agregar información útil sobre los conjuntos de datos a los que se accede comúnmente, las acciones del consumidor de API que actualmente requieren múltiples llamadas de API, y más.

Después de reconocer los patrones de acceso comunes, entra en juego la primera lección del movimiento NoSQL. En la medida de lo posible, la API debe modelarse según los patrones de acceso más comunes. Esto permitirá a la mayoría de los usuarios obtener los datos más relevantes más rápidamente.

4. Evite el problema N + 1: comprenda los datos disponibles

Considere una consulta SQL como esta:

SELECT thing FROM huge_list
JOIN all_the_related_things

Esta consulta puede molestar un poco al administrador de la base de datos, pero es capaz de solicitar todos los datos necesarios en una sola consulta. A continuación, considere una llamada API REST bastante típica:


const things = await fetch_huge_list();
const result = things.map(thing => {
fetch_all_the_related_things(thing);
}

En este ejemplo, el consumidor de API solicita una matriz de datos. Una vez que reciben los datos, iteran sobre cada elemento y realizan una solicitud de API adicional para recopilar datos adicionales para ese elemento específico. Esto se conoce como el problema N + 1 , donde se realiza una sola solicitud (la +1) y luego, para N elementos en la matriz devuelta, se realizan N solicitudes a la API. No es un gran problema cuando N son solo unos pocos elementos, pero puede salirse de control muy rápidamente para grandes conjuntos de datos.

Históricamente, esto se conoce como un problema de ORM (mapeo relacional de objetos). Al colocar la capa ORM encima de la base de datos SQL, esto elimina la capacidad del usuario final de acceder libremente a abstracciones agradables como las uniones SQL. Dependiendo de sus necesidades particulares, esto podría causar problemas de rendimiento masivos.

Hoy en día, los ORM no son el problema; más bien, es un caso de una mala abstracción. El mismo problema aparecerá en cualquier API que esté diseñada para forzar que las solicitudes de datos se realicen en varios pasos. En muchos sentidos, según Joakim, "el diseño puritano de la API REST es lo peor que puede hacer por el rendimiento de la API porque lo obliga a tener este problema".

La solución aquí es tener una comprensión completa de la API y cómo se utiliza. El diseño de la API debe considerar los datos disponibles en esta API en particular y cómo se obtendrán los datos. A partir de ahí, un buen diseño de la API facilitará a los usuarios la búsqueda de las cosas importantes de una sola vez, en lugar de hacer un ciclo lleno de solicitudes.

5. Diseñe la experiencia de API para baja latencia

Pensar en la experiencia de la API a través de los ojos del consumidor de API es muy importante. Recuerde que es crucial que la API se sienta rápida, en lugar de medirse tan rápido. El consumidor de API humano promedio se preocupa más por la rapidez con que los datos llegan a ellos que por el rendimiento sin procesar.

Este es el paso clave, según Joakim, quien dice: "No desea diseñar su API para tomar varios pasos para obtener los datos que desea". Considere formas de hacer que la API se sienta rápida y con baja latencia, incluso si las velocidades objetivas para grandes cantidades de datos no son las mismas.

6. Diseñe la API para almacenar datos en caché

Otra forma de mejorar la latencia en una API es proporcionando la capacidad de almacenar datos en caché localmente. En esta representación gráfica de latencia, las API se encuentran en la categoría de red. Esta es la categoría con mayor latencia, lo que la hace más dolorosa para el usuario final.

Al diseñar una API capaz de almacenar datos en caché , esto mueve el acceso de la categoría roja (red) a las áreas negra y azul. Tener estos datos disponibles localmente reduce la latencia, lo que marca una gran diferencia. La caché en sí también se puede optimizar colocándola lo más cerca posible del usuario final, reduciendo la mayor parte de la latencia local.

7. Diseñe la API para obtener datos previamente

Una forma de mitigar la lentitud causada por los usuarios que realizan múltiples solicitudes de API es diseñar la API con la capacidad de obtener datos relevantes previamente . Al hacer cosas como estudiar los registros de acceso, es posible determinar las acciones que los consumidores de API realizan con frecuencia a continuación. Desde allí, la API puede comenzar a solicitar estos datos antes de que lo haga el usuario.

Un ejemplo de obtención previa de API sería cómo Instagram comienza a cargar fotos en el fondo de la aplicación, incluso antes de que el usuario presione el botón de carga. Si bien esto no mejora el rendimiento sin procesar, tiene un gran impacto en la velocidad percibida . Diseñar API para permitir este tipo de cosas es crucial y, al igual que el almacenamiento en caché, hace una gran diferencia.

8. Recuerde: no se trata de las herramientas, sino de cómo se utilizan

Al final del día, la base de datos o el lenguaje particular que se usa para impulsar una API realmente no importa. Es totalmente posible diseñar una API usando cualquier nueva tecnología, como GraphQL, que aún funciona de manera terrible. Por otro lado, cuando se diseña teniendo en cuenta el rendimiento, una base de datos SQL de la vieja escuela puede impulsar una API ultrarrápida. No se trata de qué herramientas se utilizan, sino de comprenderlas completamente y utilizarlas de la manera más inteligente posible.

Conclusión

SQL definitivamente podría considerarse una de las primeras API. 40 años de diseño, implementación y acceso a bases de datos tienen mucho que enseñar sobre cómo los consumidores solicitan y utilizan los datos. Estas lecciones apuntan a métodos y enfoques claros que mejoran el rendimiento de la API. Al final del día, todo se reduce a pensar en el consumidor, estructurar los datos de manera adecuada, disminuir la latencia y considerar la velocidad percibida sobre el rendimiento sin procesar. En producción, supervise los registros en busca de patrones de acceso a datos comunes y continúe iterando y proporcionando formas eficientes de acceder a los datos de uso frecuente. Mantenga las cosas rápidas y, lo que es más importante, consistentes, y los consumidores de API seguirán regresando.

Publicar un comentario

0 Comentarios