Feathers: Пожалуйста, поддержите графический интерфейс для CRUD

@takaaptech спасибо за предложение! Мы довольно много говорили об этом в @feathersjs/core-team. Это определенно должен быть необязательный плагин, но, безусловно, выполнимый. Я предварительно хлопну это по вехе 3.0.

@ekryski большое спасибо! перья действительно классные!

Эй, мне нравится идея иметь простой графический интерфейс для операций CRUD, и я хотел бы узнать больше о том, как вы планируете решать эту проблему. Разве вам не понадобится что-то вроде схемы JSON для стандартизации определений моделей, независимо от того, какой ORM используется внутри? Я много работал с автоматическим созданием графических интерфейсов в соответствии со схемами, и раскрытие этих схем с их полями имеет решающее значение. Также имеет смысл подумать о проверке данных (maxlength, регулярное выражение строки и т. д.), редакторах свойств (дата, дата, время или время редактирования в поле типа даты) и т. д.

Разве не имеет смысла реализовать эти определения схемы (на основе простого, совместимого с браузером JSON, а не этих типичных расширений в стиле магистрали, таких как книжная полка) с их ассоциациями и написать адаптеры схемы для различных ORM?

Это также упростит реализацию swagger и переключение между ORM, поскольку вам не нужно будет переписывать свои модели.

редактировать: я считаю, что очень важно подумать о том, сколько перьев должно быть независимым от данных. Но я вижу, что вы прилагаете много усилий для реализации синхронизации данных, автономных возможностей и т. д. Таким образом, я думаю, что перья должны быть более привязаны к моделям данных, особенно если вы думаете о возможностях на стороне клиента.

Я думаю, что это должно быть похоже на то, что предлагает Strapi . Посмотрите на его studio и admin panel .

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

Strapi тесно связан с ватерлинией, поэтому реализовать эту функцию проще.

Кстати, такое же предлагает и parse, который называется parse-dashboard (https://github.com/ParsePlatform). Здесь опять нет такой гибкости, как с перьями для выбора между ORM.

Не могу дождаться, чтобы услышать, как перья справятся с этим, если они действительно решат предоставить эту функцию.

Решение, которое я вижу, состояло бы в том, чтобы разделить функцию на два типа модулей:

• плагин перьев, который выполняет основную работу, например, отображает графический интерфейс
• адаптер для плагина для управления ORM

Таким образом, у нас будет уникальный плагин и множество адаптеров, по одному на каждый ORM.

У нас есть несколько идей, и я думаю, что в этом есть разные части:

1) Интерфейс пользовательского интерфейса для визуального объединения вашего API. Я думаю, что с потоком хуков и сервисов здесь есть некоторый потенциал.
2) Отдельный интерфейс администратора, который позволяет вам работать с вашим API и просматривать сервисы. Вроде как Postman , но специально для Feathers.
3) Генерация админки CRUD в приложении. Это, наверное, самое сложное и сложное. Вы должны генерировать разные реализации для разных интерфейсных фреймворков (если нет «официального» внешнего стека поверх Feathers), а генераторы сложно поддерживать и отлаживать.

действительно стремится никогда не писать CRUD. для чего это стоит, я уже делаю это в своих собственных проектах, используя tcomb , tcomb-form , feathers-tcomb и feathers-action . увидеть все это вместе в business-stack . рекомендовал бы. :)

@ahdinosaur , это довольно круто. @daffl Я думаю, мы могли бы захотеть посветить кое-что из этого. По крайней мере, feathers-tcomb или что-то в этом роде. Именно так, как я думал, мы должны обрабатывать проверки, и независимо от того, что мы используем для этого, нам нужно будет иметь некоторое определение модели/ресурса, чтобы автоматически генерировать документы API и пользовательский интерфейс CRUD. feathers-swagger по сути просто передает определение модели мангуста в Swagger.

Нам нужно будет решить, как мы хотим немного нарезать это, учитывая, что у нас так много разных БД и ORM. Я мог видеть, что что-то вроде tcomb довольно ценно, но противоречит ли это цели использования ORM? Это не обязательно плохо, но я думаю, что важно быть последовательным в определении вашей схемы/модели/ресурса (как бы вы это ни называли), независимо от того, какая БД находится под ним. Сделать базы данных легко заменяемыми важно, поэтому мне не нравится идея использования моделей Sequelize, моделей мангуста, а затем для других БД с использованием Tcomb или чего-то еще.

