Tools for stack generation from templates and an api.
If you are ever confused about the commands, run nostack --help
.
If you want to know the parameters for any command, just run the command with '--help'.
But relax--if you are missing one you will be told. :)
The four standard steps for creating an app are the following:
- create a no-stack-app
nostack newapp -a <appName>
- create a new moderator and stack
nostack quickstarter -e <moderatorEmail> -w <password> -l <licenceId> -u <moderatorName> -s <stackName>
- spin up stack (call from the same directory as step 1):
nostack spinstack -u <moderatorName> -t dir/to/template/<templateFile> -s <stackName> -e <emailFor Moderator>
- generate code (call from the same directory as step 1):
nostack makecode -a <appName>
There is also a recommended shortcut command to get started:
nostack quickStarter -e ${email} -w ${password} -l ${license} -u ${moderator} -s ${stackName} -a${appName} -t ${appTemplate}
That will give you everything you need for your first app. Note that you will need to provide a license and a template. You can apply for a license at www.nostack.net. Documentation for creating templates is in the pipeline right now.
The test directory contains a few sample templates in /test/testData/.
It is useful to understand two things:
- NoStack stores types of data and their instances. Instances contain an
autogenerated id and a value. For instance, you might have in your application a type
restaurant
and it may have 300 instances, each of which has a name and an autogenerated id. - types are declared and used in "sources". A source is fundamentally a hierarchy of types. For instance, a source might contain at its root restaurant, with cuisine and rating as children.
Also, every source is assigned to a given user class, and a generated server has auth built in.
More details are given in the "Creating Templates" section below.
The templates are text files which contain series of declarations using the NoStack Flow Specification language (NFS).
An template file treats each line as a different declaration. Any line that does not begin with a reserved command word is ignored.
The commands are expected to change soon, but currently these are available:
- newUserClass <class>
- newSource <source> <class>
- newType <type> <source> <parent> [<data type> ] [<association type>]
- newSelection <source> <selected type>
- newConstraint <constraint value> <source> <type> ID|Value
- connectSources <childSource> <parentSource> <connecting type>
newUserClass A user class is a type of user. A source is an interface unit that is permitted to a user class. A source contains a hierarchy of types, starting from some root type. A source also can include actions that can be performed with data.
Types are loosely data entities and/or properties. A type
declaration contains the name of the type and a parent type.
[Important note: a user class declaration also results in a
type being created for the user class. In other words, each
user is an instance of their class or classes.] By default,
a type is a string. But optionally a type can be set.
Currently, only booleans and strings are supported, but that
will change soon.
A type declaration can also optionally contain a association type. Association types can specify whether a child is required for the parent (always exists) or not, and the number of children for a type. The default is not required and multiple. Currently, the only declarable association type is singleRequired, which is useful for declaring properties.
A selection means a type in a source that gets returned to the front end. It is analagous to a field that shows up in the "SELECT" clause of an SQL query.
A constraint limits the data returned. A source and the type to be constrained must be specified. Also, a constraint value is required. That is normally a variable name which can then be set in front end code. There are two types of costraints: ID and Value. Constraining by id returns the instance having the id specified. Constraining by value will return any instances that satisfy the condition provided. There are a few reserved words for constraints. The main one is currentUser, which is the id for the current user. If you set the constraint value to currentUser, then the code generated will set it as such. Otherwise, it's just a string used for a variable name that gets set in the code. [Note: the name that you give for the constraint value for an ID contraint is purely for code readability.]
Two sources can be "connected", which will affect frontend code generated. A connecting type must be shared between the sources. Usually, a connecting type will be a constrained type for the child source. When a source A is connected to parent source B, a component generated for B will contain A as a subcomponent with an instance for every instance of the connecting type.
$ npm install -g @nostack/no-stack-cli
$ nostack COMMAND
running command...
$ nostack (-v|--version|version)
@nostack/no-stack-cli/0.0.0-semantically-released linux-x64 node-v10.16.3
$ nostack --help [COMMAND]
USAGE
$ nostack COMMAND
...
nostack callapi
nostack createstack
nostack help [COMMAND]
nostack makecode
nostack newapp
nostack quickstarter
nostack spinstack
Make a call to the nostack api. Takes care of auth for the user. You need to specify a file with the graphql query and another one with a json of the variables, if anyare used.
USAGE
$ nostack callapi
OPTIONS
-h, --help show CLI help
-q, --queryFile=queryFile graphql file containing a single query
-s, --stack=stack stack
-u, --user=user moderator for stack
-v, --variablesFile=variablesFile json file with query variables
EXAMPLE
$ nostack callapi -u irnold1y -s TestStack1y -q ~/projects/no-stack-queries/queries/sourceData1y.graphql -v
~/projects/no-stack-queries/variables/sourceData1y.json
See code: src/commands/callapi.ts
Creates a new moderator and stack. Also logs in the moderator locally.
USAGE
$ nostack createstack
OPTIONS
-e, --email=email moderator email
-f, --force
-h, --help show CLI help
-l, --licenseId=licenseId license id for the organization of the user
-s, --stack=stack stack
-u, --user=user moderator to create
-w, --password=password moderator password
EXAMPLE
$ nostack createStack -u franky -s tempstack, -e [email protected] -w franky12$
See code: src/commands/createstack.ts
display help for nostack
USAGE
$ nostack help [COMMAND]
ARGUMENTS
COMMAND command to show help for
OPTIONS
--all see all commands in CLI
See code: @oclif/plugin-help
generates a starter app from a json provided by NoStack
USAGE
$ nostack makecode
OPTIONS
-a, --appName=appName application name
-f, --force
-h, --help show CLI help
See code: src/commands/makecode.ts
create an empty new no-stack app. Effectively combines create-react-app with apollo stuff and the no stack package.
USAGE
$ nostack newapp
OPTIONS
-a, --appName=appName name of application
-h, --help show CLI help
See code: src/commands/newapp.ts
Creates a new moderator and stack. Also logs in the moderator locally.
USAGE
$ nostack quickstarter
OPTIONS
-a, --appName=appName name of application
-e, --email=email moderator email
-f, --force
-h, --help show CLI help
-l, --licenseId=licenseId license id for the organization of the user
-s, --stack=stack stack
-t, --template=template template from which to spin up a stack
-u, --user=user moderator to create
-w, --password=password moderator password
EXAMPLE
$ nostack quickstarter -u franky -s tempstack, -e [email protected] -w franky12$
See code: src/commands/quickstarter.ts
Spins up a fully functional backend from a provided template. The same template can then be used to generate front end code using the command 'makeCode'.
USAGE
$ nostack spinstack
OPTIONS
-a, --appName=appName application name
-e, --email=email email to be used by sample users
-h, --help show CLI help
-s, --stack=stack stack
-t, --template=template template from which to spin up a stack
-u, --user=user moderator for stack
-x, --addedSuffix=addedSuffix added suffix for sample instances generated
See code: src/commands/spinstack.ts