Feathers: Por favor, apoye la GUI para CRUD

Creado en 19 mar. 2016  ·  57Comentarios  ·  Fuente: feathersjs/feathers

En este momento tenemos acción CRUD completa para servicios pero no tenemos GUI. Sería genial si tuviéramos una aplicación web simple para la entrada del usuario. Tal vez a través de un tutorial o mediante un generador automático de código. Feather será una semilla loca para cualquier proyecto :dancer:

Discussion Proposal

Comentario más útil

tal vez podamos usarlo: https://github.com/ForestAdmin/lumber

Todos 57 comentarios

@takaaptech gracias por la sugerencia! Hemos estado hablando de esto entre @feathersjs/core-team bastante. Definitivamente debería ser un complemento opcional, pero ciertamente es factible. Voy a abofetear tentativamente esto en el hito 3.0.

@ekryski muchas gracias! plumas es realmente impresionante!

Oye, me gusta la idea de tener una GUI simple para operaciones CRUD y me gustaría saber más sobre cómo planeas abordar esto. ¿No necesitará algo como JSON Schema para estandarizar las definiciones de modelos, independientemente de qué ORM se use debajo del capó? He estado trabajando mucho con la generación automática de GUI de acuerdo con los esquemas, y exponer esos esquemas con sus campos es crucial. También tiene sentido pensar en la validación de datos (longitud máxima, expresión regular de cadena, etc.), editores de propiedades (edición de fecha, fecha y hora en un campo de tipo de fecha), etc.

¿No tendría sentido implementar estas definiciones de esquema (basadas en JSON simple y compatible con el navegador y no en estas extensiones de estilo de columna vertebral típicas como lo hace Bookshelf) con sus asociaciones y escribir adaptadores de esquema para los diferentes ORM?

Esto también facilitaría la implementación de swagger y el cambio entre ORM, ya que no necesitará volver a escribir sus modelos.

editar: creo que es muy importante pensar en cuántas plumas deben ser independientes de los datos. Pero veo que está haciendo muchos esfuerzos para implementar la sincronización de datos, las capacidades fuera de línea, etc. Como tal, creo que las plumas deberán estar más vinculadas con los modelos de datos, especialmente si piensa en las capacidades del lado del cliente.

Creo que debería ser similar a lo que ofrece Strapi . Mire su studio y admin panel .

https://www.youtube.com/watch?v=UOQszbaZfSc

Strapi está estrechamente acoplado con la línea de flotación y, como tal, es más fácil implementar esta función.

Por cierto, parse también ofrece esto, llamado parse-dashboard (https://github.com/ParsePlatform). Aquí nuevamente, no hay tanta flexibilidad como con plumas para elegir entre ORM.

No puedo esperar a escuchar cómo las plumas abordarán esto si realmente deciden proporcionar esta función.

Una solución que veo sería dividir la función en dos tipos de módulos:

  • un complemento de plumas que hace el trabajo principal, como mostrar la GUI
  • un adaptador para el complemento para administrar el ORM

Así tendríamos un plugin único y muchos adaptadores, uno para cada ORM.

Tenemos un par de ideas aquí y creo que hay diferentes partes en esto:

1) Una interfaz de usuario para armar su API visualmente. Creo que con el flujo de ganchos y servicios hay bastante potencial aquí.
2) Una interfaz de administración separada que le permite trabajar con su API y navegar por los servicios. Algo así como Postman pero específicamente para Feathers.
3) Generar un backend de administración CRUD en la aplicación. Este es probablemente el más difícil y complicado de hacer. Debe generar diferentes implementaciones para diferentes marcos de frontend (a menos que haya una pila de frontend "oficial" además de Feathers) y los generadores son difíciles de mantener y depurar.

realmente ansioso por nunca escribir CRUD. si sirve de algo, ya estoy haciendo esto en mis propios proyectos usando tcomb , tcomb-form , feathers-tcomb y feathers-action . míralo todo junto en business-stack . recomendaría. :)

@ahdinosaur eso es bastante genial. @daffl Creo que tal vez queramos mostrar algunas de esas cosas. Al menos feathers-tcomb o algo así. Exactamente así pensé que deberíamos manejar las validaciones y sin importar lo que usemos para lograr esto, tendremos que tener alguna definición de modelo/recurso para generar automáticamente documentos API y una interfaz de usuario CRUD. feathers-swagger esencialmente solo alimenta una definición de modelo de mangosta a Swagger.

Tendremos que decidir cómo queremos dividir esto un poco, dado que tenemos tantos DB y ORM diferentes. Podría ver que algo como tcomb es bastante valioso, pero ¿anula el propósito de usar un ORM? Eso no es necesariamente algo malo, pero creo que ser consistente en su definición de esquema/modelo/recurso (como quiera llamarlo) es importante, independientemente de la base de datos subyacente. Hacer que las bases de datos sean fácilmente intercambiables es importante, así que no me gusta la idea de usar modelos Sequelize, modelos mongoose, pero luego para otras bases de datos que usan Tcomb o algo así.

Para la parte de la interfaz de usuario del administrador o algo así, acepto que:

A) Es un montón de trabajo para apoyar el sabor de la parte delantera del día.
B) Si implementamos un front-end, digamos en React, entonces no será fácil usar uno alternativo junto a él.

Por lo tanto, es posible que deba ser un frente obstinado (eso sigue siendo opcional), pero si no, por ejemplo, desea usar React, entonces es una lástima. Si podemos hacerlo súper liviano para que sea fácil de replicar para las personas y para que la comunidad cree diferentes interfaces, entonces podría funcionar realmente bien.

Inspirado por Django, he estado buscando algo que venga con un CRUD-GUI o algún tipo de administrador. He estado jugando con la idea de generar esquemas JSON para un montón de modelos. Usando esos esquemas, debería poder generar un código de validación, esquemas para mongoose[1] y otros modelos. Atornillar a un administrador a las plumas parecería relativamente sencillo usando un esquema y algo similar a ng-admin[2].

Creo que la ventaja de este enfoque sería que no se tiene que escribir ningún código específicamente para las plumas (aparte del generador de esquemas JSON y algo de pegamento generado). No habría preocupaciones sobre el "sabor del día" y las plumas manténgase obstinado donde realmente importa, la interfaz REST y Socket.io que proporciona.

Solo mis 2 centavos, si alguien está interesado en esto, quiero configurar un prototipo para esto en algún lugar en las próximas 2 a 3 semanas.

[1] Convertidor json-schema a mongoose: https://www.npmjs.com/package/json-schema-to-mongoose
[2] ng-admin, administrador CRUD: https://github.com/marmelab/ng-admin

@AndreSteenveld Empecé a trabajar en algo como esto el año pasado. Puedes ver lo que reuní aquí: https://github.com/marshallswain/AmityApp. Básicamente funciona en torno a la creación de lo que llamé adaptadores Amity, que son colecciones de servicios de plumas específicos para manejar tipos de bases de datos. Solo hice la versión de MongoDB.

https://github.com/marshallswain/amity-mongodb

amity-mongodb le permite administrar un servidor MongoDB completo. Utiliza varios servicios de plumas:

Dado que todo utiliza los servicios de Feathers, a medida que agrega o elimina bases de datos y colecciones, se actualiza en tiempo real.

Todavía no he actualizado el servidor amity a Feathers 2.0. Eres bienvenido a salvar lo que puedas de él. :)

Lo hice completamente modular, por lo que puede crear su propia interfaz de usuario sobre los adaptadores de amistad si lo desea.

probablemente ya conoces ng-admin. Me gusta la forma en que manejan backend específico. No me gusta angular, así que casi termino de transferirlo a riot.js

