ruby on rails - ¿Es ActiveResource fundamentalmente defectuoso?

ruby-on-rails rest

Question

Varios desarrolladores de diferentes equipos me han dicho de forma independiente que ActiveResource fue una idea defectuosa. La crítica más común que escucho es que fue un error diseñarla para tener una interfaz similar a ActiveRecord. También escucho quejas sobre la forma en que se manejan los errores, o se los traga. Un desarrollador realmente creó su propia gema para proporcionar la misma funcionalidad que ActiveResource (un marco para modelos basados ​​en recursos RESTful).

Soy nuevo en ActiveResource, pero cuando veo el código y experimento y veo cómo funciona, me cuesta ver de dónde proviene la resistencia. Parece basarse en conceptos limpios, sólidos. Incluso he oído que es demasiado pesado! Pero en mi examen, lo encuentro ligero y rápido.

Así que con toda esta controversia sobre ActiveResource, recurrí a la Web en busca de respuestas. Seguramente, debe haber montones de publicaciones de blog sobre por qué ActiveResource debe ser enlatado a favor de X. Después de todo, puedo encontrar publicaciones sobre si DataMapper es superior a ActiveRecord. Así que he buscado y he buscado y ... nada. Ni una sola cosa. No puedo encontrar una sola página en Internet que critique a ActiveResource (aparte de las críticas generales a REST). Ni siquiera puedo encontrar una alternativa propuesta. Cuenta con el apoyo del equipo central de Rails y parece ser el estándar de facto en la comunidad.

Línea de fondo:

¿Existe alguna controversia sobre ActiveResource? Y si es así, ¿cuál es la naturaleza del debate? ¿Hay alternativas?

Answer 1

ActiveResource se ha extraído de Rails en Rails 4.0.

Mucha gente simplemente usa RestClient o HTTParty u otra biblioteca. Esas bibliotecas son generalmente consideradas como más simples y fáciles de usar.

Answer 2

He trabajado con ActiveResource ampliamente desde 2007 y he construido y mantenido una arquitectura distribuida multiservicio utilizando ARes durante el período en que Rails pasó de v1.2 a v4.0. En mi opinión, ARes es fundamentalmente defectuosa como una biblioteca pública en su forma actual, pero contiene muchas ideas buenas que se pueden utilizar dentro de sistemas individuales. Di una charla sobre lo que hicimos en mi empresa para migrar lejos de ARes.

Una razón importante por la que a las personas no les gustan los ARes en la práctica es que no están de acuerdo con los detalles de mantenimiento o implementación deficientes. Cosas como el mensaje de error que trata su colega se incluyen en esta categoría. Además, con el tiempo, descubrirá que las cosas se están rompiendo de forma inesperada debido a mejoras improbables o correcciones de errores, o incluso a cambios internos de Rails que se están YAML-pocalypse (por ejemplo, cuando el YAML-pocalypse golpeó el año pasado, sufrimos una catástrofe en nuestras ARes sistemas). Pero todas estas cosas se pueden mejorar con un mejor mantenimiento y una mejor visión, es importante separar estos problemas del problema fundamental .

Lo que he llegado a creer, y a lo que Yehuda alude en su comentario anterior, es que ARes falla porque las API REST no tienen una semántica concreta general. Incluso aprovechando lo mejor de las convenciones de Rails, la semántica de la API HTTP es, en el mejor de los casos, endeble.

En contraste con lo que hace ActiveRecord, genera SQL: un lenguaje declarativo bien definido para seleccionar filas de datos. SQL se basa en el modelo relacional que nos proporciona definiciones matemáticas de lo que significa una consulta basada en cláusulas diferentes. Este apuntalamiento matemático es lo que permite que algo como Arel cree un DSL de SQL componible en ruby. En una base de datos SQL, se puede ejecutar cualquier consulta sintácticamente correcta (incluso si es demasiado lenta para ser práctica) porque el motor está diseñado para analizar y mapear formalmente las sentencias de SQL a la implementación que puede manipular y recuperar los datos subyacentes. Entonces, cuando construye un ORM como ActiveRecord sobre esto, tiene garantías muy sólidas en el sistema subyacente. Si genera un SQL válido, el motor garantiza que funcionará, si genera un SQL no válido, el motor le devuelve un error. E incluso con la estandarización de SQL, vale la pena señalar que cada base de datos tiene un adaptador ActiveRecord separado para garantizar la corrección y la asignación adecuada a las características de ActiveRecord. Cada uno de estos utiliza un controlador subyacente para garantizar la implementación correcta del protocolo de conexión a la base de datos en ejecución. Todo este código tiene una gran cantidad de especificación y mantenimiento detrás, todo lo cual permite la elegancia y confiabilidad benignas del ActiveRecord de hoy.

¿Considerar ahora una API HTTP y su respaldo? Podría ser cualquier tecnología de base de datos bajo el sol o ninguna en absoluto! Lo más probable es que esté escrito internamente y sirva solo lo que es necesario para la función comercial. A diferencia de una base de datos que lleva en su esquema toda la información necesaria sobre la operación de consultas genéricas, una API HTTP está completamente desconectada de cualquier mecanismo de almacenamiento subyacente o lógica empresarial. Incluso si una API proporciona un estándar para la forma en que utiliza los parámetros de consulta, no hay una definición de autodocumentación de qué opciones de filtro o clasificación están disponibles. Diablos, incluso la verificación de la validez de los parámetros no está garantizada, con la frecuencia en que una API simplemente se traga o ignora un parámetro no válido.

Dicho todo esto, ARes es muy conveniente, pero está construido sobre arenas movedizas. Las ideas y convenciones que utiliza son útiles, pero carecen de una visión coherente y estabilidad para ser confiables. Personalmente, creo que no es irrazonable hacer que sus ARes se parezcan con sus propias convenciones y especificaciones sólidas que luego puede aplicar a la implementación de su servicio.

En términos de construir una base sobre la cual algo como ARes podría tener sentido, la excelente especificación de JSON: API de Yehuda Katz y Steve Klabnik es un gran proyecto comunitario que proporcionará un bloque de construcción muy importante de dicha base, sin embargo, vale la pena señalar que Todavía no se acerca a un controlador de base de datos específico en términos de garantías semánticas y funcionalidad derivable. Sospecho que una muy buena biblioteca tipo ARes para aprovechar JSON-API se verá significativamente diferente de lo que hace hoy para abarcar mejor las áreas grises implícitas en una API adhoc en comparación con un RDBMS.

Edit: JSON: API acaba de alcanzar 1.0 después de dos años de intenso debate y retroalimentación de diversas comunidades. Yo estimaría que la cantidad de trabajo puesto en esta especificación es un par de órdenes de magnitud más de lo que ActiveResource ha logrado. Aunque es un nivel de abstracción diferente al de ActiveResource, JSON: API persigue un objetivo similar de proporcionar semántica estándar para que las API sean más fáciles de producir y consumir. Mirar algunas de las implementations da una buena idea de cuánto apalancamiento puede proporcionar JSON: API.