Feathers: Bitte unterstützen Sie die GUI für CRUD

@takaaptech danke für den Vorschlag! Wir haben im @feathersjs/core-team ziemlich viel darüber gesprochen. Es sollte definitiv ein optionales Plugin sein, ist aber sicherlich machbar. Ich werde dies versuchsweise auf den 3.0-Meilenstein schlagen.

@ekryski vielen Dank! Federn ist wirklich toll!

Hey, mir gefällt die Idee, eine einfache GUI für CRUD-Vorgänge zu haben, und ich würde gerne mehr darüber erfahren, wie Sie dies angehen wollen. Benötigen Sie nicht so etwas wie JSON Schema, um Modelldefinitionen zu standardisieren, unabhängig davon, welches ORM unter der Haube verwendet wird? Ich habe viel mit dem automatischen Generieren von GUIs gemäß Schemas gearbeitet, und es ist von entscheidender Bedeutung, diese Schemas mit ihren Feldern verfügbar zu machen. Es ist auch sinnvoll, über Datenvalidierung (maxlength, String Regex usw.), Eigenschaftseditoren (Datum, Datumszeit oder Uhrzeit in einem Datumstypfeld bearbeiten) und so weiter nachzudenken.

Wäre es nicht sinnvoll, diese Schemadefinitionen (basierend auf einfachem, browserkompatiblem JSON und nicht auf diesen typischen Backbone-Erweiterungen wie bei Bookshelf) mit ihren Zuordnungen zu implementieren und Schemaadapter für die verschiedenen ORMs zu schreiben?

Dies würde es auch einfacher machen, Swagger zu implementieren und zwischen ORMs zu wechseln, da Sie Ihre Modelle nicht neu schreiben müssen.

Bearbeiten: Ich denke, es ist sehr wichtig, darüber nachzudenken, wie viel Federn datenunabhängig sein müssen. Aber ich sehe, Sie unternehmen große Anstrengungen, um Datensynchronisierung, Offline-Funktionen usw. zu implementieren. Daher denke ich, dass Federn stärker mit Datenmodellen verknüpft werden müssen, insbesondere wenn Sie über clientseitige Funktionen nachdenken.

Ich denke, es sollte ähnlich sein wie das, was Strapi anbietet. Sehen Sie sich seine studio und admin panel an.

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

Strapi ist eng mit der Wasserlinie gekoppelt und daher ist es einfacher, diese Funktion zu implementieren.

Das bietet übrigens auch parse, genannt parse-dashboard (https://github.com/ParsePlatform). Auch hier gibt es nicht so eine Flexibilität wie bei Federn, um zwischen ORMs zu wählen.

Ich kann es kaum erwarten zu hören, wie Federn das angehen werden, wenn sie sich wirklich entscheiden, diese Funktion bereitzustellen.

Eine Lösung, die ich sehe, wäre, das Feature in zwei Arten von Modulen aufzuteilen:

• ein Feathers-Plugin, das die Hauptaufgabe übernimmt, wie das Anzeigen der GUI
• ein Adapter für das Plugin zur Verwaltung des ORM

Wir hätten also ein einzigartiges Plugin und viele Adapter, einen für jedes ORM.

Wir haben hier ein paar Ideen und ich denke, es gibt verschiedene Teile davon:

1) Eine UI-Schnittstelle, um Ihre API visuell zusammenzustellen. Mit dem Fluss von Hooks und Services gibt es hier ein ziemliches Potenzial, denke ich.
2) Eine separate Verwaltungsoberfläche, mit der Sie mit Ihrer API arbeiten und Dienste durchsuchen können. Ähnlich wie Postman , aber speziell für Feathers.
3) Generieren eines CRUD-Admin-Backends in der App. Dies ist wahrscheinlich das Schwierigste und Schwierigste. Sie müssen verschiedene Implementierungen für verschiedene Frontend-Frameworks generieren (es sei denn, es gibt einen "offiziellen" Frontend-Stack auf Feathers) und Generatoren sind schwer zu warten und zu debuggen.

wirklich daran interessiert, niemals CRUD zu schreiben. für das, was es wert ist, mache ich das bereits in meinen eigenen Projekten mit tcomb , tcomb-form , feathers-tcomb und feathers-action . sehen Sie alles zusammen in business-stack . würde empfehlen. :)

@ahdinosaur das ist ziemlich krass. @daffl Ich denke, wir sollten einige dieser Sachen glänzen lassen. Mindestens feathers-tcomb oder so. Genauso hatte ich mir gedacht, dass wir mit Validierungen umgehen sollten, und egal, was wir verwenden, um dies zu erreichen, wir müssen eine Modell-/Ressourcendefinition haben, um automatisch API-Dokumente und eine CRUD-Benutzeroberfläche zu generieren. feathers-swagger füttert Swagger im Wesentlichen nur mit einer Mongoose-Modelldefinition.

Wir müssen entscheiden, wie wir das ein wenig aufteilen wollen, da wir so viele verschiedene DBs und ORMs haben. Ich könnte sehen, dass etwas wie tcomb ziemlich wertvoll ist, aber macht es den Zweck der Verwendung eines ORM zunichte? Das ist nicht unbedingt eine schlechte Sache, aber ich denke, dass es wichtig ist, in Ihrer Schema-/Modell-/Ressourcendefinition (wie auch immer Sie es nennen möchten) unabhängig von der darunter liegenden Datenbank konsistent zu sein. Es ist wichtig, Datenbanken leicht austauschbar zu machen, daher mag ich die Idee nicht, Sequelize-Modelle, Mongoose-Modelle zu verwenden, aber dann für andere DBs, die Tcomb oder so verwenden.

Für den UI-Teil von Admin oder so stimme ich zu:

A) Es ist eine Menge Arbeit, den Front-End-Geschmack des Tages zu unterstützen
B) Wenn wir ein Frontend implementieren, sagen wir in React, dann wird es nicht einfach sein, ein alternatives Frontend daneben zu verwenden.

Es muss also möglicherweise eine rechthaberische Front sein (das ist immer noch optional), aber wenn Sie beispielsweise React nicht verwenden möchten, ist das schade. Wenn wir es super leicht machen können, damit es für die Leute einfach zu replizieren ist und für die Community, verschiedene Front-Ends zu erstellen, dann könnte es wirklich gut funktionieren.

Inspiriert von Django habe ich mich nach etwas umgesehen, das eine CRUD-GUI oder eine Art Admin enthält. Ich habe mit der Idee herumgespielt, JSON-Schemas für eine Reihe von Modellen zu generieren. Mit diesen Schemas sollten Sie in der Lage sein, einen Validierungscode, Schemata für Mungo[1] und andere Modelle zu generieren. Einen Admin an Feathers zu schrauben, scheint relativ einfach zu sein, wenn man ein Schema und etwas in der Art von ng-admin[2] verwendet.

Ich denke, der Vorteil dieses Ansatzes wäre, dass kein Code speziell für Federn geschrieben werden muss (außer dem JSON-Schema-Generator und einigen generierten Klebern). Es gäbe keine Sorgen über den "Geschmack des Tages" und Federn bleiben Sie eigensinnig, wo es wirklich darauf ankommt, die REST- und Socket.io-Schnittstelle, die es bietet.

Nur meine 2 Cent, wenn jemand daran interessiert ist, möchte ich irgendwo in den nächsten 2 bis 3 Wochen einen Prototyp dafür aufbauen.

[1] Konverter von json-schema zu Mongoose: https://www.npmjs.com/package/json-schema-to-mongoose
[2] ng-admin, CRUD-Admin: https://github.com/marmelab/ng-admin

@AndreSteenveld Ich habe letztes Jahr angefangen, an so etwas zu arbeiten. Sie können sehen, was ich hier zusammengestellt habe: https://github.com/marshallswain/AmityApp. Es funktioniert im Wesentlichen rund um das Erstellen von sogenannten Amity-Adaptern, bei denen es sich um Sammlungen von Feather-Diensten handelt, die spezifisch für die Handhabung von Datenbanktypen sind. Ich habe nur die MongoDB-Version gemacht.

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

amity-mongodb können Sie einen ganzen MongoDB-Server verwalten. Es verwendet mehrere Federdienste:

• feathers-mongo-databases
• feathers-mongo-collections
• feathers-mongo-users Kommt in Auth-Release
• feathers-mongodb

Da alles die Feathers-Dienste verwendet, wird es beim Hinzufügen/Entfernen von Datenbanken und Sammlungen in Echtzeit aktualisiert.

Ich habe den amity -Server noch nicht auf Feathers 2.0 aktualisiert. Sie können gerne alles davon retten, was Sie können. :)

Ich habe es vollständig modular aufgebaut, sodass Sie Ihre eigene Benutzeroberfläche auf den Amity-Adaptern aufbauen können, wenn Sie möchten.

wahrscheinlich kennen Sie ng-admin bereits. Ich mag die Art und Weise, wie sie mit bestimmten Backends umgehen. Ich mag eckig nicht, also wäre ich fast fertig damit, das auf riot.js zu portieren

Ich werde auch darauf hinweisen, dass es eine ziemlich gute Alternative namens http://forestadmin.com/ gibt. Es ist kostenpflichtig und wird gehostet, kann aber kostenlos lokal arbeiten. Der Ersteller sagte mir, wenn Sie die Feathers-Middleware einfach nach der Forest-Middleware laden, funktioniert sie sofort. Ich werde es in Kürze ausprobieren.

@ekryski @SeyZ
Ist das kostenlose Software?

Hey @josx - Wir haben einen kostenlosen Plan für 1 Benutzer :)

Wenn Sie es ausprobiert / verwendet / gesehen haben – das StrongLoop-API-Framework generiert eine sehr schöne Web-Benutzeroberfläche für Ihren RestFUL-Dienst ... Was jetzt http://loopback.io ist, denke ich (nachdem IBM Strongloop erworben hat). Wie auch immer, vielleicht gibt es dort etwas, das es wert ist, zu glänzen ...

@ekryski - habe auf forestadmin.com geschaut, aber ich sehe nicht, wo / wie es lokal kostenlos funktionieren kann? Wir überlegen uns, Feathersjs zu verwenden, um unser Unternehmen der nächsten Generation (hinter Firewalls ohne Internetzugang) zu gründen, also kann hoffentlich alles / alles lokal gehostet werden .. :)

Hey @sjmcdowall – Sie können es je nach verwendetem ORM mit dem Forest-Paket in Ihrer App installieren: Sequelize , Mongoose oder sogar Loopback .

Sie können Forest in Ihrer Localhost-Umgebung ( http://localhost... ) ausprobieren, da Daten direkt von Ihrem Browser zu Ihrer Anwendung übertragen werden, ohne Forest zu durchlaufen.

Es ist völlig kostenlos für 1 Admin-Benutzer 👍

Das ist eine großartige Idee. Sowohl Strapi als auch Treeline (gleiches Team hinter Sails) haben dies implementiert.

@ekryski wie gut lief Forest Admin für dich? War viel Fummelei nötig? Wir haben unsere eigene benutzerdefinierte Admin-Benutzeroberfläche in React erstellt, aber es wäre schön, die Arbeitslast zu entfernen, wenn Forest problemlos funktioniert?

@Mentioum Ich hatte kein Glück mit Mungo bei dem Projekt und wir waren ziemlich unter Zeitdruck, also ging ich zu ng-admin. Ich versuche mit dem Forest-Team zu klären, ob es etwas mit Forest, Feathers ist oder ob ich einfach nur dumm bin. Sollte später in dieser Woche etwas Zeit haben, es noch einmal richtig zu versuchen. Werde auf jeden Fall berichten.

@Mentioum Gestatten Sie mir, mich einzumischen, ich arbeite mit @SeyZ an Forest. Wir werden das Problem mit @ekryski untersuchen. Wenn Sie daran interessiert sind, Forest auszuprobieren, können Sie sich auf jeden Fall entweder an Sandro oder mich wenden (E-Mails sind [email protected]) und wir werden jedes Problem gemeinsam lösen.

Ich habe Forest dazu gebracht, an FeathersJS mit Sequelize für ein Nebenprojekt zu arbeiten, daher könnte das Problem auf Mungo beschränkt sein. Hier ist ein Überblick über die app.js-Datei, die nur optimiert wurde, um Forest hinzuzufügen.

Tut mir leid, aber ich sehe keinen Sinn darin, an einem Admin-ähnlichen Wald zu arbeiten, dass es keine freie Software/Open Source ist.
Ich denke, wir sollten besser an ngadmin oder ähnlichem arbeiten.

danke @ekryski .

danke @VinzGhyz. Das ist furchtbar nett, aber nein danke. Bis ich weiß, dass es mit Mungo sofort funktioniert, habe ich keine Zeit, mich darauf einzulassen, da wir bereits eine funktionierende Lösung haben, die wir selbst warten. Der einzige Grund für uns zu wechseln wäre bei einer Arbeitslast von 0 / weniger Arbeitslast als unsere aktuelle Lösung.

Ich werde beobachten, was passiert.

(Ich weiß, dass ich es schon einmal erwähnt habe, aber ich denke tatsächlich, dass KeystoneJS einen großartigen automatisch generierten Admin mit ziemlich soliden Optionen hat, die auf ElementalUI (react) basieren.) @JedWatson hätte wahrscheinlich einen guten Einblick in die beste Vorgehensweise.

@Mentioum danke für die Erwähnung, ich würde gerne glauben, dass KeystoneJS das hat 😀

Wir diskutieren gerade darüber, wie wir uns mehr auf die beiden Kernkonzepte konzentrieren können, mit denen Keystone wirklich stark ist: Keystone-Listen und die Admin-Benutzeroberfläche. Ich habe eine Weile nicht mehr tief in Feathers eingetaucht, aber was ich gesehen habe, sieht großartig aus und konzentriert sich auf einen etwas anderen Bereich.

Unsere nächste Hauptversion steht kurz bevor (in der Hoffnung, am nächsten Tag oder so eine Beta auszuliefern), die ein Jahr lang neu geschrieben wurde, einschließlich einer vollständig reagierenden / reduzierten Benutzeroberfläche und neuen APIs. Ich wäre auf jeden Fall bereit, mit Feathers zusammenzuarbeiten, um herauszufinden, wie wir einen Teil des Crossovers reduzieren und unsere Projekte kompatibel machen können, falls das von Interesse ist.

Wir hoffen auch, uns in nicht allzu ferner Zukunft von der harten Verbindung zu Mungo befreien zu können, wodurch es vielleicht noch besser passt, wenn wir die richtige Flexibilität bei der Verbindung zu einer API / einem Datenspeicher finden .

Feathers-Team – zögern Sie nicht, uns zu kontaktieren, wenn Sie dies weiter erkunden möchten.

@JedWatson großartig. Wir sollten total zusammenarbeiten. Aufgeregt, die neue Version zu sehen. Ich hatte eigentlich gehofft/darüber nachgedacht, wie wir Keystone hacken könnten, um Feathers als Backend-Stück zu haben.

@Mentioum Ich sitze genau im selben Boot wie du. Zu beschäftigt. Hopefull wird in der Lage sein, sich diese Woche etwa eine halbe Stunde Zeit zu nehmen, um zu sehen, ob ich Forest zum Laufen bringen kann.

Wir waren ziemlich beeindruckt von ng-admin (auch wenn ich kein großer Fan von Angular bin). Es gibt jedoch immer noch viele Boilerplates/Redundanzen, die Sie auf der Clientseite ausführen, um Dinge zu unterstützen, die Sie bereits auf der Schemaserverseite definiert haben.

Keystone auf Federn zu setzen wäre Gold wert! Dazu werde ich beitragen.

@JedWatson @ekryski @daffl

Kein Problem, ich habe viele Sachen mit Keystone gemacht (ich bin ein Fan) (dasselbe mit Federn):

http://161london.com (Kundenarbeit)
http://thenidocollection.com (Kundenarbeit)
http://headstartapp.com (aktuelles Startup)

Und wir verwenden Feathers als eine einfache Möglichkeit, viele kleine Dienste zu öffnen, die die eigentlichen Headstart-Apps antreiben (All React und React Native atm – einige mit Electron-Wrapping für Unternehmen, die „Browser-Apps“ hassen).

Das mag ein bisschen langwierig sein, aber wenn Sie ernsthaft darüber nachdenken, Keystone mit einer Art ORM zu haben, wäre es nicht viel cooler, Federn als Microservice zu verwenden, der neben Keystone läuft, und Sie verwenden einfach das?

Auf diese Weise kann Keystone immer noch seine schlüsselfertige Lösung haben, die alles mit Mongoose generiert, aber wenn Sie etwas ausgefallener sein möchten, können Sie einige Feathers-Microservices für bestimmte Listen einrichten, die Sie einem bestimmten Feathers-Dienst als Endpunkt bereitstellen.

Ich bin sicher, ihr habt eine viel bessere Vorstellung davon, wie man es strukturiert. (Obs du es einfach mit Expressrouten in Keystone machen kannst, aber dann hättest du keinen automatisch generierenden Admin :))