También voy a descartar que parece una alternativa bastante buena llamada http://forestadmin.com/. Es pagado y alojado, pero puede funcionar localmente de forma gratuita. El creador me dijo que si solo carga el middleware Feathers después del middleware Forest, funciona de inmediato. Voy a darle una oportunidad en breve.

@ekryski @SeyZ
¿Eso es software libre?

Hola @josx - Tenemos un plan gratuito para 1 usuario :)

Si lo ha probado/usado/visto, el marco API de StrongLoop genera una interfaz de usuario web muy agradable para su servicio RestFUL... Que ahora es http://loopback.io , supongo (después de que IBM adquirió Strongloop). De todos modos, tal vez haya algo allí que valga la pena brillar...

@ekryski : miré forestadmin.com pero no veo dónde / cómo puede funcionar localmente de forma gratuita. Estamos considerando usar feathersjs para basar nuestra empresa de próxima generación (detrás de firewalls sin acceso a Internet), por lo que esperamos que cualquier cosa / todo pueda alojarse localmente ... :)

Hola, @sjmcdowall : puede instalarlo en su aplicación usando el paquete Forest según el ORM que use: Sequelize , Mongoose o incluso Loopback .

Puede probar Forest en su entorno localhost ( http://localhost... ) porque los datos transitan directamente desde su navegador a su aplicación sin pasar por Forest.

Es completamente gratis para 1 usuario administrador 👍

Esta es una gran idea. Tanto Strapi como Treeline (el mismo equipo detrás de Sails) han implementado esto.

@ekryski, ¿qué tan bien te fue con Forest Admin? ¿Requirió mucho trastear? Hemos estado creando nuestra propia interfaz de usuario de administración personalizada en reaccionar, pero sería bueno eliminar la carga de trabajo si el bosque funciona bien desde el primer momento.

@Mentioum No tuve suerte con mongoose en el proyecto y estábamos bastante presionados por el tiempo, así que fui a ng-admin. Tratando de resolver con el equipo de Forest si es algo con Forest, Feathers o si simplemente soy un estúpido. Debería tener algo de tiempo para darle otra oportunidad más adelante esta semana. Definitivamente informaré de nuevo.

@Mentioum Permítanme intervenir, estoy trabajando con @SeyZ en Forest. Estaremos investigando el problema con @ekryski. En cualquier caso, si está interesado en probar Forest, no dude en comunicarse con Sandro o conmigo (los correos electrónicos son [email protected]) y resolveremos cualquier problema juntos.

Tengo a Forest trabajando en FeathersJS con Sequelize para un proyecto paralelo, por lo que el problema podría limitarse a la mangosta. Aquí hay una idea general del archivo app.js que solo se modificó para agregar Forest.

Lo siento, pero no veo el sentido de trabajar en un administrador como el bosque que no es software libre/código abierto.
Creo que mejor trabajamos en ngadmin o similar.

gracias @ekryski .

gracias @VinzGhyz. Eso es muy amable, pero no, gracias. Hasta que sepa que funciona con mongoose, no tengo tiempo para comprometerme con él, ya que tenemos una solución que funciona y la mantenemos nosotros mismos. La única razón por la que cambiaríamos sería con una carga de trabajo de 0/menos carga de trabajo que nuestra solución actual.

Estaré pendiente a ver que pasa.

(Sé que lo mencioné antes, pero en realidad creo que KeystoneJS tiene un excelente administrador generado automáticamente con opciones bastante sólidas basadas en ElementalUI (reaccionar)) @JedWatson probablemente tendría una buena idea de la mejor manera de hacerlo.

@Mentioum gracias por la mención, me gustaría pensar que eso es lo que tiene KeystoneJS 😀

De hecho, estamos discutiendo cómo podemos centrarnos más en los dos conceptos básicos con los que Keystone es realmente fuerte: las listas de Keystone y la IU de administración. No me he sumergido profundamente en Feathers por un tiempo, pero lo que he visto se ve muy bien y está enfocado en un área ligeramente diferente.

Nuestra próxima versión principal es inminente (con la esperanza de enviar una versión beta en los próximos días) que ha sido una reescritura de un año que incluye una interfaz de usuario completamente reactiva / redux y nuevas API. Definitivamente estaría abierto a trabajar con Feathers para descubrir cómo reducir algunos de los cruces y hacer que nuestros proyectos sean compatibles, si eso es de interés.

También esperamos liberarnos de la conexión difícil con mongoose en un futuro no muy lejano, lo que podría hacer que encaje aún mejor, si podemos encontrar la flexibilidad adecuada en la forma en que se conecta a una API/almacén de datos. .

Equipo de Feathers: siéntase libre de comunicarse si desea explorar esto más a fondo.

@JedWatson increíble. Deberíamos colaborar totalmente. Emocionado de ver la nueva versión. De hecho, había estado esperando/pensando en cómo podríamos hackear Keystone para tener Feathers como pieza de fondo.

@Mentioum Estoy exactamente en el mismo barco que tú. Demasiado ocupado. Hopefull podrá dedicar media hora más o menos esta semana para ver si puedo hacer que Forest funcione.

Estamos bastante impresionados con ng-admin (aunque no soy un gran fanático de Angular). Sin embargo, todavía hay una gran cantidad de repeticiones/redundancia que termina haciendo en el lado del cliente para admitir cosas que ya ha definido en el lado del servidor de esquemas.

¡Poner Keystone en Feathers sería oro! Contribuiré a eso.

@JedWatson @ekryski @daffl

No hay problema, he hecho muchas cosas con Keystone (soy un fan) (lo mismo con las plumas):

http://161london.com (trabajo del cliente)
http://thenidocollection.com (trabajo del cliente)
http://headstartapp.com (inicio actual)

Y estamos usando Feathers como una forma sencilla de abrir muchos pequeños servicios que impulsan las aplicaciones Headstart reales (todos los cajeros automáticos React y React Native, algunos con Electron envolviéndolos para empresas que odian las 'aplicaciones de navegador').

Esto podría ser un poco exagerado, pero si realmente está pensando en que Keystone tenga algún tipo de ORM, ¿no sería mucho más genial usar plumas como un microservicio que se ejecuta junto con Keystone y simplemente lo usa?

De esa manera, Keystone aún puede tener su solución 'llave en mano' que genera todo con mongoose, pero luego, si quiere ser un poco más sofisticado, puede activar algunos microservicios de Feathers para Listas específicas que proporciona un punto final a un servicio de Feathers específico.

Estoy seguro de que ustedes tienen una idea mucho mejor sobre cómo estructurarlo. (Obs, puede hacerlo con rutas rápidas en Keystone, pero entonces no tendría un administrador de generación automática :))

