Feathers: Veuillez prendre en charge l'interface graphique pour CRUD

@takaaptech merci pour la suggestion ! Nous en avons beaucoup parlé au sein de l'équipe @feathersjs/core-team. Ce devrait certainement être un plugin facultatif mais c'est certainement faisable. Je vais provisoirement gifler cela sur le jalon 3.0.

@ekryski merci beaucoup! les plumes sont vraiment géniales !

Hé, j'aime l'idée d'avoir une interface graphique simple pour les opérations CRUD et j'aimerais en savoir plus sur la façon dont vous envisagez de résoudre ce problème. N'aurez-vous pas besoin de quelque chose comme JSON Schema pour standardiser les définitions de modèles, indépendamment de l'ORM utilisé sous le capot ? J'ai beaucoup travaillé avec la génération automatique d'interfaces graphiques en fonction de schémas, et exposer ces schémas avec leurs champs est crucial. Il est également logique de penser à la validation des données (maxlength, string regex, etc.), aux éditeurs de propriétés (date, datetime ou time edit sur un champ de type date) et ainsi de suite.

Ne serait-il pas logique d'implémenter ces définitions de schéma (basées sur un JSON simple et compatible avec le navigateur et non sur ces extensions typiques de style backbone comme le fait Bookshelf) avec leurs associations et d'écrire des adaptateurs de schéma pour les différents ORM ?

Cela faciliterait également l'implémentation de swagger et le basculement entre les ORM, car vous n'aurez pas besoin de réécrire vos modèles.

edit : Je pense qu'il est très important de réfléchir à la quantité de plumes qui doit être indépendante des données. Mais je vois que vous faites beaucoup d'efforts pour implémenter la synchronisation des données, les capacités hors ligne, etc. En tant que tel, je pense que les plumes devront être davantage liées aux modèles de données, surtout si vous pensez aux capacités côté client.

Je pense que cela devrait être similaire à ce que propose Strapi . Regardez ses studio et admin panel .

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

Strapi est étroitement couplé à la ligne de flottaison et, en tant que tel, il est plus facile de mettre en œuvre cette fonctionnalité.

Soit dit en passant, parse propose également cela, appelé parse-dashboard (https://github.com/ParsePlatform). Là encore, il n'y a pas une telle flexibilité comme avec les plumes pour choisir entre les ORM.

J'ai hâte d'entendre comment les plumes vont s'y prendre si elles décident vraiment de fournir cette fonctionnalité.

Une solution que je vois serait de scinder la fonctionnalité en deux types de modules :

• un plugin plumes qui fait le travail principal, comme afficher l'interface graphique
• un adaptateur pour le plugin pour gérer l'ORM

Nous aurions donc un plugin unique et de nombreux adaptateurs, un pour chaque ORM.

Nous avons quelques idées ici et je pense qu'il y a différentes parties à cela :

1) Une interface UI pour assembler visuellement votre API. Avec le flux de crochets et de services, il y a un certain potentiel ici, je pense.
2) Une interface d'administration distincte qui vous permet de travailler avec votre API et de parcourir les services. Un peu comme Postman mais spécifiquement pour Feathers.
3) Générer un backend d'administration CRUD dans l'application. C'est probablement le plus difficile et le plus délicat à faire. Vous devez générer différentes implémentations pour différents frameworks frontaux (à moins qu'il n'y ait une pile frontale "officielle" au-dessus de Feathers) et les générateurs sont difficiles à maintenir et à déboguer.

vraiment envie de ne jamais écrire CRUD. pour ce que ça vaut, je le fais déjà dans mes propres projets en utilisant tcomb , tcomb-form , feathers-tcomb et feathers-action . voyez tout cela ensemble dans business-stack . recommanderais. :)

@ahdinosaur c'est plutôt génial. @daffl Je pense que nous voudrions peut-être faire briller certains de ces trucs. Au moins feathers-tcomb ou quelque chose. C'est exactement comme ça que je pensais que nous devrions gérer les validations et peu importe ce que nous utilisons pour accomplir cela, nous devrons avoir une définition de modèle/ressource afin de générer automatiquement des documents API et une interface utilisateur CRUD. feathers-swagger alimente essentiellement une définition de modèle de mangouste à Swagger.

Nous devrons décider comment nous voulons découper cela un peu, étant donné que nous avons tellement de bases de données et d'ORM différents. Je pourrais voir quelque chose comme tcomb être assez précieux, mais cela va-t-il à l'encontre de l'utilisation d'un ORM ? Ce n'est pas nécessairement une mauvaise chose, mais je pense qu'il est important d'être cohérent dans votre définition de schéma/modèle/ressource (peu importe comment vous l'appelez) , quelle que soit la base de données en dessous. Il est important de rendre les bases de données facilement échangeables, donc je n'aime pas l'idée d'utiliser des modèles Sequelize, des modèles de mangouste, mais ensuite pour d'autres bases de données utilisant Tcomb ou quelque chose du genre.

Pour la partie interface utilisateur de l'administrateur ou quelque chose, je suis d'accord que :

A) C'est une tonne de travail pour soutenir la saveur frontale du jour
B) Si nous implémentons un frontal, disons dans React, il ne sera pas facile d'en utiliser un autre à côté.

Donc, il faudra peut-être que ce soit un front opiniâtre (c'est toujours facultatif) mais si vous ne voulez pas, par exemple, utiliser React, alors tant pis. Si nous pouvons le rendre super léger afin qu'il soit facile pour les gens de le reproduire et pour que la communauté crée différents frontaux, cela pourrait très bien fonctionner.

Inspiré par Django, j'ai cherché quelque chose qui vient avec une interface graphique CRUD ou une sorte d'administrateur. J'ai joué avec l'idée de générer des schémas JSON pour un tas de modèles. En utilisant ces schémas, vous devriez pouvoir générer un code de validation, des schémas pour mongoose[1] et d'autres modèles. Boulonner un administrateur sur des plumes semblerait relativement simple en utilisant un schéma et quelque chose comme ng-admin[2].

Je pense que l'avantage de cette approche serait qu'aucun code ne doit être écrit spécifiquement pour les plumes (autre que le générateur de schéma JSON et de la colle générée). restez opiniâtre là où ça compte vraiment, l'interface REST et Socket.io qu'elle fournit.

Juste mes 2 cents, si quelqu'un est intéressé par cela, je veux mettre en place un prototype pour cela quelque part dans les 2 à 3 prochaines semaines.

[1] Convertisseur json-schema en mangouste : https://www.npmjs.com/package/json-schema-to-mongoose
[2] ng-admin, administrateur CRUD : https://github.com/marmelab/ng-admin

@AndreSteenveld J'ai commencé à travailler sur quelque chose comme ça l'année dernière. Vous pouvez voir ce que j'ai rassemblé ici : https://github.com/marshallswain/AmityApp. Il fonctionne essentiellement autour de la création de ce que j'ai appelé des adaptateurs Amity, qui sont des collections de services plumes spécifiques à la gestion des types de bases de données. Je n'ai fait que la version MongoDB.

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

amity-mongodb vous permet de gérer un serveur MongoDB entier. Il utilise plusieurs services de plumes :

• feathers-mongo-databases
• feathers-mongo-collections
• feathers-mongo-users À venir dans la version Auth
• feathers-mongodb

Puisque tout utilise les services Feathers, au fur et à mesure que vous ajoutez/supprimez des bases de données et des collections, il se met à jour en temps réel.

Je n'ai pas encore mis à niveau le serveur amity vers Feathers 2.0. Vous pouvez en récupérer tout ce que vous pouvez. :)

Je l'ai rendu complètement modulaire, vous pouvez donc créer votre propre interface utilisateur au-dessus des adaptateurs d'amitié si vous le souhaitez.

vous connaissez probablement déjà ng-admin. J'aime la façon dont ils gèrent un backend spécifique. Je n'aime pas angular donc j'ai presque fini de le porter sur riot.js

Je vais aussi dire qu'il y a une assez bonne alternative appelée http://forestadmin.com/. Il est payant et hébergé mais peut fonctionner localement gratuitement. Le créateur m'a dit que si vous chargez simplement le middleware Feathers après le middleware Forest, cela fonctionne immédiatement. Je vais essayer sous peu.

@ekryski @SeyZ
C'est un logiciel gratuit ?

Hey @josx - Nous avons un plan gratuit pour 1 utilisateur :)

