feathers

feathers copied to clipboard

Benefits

• we could fit all these projects on screenshot, 2 folders are cutoff
• we could run this on ANY pure JS system without worrying about mongoDB or SQL lite compiling or running on WASI / RISC / NixOS / Raspberry Pi / Cloudflare Workers / Lambda / Google Cloud Functions / Microsoft Excel.
• Maybe it will run better on my 16GB / 8GB devices that are constantly screeming at me for having too many projects open. Sleeping tabs are a pita.
• Could run on in the browser, which is a lot more battery / memory efficient on MacOS, iPadOS, vrOS and ChromeOS.
• Could maybe run on cloud workspaces a lot smoother... Currently the one gigabyte BTRFS limit is an issue on Replit, and everything else is even less capable in other ways, like VNC support for E2E testing and native GUI tools.
• Would allow people to contribute more efficiently, rather than having to setup a whole bunch of stuff on every device just to get a 20 minute full-cycle time and a dead battery.
• multiplayer is currently impossible, because this is too big for replit... more efficient strict packages would make it work, but thats far more work than an mv command. I can't train coworkers on feathersjs effectively, remotely without it.
• Would allow contributors to work from home / bed / VR / sailboat / cottage / pregnancy test.

I would be thrilled to take on this project if you make the Repo and give me access. I'll even setup some badass workflows. I think the adapter name was good, but data or stateful also works.

If we use data, we could also move other stateful things like

• generators
• create-feathers
• cli

All of which are concerned about generating or maintaining out of memory, non-statically-typed, long living, stored data. TypeBox and Schema are just typescript on steroids, the can be used in authorization, channels, services, all of which deal with short lived in transit data.

This would also allow us to potentially bring in other popular ideas into /data or /stateful Like authentication-management and lowdb. As well as making room for authorization in the core feathers repo, which I think should be @feathersjs/core, rather than the wet @feathersjs/feathers. Wet feathers are never good.

This is actually something I've been talking with @marshallswain about as well. As we all discussed before it seems that bundling everything together for v5 was a little overambitious so going forward, making the core framework and repository as platform independent as it can be and focussing back on Feathers core strength (services, hooks and transports) instead of trying to solve database problems (and everything that comes with that like external resolvers and query syntax validation) seems to be a good way to go.

This would also mean promoting a better separation between services and database adapters. @marshallswain started a standalone project for the database adapters where they can be used with basically any framework. Using them with a service could then look like this:

import { feathers, hooks, service } from '@feathersjs/feathers'
import { authenticate } from '@feathersjs/authentication'
import { Type, Static, validateData } from '@feathersjs/typebox'
import { KnexDatabase } from '@birdhaus/knex'


const messageSchema = Type.Object({
  id: Type.Number(),
  text: Type.String()
})

type Message = Static<typeof messageSchema>

@hooks([
  authenticate('jwt')
])
class MessageService {
  db: KnexDatabase<Message>

  constructor () {
    this.db = new KnexDatabase<Message>({
      Model: app.get('knexClient')
    })
  }

  async find () {
    return this.db.find()
  }

  @hooks([
    validateData(messageSchema)
  ])
  async create(data: Message) {
    return this.db.create(data)
  }
}

export const app = feathers<{ messages: MessageService }>()
  .use('messages', new MessageService())

This would also mean promoting a better separation between services and database adapters. @marshallswain started a standalone project for the database adapters where they can be used with basically any framework

This could be huge... Kinda like angular using Volar chrome extensions and many React and Svelte projects now being bundled with vite. When more people find it useful, they are more likely to come back and contribute innovative features that help everyone... Like how Vite 4.3 somehow got faster https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#430-2023-04-20

I would love it if my work on Replit and LowDB adapters would help others by default. Might need a rebrand though. The Supercharger Network, Volar and Vite would not be as popular outside the ecosystem if they were called Tesla Supercharger Network, Vuelar and Vueti... Though I kinda like that last one.