Realmente tener pequeños sueños de Dockerstack en este momento:

redis,
mongodb,
piedra clave,
plumas-microservicio1,
plumas-microservicex,
pgreso,
Elasticsearch
etcétera etcétera....
....

De todos modos, no hace falta decir que si esto puede ser una cosa... estaría dispuesto a hacerlo.

Hola chicos. Si ha comenzado a construir este proyecto, ¿puede proporcionar un enlace a su repositorio o cualquier otra cosa para que la gente pueda vigilarlo?

A +1 le gustaría ver algunos ejemplos de patrones, usando keystone con plumas.

Sin duda, es una buena idea tener un backend generado automáticamente.

Para los desarrolladores que usan GraphQL, esta puede ser una buena solución: CMS de generación automática de GraphQL .

Tengo un proyecto en el que he estado trabajando durante un tiempo que puede ser de utilidad/interés: NodeMDA es un motor de generación de código que toma modelos UML y genera código fuente. Puede modelar conceptos de alto nivel como "Entidad" y "Servicio", y generar una pila completa para usted. Acabo de completar un complemento que genera una aplicación completa usando Feathers en el lado del servidor y React + Material-UI en el lado del cliente. Cada entidad que modela obtiene un editor CRUD completo.

Todo el marco tiene licencia MIT, pero actualmente no tiene su propia herramienta de modelado. Actualmente estoy usando StarUML para mi aplicación de modelado, pero eso es solo porque era económico y sus metadatos se almacenaban en JSON en lugar de un documento xml (como XMI). Si bien StarUML es un producto comercial, tienen un período de evaluación gratuito e ilimitado (su software molesto). No estoy afiliado a StarUML de ninguna manera, es solo que su herramienta de modelado satisfizo mis necesidades inmediatas. Sin embargo, NodeMDA admite lectores conectables. Tengo en mi hoja de ruta de largo alcance escribir un editor de clases UML rápido y sucio para que las personas puedan usarlo sin tener que pagar nada.

