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:
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.
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:
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.
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.
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:
// 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';
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é:
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 } });
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.
Puede lograr la dependencia cero simplemente siguiendo los estándares de JavaScript y usando Typescript.
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.
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: