Closed eddyystop closed 4 years ago
eddyystop
commented
6 years ago marshall [3:27 PM] https://github.com/akxcv/vuera
Lets you use Vue in React or vice versa. React has such a small footprint that it’s not much of a concern to use React components in a Vue app.
gabrielstuff
commented
6 years ago Hey ! Nice. We are making progress on the doc. In order to project our work in real working condition. I'd like to battle test it against some basic API.
I plan to demo it, against :
What other project would be interesting to test ?
Cheers, g
eddyystop
commented
6 years ago I'll look at what you come up with. It would make sense to wire a CRUD into cli+
gabrielstuff
commented
6 years ago Works ok with feathers-chat and myethereumapp. Need some tweaking for api-playground. Any classical example project / API would be a good fit for testing.
ipalfy
commented
5 years ago Hi @eddyystop, Not exactly a CRUD Backend, but I would really love to see a "Real World" (https://github.com/gothinkster/realworld) - implementation done in feathers.
It took me quite a while to get used to feathers, since there were/are no really good CRUD examples. Especially when it comes to "one to many" or "many to many" relations etc. Realword specifies exactly that kind of app, developers might have to implement most often (not chat). Still very basic, but showing everything to get started. More benefits: See how things are done with different frontends and a really good postman collection. Extenting realworld with a realtime-best practice for CRUD would be a nice bonus ...
btw: Funny to see that all "API over REST"-frontends are made either in Paris: https://strapi.io/ and https://www.forestadmin.com/ or Nancy (also in France), like https://marmelab.com/en/. ;-)
btw2: forest is looking for a developer advocate. And they really need one, since their website seems to be made for business guys only, "begging" for email-addresses, focusing too much on the "what" (business results) not the "how" (developers main concern). I still couldn't find out, how I could use forest in a completely self hosted, open source environment. I am sure, many developers spent too much time on their website not getting it.
eddyystop
commented
5 years ago There are impedements to releasing commercially developed apps. The funding company may own the rights, or they would be unhappy if the code they paid for was released into the wild. Feathers suffers from this as its being used by multinationals who don't even want their names released.
Apps of a personal nature tend to be limited in scope.
Even in general, an app has many needs with multiple possibilities (For the frontend alone fhink React ecosystem, Vue, and Angular. For API think REST and GraphQL). First, you won't find something addressing you particular desires. Second, you'll get lost in the details of the app.
That being said, the chat example does highlight the realtime features of Feathers.
There is a GitHub project that's implementing a more comprehensive example that a To Do list in multiple frameworks.
There is only so much time in OS. I spend almost as much time doing docs as I do writing code. I'll leave it to someone else to "donate" an example app.
ipalfy
commented
5 years ago @eddyystop All true, all understandable. On the other hand, regarding realworld.io: Docs, frontends etc. are all done, that's less work for the implementer of a new backend. Just the code and a few lines of readme. However: I just found: https://generator.feathers-plus.com/get-started/#comprehensive-example . Almost the same as realworld.io. Very nice!
btw: You do an awesome work. I might use most of feathers-plus ... (not for a multinational but a nice, small, free volunteering-app)
Some boilerplate into which dev adds code for rules.
====================== gabrielstuff [9:25 AM] Hola ! I'm reading https://github.com/feathersjs/feathers/issues/271 and wondered what was the standard and preferred way for the feathersjs community to provide CRUD Admin(Backend) for there services ?
gabrielstuff [9:28 AM] We have :
ryan.wheale [2:19 PM] I agree with @Beau Shaw - every project has such drastically different business requirements that I've had to build custom stuff per client. When you start trying to build something that can be used anywhere, you end up with something like SharePoint and everybody loses.
Beau Shaw [2:24 PM] I don’t mean to discourage you @gabrielstuff! I want to see the feathers community grow and some sort of automatic “super admin” app that “just works” would be great! So I think what your a proposing is super cool.
ryan.wheale [2:58 PM] ^^^ again, I agree with Beau. I have some pretty nifty form generation code written in react - it takes a JSONSchema and builds a form. I didn't get a chance to finish it before the project got killed by corporate BS, but it was going to recursively generate nested forms too so you could create/edit objects with related data.
gabrielstuff [2:59 PM] Beau, no problem i’m happy to exchange and discover usage. Maybe I wasn’t clear. I’m not trying to build a tool for everything. I’m trying to bring a part of what feathers have bring to API development . I’ve waited longtime before switching to Feathers. I was a huge fan of meteor, hapi, and been experiencing 1 year with strapi. The reason I embraced feathers since a year is the modularity and flexibility
Beau Shaw [3:01 PM] Strapi is cool. I have looked at t a few times
gabrielstuff [3:02 PM] Plus no bullshit philosophy
ryan.wheale [3:03 PM] Yeah, if you are used to those tools, the main difference is that where those tools required an opinion, feathers doesn't. One of the drawbacks of not holding strong opinions in a framework is the inability to have things like a default super admin interface.
gabrielstuff [3:03 PM] So I do not want to add a crud to feathers. It is more something that will live in the eco An opinions ? I’m french not sure I get it
ryan.wheale [3:05 PM] For example, they have a certain way of doing things - you don't get to choose. For example, meteor uses only MongoDB, right? As far as I know they have a "standard" way of defining models and/or a way of doing things. Feathers does not really impose these limitations.
gabrielstuff [3:06 PM] Oh yes ! This is the reason I switched to feathers
ryan.wheale [3:06 PM] Those other frameworks make you adopt their "opinion" about certain things.
gabrielstuff [3:06 PM] Currently I’m working with Nedb / mongoose / mongodb Ok understood So I think this is the pitfall I do not want to fall in
ryan.wheale [3:08 PM] For example, if you build an admin interface in veu, I probably wouldn't use it on my react project... because we took a different opinion about the frontend framework.
gabrielstuff [3:09 PM] Yes ! Reason why I’ve planned for the question what framework do you want to use A bit like the way you can use koa
ryan.wheale [3:09 PM] All that said, I'd love to help in any way I can - I think it would be a heavily used contribution, especially for newcomers.
gabrielstuff [3:09 PM] And not only express And you can choose primus or mqqt etc Anyway finishing first draft of the doc next week I’m happy to read your comments and discuss. And about vue or react or both, you are totally right ! The reason I went for a new tool is because the only good one was written in react and my whole team is on vue :) since v0
ryan.wheale [3:14 PM] ahh, there you go. do you have a link to the react one?
gabrielstuff [3:15 PM] Daffl cited it. React admin based Renamed https://github.com/josx/ra-data-feathers Message Input
ryan.wheale [4 hours ago] Pulling to a thread so we don't pollute the channel. Yeah, I was just looking at that. It uses react-admin: https://github.com/marmelab/react-admin
The same group also built
ng-adminfor angular, and react-admin is based onng-admin. You might want to see if you can coordinate with them to build aveu-adminwhich follows the same patterns (material design, internationalization (i18n), et al). Though that might be too much for you to take on.