Solía ​​contribuir a un proyecto Java MDA (AndroMDA), y quería tener algo similar en el mundo de Node, así que he estado hackeando NodeMDA. El motor en sí está funcionando bastante bien. Es bastante fácil crear NUEVOS complementos para generar código de una manera diferente, o incluso en un idioma diferente. Me gusta decir "es obstinado, pero de mente abierta".

Dado que hace Feathers en el back-end, puede que lo encuentre útil de inmediato, o puede ser un buen punto de partida para otra cosa. Echale un vistazo:

https://www.npmjs.com/package/nodemda

y el complemento de plumas está aquí:

https://www.npmjs.com/package/nodemda-feathers-react

feathers-react-default-model

tal vez podamos usarlo: https://github.com/ForestAdmin/lumber

sería genial hacer algo con admin-on-rest

Si alguien está interesado. Comencé a trabajar en una bifurcación de evolutility-ui-react para agregar soporte para la API de plumas. Literalmente, recién comencé, pero obtuve CRUD básico que funciona para modelos simples, y parte del camino para archivos binarios ... el código base original puede usar un poco de refactorización y necesito agregar soporte para / probar un montón de tipos de campo , sin embargo podría ser de utilidad para alguien. Estaré impulsando más cambios en las próximas semanas.

Sobre el problema de

apoyar el sabor de la parte delantera del día

Creo que Svelte resuelve esto bastante bien ( github ). Todo lo que se hace con él es universal y se convierte en JavaScript vainilla sin marco.

Lo sugiero encarecidamente porque es a prueba de futuro y siempre intercambiable con cualquier tecnología "del día".

@ddela-cr comencé un proyecto para escribir un cliente de descanso de plumas personalizado para admin-on-rest.
Por favor revíselo, contribución bienvenida...

https://github.com/josx/aor-feathers-cliente

Lanzamos una nueva versión para https://github.com/josx/aor-feathers-client y también tenemos una prueba de trabajo en https://github.com/Cambalab/test-feathers-admin

Como luché con este mismo tema durante bastante tiempo, me gustaría compartir mi enfoque usando ng-admin (el hermano mayor admin-on-rest basado en el antiguo AngularJS) también.

Extraje la configuración mínima requerida para obtener ng-admin y ng-admin.jwt-auth trabajando con Feathers y la convertí en un repositorio cuidadosamente diseñado: https://github.com/beevelop/feathers-admin-starter

@beevelop bien hecho!

Hace algunos días hice casi lo mismo con ng-admin (pero su versión tiene más funciones hechas). Aquí un repositorio con (aplicación de plumas, ngadmin y admin-on-rest).

Tal vez podamos mejorar el mismo ejemplo con ng-admin y admin-on-rest + feathers.

Hola chicos,

