Create a target
A target defines how a product is exposed to the end user. It's a combination of platform and runtime.
Intro
A target is a set of classes and functions that expose a product (and therefore apps and use cases).
Before creating your own, check the targets reference to see if libmodulor
does not already provide it.
If you don't find your "bonheur" there, check out the examples below.
Although the provided targets are pretty generic (espcially the GUI
ones), feel free to explore their code in order to take inspiration from them.
It will allow you to understand how a product (and therefore apps and use cases) is instrumented.
CLI
A CLI target exposes a product so it can be used in a Terminal Emulator :
node index.js SignIn --email dexter@caramail.com
> Password : *******************
node index.js --help
node index.js --version
To create a CLI target, you need to implement the CLIManager
interface.
See node-core-cli as an example.
Important aspects to take into account (non-exhaustive list) :
- the command must be mounted at
uc.def.ext.cmd.mountAt ?? ucMountingPoint(uc)
- the command must execute
uc.def.lifecycle.client.main
according to thepolicy
- each input field must be mapped to a dedicated flag (e.g.
email => --email
) - handle the fields type when parsing the command (e.g.
number
,boolean
) - handle the field cardinality when parsing the command (e.g.
--tag Work --tag Boss
=>tag: ['Work', 'Boss']
) - handle the field "sensitivity" (see
isSensitive()
) by prompting for them instead of providing a flag to avoid leaking secrets in your history - expose common commands usually provided by a CLI program (e.g.
--help
,--version
, etc.) (these are usually not use cases) - build the help based on
uc.def.io
andWordingManager
- build the version based on your
package.json
- handle unknown commands by whether failing or displaying the help section
Here is a great list of solutions to build your own.
Server
A server target exposes a product so it can be called as a REST-like API :
curl \
-X POST \
-H "Content-Type: application/json" \
-H "X-API-Key: PublicApiKeyToBeChangedWhenDeploying" \
-d '{"email":"dexter@caramail.com","password":"thedarkpassenger305"}' \
http://localhost:7443/api/v1/SignIn
To create a server target, you need to implement the ServerManager
interface.
See node-express-server as an example.
Important aspects to take into account (non-exhaustive list) :
- the use case must be mounted at the
path
andpathAliases
provided by ucHTTPContract - the request handler must execute
uc.def.lifecycle.server.main
according to thepolicy
- the request handler must handle the
uc.def.io.o.sideEffects
- the request handler must return a
204
when there is nouc.def.io.o
- the request handler must handle the output transformation based on
ext.http.transform
- the appropriate middleware must be mounted to handle
uc.def.sec.publicApiKeyCheckType
- the appropriate middleware must be mounted to handle
uc.def.sec.authType
- cookies must be implemented to handle authentication
This is the implementation used in the apps automated tests. Check Test an app for more details.
GUI
A GUI target exposes a product as a user interface. See react-native-pure and react-web-pure as examples.
Typically, it provides "components" to :
- access a use case (e.g. a button or a link)
- interact with a use case (e.g. a button or a form)
Important aspects to take into account (non-exhaustive list) :
- the "access" component must handle the
uc.def.lifecycle.client.policy
- the "interact" component must display a form when the use case needs input filling
- the form fields must handle the input fields type, cardinality, etc.
- the "interact" component must display a control (e.g. a button) when the use case does not need input filling
- the button submitting a use case must handle the different statuses (
idle
,changing
,submitting
, etc.) - the wording must rely on
WordingManager
MCP Server
A MCP server target exposes a product as a MCP server. See node-mcp-server as an example.
Like a regular server, it exposes the use cases as MCP tools.
Others
The list above corresponds to the current state of human interfaces in Software. We can bet that new ones will arrive pretty soon. So the only limit is your imagination.
We're looking forward to working on AR/VR targets, Voice targets, Haptic targets, etc...