Feathers: Por favor, suporte GUI para CRUD

@takaaptech obrigado pela sugestão! Temos falado bastante sobre isso entre o @feathersjs/core-team. Definitivamente deve ser um plugin opcional, mas certamente é factível. Vou tentar colocar isso no marco 3.0.

@ekryski muito obrigado! penas é realmente incrível!

Ei, eu gosto da ideia de ter uma GUI simples para operações CRUD e gostaria de saber mais sobre como você planeja lidar com isso. Você não precisará de algo como JSON Schema para padronizar as definições de modelo, independentemente de qual ORM é usado nos bastidores? Eu tenho trabalhado muito com a geração automática de GUIs de acordo com esquemas, e expor esses esquemas com seus campos é crucial. Também faz sentido pensar na validação de dados (maxlength, string regex, etc), editores de propriedades (data, data e hora ou edição de hora em um campo do tipo data) e assim por diante.

Não faria sentido implementar essas definições de esquema (com base em JSON simples e compatível com navegador e não nessas extensões típicas de estilo de backbone, como o bookshelf) com suas associações e adaptadores de esquema de gravação para os diferentes ORMs?

Isso também tornaria mais fácil implementar o swagger e alternar entre ORMs, pois você não precisará reescrever seus modelos.

edit: Eu sinto que é muito importante pensar em quantas penas precisam ser agnósticas de dados. Mas vejo que você está fazendo muitos esforços para implementar sincronização de dados, recursos off-line etc. Como tal, acho que as penas precisarão estar mais vinculadas aos modelos de dados, especialmente se você pensar nos recursos do lado do cliente.

Acho que deve ser semelhante ao que o Strapi oferece. Olhe para seus studio e admin panel .

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

O Strapi está fortemente acoplado à linha d'água e, como tal, é mais fácil implementar esse recurso.

A propósito, o parse também oferece isso, chamado parse-dashboard (https://github.com/ParsePlatform). Aqui, novamente, não há tanta flexibilidade como com penas para escolher entre ORMs.

Mal posso esperar para saber como as penas vão lidar com isso se eles realmente decidirem fornecer esse recurso.

Uma solução que vejo seria dividir o recurso em dois tipos de módulos:

• um plugin de penas que faz o trabalho principal, como exibir a GUI
• um adaptador para o plugin para gerenciar o ORM

Assim teríamos um plugin único e muitos adaptadores, um para cada ORM.

Temos algumas ideias aqui e acho que há partes diferentes para isso:

1) Uma interface de interface do usuário para montar sua API visualmente. Com o fluxo de ganchos e serviços, acho que há bastante potencial aqui.
2) Uma interface de administração separada que permite trabalhar com sua API e serviços de navegação. Mais ou menos como Postman , mas especificamente para Feathers.
3) Gerando um back-end de administração CRUD no aplicativo. Este é provavelmente o mais difícil e complicado de fazer. Você tem que gerar diferentes implementações para diferentes frameworks de front-end (a menos que haja uma pilha de front-end "oficial" em cima de Feathers) e os geradores são difíceis de manter e depurar.

realmente ansioso para nunca escrever CRUD. vale a pena, já estou fazendo isso em meus próprios projetos usando tcomb , tcomb-form , feathers-tcomb e feathers-action . veja tudo junto em business-stack . recomendaria. :)

@ahdinosaur isso é muito radical. @daffl Acho que podemos querer brilhar algumas dessas coisas. Pelo menos feathers-tcomb ou algo assim. Exatamente como eu pensei que deveríamos estar lidando com validações e não importa o que usarmos para fazer isso, teremos que ter alguma definição de modelo/recurso para gerar automaticamente documentos de API e uma interface de usuário CRUD. feathers-swagger essencialmente apenas alimenta uma definição de modelo de mangusto para Swagger.

Teremos que decidir como queremos dividir isso um pouco, já que temos tantos DBs e ORMs diferentes. Eu poderia ver algo como tcomb sendo bastante valioso, mas isso anula o propósito de usar um ORM? Isso não é necessariamente uma coisa ruim, mas acho que ser consistente em sua definição de esquema/modelo/recurso (como você quiser chamá-lo) é importante, independentemente do banco de dados abaixo. Tornar os bancos de dados facilmente trocáveis ​​é importante, então eu não amo a ideia de usar modelos Sequelize, modelos mangustos, mas para outros bancos de dados usando Tcomb ou algo assim.

Para a parte da interface do usuário do administrador ou algo assim, concordo que:

