-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new CLI interface #10
Comments
This task has been partially completed in the
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 |
All concerns have been covered besides the third point (having If you believe that having more |
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 obtain the expanded schema without importing it to fauna #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?The text was updated successfully, but these errors were encountered: