Skip to content

Architecture direction (discussion) #798

@ryardley

Description

@ryardley

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

  • Create app package - deep imports separating context - move rpcHandler from server.

Metadata

Metadata

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions