Feathers: CRUDのGUIをサポートしてください

@takaaptech提案をありがとう！ これについては@feathersjs / core-teamの間でかなり話し合っています。 それは間違いなくオプションのプラグインであるはずですが、確かに実行可能です。 これを3.0マイルストーンで暫定的に叩きます。

@ekryskiどうもありがとう！ 羽は本当に素晴らしいです！

ねえ、私はCRUD操作用のシンプルなGUIを用意するというアイデアが好きで、これにどのように取り組む予定かについてもっと知りたいです。 内部で使用されているORMに関係なく、モデル定義を標準化するためにJSONスキーマのようなものが必要ではありませんか？ 私はスキーマに従ってGUIを自動的に生成することに多くの作業を行ってきましたが、それらのスキーマをフィールドとともに公開することは非常に重要です。 また、データ検証（maxlength、string regexなど）、プロパティエディター（日付タイプフィールドでの日付、日時、または時刻の編集）などについて考えることも理にかなっています。

これらのスキーマ定義（本棚のような典型的なバックボーンスタイルの拡張機能ではなく、単純なブラウザー互換のJSONに基づく）をそれらの関連付けで実装し、さまざまなORM用のスキーマアダプターを作成することは意味がありませんか？

これにより、モデルを書き直す必要がなくなるため、Swaggerの実装やORMの切り替えも簡単になります。

編集：データにとらわれない羽がどれだけ必要かを考えることは非常に重要だと思います。 しかし、データ同期やオフライン機能などを実装するために多くの努力を払っていると思います。そのため、特にクライアント側の機能について考える場合、フェザーはデータモデルとより密接に結びつく必要があると思います。

ストラピが提供するものと似ているはずだと思います。 彼のstudioとadmin panelを見てください。

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

ストラップは喫水線と緊密に結合されているため、この機能を簡単に実装できます。

ちなみに、parseはparse-dashboard（https://github.com/ParsePlatform）と呼ばれるこれも提供しています。 ここでも、ORMを選択するためのフェザーのような柔軟性はありません。

彼らが本当にこの機能を提供することを決定した場合、羽がこれにどのように取り組むかを聞くのが待ちきれません。

私が見る解決策は、機能を2つのタイプのモジュールに分割することです。

• GUIの表示などの主な仕事を行うfeathersプラグイン
• プラグインがORMを管理するためのアダプター

したがって、ORMごとに1つずつ、固有のプラグインと多くのアダプターがあります。

ここにはいくつかのアイデアがあり、これにはさまざまな部分があると思います。

1）APIを視覚的にまとめるためのUIインターフェース。 フックとサービスの流れにより、ここにはかなりの可能性があると思います。
2）APIを操作してサービスを参照できるようにする個別の管理インターフェース。 ポストマンのようなものですが、特にフェザー用です。
3）アプリでCRUD管理バックエンドを生成します。 これはおそらく最も困難で最も難しいことです。 さまざまなフロントエンドフレームワークに対してさまざまな実装を生成する必要があり（フェザーの上に「公式」フロントエンドスタックがない限り）、ジェネレーターの保守とデバッグは困難です。

CRUDを絶対に書かないことに本当に熱心です。 価値があるので、私はすでに自分のプロジェクトでtcomb 、 tcomb-form 、 feathers-tcomb 、およびfeathers-actionを使用してこれを行っています。 business-stackですべてを一緒に見てください。 お勧めします。 :)

@ahdinosaurそれはかなりラッドです。 @daffl私たちはそのようなもののいくつかを輝かせたいと思うかもしれません。 少なくともfeathers-tcombか何か。 まさにそれが私たちが検証を処理するべきだと思っていた方法であり、これを達成するために何を使用しても、APIドキュメントとCRUDUIを自動的に生成するためにモデル/リソース定義が必要になります。 feathers-swagger基本的に、マングースモデルの定義をSwaggerにフィードするだけです。

非常に多くの異なるDBとORMがあることを考えると、これをどのようにスライスするかを決定する必要があります。 tcombのようなものはかなり価値があることがわかりましたが、ORMを使用する目的を損なうのでしょうか？ これは必ずしも悪いことではありませんが、下にあるDBに関係なく、スキーマ/モデル/リソース定義（どのように呼んでも）で一貫性を保つことが重要だと思います。 データベースを簡単に交換できるようにすることは重要なので、Sequelizeモデル、マングースモデルを使用するというアイデアは好きではありませんが、Tcombなどを使用する他のDBの場合は好きです。

管理者のUI部分などについては、次のことに同意します。

