Please support GUI for CRUD

[takaaptech]

Right now we have full CRUD action for services but do not have GUI. It would be great if we have simple web application for user input. Maybe via tutorial or via code auto generator. Feather will be crazy seed for any project :dancer:

[ekryski]

@takaaptech thanks for the suggestion! We've been talking about this among the @feathersjs/core-team quite a bit. It definitely should be an optional plugin but is certainly doable. I'll tentatively slap this on the 3.0 milestone.

[takaaptech]

@ekryski thank so much! feathers is really awesome!

[bkniffler]

Hey, I like the idea of having a simple GUI for CRUD operations and I'd like to know more about how you plan to tackle this. Won't you need something like JSON Schema to standardize model definitions, independent of what ORM is used under the hood? I've been working a lot with automatically generating GUIs according to schemas, and exposing those schemas with their fields is crucial. Also it makes sense to think about data validation (maxlength, string regex, etc), property editors (date, datetime or time edit on a date type field) and so on.

Wouldn't it make sense to implement these schema definitions (based on simple, browser-compatible JSON and not these typical backbone style extensions like bookshelf does) with their associations and write schema adaptors for the different ORMs?

This would also make it easier to implement swagger and to switch between ORMs as you won't need to rewrite your models.

edit: I feel it is very important to think about how much feathers needs to be data agnostic. But I see you're making a lot of efforts to implement data sync, offline capabilities, etc. As such, I think feathers will need to be more tied with data models, especially if you think about client-side capabilities.

[kulakowka]

I think it should be similar to what Strapi offers. Look at his studio and admin panel.

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

[bkniffler]

Strapi is tightly coupled with waterline and as such, its easier to implement this feature.

By the way, also parse offers this, called parse-dashboard (https://github.com/ParsePlatform). Here again, there is not such a flexibility like with feathers for choosing between ORMs.

Can't wait to hear how feathers gonna tackle this if they really decide to provide this feature.

[ArnaudValensi]

A solution I see would be to split the feature in two types of modules:

• a feathers plugin which does the main job, like displaying the GUI
• an adaptor for the plugin to manage the ORM

So we would have a unique plugin and many adaptors, one for each ORM.

[daffl]

We have a couple of ideas here and I think there are different parts to this:

1) A UI interface to put together your API visually. With the flow of hooks and services there is quite some potential here I think. 2) A separate admin interface that lets you work with your API and browse services. Kind of like Postman but specifically for Feathers. 3) Generating a CRUD admin backend in the app. This is probably the hardest and most tricky to do. You have to generate different implementations for different frontend frameworks (unless there is an "official" frontend stack on top of Feathers) and generators are hard to maintain and debug.

[ahdinosaur]

really keen to never write CRUD. for what it's worth, i'm doing this already in my own projects using tcomb, tcomb-form, feathers-tcomb, and feathers-action. see it all together in business-stack. would recommend. :)

[ekryski]

@ahdinosaur that's pretty rad. @daffl I think we might want to gleam some of that stuff. At least feathers-tcomb or something. That exactly how I had thought we should be handling validations and no matter what we use to accomplish this we'll have to have some model/resource definition in order to automatically generate API docs and a CRUD UI. feathers-swagger essentially just feeds a mongoose model definition to Swagger.

We'll have to decide how we want to slice this a bit, given that we have so many different DBs and ORMs. I could see something like tcomb being pretty valuable but does it defeat the purpose of using an ORM? That's not necessarily a bad thing but I think being consistent in your schema/model/resource definition (whatever you wanna call it) is important, regardless of the DB underneath. Making databases easily swappable is important so I don't love the idea of using Sequelize models, mongoose models, but then for other DBs using Tcomb or something.

For the UI part of admin or something I agree that:

A) It's a shit ton of work to support the front end flavour of the day B) If we implement a front end, say in React, then it won't be easy to use an alternative one along side it.

So it might need to be an opinionated front (that's still optional) but if you don't, for example, want to use React then too bad. If we can make it super light-weight so that it's easy for people to replicate and for the community to create different front-ends then it might work really well.

[AndreSteenveld]

Inspired by Django I have been looking around for something that comes with a CRUD-GUI or some sort of admin. I've been playing around with the idea of generating JSON-schemas for a bunch of models. Using those schema's you should be able to generate a validation code, schemas for mongoose[1] and other models. Bolting an admin on to feathers would seem relatively straight forward using a schema and something along the lines of ng-admin[2].

I think the advantage of this approach would be that no code has to be written for feathers specifically.(other than the JSON-schema generator, and some generated glue) There would be no worries about the "flavor of the day" and feathers would stay opinionated where it really matters, the REST and Socket.io interface it provides.

Just my 2 cents, if anyone is interested in this I want to set up a prototype for this somewhere in the next 2~3 weeks.

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

[marshallswain]

@AndreSteenveld I started working on something like this last year. You can see what I put together here: https://github.com/marshallswain/AmityApp. It basically functions around creating what I called Amity adapters, which are collections of feathers services specific to handling database types. I only made the MongoDB version.

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

amity-mongodb lets you manage an entire MongoDB server. It uses several feathers services:

• feathers-mongo-databases
• feathers-mongo-collections
• [feathers-mongo-users]() Coming in Auth release
• feathers-mongodb

Since everything uses Feathers services, as you add/remove databases and collections, it updates in realtime.

I haven't upgraded the amity server to Feathers 2.0, yet. You're welcome to salvage whatever you can from it. :)

I made it completely modular, so you can build your own UI on top of the amity adapters if you want.

[sajov]

you probaply alraedy know ng-admin. I like the way they handle specific backend. I do not like angular so i almost done porting that to riot.js

[ekryski]

I'm going to also toss out that there looks like a pretty good alternative called http://forestadmin.com/. It's paid and hosted but can work local for free. The creator told me that if you just load the Feathers middleware after the Forest middleware it works out of the box. I'm going to give it a try shortly.

[josx]

@ekryski @SeyZ Is that free software?

[SeyZ]

Hey @josx - We have a free plan for 1 user :)

[sjmcdowall]

If you have tried / used it / seen it -- the StrongLoop API framework generates a very nice Web UI for your RestFUL service ... Which is now http://loopback.io I guess (after IBM acquired Strongloop). Anyway, there maybe something there worth gleaming ...

[sjmcdowall]

@ekryski - looked at forestadmin.com but I don't see where / how it can work local for free? We are looking at using feathersjs to base our next gen enterprise (behind firewalls with no Internet access) so hopefully anything / everything can be locally hosted .. :)

[SeyZ]

Hey @sjmcdowall - You can install it on your app using the Forest package depending on the ORM you use: Sequelize, Mongoose or even Loopback.

You can try Forest on your localhost environment (http://localhost...) because data transits directly from your browser to your application without passing through Forest.

It's completely free for 1 admin user 👍

[junland]

This is a great idea. Both Strapi and Treeline (Same team behind Sails) have implemented this.

[Mentioum]

@ekryski how well did Forest Admin go for you? Did it require much fiddling? We've been building our own custom admin UI in react but it'd be nice to remove the workload if forest works nicely out the box?

[ekryski]

@Mentioum I didn't have luck with mongoose on the project and we were pretty pressed for time so went to ng-admin. Trying to sort out with the Forest team whether it's something with Forest, Feathers or if I'm just stupid. Should have some time to give it another proper go later this week. Will definitely report back.

[VinzGhyz]

@Mentioum Allow me to chime in, I'm working with @SeyZ on Forest. We'll be investigating the issue with @ekryski. In any case, if you're interested in trying out Forest feel free to reach out to either Sandro or me (emails are firstname@forestadmin.com) and we'll work out any issue together.

I've got Forest working on FeathersJS with Sequelize for a side project, so the issue might be limited to mongoose. Here's a gist of the app.js file which was only tweaked to add Forest.

[josx]

Sorry but i dont see the point on working on an admin like forest that it is not free software/open source. I think we better work on ngadmin o similar.

[Mentioum]

thanks @ekryski .

thank you @VinzGhyz. Thats awfully kind but no thank you. Until i know it works with mongoose out the box i don't have the time to commit to it as we already have a working solution we are maintaining ourselves. The only reason for us to switch would be at a 0 work load / less work load than our current solution.

I'll be watching to see what happens.

(I know I have mentioned it before but I actually think KeystoneJS has a great autogenerated admin with pretty solid options based on ElementalUI (react) ) @JedWatson would probably have some good insight into the best way to go about this.

[JedWatson]

@Mentioum thanks for the mention, I'd like to think that's what KeystoneJS has 😀

We're actually discussing how we can focus more on the two core concepts that Keystone is really strong with: Keystone Lists and the Admin UI. I haven't taken a deep dive into Feathers for a while but what I've seen looks great, and it's focused on a slightly different area.

Our next major version is imminent (hoping to ship a beta in the next day or so) which has been a year-long rewrite including a fully react / redux UI and new APIs. I'd definitely be open to working with Feathers to figure out how to reduce some of the crossover and make our projects compatible, if that's of interest.

We're also hoping to liberate ourselves from the hard connection to mongoose in the not-too-distant future, which might make it an even better fit, if we can come up with the right flexibility in how you connect to an API / datastore.

Feathers team - feel free to reach out if you want to explore this further.

[ekryski]

@JedWatson awesome. We should totally collab. Excited to see the new version. I had actually been hoping/thinking about how we could hack up Keystone to have Feathers as the backend piece.

@Mentioum I'm in the exact same boat as you. Too busy. Hopefull will be able to carve off half an hour or so this week to see if I can get Forest working.

We've been pretty impressed with ng-admin (even though I'm not a massive fan of Angular). However, there is still a lot of boilerplate/redundancy you end up doing on the client side to support stuff that you already have defined in schemas server side.

[marshallswain]

Putting Keystone on Feathers would be gold! I'll contribute to that.

[Mentioum]

@JedWatson @ekryski @daffl

No problem I've made lots of stuff with Keystone (I'm a fan) (same with feathers):

http://161london.com (client work) http://thenidocollection.com (client work) http://headstartapp.com (current startup)

And we are using Feathers as a simple way to pop up lots of little services which power the actual Headstart Apps (All React and React Native atm - some with Electron wrapping it for corporates who hate 'browser apps').

This might be a bit of a stretch but if you are genuinely thinking about keystone having some sort of ORM wouldn't it be way cooler to use feathers as a microservice which runs alongside keystone and you just use that?

That way keystone can still have its 'turn key' solution which generates everything with mongoose but then if you want to be a bit more fancy you can spin up some Feathers microservices for specific Lists which you supply an endpoint to a specific Feathers service.

I'm sure you guys have a much better idea on how to structure it. (Obs you can just do it with express routes in Keystone but then you'd have no autogenerating admin :))

Genuinely having small Dockerstack dreams right now:

redis, mongodb, keystone, feathers-microservice1, feathers-microservicex, PSgress, Elasticsearch etc etc.... ....

Anyway needless to say if this can be a thing... id be up for it.

[sunabozu]

Hey guys. If you've started building this project, can you give a link to your repository or anything else so people can keep an eye on it?

[sarkistlt]

+1 would like to see some patterns example, using keystone with feathers.

[osenvosem]

It is certainly a good idea to have auto-generated backend.

[sarkistlt]

For developers who use GraphQL, this can be a good solution: GraphQL auto generating CMS.

[joelkoz]

I have a project that I have been working on for a while that may be of use/interest: NodeMDA is a code generation engine that takes UML models and generates source code. You can model high level concepts like "Entity" and "Service", and get an entire stack generated for you. I just completed a plugin for it that generates a complete app using Feathers on the server side, and React + Material-UI on the client side. Each entity you model gets a full CRUD editor.

The entire framework is MIT Licensed, but it currently does not have its own modeling tool. I am currently using StarUML for my modeling app, but that is only because it was inexpensive and its meta data was stored in JSON rather than an xml doc (like XMI). While StarUML is a commercial product, they do have a free unlimited evaluation period (its nag ware). I am not affiliated with StarUML in any way - its just their modeling tool met my immediate needs. NodeMDA does support pluggable readers, however. I have on my long range road map to write a quick and dirty UML class editor so people can use it without having to pay anything.

I used to contribute to a Java MDA project (AndroMDA), and I wanted to have something similar in the Node world, so I've been hacking away at NodeMDA. The engine itself is performing pretty well. Its pretty easy to create NEW plugins to generate code a different way, or even in a different language. I like to say "its opinionated, but open minded."

