Replies: 1 comment
-
|
While i am the last one on earth that someone would listen to in tech, due to hard falls ,i will comment :), because i love the design philosophy of feathersjs Service Oriented approach and unified layer to HTTP and web-sockets despite the fact i could not back feathersjs project financially my point is simplicity and loosely coupled libraries may have lead to the freedom of choice yet they have made the JS echo-system to expand exponentially in such a way that is killing clustered adoption and community contribution , looking at Laravel, Ruby in Rails and the following tweet from Laravel maintainer might shed some light on the topic : i hope that this project finds its way to not only sustain the living costs of the maintainers but also to prosper as you deserve it |
Beta Was this translation helpful? Give feedback.
-
I've been wanting to make a more official recap and announcement post but it keeps getting put off so I at least wanted to drop some thoughts here for anybody that might be interested.
TL;DR - Feathers v6 (no bird name) will be a return back to the basics, focusing on the things that Feathers has always been good at - services, hooks and HTTP and real-time APIs. It will be based on modern web standards and work with NodeJS, Deno, BunJS and Cloudflare Workers. Everything else will be moved back to the ecosystem - making things a little less batteries included and better separated will leave more options for choosing the best database, authentication and framework integration for your needs.
Why?
As I said before, v5 was a very ambitious release. Too ambitious as it turned out. We've always accomplished a lot for the very limited resources that this project had but this time, the direction wasn't ideal. It was also bad timing with some tough times in the tech industry combined with GPT and friends essentially killing open source consulting as a business (at least in this case). Since the beginning of last year things have gone from the previously one or two paid support/consulting requests per month to literally zero. While before it may have made sense to officially support multiple databases, frameworks, languages and authentication methods in order to drive consulting, that is no longer the case and I am not expecting that to come back.
Web standards
Web standards for server side JavaScript have come a long way. Far enough in fact that I don't think there will be a need for low level HTTP frameworks like Express, Koa or Fastify anymore in the long run. Platforms like Deno, Cloudflare Workers and Bun already support much of it out of the box and NodeJS is not too far behind.
Similar to how jQuery eventually went away but made way for things like React, VueJS etc., I think there is still a need for higher level application frameworks. To this day, Feathers is the only one that has a unified approach for HTTP and real-time APIs. This is something that - in the fight with database associations, TypeScript types and user management - often gets missed but really should be the main focus.
Authentication
Authentication is hard. Over the past 10 years we've seen the struggle and done our best to try and provide a secure and well supported open source solution but we finally came to the conclusion that the best way to continue solving this problem in a sustainable way is a developer-friendly service. For the past few months we have been working on Feathers Cloud Auth which lets you add scalable and secure, user-owned authentication to any NodeJS, Deno, Cloudflare, BunJS and browser application with just a few lines of code. We are really excited with how it is all coming together and are currently looking for interested beta testers. You can sign up for the newsletter at https://feathers.cloud to keep up to date.
Databases
We really like our database adapters. The common syntax and CRUD functionality makes it easy to get started quickly. However, we made a mistake in the separation of concerns by having the adapter be the same thing as the externally accessible service. You end up having to do a lot of convoluted things when you want different data returned than what is in the database or depending on whether it is accessed internally vs external.
This is why we started Wings. It's the same thing as the existing data adapters but not intended for external access. Instead, you initialize the adapter in a custom service and call the methods and return the data that you need. They can also be used with any framework and are no longer limited to just Feathers.
In reality, every service should be a custom service that only deals with external access and makes exactly the database calls you need. I've been having a great time going back to basic services and using Kysely directly for end-to-end typed services. And if you want to use a database adapter, including the upcoming Kysely adapter, you'll still get end-to-end typed services. It's really nice.
Compatibility
There weren't really too many breaking changes in v5 but due to the changes in the generated app, a large majority of users have not upgraded to the latest version. v6 will have a migration path for both, v4 and v5. In both cases you should be able to continue using the existing generator for that version. A paid automated upgrade script may be available. v6 will come with a very minimal starter for each platform and a simple customizable Pinion template to generate a new service.
Maintenance mode
As mentioned above, everything else - the authentication modules, the Express, Koa and Socket.io adapters, schema and TypeBox integrations will be moved to the Ecosystem. This means they will continue to work as is, receive dependency updates where necessary (and possible) but only continue to be actively developed as it makes sense.
Beta Was this translation helpful? Give feedback.
All reactions