A）その日のフロントエンドフレーバーをサポートするのは大変な作業です
B）たとえば、Reactでフロントエンドを実装する場合、それと一緒に別のフロントエンドを使用するのは簡単ではありません。

したがって、それは意見のあるフロントである必要があるかもしれませんが（それはまだオプションです）、たとえば、Reactを使用したくない場合は、あまりにも悪いです。 人々が複製しやすく、コミュニティがさまざまなフロントエンドを作成しやすいように、超軽量にすることができれば、非常にうまく機能する可能性があります。

Djangoに触発されて、CRUD-GUIまたはある種の管理者に付属するものを探していました。 私はたくさんのモデルのJSONスキーマを生成するというアイデアで遊んでいます。 これらのスキーマを使用すると、検証コード、mongoose [1]およびその他のモデルのスキーマを生成できるはずです。 管理者をフェザーにボルトで固定することは、ng-admin [2]の方針に沿ったスキーマと何かを使用すると比較的簡単に思えます。

このアプローチの利点は、フェザー用に特別にコードを記述する必要がないことだと思います（JSONスキーマジェネレーターと生成された接着剤を除く）「今日のフレーバー」についての心配はなく、フェザーはそれが本当に重要な場所、それが提供するRESTおよびSocket.ioインターフェースについて意見を述べ続けてください。

ちょうど私の2セント、誰かがこれに興味があるなら、私は次の2〜3週間のどこかにこれのプロトタイプをセットアップしたいと思います。

[1] json-schemaからmongooseへのコンバーター： https ：//www.npmjs.com/package/json-schema-to-mongoose
[2] ng-admin、CRUD管理者： https ：//github.com/marmelab/ng-admin

@AndreSteenveld私は昨年このようなものに取り組み始めました。 https://github.com/marshallswain/AmityAppで私がまとめたものを見ることができます。 これは基本的に、データベースタイプの処理に固有のフェザーサービスのコレクションであるAmityアダプターと呼ばれるものを作成することを中心に機能します。 私はMongoDBバージョンのみを作成しました。

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

amity-mongodbを使用すると、MongoDBサーバー全体を管理できます。 それはいくつかの羽のサービスを使用します：

• feathers-mongo-databases
• feathers-mongo-collections
• feathers-mongo-users Authリリースで登場
• feathers-mongodb

すべてがFeathersサービスを使用するため、データベースとコレクションを追加/削除すると、リアルタイムで更新されます。

amityサーバーをまだFeathers2.0にアップグレードしていません。 あなたはそれからあなたができることは何でも救うことを歓迎します。 :)

完全にモジュール化したので、必要に応じてamityアダプターの上に独自のUIを構築できます。

あなたはおそらくng-adminを知っています。 私は彼らが特定のバックエンドを処理する方法が好きです。 私はAngularが好きではないので、それをriot.jsに移植することはほとんど完了しました。

また、 http：//forestadmin.com/と呼ばれるかなり良い代替手段のように見えることも捨てます。 有料でホストされていますが、ローカルで無料で作業できます。 作成者は、Forestミドルウェアの後にFeathersミドルウェアをロードするだけで、そのまま使用できると言っていました。 すぐに試してみます。

@ekryski @SeyZ
それは自由ソフトウェアですか？

ちょっと@ josx -1人のユーザーのための無料プランがあります:)

試した/使用した/見た場合-StrongLoopAPIフレームワークはRestFULサービス用の非常に優れたWebUIを生成します...これは現在http://loopback.ioです（IBMがStrongloopを買収した後）。 とにかく、キラリと光る価値のあるものがあるかもしれません...

@ ekryski-forestadmin.comを見ましたが、どこで/どのようにローカルで無料で機能するのかわかりませんか？ 私たちはfeathersjsを使用して次世代のエンタープライズ（インターネットアクセスのないファイアウォールの背後）の基盤となることを検討しているので、うまくいけば何でも/すべてをローカルでホストできます.. :)

ちょっと@ sjmcdowall-使用するORMに応じて、Forestパッケージを使用してアプリにインストールできます： Sequelize 、 Mongoose 、さらにはLoopback 。

データはフォレストを通過せずにブラウザからアプリケーションに直接転送されるため、ローカルホスト環境（ http://localhost... ）でフォレストを試すことができます。

1人の管理者ユーザーは完全に無料です👍

これは素晴らしいアイデアです。 ストラピとツリーライン（セイルズの背後にある同じチーム）の両方がこれを実装しています。