Since it does Feathers on the back end, you may find it useful right away, or it may make a good starting point for something else. Check it out:

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

and the feathers plugin is here:

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

[kulakowka]

maybe we can use it: https://github.com/ForestAdmin/lumber

[davidnathanael]

would be great to do something with admin-on-rest

[thepearson]

If anyone is interested. I've started working on a fork of evolutility-ui-react to add support for the feathers API. I've literally only just started, but got basic CRUD working for simple models, and part way there for binary files... the original codebase can use a bit of refactoring and I need to add support for/test a bunch of field types, however it could be of use for someone. I'll be pushing more changes over the next few weeks.

[paulocoghi]

About the problem of

support the front end flavour of the day

I believe that Svelte solves this pretty well (github). Everything made with it is universal and becomes framework-less vanilla JavaScript.

I strongly suggest it because it's future proof and always interchangeable with whatever technology "of the day"

[josx]

@ddela-cr i have started a project to write a custom feathers rest client for admin-on-rest . Please check it, contribution welcomed...

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

[josx]

We realeased a new version for https://github.com/josx/aor-feathers-client and also we have a proof of work on https://github.com/Cambalab/test-feathers-admin

[beevelop]

As I struggled with this very same topic for quite some time, I'd like to share my approach using ng-admin (admin-on-rest's older brother based on the plain-old AngularJS) too.

I extracted the bare minimum configuration required to get ng-admin & ng-admin.jwt-auth working with Feathers and turned it into a carefully crafted repo: https://github.com/beevelop/feathers-admin-starter

[josx]

@beevelop well done!

Some days ago i have donde almost the same with ng-admin (but your version has more features done). Here a repo with (feathers app, ngadmin and admin-on-rest).

Maybe we can improve the sam example with ng-admin and admin-on-rest + feathers.

[SeyZ]

Hey guys,

Each framework needs to reinvent the wheel for the admin interface. There's a "feather admin", a "laravel admin", a "rails admin", etc. Crazy, isn't it? This is why I've released Lumber (https://github.com/ForestAdmin/lumber) - instead of being plugged in your application, it generates a new one specially for the admin (in other words, it generates an admin microservice).

What do you think about this solution?

[josx]

@SeyZ in my project is not viable, beacuse we decide to have control over all software. So if it is not free software i am not able to buy a service.

Also from the developer point of view I think you have done a great work but it is not usefull for the community.

You may think a business model that includes free software as core. Just my 2 cents.

[SeyZ]

@josx Lumber is completely opensource and Forest is a service that give you automatically a great UI (I hope :D). Everything is completely free of course!

[kulakowka]

Take a look at the updated version of admin-on-rest. It looks amazing.

[ekryski]

I think there are some pretty good solutions here now, so I'm going to close this for now. The core team is not working on anything official and doesn't have plans to do so in the near term.

This issue is getting lengthy, but I don't want to lock it in case something new comes along. If you come across something that hasn't already been mentioned that you think would be a good fit, feel free to post it! If this starts to just become a discussion board or we start to see to much of the same thing, we'll lock the thread.

Thanks for all the input everyone! You guys are making the community amazing! ❤️

[kulakowka]

In a project of any scale one way or another, you will need to create an admin pages. Maybe we should create a page in the docs with links to different libraries for creating GUI Admin pages? I would be glad to have a solution out of the box, but we can at least recommend the best quality solutions.

[marshallswain]

@kulakowka It would make the most sense to add a section to the Ecosystem page after the starter stacks section. https://docs.feathersjs.com/v/auk/ecosystem/readme.html

[christiaanwesterbeek]

An equivalent solution based on Loopback and Angular exists too. It's called Colmena-cms (formerly known as Loopback Angular Admin).

Combining Feathers with admin-on-rest makes the most sense because we'd then need to focus mainly on building the bridge between the both without needing to focus on how to render admin pages.

For such a new solution that depends on feathers and admin-on-rest, we would need a way that allows easy updates of these two dependencies.

I suppose building and maintaining such a solution should take less effort than Colmena.

[josx]

I have contributed to colemena-cms in the past, but it is just for loopback. That's why having an app like admin on rest is the perfect option to feathers.

Take a look on aor plugin that we are working on. https://github.com/josx/aor-feathers-client