Our History
Our small team of eight has been using FeathersJs as Backend & API for about three years now. In the beginning, the first week we chose Feathers, was challenging. Feathers introduced new work and think patterns which took us some time to grasp. After that initial bump, we never looked back and started to recommend it to anybody. The community is very helpful and nice. It was great.
Stability
The software proved super stable and all just works. We never had even one serious issue in all these years. I have tremendous admiration for the team behind the tool. Especially David, @daffl is by far the nicest, most knowledgable, and most responsive founder of an open source project that I know of. I am just very grateful that such people give their energy to the community.
Nice to juniors
What is also great, is that junior developers could maintain our API. And this is a good thing when you realize that maintaining APIs is usually not the hobby of senior programmers. Of course, all juniors have this first tedious week where they need to get their heads around "hooks" and stuff before we can use Feathers, but it is worth it.
Some minor wishes
During the time, we only had a few desires:
- It would have been nice to have Typescript support. We moved to Vue 3 on the Front-End, and there we are happy to use TS
- We would like to get rid of the
myservice.class.js files from the feathers generate service. You see, we had decided already about twenty(oops) years ago that software with abundant use of classes is not the easiest to maintain over time. It all sounds super savvy at first, but if the developers are either junior or even seniors when time passes, we better do without. I realize other people might feel different. But for us, when scaffolding new services, we just told the junior to pretend these files did not exist.
- Documentation. We did not reach a level where we felt confident enough that we could contribute to the project with user manuals ourselves, but we knew we had to one day. Do not get me wrong, the current doc is great and we are thankful, but juniors almost always get a bit lost. They need to start Googling. Coincidentally, then there the best information again comes from David))
Now Dove
So we were super happy to learn that in September 2022 we could start a new Greenfield project, and we decided to go for Feathers 5.0, aka Dove. However, truth be told, that has been a week of mixed feelings.
The good
Typescript is omnipresent everywhere. You can not go wrong with that. Also, the project shows lots of love and care and feels robust and trustworthy.
The bad
We found upgrading from previous Feathers to be less pleasant. Even though there is a long list of migration tips, we still get a lot of errors. For example, yesterday we noticed that no longer is working
// in users.service.js
app.use('/version', { async find() { return { v: await versionInfo() } })I know, these are small things. And while it will take us some weeks, I suppose it might make our code a bit even better.
The Ugly
In all this, the main issue with Dove is that we feel we lost the beauty of the simplicity of Feathers.
As an example, there are no longer myService.hooks.js files. This is sad, as it was a dream: simple files with the before, after and error hooks that we all understood. Perfect. Instead, Dove hides hooks in myService.class.js. And there it's confusing, as Dove introduces around hooks. I read the documentation on that twice, but I can not get the logic. I am sure it is super savvy though.
Then the schemas. That's the worst about the new version. Previously a new myService.model.js was about ten lines of code, without field definitions. Now in the new myService.schema.ts, we have more than fifty lines! Of course, there all kinds of magic happen and no doubt the code is more robust for query and patch and whatnot. But so much boilerplate? For each new service again? It feels scary to me and to juniors at first glance.
The list is long, but that would be too much for this post.
The future
I recall I felt the same long ago with Modx and later also with a full stack framework called Meteor. Both were amazing products created by, very smart developers. But after their initial success, new versions came that were too smart for the majority of the community. Both lost momentum and never really recovered.
Maybe with Dove, it is just the CLI and scaffolding that tries to scare us. Maybe the elegant simplicity of the previous versions can be reinstated? What can we do to help?
For now, it seems the best we can do is try to downgrade back to version 4.5, after the weekend though. It's Friday today))
About the long term, we do not know though. And hopefully, others can weigh in. What is wise? Should we accept that the target audience for Feathers has changed to a more sophisticated, higher level of developers? Should we stay on version 4? What about long-term maintenance?
Our History
Our small team of eight has been using FeathersJs as Backend & API for about three years now. In the beginning, the first week we chose Feathers, was challenging. Feathers introduced new work and think patterns which took us some time to grasp. After that initial bump, we never looked back and started to recommend it to anybody. The community is very helpful and nice. It was great.
Stability
The software proved super stable and all just works. We never had even one serious issue in all these years. I have tremendous admiration for the team behind the tool. Especially David, @daffl is by far the nicest, most knowledgable, and most responsive founder of an open source project that I know of. I am just very grateful that such people give their energy to the community.
Nice to juniors
What is also great, is that junior developers could maintain our API. And this is a good thing when you realize that maintaining APIs is usually not the hobby of senior programmers. Of course, all juniors have this first tedious week where they need to get their heads around "hooks" and stuff before we can use Feathers, but it is worth it.
Some minor wishes
During the time, we only had a few desires:
myservice.class.jsfiles from thefeathers generate service. You see, we had decided already about twenty(oops) years ago that software with abundant use of classes is not the easiest to maintain over time. It all sounds super savvy at first, but if the developers are either junior or even seniors when time passes, we better do without. I realize other people might feel different. But for us, when scaffolding new services, we just told the junior to pretend these files did not exist.Now Dove
So we were super happy to learn that in September 2022 we could start a new Greenfield project, and we decided to go for Feathers 5.0, aka Dove. However, truth be told, that has been a week of mixed feelings.
The good
Typescript is omnipresent everywhere. You can not go wrong with that. Also, the project shows lots of love and care and feels robust and trustworthy.
The bad
We found upgrading from previous Feathers to be less pleasant. Even though there is a long list of migration tips, we still get a lot of errors. For example, yesterday we noticed that no longer is working
I know, these are small things. And while it will take us some weeks, I suppose it might make our code a bit even better.
The Ugly
In all this, the main issue with Dove is that we feel we lost the beauty of the simplicity of Feathers.
As an example, there are no longer
myService.hooks.jsfiles. This is sad, as it was a dream: simple files with the before, after and error hooks that we all understood. Perfect. Instead, Dove hides hooks inmyService.class.js. And there it's confusing, as Dove introduces around hooks. I read the documentation on that twice, but I can not get the logic. I am sure it is super savvy though.Then the schemas. That's the worst about the new version. Previously a new
myService.model.jswas about ten lines of code, without field definitions. Now in the newmyService.schema.ts, we have more than fifty lines! Of course, there all kinds of magic happen and no doubt the code is more robust for query and patch and whatnot. But so much boilerplate? For each new service again? It feels scary to me and to juniors at first glance.The list is long, but that would be too much for this post.
The future
I recall I felt the same long ago with Modx and later also with a full stack framework called Meteor. Both were amazing products created by, very smart developers. But after their initial success, new versions came that were too smart for the majority of the community. Both lost momentum and never really recovered.
Maybe with Dove, it is just the CLI and scaffolding that tries to scare us. Maybe the elegant simplicity of the previous versions can be reinstated? What can we do to help?
For now, it seems the best we can do is try to downgrade back to version 4.5, after the weekend though. It's Friday today))
About the long term, we do not know though. And hopefully, others can weigh in. What is wise? Should we accept that the target audience for Feathers has changed to a more sophisticated, higher level of developers? Should we stay on version 4? What about long-term maintenance?