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
The database adapters were one of those things that looked like a good idea but make things much more difficult in the long run. 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. The query syntax, especially in combination with schemas, added another layer of mostly unnecessary complexity - an external API usually only ever actually uses a small fraction of the available syntax which is something that should be declared explicitly anyway.
In a time where an LLM can easily help you write the exact SQL or MongoDB query that you need, abstractions on top of the plain databases have become much less useful. Database drivers and tools like Prisma or Kysely also got a lot easier to integrate and better at TypeScript typings. It makes much more sense now to directly put the database calls into a plain Feathers service where you exactly see what is happening instead of having things hidden in yet another module.
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 likely go a similar path. It is currently very difficult to tell if there even is an interest in an upgrade path but a paid automated upgrade script for both v4 and v5 may be made available (possibly through some kind of a Kickstarter to finance the necessary work).
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), get pull request accepted but will no longer be actively developed.
Beta Was this translation helpful? Give feedback.
All reactions