zvictor / brainyduck

🐥 A micro "no-backend" framework 🤯 Quickly build powerful BaaS using only your graphql schemas
https://duck.brainy.sh
GNU Affero General Public License v3.0
68 stars 3 forks source link

new CLI interface #10

Closed zvictor closed 2 years ago

zvictor commented 3 years ago

I have the impression that the cli commands need to be better designed.

Ideally, a developer should not need to know how things work internally (pull/push/define). Instead, they should intuitively know what commands to call for their most basic operations and that intuition should come from standard procedures of other workflows, such as build and deploy.

In some ways the dev command tries to do that but it's just not good enough.

Proposal

--- first level commands: ---
  build [directory]                                        [NEW]
  deploy [directory]                                       [NEW]
  dev [directory]                                          [???]
  reset                                                    [KEEP, but add possibility to choose what parts
                                                                  should be reset (optional)]

--- second level commands: ---
  define-functions [pattern]                               [KEEP]
  define-indexes [pattern]                                 [KEEP]
  define-roles [pattern]                                   [KEEP]
  pull-schema [output]                                     [KEEP]
  push-schema [pattern]                                    [KEEP]
  generate-types [pattern] [output]                        [REMOVE - it doesn't seem to be useful after all]
  build-sdk [schema-pattern] [documents-pattern] [output]  [KEEP]

--- others: ---
  help [command]                                           [FIX - it has never worked]
  1. The build cmd would only run local operations (for a start, it would only call build-sdk) and provide the resources needed in the development workflow. 1.1. No side-effects to the database allowed; 1.2. Therefore, no need to have a secret key and thus it could be used in any regular build script (e.g. npm prepare)
  2. The deploy cmd would run all the operations that result in changes in the database, currently define-* and push-schema.
  3. Both build and deploy would have the option to flag with --watch to become more developer-friendly.
  4. The generate-types is cool, but what use case does it cover? The sdk is already covering all practical use cases I can think of. Only in a case of extreme modularization and code reuse is that I could envision some use for this. It's time to kill it.

Challenges

Questions

zvictor commented 2 years ago

This task has been partially completed in the 0.0.51 release.

This is how it looks right now:

build [schemas-pattern] [documents-pattern] [output]
dev [directory]                                     
deploy [types]                                      
deploy-schemas [pattern]                            
deploy-functions [pattern]                          
deploy-indexes [pattern]                            
deploy-roles [pattern]                              
pull-schema [output]                                
reset [types]                                       
help [command]                                      

Once I finish the improvements in the build command I plan to revisit this task and possibly close it, moving remaining tasks to a new issue.

zvictor commented 2 years ago

All concerns have been covered besides the third point (having --watch in the build and more places) in the latest release (v0.0.52).

If you believe that having more --watch options is important to you, feel free to open a new issue describing your needs.