A) É uma merda de trabalho para apoiar o sabor do front-end do dia
B) Se implementarmos um front end, digamos em React, não será fácil usar um alternativo ao lado dele.

Portanto, pode precisar ser uma frente opinativa (isso ainda é opcional), mas se você não quiser, por exemplo, usar o React, é uma pena. Se pudermos torná-lo super leve para que seja fácil para as pessoas replicarem e para a comunidade criar diferentes front-ends, pode funcionar muito bem.

Inspirado pelo Django, tenho procurado algo que venha com uma CRUD-GUI ou algum tipo de administrador. Eu tenho brincado com a ideia de gerar esquemas JSON para vários modelos. Usando esses esquemas, você deve ser capaz de gerar um código de validação, esquemas para mangusto[1] e outros modelos. Parafusar um administrador em penas pareceria relativamente simples usando um esquema e algo parecido com ng-admin[2].

Acho que a vantagem dessa abordagem seria que nenhum código precisa ser escrito especificamente para penas. (além do gerador de esquema JSON e alguma cola gerada) Não haveria preocupações com o "sabor do dia" e as penas seriam fique opinativo onde realmente importa, a interface REST e Socket.io que ele fornece.

Apenas meus 2 centavos, se alguém estiver interessado nisso, quero configurar um protótipo para isso em algum lugar nas próximas 2 a 3 semanas.

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

@AndreSteenveld Comecei a trabalhar em algo assim no ano passado. Você pode ver o que eu montei aqui: https://github.com/marshallswain/AmityApp. Basicamente, ele funciona em torno da criação do que chamei de adaptadores Amity, que são coleções de serviços de penas específicos para lidar com tipos de banco de dados. Eu só fiz a versão do MongoDB.

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

amity-mongodb permite gerenciar um servidor MongoDB inteiro. Utiliza vários serviços de penas:

• feathers-mongo-databases
• feathers-mongo-collections
• feathers-mongo-users Chegando na versão de autenticação
• feathers-mongodb

Como tudo usa os serviços do Feathers, conforme você adiciona/remove bancos de dados e coleções, ele é atualizado em tempo real.

Ainda não atualizei o servidor amity para o Feathers 2.0. Você é bem-vindo para salvar o que puder dele. :)

Eu o fiz completamente modular, para que você possa construir sua própria interface do usuário em cima dos adaptadores de amizade, se quiser.

você provavelmente já conhece o ng-admin. Eu gosto da maneira como eles lidam com back-end específico. Eu não gosto de angular, então eu quase terminei de portar isso para o riot.js

Também vou jogar fora que parece uma alternativa muito boa chamada http://forestadmin.com/. É pago e hospedado, mas pode funcionar localmente gratuitamente. O criador me disse que se você apenas carregar o middleware Feathers após o middleware Forest, ele funcionará imediatamente. Vou experimentá-lo em breve.

@ekryski @SeyZ
Isso é software livre?

Ei @josx - Temos um plano gratuito para 1 usuário :)

Se você já experimentou / usou / viu - a estrutura da API StrongLoop gera uma interface de usuário da Web muito boa para o seu serviço RestFUL ... Que agora é http://loopback.io , eu acho (depois que a IBM adquiriu o Strongloop). De qualquer forma, talvez haja algo lá que valha a pena brilhar ...

@ekryski - olhei para forestadmin.com, mas não vejo onde / como pode funcionar localmente de graça? Estamos pensando em usar feathersjs para basear nossa empresa de próxima geração (atrás de firewalls sem acesso à Internet), então esperamos que qualquer coisa / tudo possa ser hospedado localmente .. :)

Hey @sjmcdowall - Você pode instalá-lo em seu aplicativo usando o pacote Forest dependendo do ORM que você usa: Sequelize , Mongoose ou até mesmo Loopback .