Что касается пользовательского интерфейса администратора или чего-то еще, я согласен с тем, что:

A) Это чертова куча работы, чтобы поддерживать внешний вид дня.
Б) Если мы реализуем фронтенд, скажем, в React, то использовать рядом с ним альтернативный будет непросто.

Так что, возможно, это должно быть самоуверенным фронтом (это все еще необязательно), но если вы, например, не хотите использовать React, то это очень плохо. Если мы сможем сделать его сверхлегким, чтобы людям было легко его копировать, а сообществу было легко создавать разные интерфейсы, то это могло бы работать очень хорошо.

Вдохновленный Django, я искал что-то, что поставляется с CRUD-GUI или каким-то администратором. Я обдумывал идею создания JSON-схем для множества моделей. Используя эти схемы, вы сможете сгенерировать код проверки, схемы для мангуста [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/амити-mongodb

amity-mongodb позволяет управлять всем сервером MongoDB. Он использует несколько услуг перьев:

• feathers-mongo-databases
• feathers-mongo-collections
• feathers-mongo-users Доступно в версии Auth
• feathers-mongodb

Поскольку все использует сервисы Feathers, при добавлении/удалении баз данных и коллекций они обновляются в реальном времени.

Я еще не обновил сервер amity до Feathers 2.0. Вы можете спасти от него все, что сможете. :)

Я сделал его полностью модульным, поэтому вы можете создать свой собственный пользовательский интерфейс поверх адаптеров Amity, если хотите.

вы, вероятно, уже знаете ng-admin. Мне нравится, как они обрабатывают конкретный бэкенд. Мне не нравится angular, поэтому я почти закончил портировать его на riot.js.

Я также упомяну, что существует неплохая альтернатива под названием http://forestadmin.com/. Он платный и размещен на хостинге, но может работать локально бесплатно. Создатель сказал мне, что если вы просто загрузите промежуточное ПО Feathers после промежуточного ПО Forest, оно будет работать из коробки. Я собираюсь дать ему попробовать в ближайшее время.

@ekryski @SeyZ
Это бесплатное ПО?

Привет @josx - У нас есть бесплатный план для 1 пользователя :)

Если вы пробовали/использовали/видели его - инфраструктура API StrongLoop создает очень приятный веб-интерфейс для вашего сервиса RestFUL... Который сейчас, я думаю, http://loopback.io (после того, как IBM приобрела Strongloop). В любом случае, может там что-то стоит блеснуть...

@ekryski - посмотрел на forestadmin.com, но я не вижу, где / как это может работать локально бесплатно? Мы рассматриваем использование перьев js для создания нашего предприятия следующего поколения (за брандмауэрами без доступа в Интернет), поэтому, надеюсь, что-нибудь / все может быть размещено локально .. :)

Привет , @sjmcdowall. Вы можете установить его в свое приложение с помощью пакета Forest в зависимости от используемого вами ORM: Sequelize , Mongoose или даже Loopback .