Si vous l'avez essayé / utilisé / vu - le cadre de l'API StrongLoop génère une très belle interface utilisateur Web pour votre service RestFUL ... Qui est maintenant http://loopback.io je suppose (après l'acquisition de Strongloop par IBM). Quoi qu'il en soit, il y a peut-être quelque chose qui vaut la peine d'être brillant ...

@ekryski - a regardé forestadmin.com mais je ne vois pas où/comment cela peut fonctionner en local gratuitement ? Nous envisageons d'utiliser feathersjs pour baser notre entreprise de nouvelle génération (derrière des pare-feu sans accès Internet), donc j'espère que tout / tout pourra être hébergé localement .. :)

Hey @sjmcdowall - Vous pouvez l'installer sur votre application en utilisant le package Forest en fonction de l'ORM que vous utilisez : Sequelize , Mongoose ou même Loopback .

Vous pouvez essayer Forest sur votre environnement localhost ( http://localhost... ) car les données transitent directement de votre navigateur vers votre application sans passer par Forest.

C'est entièrement gratuit pour 1 utilisateur administrateur 👍

C'est une bonne idée. Strapi et Treeline (même équipe derrière Sails) l'ont implémenté.

@ekryski comment Forest Admin s'est-il bien passé pour vous ? Cela a-t-il demandé beaucoup de bricolage? Nous avons créé notre propre interface utilisateur d'administration personnalisée en réaction, mais ce serait bien de supprimer la charge de travail si la forêt fonctionne bien dans la boîte ?

@Mentioum Je n'ai pas eu de chance avec la mangouste sur le projet et nous étions assez pressés par le temps, alors nous sommes allés à ng-admin. Essayer de régler avec l'équipe Forest si c'est quelque chose avec Forest, Feathers ou si je suis juste stupide. Je devrais avoir un peu de temps pour lui donner une autre chance plus tard cette semaine. Je reviendrai certainement.

@Mentioum Permettez-moi d'intervenir, je travaille avec @SeyZ sur Forest. Nous allons enquêter sur le problème avec @ekryski. Dans tous les cas, si vous souhaitez essayer Forest, n'hésitez pas à contacter Sandro ou moi (les e-mails sont [email protected]) et nous réglerons tout problème ensemble.

J'ai Forest travaillant sur FeathersJS avec Sequelize pour un projet parallèle, donc le problème pourrait être limité à la mangouste. Voici un aperçu du fichier app.js qui n'a été modifié que pour ajouter Forest.

Désolé mais je ne vois pas l'intérêt de travailler sur un administrateur comme la forêt que ce n'est pas un logiciel libre/open source.
Je pense que nous ferions mieux de travailler sur ngadmin ou similaire.

merci @ekryski .

merci @VinzGhyz. C'est super gentil mais non merci. Jusqu'à ce que je sache que cela fonctionne avec la mangouste prête à l'emploi, je n'ai pas le temps de m'y engager car nous avons déjà une solution de travail que nous maintenons nous-mêmes. La seule raison pour nous de changer serait une charge de travail de 0 / moins de charge de travail que notre solution actuelle.

Je vais regarder pour voir ce qui se passe.

(Je sais que je l'ai déjà mentionné, mais je pense en fait que KeystoneJS a un excellent administrateur généré automatiquement avec des options assez solides basées sur ElementalUI (réagir)) @JedWatson aurait probablement une bonne idée de la meilleure façon de procéder.

@Mentioum merci pour la mention, j'aimerais penser que c'est ce que KeystoneJS a 😀

Nous discutons en fait de la manière dont nous pouvons nous concentrer davantage sur les deux concepts de base avec lesquels Keystone est vraiment fort : les listes Keystone et l'interface utilisateur d'administration. Je n'ai pas plongé profondément dans Feathers depuis un moment, mais ce que j'ai vu a fière allure et se concentre sur un domaine légèrement différent.

Notre prochaine version majeure est imminente (en espérant livrer une version bêta dans les prochains jours environ) qui a été une réécriture d'un an, y compris une interface utilisateur entièrement réactive / redux et de nouvelles API. Je serais certainement ouvert à travailler avec Feathers pour trouver comment réduire une partie du croisement et rendre nos projets compatibles, si cela vous intéresse.

Nous espérons également nous libérer de la connexion difficile à la mangouste dans un avenir pas trop lointain, ce qui pourrait en faire un meilleur ajustement, si nous pouvons trouver la bonne flexibilité dans la façon dont vous vous connectez à une API/datastore .

Équipe Feathers - n'hésitez pas à nous contacter si vous souhaitez approfondir cette question.

@JedWatson génial. Nous devrions totalement collaborer. Hâte de voir la nouvelle version. En fait, j'avais espéré / réfléchi à la façon dont nous pourrions pirater Keystone pour avoir Feathers comme élément principal.

@Mentioum Je suis exactement dans le même bateau que toi. Trop occupé. J'espère pouvoir me consacrer environ une demi-heure cette semaine pour voir si je peux faire fonctionner Forest.

Nous avons été assez impressionnés par ng-admin (même si je ne suis pas un grand fan d'Angular). Cependant, il y a encore beaucoup de passe-partout/redondance que vous finissez par faire côté client pour prendre en charge des éléments que vous avez déjà définis dans les schémas côté serveur.

Mettre Keystone sur Feathers serait de l'or ! J'y contribuerai.

@JedWatson @ekryski @daffl

Pas de problème j'ai fait plein de trucs avec Keystone (je suis fan) (idem avec feathers) :

http://161london.com (travail client)
http://thenidocollection.com (travail client)
http://headstartapp.com (démarrage actuel)

Et nous utilisons Feathers comme un moyen simple d'afficher de nombreux petits services qui alimentent les applications Headstart réelles (All React et React Native atm - certaines avec Electron l'enveloppant pour les entreprises qui détestent les "applications de navigateur").

Cela peut être un peu exagéré, mais si vous pensez vraiment à la clé de voûte ayant une sorte d'ORM, ne serait-il pas plus cool d'utiliser des plumes comme un microservice qui fonctionne à côté de la clé de voûte et vous l'utilisez simplement?

De cette façon, Keystone peut toujours avoir sa solution "clé en main" qui génère tout avec la mangouste, mais si vous voulez être un peu plus sophistiqué, vous pouvez créer des microservices Feathers pour des listes spécifiques auxquelles vous fournissez un point de terminaison à un service Feathers spécifique.

Je suis sûr que vous avez une bien meilleure idée de la façon de le structurer. (Obs, vous pouvez simplement le faire avec des itinéraires express dans Keystone, mais vous n'auriez alors pas d'administrateur à génération automatique :))

Vraiment avoir de petits rêves Dockerstack en ce moment :

redis,
mongodb,
clé de voûte,
plumes-microservice1,
plumes-microservicex,
PSgress,
Recherche élastique
etc....
....

Quoi qu'il en soit, inutile de dire si cela peut être une chose ... je serais partant.

Salut les gars. Si vous avez commencé à construire ce projet, pouvez-vous donner un lien vers votre référentiel ou autre chose pour que les gens puissent le surveiller ?

+1 aimerait voir des exemples de modèles, en utilisant la clé de voûte avec des plumes.

C'est certainement une bonne idée d'avoir un backend généré automatiquement.

Pour les développeurs qui utilisent GraphQL, cela peut être une bonne solution : GraphQL génère automatiquement un CMS .

J'ai un projet sur lequel je travaille depuis un certain temps qui peut être utile/intéressant : NodeMDA est un moteur de génération de code qui prend des modèles UML et génère du code source. Vous pouvez modéliser des concepts de haut niveau comme "Entité" et "Service", et obtenir une pile entière générée pour vous. Je viens de terminer un plugin qui génère une application complète en utilisant Feathers côté serveur et React + Material-UI côté client. Chaque entité que vous modélisez obtient un éditeur CRUD complet.

L'ensemble du framework est sous licence MIT, mais il ne dispose pas actuellement de son propre outil de modélisation. J'utilise actuellement StarUML pour mon application de modélisation, mais c'est uniquement parce qu'elle était peu coûteuse et que ses métadonnées étaient stockées dans JSON plutôt que dans un document xml (comme XMI). Bien que StarUML soit un produit commercial, il dispose d'une période d'évaluation gratuite et illimitée (son nag ware). Je ne suis en aucun cas affilié à StarUML - c'est juste que leur outil de modélisation a répondu à mes besoins immédiats. NodeMDA prend cependant en charge les lecteurs enfichables. J'ai sur ma feuille de route à long terme pour écrire un éditeur de classe UML rapide et sale afin que les gens puissent l'utiliser sans rien payer.

J'avais l'habitude de contribuer à un projet Java MDA (AndroMDA), et je voulais avoir quelque chose de similaire dans le monde Node, alors j'ai bidouillé NodeMDA. Le moteur lui-même fonctionne plutôt bien. Il est assez facile de créer de NOUVEAUX plugins pour générer du code d'une manière différente, ou même dans un langage différent. J'aime dire "c'est opiniâtre, mais ouvert d'esprit".

Puisqu'il fait des plumes à l'arrière, vous pouvez le trouver utile tout de suite, ou cela peut constituer un bon point de départ pour autre chose. Vérifiez-le:

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

et le plugin plumes est ici :

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

peut-être que nous pouvons l'utiliser : https://github.com/ForestAdmin/lumber

ce serait bien de faire quelque chose avec admin-on-rest

Si quelqu'un est intéressé. J'ai commencé à travailler sur un fork de evolutility-ui-react pour ajouter le support de l'API feathers. Je viens littéralement de commencer, mais le CRUD de base fonctionne pour des modèles simples, et à mi-chemin pour les fichiers binaires ... la base de code d'origine peut utiliser un peu de refactorisation et j'ai besoin d'ajouter un support pour/tester un tas de types de champs , mais cela pourrait être utile à quelqu'un. Je vais pousser plus de changements au cours des prochaines semaines.

A propos du problème de

soutenir la saveur frontale du jour

Je crois que Svelte résout assez bien ce problème ( github ). Tout ce qui est fait avec lui est universel et devient du JavaScript vanille sans framework.

Je le suggère fortement car il est à l'épreuve du temps et toujours interchangeable avec n'importe quelle technologie "du jour"

@ddela-cr j'ai lancé un projet pour écrire un client de repos de plumes personnalisé pour admin-on-rest .
Merci de vérifier, contribution bienvenue...

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

Nous avons publié une nouvelle version pour https://github.com/josx/aor-feathers-client et nous avons également une preuve de travail sur https://github.com/Cambalab/test-feathers-admin

Comme j'ai lutté avec ce même sujet pendant un certain temps, j'aimerais également partager mon approche en utilisant ng-admin (le frère aîné admin-on-rest basé sur l'ancien AngularJS).

J'ai extrait la configuration minimale requise pour que ng-admin & ng-admin.jwt-auth fonctionnent avec Feathers et je l'ai transformée en un référentiel soigneusement conçu : https://github.com/beevelop/feathers-admin-starter

@beevelop bravo !

Il y a quelques jours, j'ai fait presque la même chose avec ng-admin (mais votre version a plus de fonctionnalités). Ici un repo avec (feathers app, ngadmin et admin-on-rest).

Peut-être pouvons-nous améliorer le même exemple avec ng-admin et admin-on-rest + feathers.

Salut les gars,

Chaque framework doit réinventer la roue de l'interface d'administration. Il y a un "feather admin", un "laravel admin", un "rails admin", etc. Fou, n'est-ce pas ? C'est pourquoi j'ai publié Lumber (https://github.com/ForestAdmin/lumber) - au lieu d'être branché sur votre application, il en génère un nouveau spécialement pour l'administrateur (en d'autres termes, il génère un microservice d'administration) .

Que pensez-vous de cette solution ?

@SeyZ dans mon projet n'est pas viable, car nous décidons d'avoir le contrôle sur tous les logiciels. Donc, si ce n'est pas un logiciel gratuit, je ne peux pas acheter de service.

Aussi du point de vue du développeur, je pense que vous avez fait un excellent travail, mais ce n'est pas utile pour la communauté.

Vous pensez peut-être à un modèle commercial qui inclut le logiciel libre comme noyau.
Juste mes 2 centimes.

@josx Lumber est complètement open source et Forest est un service qui vous donne automatiquement une super interface utilisateur (j'espère :D). Tout est entièrement gratuit bien sûr !

Jetez un œil à la version mise à jour de admin-on-rest . Il a l'air incroyable.

Je pense qu'il y a de très bonnes solutions ici maintenant, donc je vais fermer ça pour l'instant. L'équipe de base ne travaille sur rien d'officiel et n'a pas l'intention de le faire à court terme.

Ce problème devient long, mais je ne veux pas le verrouiller au cas où quelque chose de nouveau arriverait. Si vous tombez sur quelque chose qui n'a pas encore été mentionné et que vous pensez être un bon choix, n'hésitez pas à le poster ! Si cela commence à devenir un forum de discussion ou si nous commençons à voir la même chose, nous verrouillerons le fil.

Merci pour toutes les contributions à tous ! Vous rendez la communauté incroyable ! ❤️

Dans un projet de toute envergure d'une manière ou d'une autre, vous devrez créer une page d'administration. Peut-être devrions-nous créer une page dans la documentation avec des liens vers différentes bibliothèques pour créer des pages d'administration GUI ? Je serais heureux d'avoir une solution prête à l'emploi, mais nous pouvons au moins recommander les meilleures solutions de qualité.

@kulakowka Il serait plus logique d'ajouter une section à la page Écosystème après la section des piles de démarrage. https://docs.feathersjs.com/v/auk/ecosystem/readme.html

Une solution équivalente basée sur Loopback et Angular existe également. Il s'appelle Colmena-cms (anciennement connu sous le nom de Loopback Angular Admin).

Combiner Feathers avec admin-on-rest est le plus logique car nous devrions alors nous concentrer principalement sur la construction du pont entre les deux sans avoir à nous concentrer sur la façon de rendre les pages d'administration.

Pour une telle nouvelle solution qui dépend des plumes et de l'administration au repos, nous aurions besoin d'un moyen permettant des mises à jour faciles de ces deux dépendances.

Je suppose que la construction et la maintenance d'une telle solution devraient demander moins d'efforts que Colmena.

J'ai contribué à colemena-cms dans le passé, mais c'est juste pour le bouclage. C'est pourquoi avoir une application comme admin on rest est l'option parfaite pour les plumes.

Jetez un oeil sur un plugin ou sur lequel nous travaillons. https://github.com/josx/aor-feathers-client

Quelqu'un a-t-il réussi à utiliser forestAdmin avec des plumes ?

@loiclouvet Cela fait un moment que je n'ai pas essayé mais j'ai réussi à faire travailler Forest le long des plumes dans le passé. J'adorerais réessayer aujourd'hui et publier un exemple de travail complet ici : https://github.com/forestadmin/forest-examples

Avis de non-responsabilité : Je suis le fondateur de Forest.

@SeyZ J'ai installé Forest avec des plumes (en utilisant de la mangouste) après quelques tentatives, je vais certainement essayer !

Je viens d'ajouter un exemple de travail pour intégrer Forest Admin à Feathers ici : https://github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database

N'hésitez pas si vous avez des questions ;)

@SeyZ J'ai configuré Forest admin avec mangouste, si je comprends bien, il contourne les crochets de plumes et injecte directement dans mongodb, n'est-ce pas?

@nadbm Vous avez tout à fait raison, donc je ne pense pas que l'administrateur de la forêt corresponde bien à Feathers. Personnellement, j'ai essayé et adopté admin-on-rest !

Ce problème a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème avec un lien vers ce problème pour les bogues associés.