Header Ads Widget

Ticker

6/recent/ticker-posts

13 marcos para crear API en Elixir

 


Elixir es, en esencia, un lenguaje basado en la idea de diseño extensible; no es de extrañar, entonces, que haya una gran cantidad de marcos adicionales diseñados para proporcionar más extensibilidad, más capacidad y más eficiencia. Hoy, vamos a echar un vistazo a algunos de esos marcos y veremos lo que hacen. Algunos son grandes, otros son pequeños, pero todos los marcos de esta lista son, como mínimo, dignos de consideración.

¿No es lo que estás buscando? También hemos revisado los marcos para crear API en Go , Python , Node.js , Java , Scala , Clojure , PHP y Rust .

1 - Marco de Phoenix

El espíritu principal de Phoenix es la mezcla de herramientas y enfoques probados con implementaciones más progresistas; debido a esto, se ha convertido en un lenguaje bastante popular tanto en los círculos de desarrollo modernos como en los más tradicionales. Una de las características más interesantes que ofrece Phoenix son los canales.

En esencia, Channels da la vuelta al paradigma tradicional de interacción web. Tradicionalmente, cuando un usuario visita una página web, el contenido se llama desde un servidor y la comunicación es “estática”. Los canales crean un "canal" para la comunicación continua, creando una conexión entre el cliente y el servidor que puede actualizar los datos de forma activa.

Por esta (y muchas otras razones), Phoenix es una excelente opción para API modernas, interactivas y dinámicas.

2 - Nervios

Nerves ofrece un argumento simple pero poderoso: ¿por qué abstraer algo del software? ¿Por qué no manejar todo en un paquete único, sólido y eficaz? Nerves es, literalmente, un marco que tiene como objetivo integrar la comunicación en red, el descubrimiento y más en una aplicación simple y empaquetada.

Nerves es todavía un marco relativamente joven, pero la oferta principal es ciertamente atractiva. Los desarrolladores de API a menudo se enfrentan a una abrumadora cantidad de bibliotecas, integraciones y microservicios externos para conectarse. A menudo, esta abrumadora opción de opciones puede conducir a una especie de ceguera de pánico y detener el desarrollo general, si no hacer que el código base subyacente sea mucho más confuso.

En consecuencia, Nerves es una excelente opción para cualquier API de Elixir que necesite un complemento completo de sistemas en su marco.

3 - Azúcar

A diferencia de otras opciones que se centran en proporcionar cualquier cosa y todo lo que pueda necesitar para poner en marcha una API en Elixir, Sugar se centra en la modularidad. A partir de esta modularidad, se habilita una buena cantidad de personalización, lo que permite una gran variedad de opciones en términos de función y configuración.

Uno de los principales beneficios de Sugar es el hecho de que, cuando puedes sumar y restar lo que quieras, obtienes una tremenda velocidad. Dado que las API a menudo viven o mueren según dos métricas centrales, la disponibilidad y la velocidad, ser capaz de crear una base de código de API ajustada y "según sea necesario" es extremadamente valioso.

4 - Hedwig

Hedwig es un marco interesante para discutir en este contexto, en gran parte porque es un marco muy específico: su función específica es como un adaptador de consola para habilitar bots en base a Elixir.

Si bien esto puede parecer demasiado específico en comparación con los enfoques más generalistas de otros marcos de esta lista, ciertamente hay algo que decir sobre lo complejo que puede ser este tipo de interacción. Sin embargo, la recompensa por implementar este tipo de solución compensa con creces cualquier complejidad adicional: poder responder a las preguntas de los usuarios en vivo con enlaces a la documentación, por ejemplo, es un gran paradigma de comunicación que está habilitado directamente por un marco como este .

5 - Enchufe

Plug es a menudo la primera sugerencia cuando se trata de conectar aplicaciones de Elixir de una manera significativa, y por una buena razón: es muy eficaz y eficiente. Plug utiliza, curiosamente, "enchufes" para recibir una conexión de algún tipo, transformar esa solicitud y pasarla. En esencia, Plug es más un protocolo entre componentes y adaptadores que un marco masivo y complejo, pero lo que hace, lo hace bien.

Cabe señalar que uno de los principales atractivos de Plug es que es una parte oficial de Elixir. Si bien no es parte predeterminada del paquete principal de Elixir, es parte del proyecto general. Esto significa que mientras se mantenga Elixir, las posibilidades de que se mantenga Plug son bastante buenas.

6 - Trote

Trot es un intento de hacer que Plug sea más fácil de usar y, por lo tanto, tiene como objetivo hacer que sus aplicaciones Elixir (y Cowboy) sean más fáciles de codificar. Si bien en su mayoría logra hacer esto, su valor realmente depende de su caso de uso específico.

La advertencia que subraya todo esto es que su necesidad de Trot depende de su nivel de uso de Plug. En un caso de uso simple, donde solo se utiliza uno de nuestros dos enchufes, Trot puede parecer una capa demasiado compleja con pocas ganancias de eficiencia. Sin embargo, en situaciones más complejas, Trot puede resultar en enormes ganancias tanto en la codificación como en la facilidad de uso debido a cómo manejan el enrutamiento y múltiples enchufes que se alimentan entre sí.

Esto crea una especie de ruta de uso interesante: si usa Plug de formas complejas, definitivamente vale la pena considerar Trot.

7 - Plácido

Placid es más un juego de herramientas que un marco, pero con tantas herramientas en oferta, cumple funcionalmente ese papel bastante bien. Placid tiene una configuración integrada, controladores, CORS, análisis de solicitudes, enrutamiento y más, y está diseñado para servir como una colección de herramientas RESTful para permitir una alta flexibilidad, extensibilidad y usabilidad.