@ekryski Forest Adminはあなたのためにどれくらいうまくいきましたか？ それは多くのいじりを必要としましたか？ 私たちはreactで独自のカスタム管理UIを構築してきましたが、フォレストがすぐに機能する場合は、ワークロードを削除するとよいでしょうか？

@Mentioumプロジェクトでマングースに運がなかったので、かなり時間に追われていたので、ng-adminに行きました。 それがForest、Feathersの問題なのか、それとも私が愚かなのか、Forestチームと一緒に整理しようとしています。 今週後半にもう一度適切に行く時間を与える必要があります。 間違いなく報告します。

@Mentioumチャイムを鳴らしてください。フォレストで@SeyZを使用しています。 @ekryskiで問題を調査します。 いずれにせよ、Forestの試用に興味がある場合は、Sandroまたは私（メールアドレスは[email protected]）に連絡してください。問題があれば、一緒に解決します。

サイドプロジェクトのために、ForestがSequelizeを使用してFeathersJSに取り組んでいるので、問題はマングースに限定される可能性があります。 これは、フォレストを追加するために微調整されただけのapp.jsファイルの要点です。

申し訳ありませんが、フォレストのような管理者で作業することのポイントは、フリーソフトウェア/オープンソースではないということはわかりません。
ngadmino同様の作業を行う方がよいと思います。

ありがとう@ekryski 。

ありがとう@VinzGhyz。 それはひどく親切ですが、ありがとうございません。 箱から出してマングースで動作することがわかるまで、私たちは自分たちで維持している実用的なソリューションをすでに持っているので、それにコミットする時間がありません。 切り替える唯一の理由は、現在のソリューションよりも作業負荷が0 /作業負荷が少ない場合です。

私は何が起こるかを見守っています。

（私は前にそれについて言及したことを知っていますが、実際にはKeystoneJSにはElementalUI（react）に基づくかなり堅実なオプションを備えた優れた自動生成管理者がいると思います） @JedWatsonはおそらくこれを行うための最良の方法についていくつかの良い洞察を持っているでしょう。

@Mentioum言及してくれてありがとう、私はそれがKeystoneJSが持っているものだと思いたいです😀

Keystoneが本当に強力な2つのコアコンセプトであるKeystoneリストと管理UIにさらに焦点を当てる方法について実際に話し合っています。 私はしばらくの間Feathersを深く掘り下げていませんが、私が見たものは素晴らしく見え、それはわずかに異なる領域に焦点を合わせています。

次のメジャーバージョンが間近に迫っています（翌日かそこらでベータ版を出荷することを望んでいます）。これは、完全に反応する/ reduxUIと新しいAPIを含む1年にわたる書き直しです。 興味があれば、フェザーと協力して、クロスオーバーの一部を減らし、プロジェクトに互換性を持たせる方法を見つけたいと思います。

また、API /データストアへの接続方法に適切な柔軟性を持たせることができれば、マングースとのハード接続からそれほど遠くない将来に解放されることを望んでいます。これにより、マングースはさらに適切になる可能性があります。 。

フェザーチーム-これをさらに調査したい場合は、お気軽にご連絡ください。

@JedWatsonすごい。 完全に協力する必要があります。 新しいバージョンを見て興奮しています。 私は実際、KeystoneをハックしてFeathersをバックエンドピースにする方法を期待/考えていました。

@Mentioum私はあなたとまったく同じ船に乗っています。 あまりにも忙しい。 Hopefullは、今週30分ほどで切り分けて、Forestを機能させることができるかどうかを確認できるようになります。

私たちはng-adminにかなり感銘を受けています（私はAngularの大ファンではありませんが）。 ただし、スキーマサーバー側で既に定義したものをサポートするために、クライアント側で実行することになる定型文/冗長性はまだたくさんあります。

キーストーンを羽につけるのは金だろう！ 私はそれに貢献します。

@JedWatson @ekryski @daffl

Keystone（私はファンです）（羽毛と同じ）でたくさんのものを作ったので問題ありません：

http://161london.com （クライアントワーク）
http://thenidocollection.com （クライアントワーク）
http://headstartapp.com （現在のスタートアップ）

そして、実際のヘッドスタートアプリを強化する多くの小さなサービスをポップアップする簡単な方法としてFeathersを使用しています（すべてのReactおよびReact Native atm-「ブラウザーアプリ」を嫌う企業向けにElectronがラップしているものもあります）。

これは少し難しいかもしれませんが、ある種のORMを持つキーストーンについて真剣に考えているのであれば、キーストーンと一緒に実行されるマイクロサービスとしてフェザーを使用する方がはるかにクールではないでしょうか。

