# The Cro Development Tools Cro includes tools to help developers work more efficiently. Currently the tools are available through a command line interface; in the future a web interface will be added also. It is entirely possible to use Cro without these tools. They aim to provide some reasonable defaults, but will not be suitable for every project. ## Stubbing Services A new service can be stubbed using the `cro stub` command. The general usage is: cro stub ['links-and-options'] Where * `service-type` is the type of service to create * `service-id` is the ID of the service (to be used with other `cro` commands; this will also be used as the service's default descriptive `name` in `.cro.yml`) * `path` is the location to create the service * `links-and-options` specifies links to other services that should be added to the stub, together with options specific to the service type If the links and options are not specified, then they will be requested interactively. To provide the options, place them in quotes using Raku colonpair-like syntax, where `:foo` enables an option, `:!foo` disables an option, and `:foo` is the option `foo` with the value `bar`. For example: cro stub http foo services/foo ':!secure :websocket' cro stub http bar services/bar ':!secure :websocket' The stubbed services take port and certificate configuration from environment variables, and when there are relations between services their addresses are also injected using environment variables. This is convenient when setting up container deployment. Links cause the stubbed service to include code that creates some kind of "client" that can communicate with another endpoint. These go in with the options, having the form `:link`. The `service-id` is the `id` field from the target `.cro.yml`, and `endpoint-id` is the `id` field of an entry in the `endpoints` list of that `.cro.yml` file. cro stub http foo services/foo ':link' ### HTTP Services The `http` service type stubs in a HTTP service, using `Cro::HTTP::Router` and served by `Cro::HTTP::Server`. By default, it stubs an HTTPS service that will accept HTTP/1.0, HTTP/1.1 and HTTP/2.0 requests. cro stub http flashcard-backend backend/flashcards The following options may be supplied: * `:secure`: generates an HTTPS service instead of an HTTP one (`:!secure` is the default); implies `:http1 :http2` by default, using ALPN to negotiate whether to use HTTP/2 * `:!http2`: generates a service without HTTP 2 support * `:!http1`: generates a service without HTTP 1 support * `:websocket`: adds a dependency to the `Cro::WebSocket` module and adds a stub web socket example ## Running Services cro run [ ...] The `cro run` command is used to run services. It automatically sets up file watching and restarts services when there are source changes to the services (with a debounce to handle a stampede of changes, for example due to fetching latest changes of a running service from version control or saving many files in an editor). To run all services (identified by searching for `.cro.yml` files in the current working directory and its subdirectories), use: cro run To run a specific service, write its `service-id` (which must appear as the `id` field in a `.cro.yml` file in the current working directory or one of its subdirectories): cro run flashcard-backend It's also possible to list multiple services: cro run flashcard-backend users frontend The output of the services will be displayed, prefixed with the `service-name`. Sending SIGINT (hitting Ctrl+C) will kill all of the services. Ports are automatically allocated and the environment variable set per the `.cro.yml` for the service. The host environment variable will be set to `localhost` by default, however can be specified with the `--host` option: cro --host=dev-vm run ## Tracing Services cro trace The `cro trace` command is much like `cro run`, except it turns on pipeline debugging in the services. This makes it possible to see the traffic that each service is receiving and sending, and how it is being interpreted and affected by middleware. The amount of output may be slightly overwhelming, so it can be filtered by the message type name. This is done by checking if any name component is, case-insensitively, equal to the filter. Inclusive filters are expressed as `:name`, and exclusive filters as `:!name`. For example, to exclude all of the TCP message messages from the trace, do: cro trace :!tcp To see only HTTP messages, do: cro trace :http To restrict that further to just requests, do: cro trace :http :request Anything not starting with a `:` is taken as a `service-name`. The order is unimportant, so these are equivalent: cro trace :http flashcard-backend cro trace flashcard-backend :http The `--host` option may be specified as for `cro run`: cro --host=dev-vm trace ## Serving Static Content cro serve [] Sometimes it is useful to set up a HTTP server to serve some static content. Serve the current directory on port 8080 of localhost with: cro serve 8080 Or specify a directory to serve: cro serve 8080 static_content/ An IP address to bind to may also be provided before the port number: cro serve 192.168.0.1:8080 static_content/ ## Working with service links The `cro link` subcommand is used to manage the `links` section of `.cro.yml` files. These describe how one Cro service uses another, resulting in the injection of environment variables specifying the host and port where the service can be found. In production, these would be set by a container engine such as Kubernetes, by some kind of configuration management system, or even just hardcoded into a wrapper script. To add a service link, use `add`: cro link add [] Where `from-service-id` is the `id` of the `.cro.yml` that whose links should be modified, `to-service-id` is the `id` of the `.cro.yml` of the service that will be consumed, and `to-endpoint-id` is the `id` of an endpoint in that service's `.cro.yml`. This command will, provided there is a link template matching the protocol of the service linked to, produce some stub code that you can paste into your service code at the appropriate place (Cro is not so crazy as to think it can edit your code under you!) If `to-endpoint-id` is not specified, and the `to-service-id` service has only one endpoint, then that one will be used by default. Otherwise, the ambiguity will be whined about. To regenerate the code for an existing link, do: cro link code [] To remove a link, use: cro link rm [] Which simply removes the entry from the `links` section of the `.cro.yml` that is identified by `from-service-id`.