Jetzt wirklich kleine Dockerstack-Träume haben:

redis,
Mongodb,
Schlussstein,
Federn-Microservice1,
Federn-Microservicex,
PSgress,
Elastische Suche
usw usw....
....

Wie auch immer, es ist unnötig zu sagen, ob dies eine Sache sein kann ... ich wäre bereit dafür.

Hallo Leute. Wenn Sie mit dem Aufbau dieses Projekts begonnen haben, können Sie einen Link zu Ihrem Repository oder irgendetwas anderem geben, damit die Leute es im Auge behalten können?

+1 möchte einige Musterbeispiele sehen, bei denen Keystone mit Federn verwendet wird.

Es ist sicherlich eine gute Idee, ein automatisch generiertes Backend zu haben.

Für Entwickler, die GraphQL verwenden, kann dies eine gute Lösung sein: GraphQL automatisch generierendes CMS .

Ich habe ein Projekt, an dem ich seit einiger Zeit arbeite und das vielleicht nützlich/interessant sein könnte: NodeMDA ist eine Codegenerierungs-Engine, die UML-Modelle verwendet und Quellcode generiert. Sie können Konzepte auf hoher Ebene wie „Entität“ und „Dienst“ modellieren und einen ganzen Stack für Sie generieren lassen. Ich habe gerade ein Plugin dafür fertiggestellt, das eine vollständige App mit Feathers auf der Serverseite und React + Material-UI auf der Clientseite generiert. Jede Entität, die Sie modellieren, erhält einen vollständigen CRUD-Editor.

Das gesamte Framework ist MIT-lizenziert, verfügt jedoch derzeit über kein eigenes Modellierungstool. Ich verwende derzeit StarUML für meine Modellierungs-App, aber das liegt nur daran, dass es kostengünstig war und seine Metadaten in JSON und nicht in einem XML-Dokument (wie XMI) gespeichert wurden. Während StarUML ein kommerzielles Produkt ist, haben sie eine kostenlose, unbegrenzte Testphase (ihre Nörgelware). Ich bin in keiner Weise mit StarUML verbunden - nur ihr Modellierungstool hat meine unmittelbaren Bedürfnisse erfüllt. NodeMDA unterstützt jedoch steckbare Lesegeräte. Ich habe auf meiner Langstrecken-Roadmap einen schnellen und schmutzigen UML-Klasseneditor geschrieben, damit die Leute ihn benutzen können, ohne etwas bezahlen zu müssen.

Ich habe früher zu einem Java-MDA-Projekt (AndroMDA) beigetragen und wollte etwas Ähnliches in der Node-Welt haben, also habe ich bei NodeMDA herumgehackt. Der Motor an sich läuft recht gut. Es ist ziemlich einfach, NEUE Plugins zu erstellen, um Code auf andere Weise oder sogar in einer anderen Sprache zu generieren. Ich sage gerne "es ist rechthaberisch, aber aufgeschlossen."

