paint-brush
Un cliente API de JavaScript puede ser un producto SaaS. Averiguar como.por@algolia
8,175 lecturas
8,175 lecturas

Un cliente API de JavaScript puede ser un producto SaaS. Averiguar como.

por Algolia2022/05/24
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Una API (interfaz de programación de aplicaciones) no es solo un contenedor; es una aplicación separada y liviana que permite a los desarrolladores interactuar con una plataforma de software con todas las funciones. Un cliente de API basado en productos debe proporcionar un acceso exhaustivo y sencillo a todas las funciones de la aplicación a la que sirve. Un diseño de API también intenta limitar la cantidad de código repetitivo necesario para instanciar, usar o parametrizar un método de API. El mejor diseño de API es un tamaño de código pequeño y dependencias bajas o nulas.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Un cliente API de JavaScript puede ser un producto SaaS. Averiguar como.
Algolia HackerNoon profile picture


Un cliente API de JavaScript basado en un producto debe poder ejecutarse en el navegador, con acceso DOM frontal directo, así como en un entorno de nodo, para acceder a servidores y servicios de back-end.


Además, un cliente de API basado en productos debe proporcionar un acceso exhaustivo y sencillo a todas las funciones de la aplicación a la que sirve. Y debe mantenerse actualizado con cada nueva función.


Finalmente, un cliente de API debe agregar valor adicional a la aplicación, agregando funcionalidades como:


  • Vuelva a intentar la lógica, para eludir la red o cualquier otra falla momentánea o tiempo de espera.
  • Límites de velocidad y estrategias de aceleración para reducir la carga del servidor y los costos de uso.
  • Procesamiento por lotes, donde la API realiza un conjunto de acciones para realizar una sola tarea común.
  • Y otra funcionalidad auxiliar .
  • Vista amigable de la API Rest subyacente.

¿Qué es un cliente API basado en productos ?

Una API (interfaz de programación de aplicaciones) no es solo un contenedor; es una aplicación separada y liviana que permite a los desarrolladores interactuar con una plataforma de software con todas las funciones.


Una API basada en productos es una API que una empresa vende como producto. Google vende la API de Google Maps, Stripe vende una API financiera y nosotros vendemos una API de búsqueda.


Un cliente de API basado en productos es una API que viene en diferentes lenguajes de programación, marcos y tipos de JavaScript. Nuestros clientes se sientan encima de diferentes puntos finales de la API REST.


Al ofrecer un cliente API en el propio idioma de un desarrollador, obtienen el beneficio de:


  • Incorporación más rápida para implementar las características básicas y avanzadas de una aplicación.

  • Integración más sencilla en sus propias bases de código.

  • Grandes cantidades de código ya escrito para ellos, incluidos reintentos, limitación y procesamiento por lotes.


El mejor diseño de API también trata de limitar la cantidad de código repetitivo necesario para instanciar, usar o parametrizar un método de API.


Podemos nombrar algunas otras características definitorias de un cliente API basado en productos:


  • Tamaño de código pequeño.
  • Dependencias bajas o nulas.
  • Personalización flexible con parámetros inteligentes.
  • DX intuitivo en la denominación y el uso de solicitudes y respuestas (mejora sobre Rest API).
  • Documentación completa de la API y tutoriales.
  • Versiones ininterrumpidas.
  • Autenticación con claves API o tokens.
  • Intercambios de datos simples y universales con JSON.
  • Mantenerse al día con los cambios y las mejores prácticas en los lenguajes y tecnologías de programación subyacentes.

Cómo mejorar un producto API de una versión a otra

Primero, unas palabras sobre el proceso: tenemos más de 10 000 clientes que utilizan nuestros clientes API. Con ese tipo de uso, estamos en una buena posición para ajustar nuestras API en función de los tickets de atención al cliente, chats y estadísticas de uso en nuestros registros.


Sin embargo, una fuente de verdad aún mayor son nuestros propios ingenieros. Nuestras API no solo las utilizan nuestros clientes.


Nuestro Tablero usa JavaScript, PHP, Ruby y otros clientes API; tenemos casos de uso internos que implementan nuestros clientes API; nuestros equipos de soporte técnico orientados al cliente crean demostraciones, prototipos y soluciones utilizando nuestros clientes API.


Con todas esas pruebas de API y el uso interno, conocemos de primera mano los puntos débiles y los aspectos positivos de nuestros clientes de API.


Con todos esos comentarios, cada lanzamiento incluye:


  • Refactorización de la interfaz y el código subyacente (sin interrupciones) para mantenerse al día con los estándares cambiantes y la evolución de la tecnología subyacente. Por ejemplo, nuestra versión más reciente de nuestro cliente de JavaScript es compatible con ES6 y TypeScript.


  • Mejorando el DX para todo tipo de desarrolladores: experimentados, principiantes, expertos en dominios.


  • Orientación a más casos de uso . Métodos nuevos o existentes para abordar mejor ciertos casos de uso, a veces incluso adoptando la jerga de una industria.


  • Generar una interfaz común en todos los lenguajes de la API. Muchos clientes cambian entre diferentes idiomas. Tener una interfaz común ayuda con eso. Usar JSON también ayuda.