Вы можете попробовать Forest в своей среде локального хоста ( http://localhost... ), потому что данные передаются непосредственно из вашего браузера в ваше приложение без прохождения через Forest.

Это совершенно бесплатно для 1 администратора 👍

Это отличная идея. И Strapi, и Treeline (та же команда, что и Sails) реализовали это.

@ekryski как хорошо у вас получилось с Forest Admin? Это потребовало много возни? Мы разрабатываем собственный пользовательский интерфейс администратора в React, но было бы неплохо удалить рабочую нагрузку, если лес работает нормально?

@Mentioum Мне не повезло с мангустом в проекте, и у нас было очень мало времени, поэтому мы обратились к ng-admin. Пытаюсь разобраться с командой Леса, то ли это что-то с Лесом, Перьями или я просто тупой. Должно быть некоторое время, чтобы дать ему еще один правильный ход позже на этой неделе. Обязательно отчитаюсь.

@Mentioum Позвольте мне вмешаться, я работаю с @SeyZ над Forest. Мы будем исследовать проблему с @ekryski. В любом случае, если вы заинтересованы в том, чтобы попробовать Forest, не стесняйтесь обращаться к Сандро или ко мне (электронная почта: [email protected]), и мы вместе решим любой вопрос.

У меня есть Forest, работающий над FeathersJS с Sequelize для побочного проекта, поэтому проблема может быть ограничена мангустом. Вот суть файла app.js, который был изменен только для добавления леса.

Извините, но я не вижу смысла работать над администратором, таким как лес, потому что это не бесплатное программное обеспечение / открытый исходный код.
Я думаю, нам лучше работать над ngadmin или подобным.

спасибо @ekryski .

спасибо @VinzGhyz. Это ужасно мило, но нет, спасибо. Пока я не узнаю, что это работает с мангустом из коробки, у меня нет времени заниматься этим, поскольку у нас уже есть рабочее решение, которое мы поддерживаем сами. Единственная причина, по которой мы должны переключиться, — это нулевая рабочая нагрузка / меньшая рабочая нагрузка, чем у нашего текущего решения.

Я буду смотреть, чтобы увидеть, что происходит.

(Я знаю, что упоминал об этом раньше, но на самом деле я думаю, что в KeystoneJS есть отличный автоматически сгенерированный администратор с довольно солидными опциями, основанными на ElementalUI (реакция)) У @JedWatson , вероятно, есть хорошее представление о том, как лучше всего это сделать.

@Mentioum спасибо за упоминание, я хотел бы думать, что это то, что есть в KeystoneJS 😀

На самом деле мы обсуждаем, как мы можем больше сосредоточиться на двух основных концепциях, в которых Keystone действительно сильна: списки Keystone и пользовательский интерфейс администратора. Я давно не углублялся в Feathers, но то, что я видел, выглядит великолепно, и оно сосредоточено на немного другой области.

Наша следующая основная версия неизбежна (мы надеемся выпустить бета-версию на следующий день или около того), которая была переписана в течение года, включая полностью реагирующий/сокращенный пользовательский интерфейс и новые API. Я определенно был бы готов поработать с Feathers, чтобы выяснить, как уменьшить некоторые пересечения и сделать наши проекты совместимыми, если это представляет интерес.

Мы также надеемся освободиться от жесткого подключения к мангусту в недалеком будущем, что может сделать его еще лучше, если мы сможем придумать правильную гибкость в том, как вы подключаетесь к API/хранилищу данных. .

Команда Feathers — не стесняйтесь обращаться к нам, если хотите узнать об этом подробнее.

@JedWatson круто . Мы должны полностью сотрудничать. Рад видеть новую версию. На самом деле я надеялся/думал о том, как мы могли бы взломать Keystone, чтобы использовать Feathers в качестве бэкенда.

@Mentioum Я в той же лодке, что и ты. Слишком занят. Хоупфулл сможет выкроить полчаса или около того на этой неделе, чтобы посмотреть, смогу ли я заставить Forest работать.

Мы были очень впечатлены ng-admin (хотя я не большой поклонник Angular). Тем не менее, на стороне клиента все еще остается много шаблонов/избыточностей, которые вы в конечном итоге делаете для поддержки вещей, которые вы уже определили на стороне сервера схем.

Положить Keystone на Feathers было бы золотом! Я буду способствовать этому.

@JedWatson @ekryski @daffl

Нет проблем, я сделал много вещей с Keystone (я фанат) (то же самое с перьями):

http://161london.com (работа с клиентом)
http://thenidocollection.com (работа с клиентом)
http://headstartapp.com (текущий запуск)

И мы используем Feathers как простой способ открыть множество небольших сервисов, которые поддерживают настоящие приложения Headstart (все React и React Native atm — некоторые с Electron, обернутые для корпораций, которые ненавидят «браузерные приложения»).

Это может быть немного натянуто, но если вы действительно думаете о том, чтобы у Keystone был какой-то ORM, не было бы намного круче использовать перья в качестве микросервиса, который работает вместе с Keystone, и вы просто используете это?

Таким образом, у keystone все еще может быть свое решение «под ключ», которое генерирует все с помощью мангуста, но затем, если вы хотите быть немного более причудливым, вы можете развернуть некоторые микросервисы Feathers для определенных списков, которые вы предоставляете конечную точку для конкретной службы Feathers.

Я уверен, что у вас, ребята, есть гораздо лучшее представление о том, как его структурировать. (Например, вы можете просто сделать это с помощью экспресс-маршрутов в Keystone, но тогда у вас не будет автогенерирующего администратора :))

Прямо сейчас мечтаю о небольшом Dockerstack:

редис,
монгодб,
краеугольный камень,
перья-микросервис1,
перья-микросервисекс,
PSgress,
Эластичный поиск
и т.д. и т.п....
....

В любом случае, само собой разумеется, если это может быть вещью ... я буду за это.

Привет, ребята. Если вы начали создавать этот проект, можете ли вы дать ссылку на свой репозиторий или что-нибудь еще, чтобы люди могли следить за ним?

+1 хотел бы увидеть пример некоторых узоров с использованием трапецеидальных искажений с перьями.

Конечно, иметь автоматически сгенерированный бэкенд — хорошая идея.

Для разработчиков, использующих GraphQL, это может быть хорошим решением: GraphQL автоматически генерирует CMS .

У меня есть проект, над которым я работаю некоторое время, который может быть полезен/интересен: NodeMDA — это механизм генерации кода, который использует модели UML и генерирует исходный код. Вы можете смоделировать концепции высокого уровня, такие как «Сущность» и «Сервис», и получить полный стек, сгенерированный для вас. Я только что закончил плагин для него, который генерирует полное приложение, используя Feathers на стороне сервера и React + Material-UI на стороне клиента. Каждый объект, который вы моделируете, получает полноценный редактор CRUD.

Весь фреймворк лицензирован MIT, но в настоящее время у него нет собственного инструмента моделирования. В настоящее время я использую StarUML для своего приложения для моделирования, но это только потому, что оно было недорогим, а его метаданные хранились в формате JSON, а не в документе xml (например, XMI). Хотя StarUML является коммерческим продуктом, у них есть бесплатный неограниченный ознакомительный период (это неприятная вещь). Я никоим образом не связан со StarUML - просто их инструмент моделирования удовлетворял мои насущные потребности. Однако NodeMDA поддерживает сменные считыватели. У меня есть долгосрочная дорожная карта, чтобы написать быстрый и грязный редактор классов UML, чтобы люди могли использовать его, не платя ничего.

Раньше я участвовал в проекте Java MDA (AndroMDA) и хотел иметь что-то подобное в мире Node, поэтому я занимался NodeMDA. Сам двигатель ведет себя вполне прилично. Довольно легко создавать НОВЫЕ плагины для генерации кода другим способом или даже на другом языке. Мне нравится говорить «это самоуверенно, но непредубежденно».

Поскольку он работает с Feathers на бэкенде, он может оказаться полезным сразу же или может стать хорошей отправной точкой для чего-то еще. Проверьте это:

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

и плагин перьев здесь:

https://www.npmjs.com/package/nodemda-feathers-реагировать

возможно, мы сможем его использовать: https://github.com/ForestAdmin/lumber

было бы здорово сделать что-нибудь с admin-on-rest

Если кому интересно. Я начал работать над ответвлением evolutility-ui-react, чтобы добавить поддержку API перьев. Я буквально только начал, но у меня есть базовый CRUD, работающий для простых моделей, и частично для двоичных файлов... исходная кодовая база может использовать небольшой рефакторинг, и мне нужно добавить поддержку/проверить кучу типов полей , а может кому пригодится. Я буду продвигать больше изменений в течение следующих нескольких недель.

О проблеме

поддержите внешний вид дня

Я считаю, что Svelte довольно хорошо решает эту проблему ( github ). Все, что сделано с его помощью, универсально и становится ванильным JavaScript без фреймворка.

Я настоятельно рекомендую это, потому что это перспективно и всегда взаимозаменяемо с любой технологией «дня».

@ddela-cr Я начал проект по написанию пользовательского клиента для отдыха с перьями для администратора на отдыхе.
Пожалуйста, проверьте это, вклад приветствуется...

https://github.com/josx/аор-перья-клиент

Мы выпустили новую версию для https://github.com/josx/aor-feathers-client , а также у нас есть доказательство работы на https://github.com/Cambalab/test-feathers-admin .

Поскольку я довольно долго боролся с этой же темой, я хотел бы поделиться своим подходом с использованием ng-admin (старший брат admin-on-rest , основанный на старом добром AngularJS).

Я извлек минимальную конфигурацию, необходимую для работы ng-admin и ng-admin.jwt-auth с Feathers, и превратил ее в тщательно продуманный репозиторий: https://github.com/beevelop/feathers-admin-starter .

@beevelop молодец!

Несколько дней назад я сделал почти то же самое с ng-admin (но в вашей версии реализовано больше функций). Здесь репо с (приложением перьев, ngadmin и admin-on-rest).