Da es Federn am hinteren Ende ausführt, finden Sie es vielleicht sofort nützlich, oder es kann ein guter Ausgangspunkt für etwas anderes sein. Hör zu:

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

und das Feder-Plugin ist hier:

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

vielleicht können wir es verwenden: https://github.com/ForestAdmin/lumber

wäre toll, etwas mit admin-on-rest zu machen

Falls es jemanden interessiert. Ich habe begonnen, an einem Fork von evolutility-ui-react zu arbeiten, um Unterstützung für die Feathers-API hinzuzufügen. Ich habe buchstäblich gerade erst angefangen, aber grundlegendes CRUD für einfache Modelle und teilweise für Binärdateien zum Laufen gebracht ... die ursprüngliche Codebasis kann ein wenig Refactoring gebrauchen, und ich muss eine Reihe von Feldtypen unterstützen/testen , aber es könnte für jemanden von Nutzen sein. Ich werde in den nächsten Wochen weitere Änderungen vornehmen.

Über das Problem der

Unterstützen Sie den Front-End-Geschmack des Tages

Ich glaube, dass Svelte das ziemlich gut löst ( github ). Alles, was damit gemacht wird, ist universell und wird zu Framework-losem Vanilla-JavaScript.

Ich empfehle es dringend, weil es zukunftssicher und immer mit jeder Technologie "des Tages" austauschbar ist.

@ddela-cr Ich habe ein Projekt gestartet, um einen benutzerdefinierten Feathers-Rest-Client für admin-on-rest zu schreiben.
Bitte überprüfen Sie es, Beitrag willkommen ...

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

Wir haben eine neue Version für https://github.com/josx/aor-feathers-client veröffentlicht und wir haben auch einen Proof of Work auf https://github.com/Cambalab/test-feathers-admin