Uno de los grandes puntos destacados en toda la documentación de Placid es la idea de aprovechar este conjunto de herramientas para ofrecer tolerancia a fallas. Este es un caso de uso muy común, especialmente en torno a sus sistemas de enrutamiento y análisis de solicitudes. Por esta razón, Placid es una recomendación relativamente común para aquellos que buscan construir API HTTP tolerantes a fallas en Elixir.

8 - Kitto

Kitto es un marco de trabajo muy específico y de un solo propósito diseñado para crear paneles de control. Dicho esto, lo hace realmente bien y, sin duda, es una adición de valor.

Curiosamente, uno de los mejores casos de uso para este tipo de aplicación no es el panel de control orientado hacia el futuro que podría esperar, donde el contenido social se sincroniza y comparte; en cambio, este tipo de panel de control podría aportar mucho valor a un equipo de desarrollo que desee versión, mostrar procesos de desarrollo en cascada, etc. Por esta razón, Kitto debe verse como un marco que permite tanto el intercambio público como el desarrollo de equipos, tanto como una herramienta social y de desarrollo.

9 - Maru

Maru se anuncia a sí mismo como un marco de API similar a REST, y específicamente menciona varios marcos existentes y comunes (incluido Phoenix) como soluciones complementarias. Maru se define mejor como un lenguaje específico de dominio: ofrece una amplia gama de opciones para el control de versiones, la respuesta del proceso y más. Es de destacar que no maneja conexiones de bases de datos, envoltorios de conectores, etc. Por esa razón, Maru es un complemento, no un reemplazo, de otras opciones de esta lista.

10 - Flowex

Flowex es un marco que permite un tipo diferente de desarrollo en conjunto: los creadores de Flowex detallan este propósito como "un conjunto de abstracciones construidas sobre Elixir GenStage" que permite a los desarrolladores utilizar tanto la programación basada en flujo (FBP) como el ferrocarril. Enfoques de programación orientada (ROP). Si bien estos dos enfoques podrían justificar por sí mismos una pieza completa, los resumiremos brevemente aquí.

En esencia, ambas rutas de desarrollo esperan que los desarrolladores presten tiempo y atención a la realidad de que no existe un escenario de uso perfecto: los usuarios no siempre usarán los procesos correctamente, los entornos no siempre serán estables y la falla es algo que debería ser compatible, no resumido con un simple código de error. El enfoque entonces es definir procesos específicos (“proceso de caja negra” en FBP y lógica de ruta ferroviaria o “estaciones” en ROP), y asegurar que los casos de uso se empujen a lo largo de rutas predefinidas en lugar de puntos finales predefinidos.

Esto permite una flexibilidad mucho mayor en los paquetes de Elixir, y codifica específicamente una especie de "ruta de falla" en Elixir propiamente dicho.

11 - Raxx

Raxx se anuncia a sí mismo como una "especificación de una interfaz pura para servidores web y marcos", y ciertamente lo refleja en su enfoque. La idea completa de Raxx es reflejar el flujo de transformación HTTP subyacente y el esquema de interacción del servidor para crear una experiencia interactiva "pura" y simple. Primero, lo positivo de este enfoque: Raxx es eficiente y muy específico en cuanto a lo que hace, cómo lo hace y qué tan rápido lo hace. En consecuencia, Raxx es una excelente opción para alguien que busca optimizar su flujo de transformación de una manera muy transparente.

Por supuesto, hay una desventaja significativa: la simplicidad en el enfoque generalmente significa limitaciones a la complejidad general. Raxx reconoce esto en su documentación, sugiriendo que dos casos de uso comunes - respuestas grandes para transformaciones, como un video HD como respuesta, y solicitudes únicas que resultan en respuestas múltiples (como WebSockets y eventos enviados por el servidor) - no son apropiados para API de Raxx. Por esa razón, Raxx debería considerarse una gran opción, pero con requisitos específicos que dictan su adopción.

12 - Weber

Weber es un marco fuerte con la idea de flexibilidad. Con un enrutamiento altamente flexible, compatibilidad con WebSockets y métodos de generación de proyectos, fue (al menos durante un tiempo) una opción muy popular y sólida para los desarrolladores basados ​​en Elixir.

El principal problema de Weber es que no se mantiene de forma activa. Si bien existen algunas bifurcaciones y extensiones secundarias para Weber, su popularidad ha disminuido con el tiempo: las bases de código más antiguas son más difíciles de integrar y rápidamente dejan de utilizarse a medida que la web cambia y se transforma. Dicho esto, no es raro verlo en la naturaleza y, como tal, vale la pena mencionarlo en esta lista.

13 - Anubis

Anubis realmente solo hace una cosa: permite la creación de aplicaciones CLI en Elixir mediante el uso de una biblioteca simple y optimizada. Dicho esto, Anubis hace esto en particular muy bien y sugiere varios casos de uso para la implementación. La principal de ellas es la capacidad de exportar la aplicación como un todo a un script limpio, eficiente y transportable que se puede invocar simplemente para hacer casi cualquier cosa que pueda hacer una CLI tradicional.

Conclusión

Elixir es un lenguaje poderoso, y con los marcos discutidos en este artículo, solo se vuelve más poderoso. Con una variedad tan amplia de opciones, Elixir puede ser una buena opción para casi cualquier proyecto o aplicación moderna. ¿Qué opinas de los marcos presentados aquí? ¿Perdimos algún marco significativo? ¿Qué piensa acerca de los marcos de “alcance limitado” o de propósito único que hacen una cosa, pero la hacen bien? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios