search

Phoenix-Codeworx / phoenix-framework

A plugin-based graphql server framework built on Bun, Apollo, Mongo, and Express. Rising from the ashes of Reaction Commerce
MIT License
3 stars 0 forks source link

feat: decouple plugins from framework. #22

Open brent-hoover opened 5 months ago

brent-hoover commented 5 months ago

Right now your plugins need to be in a very specific place in the structure of the project for them to work. Most people using a framework will want to keep their custom plugins separate from the framework code. A couple of issues now:

  1. Global imports of things like logger and GlobalContext are done through explicit path. Is there some way to do a type of virtual package where these can all be imported from @phoenix/phoenix-framework?

  2. Right now it iterates over the plugins directory, but it should be able to import these from anywhere. The optimal setup from a developers perspective is that their custom code can live in a completely different repository. Reaction solved this with having npm packages but this was always a difficult solution as it involved either publishing packages to your own private npm or github, or using something like pnpm to have "virtual" packages.

Should spend some time looking at what other people are doing since this is a pretty critical feature. At some point will probably involve publishing a package that can be imported from and that each plugin just needs to call a "register" function.

brent-hoover commented 4 months ago

I am going spend a little more time investigating what other frameworks do but I think the approach will be essentially what we ended up with RC.

We create an cli app that can:

  1. Create a skeleton app
  2. Create an example app (this will be our commerce app)
  3. Skeleton out a plugin

The framework package will import a "register" function that they will pass everything into (models, etc). In each app will be a pluginloader that iterates over all the plugins and calls their index and in the index they will call the register function. This will be like the 25 line loader in the RC app so none of that logic lives in the app, but in the framework

Possibly I can use my work on the RC cli app.

Also it's going to be time to think of a better name for the package than phoenix-framework although I suppose while no one is using it it doesn't really matter

Not sure what makes the most sense if we want to go with a monorepo approach and have both the cli app and package in this repo or if it's just simpler to keep them separate. Again, I will spend a little more time investigating what other people are doing.

brent-hoover commented 4 months ago

I notice that Adonis just uses npm init to init a project rather than having to install a cli. Also I noticed that expressoTS also is Bun compatible.

brent-hoover commented 4 months ago

@aldeed This is the thing I will work on next, would like to get your thoughts

Also any thoughts on how to best structure the repo to possibly keep the CLI, the template app and the main framework that will be published as a package all in the same repo?

Also might want to move the Event System and the RBAC to separate plugins