Você pode experimentar o Forest em seu ambiente localhost ( http://localhost... ) porque os dados transitam diretamente do seu navegador para o seu aplicativo sem passar pelo Forest.

É totalmente gratuito para 1 usuário administrador 👍

Esta é uma ótima idéia. Tanto Strapi quanto Treeline (mesma equipe por trás do Sails) implementaram isso.

@ekryski quão bem o Forest Admin foi para você? Exigiu muito esforço? Estamos construindo nossa própria interface de usuário de administração personalizada no react, mas seria bom remover a carga de trabalho se a floresta funcionar bem na caixa?

@Mentioum Eu não tive sorte com o mangusto no projeto e estávamos bastante pressionados pelo tempo, então fomos para o ng-admin. Tentando resolver com a equipe da Floresta se é algo com Floresta, Penas ou se eu sou apenas estúpido. Deve ter algum tempo para dar outra chance ainda esta semana. Definitivamente reportará de volta.

@Mentioum Permita-me comentar, estou trabalhando com @SeyZ em Forest. Estaremos investigando o problema com @ekryski. De qualquer forma, se você estiver interessado em experimentar o Forest, sinta-se à vontade para entrar em contato com Sandro ou comigo (os e-mails são [email protected]) e resolveremos qualquer problema juntos.

Eu tenho Forest trabalhando em FeathersJS com Sequelize para um projeto paralelo, então o problema pode ser limitado ao mangusto. Aqui está um resumo do arquivo app.js que só foi ajustado para adicionar Forest.

Desculpe, mas não vejo sentido em trabalhar em um administrador como o forest que não é software livre/código aberto.
Acho melhor trabalharmos no ngadmin ou similar.

obrigado @ekryski .

obrigado @VinzGhyz. Isso é muito gentil, mas não, obrigado. Até que eu saiba que funciona com mangusto fora da caixa, não tenho tempo para me comprometer com isso, pois já temos uma solução de trabalho que estamos mantendo. A única razão para mudarmos seria uma carga de trabalho 0 / menos carga de trabalho do que nossa solução atual.

Estarei de olho para ver o que acontece.

(Sei que já mencionei isso antes, mas na verdade acho que o KeystoneJS tem um ótimo administrador gerado automaticamente com opções bastante sólidas baseadas em ElementalUI (react) ) @JedWatson provavelmente teria uma boa visão sobre a melhor maneira de fazer isso.

@Mentioum obrigado pela menção, gostaria de pensar que é isso que o KeystoneJS tem 😀

Na verdade, estamos discutindo como podemos nos concentrar mais nos dois conceitos principais com os quais o Keystone é realmente forte: Listas do Keystone e a interface do usuário do administrador. Eu não me aprofundei em Penas por um tempo, mas o que eu vi parece ótimo, e é focado em uma área um pouco diferente.

Nossa próxima versão principal é iminente (esperamos lançar uma versão beta no próximo dia ou mais), que foi reescrita ao longo de um ano, incluindo uma interface do usuário totalmente react/redux e novas APIs. Eu definitivamente estaria aberto a trabalhar com a Feathers para descobrir como reduzir alguns dos crossovers e tornar nossos projetos compatíveis, se isso for de interesse.

Também esperamos nos libertar da conexão difícil com o mangusto em um futuro não muito distante, o que pode torná-lo ainda melhor, se conseguirmos a flexibilidade certa em como você se conecta a uma API / armazenamento de dados .

Equipe Feathers - sinta-se à vontade para entrar em contato se quiser explorar mais isso.

@JedWatson incrível. Devemos colaborar totalmente. Ansioso para ver a nova versão. Na verdade, eu estava esperando/pensando em como poderíamos hackear Keystone para ter Penas como a peça de back-end.

@Mentioum Estou exatamente no mesmo barco que você. Muito ocupado. Hopefull será capaz de separar meia hora ou mais esta semana para ver se consigo fazer Forest funcionar.

Ficamos bastante impressionados com o ng-admin (mesmo que eu não seja um grande fã do Angular). No entanto, ainda há muito clichê/redundância que você acaba fazendo no lado do cliente para dar suporte a coisas que você já definiu no lado do servidor de esquemas.

Colocar Pedra-chave em Penas seria ouro! Vou contribuir para isso.

@JedWatson @ekryski @daffl

Não tem problema eu fiz muitas coisas com Keystone (sou fã) (o mesmo com penas):

http://161london.com (trabalho do cliente)
http://thenidocollection.com (trabalho do cliente)
http://headstartapp.com (inicialização atual)

E estamos usando o Feathers como uma maneira simples de exibir muitos pequenos serviços que alimentam os aplicativos Headstart reais (todos React e React Native atm - alguns com Electron encapsulando-o para empresas que odeiam 'aplicativos de navegador').

Isso pode ser um pouco exagerado, mas se você está realmente pensando em keystone ter algum tipo de ORM, não seria muito mais legal usar penas como um microsserviço que funciona ao lado de keystone e você apenas usa isso?

Dessa forma, o keystone ainda pode ter sua solução 'turn key' que gera tudo com o mangusto, mas, se você quiser ser um pouco mais sofisticado, pode criar alguns microsserviços Feathers para listas específicas que você fornece um endpoint para um serviço Feathers específico.

Tenho certeza que vocês têm uma idéia muito melhor sobre como estruturá-lo. (Obs, você pode fazer isso com rotas expressas no Keystone, mas não teria administrador de geração automática :))