Da ich seit geraumer Zeit mit genau diesem Thema zu kämpfen hatte, möchte ich auch meinen Ansatz mit ng-admin ( admin-on-rest 's älterer Bruder basierend auf dem einfachen alten AngularJS) teilen.

Ich habe die absolute Mindestkonfiguration extrahiert, die erforderlich ist, um ng-admin und ng-admin.jwt-auth dazu zu bringen, mit Feathers zu arbeiten, und daraus ein sorgfältig erstelltes Repo gemacht: https://github.com/beevelop/feathers-admin-starter

@beevelop gut gemacht!

Vor einigen Tagen habe ich fast dasselbe mit ng-admin gemacht (aber Ihre Version hat mehr Funktionen). Hier ein Repo mit (feathers app, ngadmin und admin-on-rest).

Vielleicht können wir dasselbe Beispiel mit ng-admin und admin-on-rest + feathers verbessern.

Hallo Leute,

Jedes Framework muss das Rad für die Admin-Oberfläche neu erfinden. Es gibt einen "Feder-Admin", einen "Laravel-Admin", einen "Rails-Admin" usw. Verrückt, nicht wahr? Aus diesem Grund habe ich Lumber (https://github.com/ForestAdmin/lumber) veröffentlicht – anstatt in Ihre Anwendung eingesteckt zu werden, generiert es eine neue Anwendung speziell für den Administrator (mit anderen Worten, es generiert einen Admin-Microservice). .

Was haltet ihr von dieser Lösung?

@SeyZ in meinem Projekt ist nicht realisierbar, da wir uns dafür entscheiden, die Kontrolle über die gesamte Software zu haben. Wenn es sich also nicht um freie Software handelt, kann ich keinen Dienst kaufen.

Auch aus Entwicklersicht denke ich, dass Sie eine großartige Arbeit geleistet haben, aber es ist nicht nützlich für die Community.

Sie denken vielleicht an ein Geschäftsmodell, das kostenlose Software als Kern beinhaltet.
Nur meine 2 Cent.

@josx Lumber ist vollständig Open Source und Forest ist ein Dienst, der Ihnen automatisch eine großartige Benutzeroberfläche bietet (hoffe ich: D). Alles ist natürlich völlig kostenlos!

Werfen Sie einen Blick auf die aktualisierte Version von admin-on-rest . Es sieht erstaunlich aus.

Ich denke, es gibt hier jetzt einige ziemlich gute Lösungen, also werde ich das jetzt schließen. Das Kernteam arbeitet an nichts Offiziellem und hat auch keine Pläne, dies kurzfristig zu tun.

Diese Ausgabe wird langwierig, aber ich möchte sie nicht sperren, falls etwas Neues auftaucht. Wenn Sie auf etwas stoßen, das noch nicht erwähnt wurde und das Ihrer Meinung nach gut passen würde, können Sie es gerne posten! Wenn dies nur ein Diskussionsforum wird oder wir anfangen, zu viel vom Gleichen zu sehen, werden wir den Thread sperren.

Danke für den Input an alle! Ihr macht die Community großartig! ❤️

In einem Projekt jeder Größenordnung müssen Sie auf die eine oder andere Weise eine Admin-Seite erstellen. Vielleicht sollten wir eine Seite in den Dokumenten mit Links zu verschiedenen Bibliotheken zum Erstellen von GUI-Admin-Seiten erstellen? Ich würde mich freuen, eine Lösung sofort einsatzbereit zu haben, aber wir können zumindest die qualitativ besten Lösungen empfehlen.

@kulakowka Es wäre am sinnvollsten, der Ecosystem-Seite nach dem Starter-Stacks-Abschnitt einen Abschnitt hinzuzufügen. https://docs.feathersjs.com/v/auk/ecosystem/readme.html

Eine gleichwertige Lösung auf Basis von Loopback und Angular existiert ebenfalls. Es heißt Colmena-cms (früher bekannt als Loopback Angular Admin).

Die Kombination von Feathers mit Admin-on-Rest ist am sinnvollsten, da wir uns dann hauptsächlich darauf konzentrieren müssten, die Brücke zwischen den beiden zu bauen, ohne uns darauf konzentrieren zu müssen, wie Admin-Seiten gerendert werden.

Für eine solche neue Lösung, die von Feathers und Admin-on-Rest abhängt, bräuchten wir einen Weg, der einfache Updates dieser beiden Abhängigkeiten ermöglicht.

Ich nehme an, dass der Aufbau und die Wartung einer solchen Lösung weniger Aufwand erfordern sollte als Colmena.

Ich habe in der Vergangenheit zu colemena-cms beigetragen, aber es ist nur für Loopback. Aus diesem Grund ist eine App wie Admin in Ruhe die perfekte Option für Federn.

Werfen Sie einen Blick auf ein oder mehrere Plugins, an denen wir arbeiten. https://github.com/josx/aor-feathers-client

Ist es jemandem gelungen, forestAdmin zusammen mit Federn zu verwenden?

@loiclouvet Es ist schon eine Weile her, seit ich es versucht habe, aber ich habe Forest in der Vergangenheit erfolgreich dazu gebracht, an Federn zu arbeiten. Würde es gerne heute noch einmal versuchen und hier ein voll funktionsfähiges Beispiel veröffentlichen: https://github.com/forestadmin/forest-examples

Haftungsausschluss: Ich bin der Gründer von Forest.

@SeyZ Ich habe Forest mit Federn (mit Mungo) nach ein paar Versuchen eingerichtet, werde es auf jeden Fall ausprobieren!

Ich habe gerade ein funktionierendes Beispiel zur Integration von Forest Admin in Feathers hier hinzugefügt: https://github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database

Zögern Sie nicht, wenn Sie Fragen haben ;)

@SeyZ Ich habe Forest Admin mit Mungo eingerichtet, wie ich es verstehe, umgeht es die Federhaken und injiziert direkt in Mongodb, richtig?

@nadbm Du hast völlig Recht, also glaube ich nicht, dass Forest Admin gut zu Feathers passt. Persönlich habe ich Admin-on-Rest ausprobiert und übernommen!

Dieses Problem wurde automatisch gesperrt, da es nach dem Schließen keine Aktivitäten mehr gab. Bitte öffnen Sie ein neues Problem mit einem Link zu diesem Problem für verwandte Fehler.