What do you want and why?
This is a big one but could work as a roadmap for what we want in terms of the internal codebase of blitz moving forward.
We need to guide our internal architecture to avoid unnecessary dependencies and spaghetti code.
We want to somehow keep things orthogonal which means following "things that change together stay together" but also allow for horizontal layers to be grouped where appropriate.
Possible implementation(s)
I have a suggestion (feel free to workshop this with me - also if you are a code owner and want to update the description of any package please comment):
app framework
User app Code that actually runs in user apps.
- rpc,
- cache management
- rpc and reactQuery templates used by generator and server-manager's synchronizer rules should live here and be imported
Code should be built for both node and browser and deeply linked.
blitz
Blitz wrapper package.
Determines launch environment exports public api for users. This stays the same
cli
Argument parsing
Responsible for parsing command-line arguments and delegating data to the correct downstream packages and displaying help text. Data qualification with enquirer can be managed here as that is part of parsing arguments (or not?)
Will probably accept configuration from the prisma package and generate an oclif plugin internally here to configure new commands.
repl
REPL
Launch the blitz REPL
generator
Dynamically generate source files in a users project
Generate files within client app directory. Pull in templates and generators from the prisma package and elsewhere eventually and use that to generate assets appropriately.
prisma
Database plugin
Fledgeling db package and first plugin. Anything related to prisma should live here and get exported into wherever it is needed. API can be refactored internally and get ready for release
We want to avoid any system dependencies here that we don't control (eg. oclif) as whatever dependencies we have here that aren't prisma related will need to eventually become part of the plugin framework. Naturally anything prisma/db related is fine
synchronizer
Accept rules and pipe and transform files based on those rules
Accept config and setup a vinyl file transform pipeline with dynamic stages (could possibly eventually be used by generator) pipe them to a file writer interface.
server-manager
Manage next-server process
Accept an input stream listen for events and manage the next server start, stop and output appropriately
utils
Shared general development libraries
General small focussed development utilities similar to lodash and not blitz specific. Nothing should have any dependencies on anything else in the codebase aside from potentially other utilities.
EDIT: Avoiding a utils library will mean less refactoring in the future as we rarely will need to extract out libs from utils which may happen if people start adding things to utils.
display
Render client facing awesomeness
Currently called log. Blitz specific node cli display library. This might end up depending on ink or something like that at a later date. Should be able to be piped to. Can be swapped out for a view that writes JSON objects to a file for debugging for example. Can be set to remove all clear commands for nice display logging in a concurrent process or logging to a file.
UPDATE: Possible Action Summary
What do you want and why?
This is a big one but could work as a roadmap for what we want in terms of the internal codebase of blitz moving forward.
We need to guide our internal architecture to avoid unnecessary dependencies and spaghetti code.
We want to somehow keep things orthogonal which means following "things that change together stay together" but also allow for horizontal layers to be grouped where appropriate.
Possible implementation(s)
I have a suggestion (feel free to workshop this with me - also if you are a code owner and want to update the description of any package please comment):
appframeworkUser appCode that actually runs in user apps.Code should be built for both node and browser and deeply linked.
blitz
Blitz wrapper package.
Determines launch environment exports public api for users. This stays the same
cli
Argument parsing
Responsible for parsing command-line arguments and delegating data to the correct downstream packages and displaying help text. Data qualification with enquirer can be managed here as that is part of parsing arguments (or not?)
Will probably accept configuration from the prisma package and generate an oclif plugin internally here to configure new commands.
repl
REPL
Launch the blitz REPL
generator
Dynamically generate source files in a users project
Generate files within client app directory. Pull in templates and generators from the prisma package and elsewhere eventually and use that to generate assets appropriately.
prisma
Database plugin
Fledgeling db package and first plugin. Anything related to prisma should live here and get exported into wherever it is needed. API can be refactored internally and get ready for release
We want to avoid any system dependencies here that we don't control (eg. oclif) as whatever dependencies we have here that aren't prisma related will need to eventually become part of the plugin framework. Naturally anything prisma/db related is fine
synchronizer
Accept rules and pipe and transform files based on those rules
Accept config and setup a vinyl file transform pipeline with dynamic stages (could possibly eventually be used by generator) pipe them to a file writer interface.
server-manager
Manage next-server process
Accept an input stream listen for events and manage the next server start, stop and output appropriately
utilsShared general development librariesGeneral small focussed development utilities similar to lodash and not blitz specific. Nothing should have any dependencies on anything else in the codebase aside from potentially other utilities.EDIT: Avoiding a utils library will mean less refactoring in the future as we rarely will need to extract out libs from utils which may happen if people start adding things to utils.
display
Render client facing awesomeness
Currently called
log. Blitz specific node cli display library. This might end up depending on ink or something like that at a later date. Should be able to be piped to. Can be swapped out for a view that writes JSON objects to a file for debugging for example. Can be set to remove all clear commands for nice display logging in a concurrent process or logging to a file.UPDATE: Possible Action Summary
apppackage - deep imports separating context - moverpcHandlerfrom server.