Realmente tendo pequenos sonhos do Dockerstack agora:

redis,
mongodb,
pedra angular,
penas-microservice1,
penas-microservicex,
PSgresso,
Elasticsearch
etc etc....
....

De qualquer forma, escusado será dizer se isso pode ser uma coisa... eu estou pronto para isso.

Ei pessoal. Se você começou a construir este projeto, você pode fornecer um link para seu repositório ou qualquer outra coisa para que as pessoas possam ficar de olho nele?

+1 gostaria de ver alguns exemplos de padrões, usando keystone com penas.

Certamente é uma boa ideia ter um back-end gerado automaticamente.

Para desenvolvedores que usam GraphQL, esta pode ser uma boa solução: CMS de geração automática de GraphQL .

Tenho um projeto no qual venho trabalhando há algum tempo que pode ser de uso/interesse: NodeMDA é um mecanismo de geração de código que pega modelos UML e gera código fonte. Você pode modelar conceitos de alto nível como "Entidade" e "Serviço" e obter uma pilha inteira gerada para você. Acabei de completar um plugin para ele que gera um aplicativo completo usando Feathers no lado do servidor e React + Material-UI no lado do cliente. Cada entidade que você modela recebe um editor CRUD completo.

Todo o framework é licenciado pelo MIT, mas atualmente não possui sua própria ferramenta de modelagem. Atualmente, estou usando StarUML para meu aplicativo de modelagem, mas isso é apenas porque era barato e seus metadados eram armazenados em JSON em vez de um documento xml (como XMI). Embora o StarUML seja um produto comercial, eles têm um período de avaliação gratuito e ilimitado (seu nag ware). Não sou afiliado à StarUML de forma alguma - é apenas a ferramenta de modelagem deles que atendeu às minhas necessidades imediatas. NodeMDA, no entanto, suporta leitores conectáveis. Eu tenho no meu roteiro de longo alcance para escrever um editor de classe UML rápido e sujo para que as pessoas possam usá-lo sem ter que pagar nada.

Eu costumava contribuir para um projeto Java MDA (AndroMDA) e queria ter algo semelhante no mundo do Node, então estou hackeando o NodeMDA. O motor em si está funcionando muito bem. É muito fácil criar NOVOS plugins para gerar código de uma maneira diferente, ou até mesmo em um idioma diferente. Eu gosto de dizer "é opinativo, mas de mente aberta".

Como ele faz Penas no back-end, você pode achar útil imediatamente ou pode ser um bom ponto de partida para outra coisa. Confira:

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

e o plugin de penas está aqui:

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

talvez possamos usá-lo: https://github.com/ForestAdmin/lumber

seria ótimo fazer algo com admin-on-rest

Se alguém estiver interessado. Comecei a trabalhar em um fork do evolutility-ui-react para adicionar suporte à API de penas. Eu literalmente apenas comecei, mas tenho o CRUD básico funcionando para modelos simples e parte do caminho para arquivos binários ... a base de código original pode usar um pouco de refatoração e eu preciso adicionar suporte para/testar vários tipos de campo , no entanto, pode ser útil para alguém. Eu estarei empurrando mais mudanças ao longo das próximas semanas.

Sobre o problema de

apoiar o sabor de front-end do dia

Acredito que o Svelte resolva isso muito bem ( github ). Tudo feito com ele é universal e torna-se JavaScript vanilla sem framework.

Eu sugiro fortemente porque é à prova de futuro e sempre intercambiável com qualquer tecnologia "do dia"

@ddela-cr Comecei um projeto para escrever um cliente de descanso de penas personalizado para admin-on-rest .
Por favor, verifique, contribuição bem-vinda...

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

Lançamos uma nova versão para https://github.com/josx/aor-feathers-client e também temos uma prova de trabalho em https://github.com/Cambalab/test-feathers-admin

Como eu lutei com esse mesmo tópico por algum tempo, gostaria de compartilhar minha abordagem usando ng-admin (irmão mais velho de admin-on-rest baseado no antigo AngularJS) também.

Eu extraí a configuração mínima necessária para obter ng-admin & ng-admin.jwt-auth trabalhando com Feathers e o transformei em um repositório cuidadosamente criado: https://github.com/beevelop/feathers-admin-starter

@beevelop bem feito!