Algunas actualizaciones que hemos realizado en nuestro cliente API de JavaScript

Para las empresas de SaaS como la nuestra, un cliente API de JavaScript es fundamental, debido a su capacidad para solicitar servicios directamente desde nuestros servidores en la nube sin que los clientes tengan que pasar por sus propios servidores back-end.


Entre otras cosas, las solicitudes de API del lado del cliente mejoran el tiempo de respuesta de la nueva API y simplifican el código de front-end en el front-end. Debido a estos beneficios, nuestra API de JavaScript es nuestro cliente más utilizado.


Con eso en mente, las API de JavaScript tienen que manejar los desafíos del desarrollo de aplicaciones del lado del cliente, así como las particularidades del lenguaje JavaScript y sus versiones como React, Vue y Angular.


Estas son algunas de las mejoras que hemos realizado recientemente:

Compatibilidad con ambas versiones, require e import, y default y lite:


 // For the default version const algoliasearch = require('algoliasearch'); // For the default version import algoliasearch from 'algoliasearch'; // For the search only version import algoliasearch from 'algoliasearch/lite';


Instanciación parametrizada

Comenzamos con una instanciación simple: la identificación de la aplicación del cliente y la clave API:


 const algoliasearch = algoliasearch('YourApplicationID', 'YourAdminAPIKey');


Luego agregamos un tercer parámetro, lo que permite al desarrollador personalizar una serie de funciones adicionales:


 const algoliasearch = algoliasearch( 'YourApplicationID', 'YourSearchOnlyAPIKey', { timeouts: { connect: 1, read: 2, write: 30, }, requester: createBrowserXhrRequester(), logger: createConsoleLogger(LogLevelEnum.Error), responsesCache: createInMemoryCache(), requestsCache: createInMemoryCache({ serializable: false }), hostsCache: createFallbackableCache({ caches: [ createBrowserLocalStorageCache({ key: `${version}-${appId}` }), createInMemoryCache(), ], }), });


Como puede ver, el tercer parámetro permite a los desarrolladores definir:


  • Tiempos de espera únicos.

  • El comportamiento de los solicitantes.

  • Personalizaciones para solicitudes de nodos o un entorno de navegador.


  • Registrar devoluciones de llamadas:

    • El registro nos permite seguir el ciclo de vida de un cliente, registrar y luego analizar la actividad de la API.

    • El registro de la actividad de la API nos ayuda a mejorar el uso de una API en futuras versiones. También nos permite reducir los precios al eliminar ciertos usos comunes de los costos.

    • Además, al permitir que los desarrolladores nos envíen sus propios métodos de registro, podemos almacenar la información que consideren importante, mejorando así la calidad de nuestros propios registros.


  • Almacenamiento en caché de respuestas:

    • Los desarrolladores pueden administrar su propia limitación, por ejemplo.

    • También pueden deshabilitar nuestro almacenamiento en caché de respuestas.

    • Pueden administrar el almacenamiento local, preservando el estado de búsqueda incluso después de que se actualice el navegador.


  • Solicitud de almacenamiento en caché:

    • Permite compartir promesas, por ejemplo.

Tamaño reducido del JavaScript

Haz que el árbol de clientes se pueda sacudir:


 // Tree shakable ( 1 kb, dead code elimination ) // list the methods you use and don't include the code of any other method const client = createSearchClient({ // .. methods: { search } });

Solicitudes personalizadas

Los expertos a veces requieren una solicitud abierta y sin opiniones para manejar casos de uso inesperados. Por ejemplo, los desarrolladores pueden pasar solicitudes de lectura/escritura para cubrir lo que no está en la API:


 client.transporter.read ({ path: '', verb: 'GET' });


Nota sobre el registro: cuando registramos estas solicitudes personalizadas, podemos tomar esa información para crear nuevos métodos en el futuro.

Reduciendo las Dependencias a Cero

Puede lograr la dependencia cero simplemente siguiendo los estándares de JavaScript y usando Typescript.

Operaciones por lotes comunes y multitarea

En lugar de un solo método Save() , agregamos métodos más sólidos como replaceAllObjects() , reindex() , copyIndex() .


Esto ayuda a garantizar las mejores prácticas en dichos métodos sensibles a los datos. Además, hemos escrito todo el código que administra los reintentos y la lógica de tiempo de inactividad cero.

Soporte de mecanografiado


javascript mecanografiado


Administrar el programa de lanzamiento


Por último, pero no menos importante, un cliente de API basado en productos debe seguir las mejores estrategias para las prácticas de prueba y lanzamiento.


Dejaremos las pruebas para otro blog, pero esta es la estrategia general que usamos para nuestro ciclo de lanzamiento:


  • Lance una versión beta para casos de uso interno, aplicaciones y demostraciones.
  • Trabaje con el equipo de Docs para estandarizar y documentar el DX.
  • Ayude a actualizar los productos que dependen de nuestros clientes API.
  • Lance una versión beta final para un puñado de clientes.
  • Publique la versión estable, junto con los documentos actualizados.
  • Promueva y fomente la migración a través de llamadas de soporte, publicaciones de blog y redes sociales.