そうすれば、keystoneはマングースですべてを生成する「ターンキー」ソリューションを持つことができますが、もう少し凝ったものにしたい場合は、特定のFeathersサービスにエンドポイントを提供する特定のリスト用にいくつかのFeathersマイクロサービスを起動できます。

皆さんはそれをどのように構成するかについてもっと良い考えを持っていると確信しています。 （Obsは、Keystoneの高速ルートでそれを行うことができますが、自動生成管理者はありません:)）

本当に今小さなDockerstackの夢を持っています：

redis、
mongodb、
キーストーン、
羽毛-microservice1、
羽毛-microservicex、
PSgress、
Elasticsearch
などなど...
...。

とにかく、これが問題になる可能性があるかどうかは言うまでもありません... idはそれに賛成です。

やあみんな。 このプロジェクトの構築を開始した場合、他の人がプロジェクトを監視できるように、リポジトリなどへのリンクを提供できますか？

+1は、羽のあるキーストーンを使用したいくつかのパターンの例を見たいと考えています。

自動生成されたバックエンドを使用することは確かに良い考えです。

GraphQLを使用する開発者にとって、これは優れたソリューションになる可能性があります。GraphQLはCMSを自動生成します。

私はしばらくの間取り組んできたプロジェクトがあり、それは役に立つ/興味があるかもしれません。NodeMDAは、UMLモデルを受け取り、ソースコードを生成するコード生成エンジンです。 「エンティティ」や「サービス」などの高レベルの概念をモデル化して、スタック全体を生成することができます。 サーバー側でFeathersを使用し、クライアント側でReact + Material-UIを使用して完全なアプリを生成する、プラグインを完成させました。 モデル化する各エンティティは、完全なCRUDエディターを取得します。

フレームワーク全体はMITライセンスですが、現在、独自のモデリングツールはありません。 現在、モデリングアプリにStarUMLを使用していますが、それは安価であり、メタデータがxmlドキュメント（XMIなど）ではなくJSONに保存されているためです。 StarUMLは商用製品ですが、無制限の無料評価期間（ナグウェア）があります。 私はStarUMLとは一切関係がありません。そのモデリングツールだけが、私の差し迫ったニーズを満たしていました。 ただし、NodeMDAはプラグ可能なリーダーをサポートしています。 私は長距離ロードマップ上に、迅速で汚いUMLクラスエディターを作成して、人々が何も支払うことなくそれを使用できるようにする必要があります。

以前はJavaMDAプロジェクト（AndroMDA）に貢献していましたが、Nodeの世界で似たようなものが欲しかったので、NodeMDAをハッキングしてきました。 エンジン自体はかなりうまく機能しています。 新しいプラグインを作成して、別の方法で、または別の言語でコードを生成するのは非常に簡単です。 私は「意見はあるが、心を開いている」と言いたい。

バックエンドでFeathersを実行するため、すぐに役立つ場合もあれば、他の何かの開始点として適している場合もあります。 見てみな：

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

そしてfeathersプラグインはここにあります：

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

多分私たちはそれを使うことができます： https ：//github.com/ForestAdmin/lumber

admin-on-restで何かをするのは素晴らしいことです

誰かが興味を持っているなら。 evolutility-ui-reactのフォークに取り組み始め、feathersAPIのサポートを追加しました。 私は文字通り始めたばかりですが、基本的なCRUDは単純なモデルで機能し、バイナリファイルでは途中で機能します...元のコードベースは少しリファクタリングを使用でき、一連のフィールドタイプのサポートを追加/テストする必要があります、しかしそれは誰かのために役立つかもしれません。 今後数週間でさらに変更をプッシュする予定です。

の問題について

その日のフロントエンドフレーバーをサポートする

Svelteはこれをかなりうまく解決すると思います（ github ）。 それで作られたものはすべて普遍的であり、フレームワークのないバニラJavaScriptになります。

これは将来性があり、「その日の」テクノロジーと常に互換性があるため、強くお勧めします。

@ ddela-cradmin-on-rest用のカスタムfeathersrestクライアントを作成するプロジェクトを開始しました。
確認してください、貢献を歓迎します...

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

https://github.com/josx/aor-feathers-clientの新しいバージョンをリリースしました。また、 https ：//github.com/Cambalab/test-feathers-adminにプルーフオブワークがあります。

これとまったく同じトピックにかなり長い間苦労していたので、 ng-admin （昔ながらのAngularJSに基づくadmin-on-restの兄）を使用したアプローチも共有したいと思います。

ng-adminとng-admin.jwt-authをFeathersで動作させるために必要な最小限の構成を抽出し、慎重に作成されたリポジトリに変換しました： https ：//github.com/beevelop/feathers-admin-starter

@beevelopよくやった！

数日前、私はng-adminとほぼ同じようにドンデしました（しかし、あなたのバージョンにはより多くの機能があります）。 ここに（feathers app、ngadmin、admin-on-rest）のリポジトリがあります。

おそらく、ng-adminとadmin-on-rest + feathersを使用してsamの例を改善できます。

やあみんな、

各フレームワークは、管理インターフェースの車輪を再発明する必要があります。 「フェザー管理者」、「laravel管理者」、「rails管理者」などがあります。クレイジーですね。 これが私がLumber（https://github.com/ForestAdmin/lumber）をリリースした理由です-アプリケーションに接続する代わりに、管理者専用の新しいものを生成します（つまり、管理者マイクロサービスを生成します） 。

このソリューションについてどう思いますか？

私のプロジェクトの@SeyZは実行可能ではありません。これは、すべてのソフトウェアを制御することにしたためです。 ですから、それが自由ソフトウェアでなければ、私はサービスを購入することができません。

また、開発者の観点からは、あなたは素晴らしい仕事をしたと思いますが、それはコミュニティにとっては役に立ちません。

自由ソフトウェアをコアに持つビジネスモデルを考えるかもしれません。
ちょうど私の2セント。

@josx Lumberは完全にオープンソースであり、Forestは自動的に優れたUIを提供するサービスです（私は：Dを望んでいます）。 もちろん、すべてが完全に無料です！

admin-on-restの更新バージョンを見てください。 すごいですね。

ここにはかなり良い解決策があると思うので、今はこれを閉じます。 コアチームは公式な作業を行っておらず、近い将来に作業を行う予定はありません。

この問題は長くなっていますが、何か新しいことが起こった場合に備えてロックしたくありません。 まだ言及されていないものに出くわした場合は、気軽に投稿してください。 これがディスカッション掲示板になり始めた場合、または同じことの多くに気づき始めた場合は、スレッドをロックします。

皆様からのご意見ありがとうございました！ あなたたちはコミュニティを素晴らしいものにしています！ ❤️

何らかの規模のプロジェクトでは、管理ページを作成する必要があります。 たぶん、GUI管理ページを作成するためのさまざまなライブラリへのリンクを含むページをドキュメントに作成する必要がありますか？ 箱から出してすぐに解決できるソリューションがあれば嬉しいですが、少なくとも最高品質のソリューションをお勧めできます。

@kulakowkaスタータースタックセクションの後に、エコシステムページにセクションを追加するのが最も理にかなっています。 https://docs.feathersjs.com/v/auk/ecosystem/readme.html

LoopbackとAngularに基づく同等のソリューションも存在します。 これはColmena-cms （以前はLoopback Angular Adminとして知られていました）と呼ばれています。

フェザーとadmin-on-restを組み合わせるのが最も理にかなっています。これは、管理ページのレンダリング方法に焦点を当てる必要がなく、主に両方の間のブリッジを構築することに焦点を当てる必要があるためです。

フェザーとadmin-on-restに依存するこのような新しいソリューションの場合、これら2つの依存関係を簡単に更新できる方法が必要になります。

このようなソリューションの構築と維持は、コルメナよりも少ない労力で済むと思います。

私は過去にcolemena-cmsに貢献したことがありますが、これはループバック用です。 そのため、adminのようなアプリをRESTに置くことは、フェザーに最適なオプションです。

私たちが取り組んでいるaorプラグインを見てください。 https://github.com/josx/aor-feathers-client

誰もが羽に沿ってforestAdminを使用することに成功しますか？

@loiclouvet試してからしばらく経ちましたが、過去にForestを羽毛に沿って動作させることに成功しました。 今日もう一度試して、完全に機能する例をここに公開したいと思います： https ：//github.com/forestadmin/forest-examples

免責事項：私はフォレストの創設者です。

@SeyZ数回の試行の後、（マングースを使用して）羽のあるフォレストを設定しました。間違いなく試してみます！

ここに、 Forest AdminをFeathersに統合するための実用的な例を追加しました： https ：//github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database

ご不明な点がございましたら、お気軽に;）

@SeyZ私はマングースでフォレスト管理者を設定しました。私が理解しているように、それは羽のフックをバイパスし、mongodbに直接注入します。

@nadbmあなたは完全に正しいので、Forest管理者はFeathersにうまく適合しないと思います。 個人的には、admin-on-restを試して採用しました！

この問題は、クローズされた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、この問題へのリンクを含む新しい問題を開いてください。