Alguns dias atrás eu fiz quase o mesmo com o ng-admin (mas sua versão tem mais recursos). Aqui um repositório com (aplicativo de penas, ngadmin e admin-on-rest).

Talvez possamos melhorar o mesmo exemplo com ng-admin e admin-on-rest + feathers.

Ei pessoal,

Cada estrutura precisa reinventar a roda para a interface de administração. Existe um "administrador de penas", um "administrador de laravel", um "administrador de rails", etc. Louco, não é? É por isso que lancei o Lumber (https://github.com/ForestAdmin/lumber) - em vez de ser plugado em seu aplicativo, ele gera um novo especialmente para o administrador (em outras palavras, gera um microsserviço de administrador) .

O que você acha dessa solução?

@SeyZ no meu projeto não é viável, porque decidimos ter controle sobre todo o software. Portanto, se não for software livre, não posso comprar um serviço.

Também do ponto de vista do desenvolvedor, acho que você fez um ótimo trabalho, mas não é útil para a comunidade.

Você pode pensar em um modelo de negócios que inclui software livre como núcleo.
Apenas meus 2 centavos.

@josx Lumber é totalmente opensource e Forest é um serviço que oferece automaticamente uma ótima interface do usuário (espero :D). Tudo é totalmente gratuito, é claro!

Dê uma olhada na versão atualizada do admin-on-rest . Parece incrível.

Eu acho que existem algumas soluções muito boas aqui agora, então vou fechar isso por enquanto. A equipe principal não está trabalhando em nada oficial e não tem planos de fazê-lo no curto prazo.

Este problema está ficando longo, mas não quero bloqueá-lo caso algo novo apareça. Se você se deparar com algo que ainda não foi mencionado que você acha que seria uma boa opção, sinta-se à vontade para publicá-lo! Se isso começar a se tornar apenas um fórum de discussão ou começarmos a ver a mesma coisa, bloquearemos o tópico.

Obrigado por toda a entrada de todos! Vocês estão tornando a comunidade incrível! ❤️

Em um projeto de qualquer escala de uma forma ou de outra, você precisará criar uma página de administração. Talvez devêssemos criar uma página nos documentos com links para diferentes bibliotecas para criar páginas de administração da GUI? Eu ficaria feliz em ter uma solução pronta para uso, mas podemos pelo menos recomendar as soluções de melhor qualidade.

@kulakowka Faria mais sentido adicionar uma seção à página do Ecossistema após a seção de pilhas iniciais. https://docs.feathersjs.com/v/auk/ecosystem/readme.html

Uma solução equivalente baseada em Loopback e Angular também existe. É chamado Colmena-cms (anteriormente conhecido como Loopback Angular Admin).

Combinar Feathers com admin-on-rest faz mais sentido porque então precisaríamos nos concentrar principalmente em construir a ponte entre os dois sem precisar focar em como renderizar páginas de administração.

Para uma solução tão nova que depende de penas e admin-on-rest, precisaríamos de uma maneira que permitisse atualizações fáceis dessas duas dependências.

Suponho que construir e manter tal solução deve exigir menos esforço do que Colmena.

Eu contribuí para colemena-cms no passado, mas é apenas para loopback. É por isso que ter um aplicativo como admin em repouso é a opção perfeita para penas.

Dê uma olhada em um ou plugin que estamos trabalhando. https://github.com/josx/aor-feathers-client

Alguém conseguiu usar o forestAdmin junto com as penas?

@loiclouvet Já faz um tempo desde que tentei, mas consegui fazer Forest trabalhar com penas no passado. Adoraria tentar novamente hoje e publicar um exemplo completo de trabalho aqui: https://github.com/forestadmin/forest-examples

Disclaimer: Eu sou o fundador da Forest.

@SeyZ Eu configurei o Forest com penas (usando mangusto) depois de algumas tentativas, definitivamente vou tentar!

Acabei de adicionar um exemplo de trabalho para integrar Forest Admin a Feathers aqui: https://github.com/ForestAdmin/forest-examples/tree/master/examples/feathers/sql-database

Não hesite se tiver alguma dúvida ;)

@SeyZ Configurei o administrador da floresta com o mangusto, pelo que entendi, ele ignora os ganchos de penas e injeta diretamente no mongodb, correto?

@nadbm Você está totalmente certo, então não acho que o administrador da floresta se encaixe bem com o Feathers. Pessoalmente, eu tentei e adotei admin-on-rest !

Este problema foi bloqueado automaticamente, pois não houve nenhuma atividade recente após o fechamento. Por favor, abra um novo problema com um link para este problema para bugs relacionados.