Возможно, мы сможем улучшить пример sam с помощью ng-admin и admin-on-rest + перья.

Привет, ребята,

Каждый фреймворк должен заново изобретать колесо для административного интерфейса. Есть «администратор пера», «администратор laravel», «администратор рельсов» и т. д. Сумасшествие, не так ли? Вот почему я выпустил Lumber (https://github.com/ForestAdmin/lumber) — вместо того, чтобы подключаться к вашему приложению, он генерирует новый специально для администратора (другими словами, он генерирует микросервис администратора) .

Что вы думаете об этом решении?

@SeyZ в моем проекте нежизнеспособен, потому что мы решили контролировать все программное обеспечение. Поэтому, если это не бесплатное программное обеспечение, я не могу купить услугу.

Также с точки зрения разработчика я думаю, что вы проделали большую работу, но она бесполезна для сообщества.

Вы можете подумать о бизнес-модели, которая включает бесплатное программное обеспечение в качестве ядра.
Просто мои 2 цента.

@josx Lumber — это полностью открытый исходный код, а Forest — это сервис, который автоматически предоставляет вам отличный пользовательский интерфейс (надеюсь :D). Все совершенно бесплатно, конечно!

Взгляните на обновленную версию admin-on-rest . Это выглядит потрясающе.

Я думаю, что сейчас здесь есть несколько довольно хороших решений, поэтому я собираюсь закрыть это сейчас. Основная команда не работает над чем-то официальным и не планирует делать это в ближайшем будущем.

Эта проблема становится длинной, но я не хочу закрывать ее на случай, если появится что-то новое. Если вы столкнетесь с чем-то, что еще не было упомянуто и что, по вашему мнению, будет хорошо подходить, не стесняйтесь публиковать это! Если это станет просто доской для обсуждения или мы начнем видеть одно и то же, мы закроем ветку.

Спасибо всем за участие! Вы, ребята, делаете сообщество удивительным! ❤️

В проекте любого масштаба так или иначе потребуется создание админки. Может быть, нам следует создать страницу в документах со ссылками на разные библиотеки для создания страниц администрирования графического интерфейса? Я был бы рад получить решение из коробки, но мы можем, по крайней мере, порекомендовать решения самого высокого качества.

@kulakowka Было бы разумнее добавить раздел на страницу «Экосистема» после раздела «Стартовые стеки». https://docs.feathersjs.com/v/auk/ecosystem/readme.html

Также существует эквивалентное решение на основе Loopback и Angular. Он называется Colmena-cms (ранее известный как Loopback Angular Admin).

Сочетание Feathers с admin-on-rest имеет наибольший смысл, потому что тогда нам нужно будет сосредоточиться в основном на построении моста между обоими, без необходимости сосредотачиваться на том, как отображать страницы администрирования.

Для такого нового решения, которое зависит от перьев и admin-on-rest, нам понадобится способ, позволяющий легко обновлять эти две зависимости.

Я полагаю, что создание и поддержка такого решения потребует меньше усилий, чем Colmena.

В прошлом я участвовал в colena-cms, но это только для обратной связи. Вот почему приложение, такое как admin, на отдыхе — идеальный вариант для перьев.

Взгляните на плагин, над которым мы работаем. https://github.com/josx/аор-перья-клиент

Кому-нибудь удалось использовать forestAdmin вместе с перьями?

@loiclouvet Прошло много времени с тех пор, как я пытался, но в прошлом я успешно заставлял Фореста работать с перьями. Хотелось бы попробовать еще раз сегодня и опубликовать полный рабочий пример здесь: https://github.com/forestadmin/forest-examples .

Отказ от ответственности: я основатель Forest.

@SeyZ Я создал Forest с перьями (используя мангуста) после нескольких попыток, обязательно попробую!

Я только что добавил рабочий пример интеграции Forest Admin в Feathers здесь: https://github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database .

Не стесняйтесь, если у вас есть какие-либо вопросы ;)

@SeyZ Я настроил администратора леса с помощью мангуста, насколько я понимаю, он обходит хуки перьев и напрямую внедряется в mongodb, верно?

@nadbm Вы совершенно правы, поэтому я не думаю, что администратор леса хорошо сочетается с Feathers. Лично я попробовал и принял admin-on-rest!

Эта проблема была автоматически заблокирована, так как после ее закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему со ссылкой на эту проблему для связанных ошибок.