Closed zvictor closed 2 years ago
This task has been partially completed in the 0.0.51
release.
define-*
commands plus push-schema
became deploy-*
deploy
command was added to orchestrate the call of every single deploy-*
ones, as a top command.build-sdk
has been renamed to build
. More still has to be done in regards to #1.generate-types
has been removed.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.
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.
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
anddeploy
.In some ways the
dev
command tries to do that but it's just not good enough.Proposal
build
cmd would only run local operations (for a start, it would only callbuild-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
)deploy
cmd would run all the operations that result in changes in the database, currentlydefine-*
andpush-schema
.build
anddeploy
would have the option to flag with--watch
to become more developer-friendly.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
build
command without side-effects to the database until https://github.com/zvictor/faugra/issues/1 is fixed. Until then, a fauna secret needs to be provided in order to generate the sdk.Questions
How can we make a clear distinction between first and second levels? I thought on grouping "second level commands" as subcommands (e.g. wrapping them all under
run
as innpx faugra run define-functions [pattern]
), but it doesn't look sexy enough.What should be done with the
dev
cmd? If bothbuild
anddeploy
have the--watch
option, what is the point ofdev
other than just putting both cmds together?