Cada marco necesita reinventar la rueda para la interfaz de administración. Hay un "administrador de plumas", un "administrador de laravel", un "administrador de rieles", etc. Loco, ¿no? Es por eso que lancé Lumber (https://github.com/ForestAdmin/lumber): en lugar de estar conectado a su aplicación, genera una nueva especialmente para el administrador (en otras palabras, genera un microservicio de administración) .

¿Qué opinas de esta solución?

@SeyZ en mi proyecto no es viable, porque decidimos tener control sobre todo el software. Entonces, si no es software libre, no puedo comprar un servicio.

También desde el punto de vista del desarrollador, creo que has hecho un gran trabajo, pero no es útil para la comunidad.

Puede pensar en un modelo de negocio que incluya software libre como núcleo.
Sólo mis 2 centavos.

@josx Lumber es completamente de código abierto y Forest es un servicio que le brinda automáticamente una excelente interfaz de usuario (espero: D). ¡Todo es completamente gratis, por supuesto!

Eche un vistazo a la versión actualizada de admin-on-rest . se ve increíble

Creo que hay algunas soluciones bastante buenas aquí ahora, así que voy a cerrar esto por ahora. El equipo central no está trabajando en nada oficial y no tiene planes de hacerlo a corto plazo.

Este problema se está haciendo largo, pero no quiero bloquearlo en caso de que surja algo nuevo. Si te encuentras con algo que aún no se ha mencionado y que crees que encajaría bien, ¡no dudes en publicarlo! Si esto comienza a convertirse simplemente en un foro de discusión o empezamos a ver más de lo mismo, cerraremos el hilo.

¡Gracias por la ayuda de todos! ¡Ustedes están haciendo que la comunidad sea increíble! ❤️

En un proyecto de cualquier escala de una forma u otra, deberá crear páginas de administración. ¿Tal vez deberíamos crear una página en los documentos con enlaces a diferentes bibliotecas para crear páginas de administración de GUI? Me encantaría tener una solución lista para usar, pero al menos podemos recomendar las soluciones de mejor calidad.

@kulakowka Tendría más sentido agregar una sección a la página del Ecosistema después de la sección de pilas iniciales. https://docs.feathersjs.com/v/auk/ecosystem/readme.html

También existe una solución equivalente basada en Loopback y Angular. Se llama Colmena-cms (anteriormente conocido como Loopback Angular Admin).

Combinar Feathers con admin-on-rest tiene más sentido porque entonces tendríamos que centrarnos principalmente en construir el puente entre ambos sin necesidad de centrarnos en cómo representar las páginas de administración.

Para una solución tan nueva que depende de plumas y admin-on-rest, necesitaríamos una forma que permita actualizaciones fáciles de estas dos dependencias.

Supongo que construir y mantener una solución de este tipo debería requerir menos esfuerzo que Colmena.

He contribuido a colemena-cms en el pasado, pero es solo para loopback. Es por eso que tener una aplicación como admin en descanso es la opción perfecta para las plumas.

Eche un vistazo a un complemento o en el que estamos trabajando. https://github.com/josx/aor-feathers-cliente

¿Alguien logró usar forestAdmin a lo largo de las plumas?

@loiclouvet Ha pasado un tiempo desde que lo intenté, pero conseguí que Forest trabajara con plumas en el pasado. Me encantaría volver a intentarlo hoy y publicar un ejemplo de trabajo completo aquí: https://github.com/forestadmin/forest-examples

Descargo de responsabilidad: soy el fundador de Forest.

@SeyZ Configuré Forest con plumas (usando mangosta) después de algunos intentos, ¡definitivamente lo intentaré!

Acabo de agregar un ejemplo de trabajo para integrar Forest Admin a Feathers aquí: https://github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database

No lo dudes si tienes alguna pregunta ;)

@SeyZ Configuré Forest admin con mongoose, según tengo entendido, pasa por alto los ganchos de plumas y se inyecta directamente en mongodb, ¿correcto?

@nadbm Tienes toda la razón, así que no creo que el administrador de Forest encaje bien con Feathers. ¡Personalmente, probé y adopté admin-on-rest!

Este problema se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema con un enlace a este problema para ver los errores relacionados.

¿Fue útil esta página
0 / 5 - 0 calificaciones