feathersjs / feathers

The API and real-time application framework
https://feathersjs.com
MIT License
15.04k stars 751 forks source link

[FR] Give adapters, generators and migrators a better home #3209

Open FossPrime opened 1 year ago

FossPrime commented 1 year ago

Screenshot_20230608-201132~3

Benefits

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

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.

daffl commented 1 year ago

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())
FossPrime commented 1 year ago

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.