{"id":22468671,"url":"https://github.com/jazzdotdev/sample-lighttouch-app","last_synced_at":"2026-02-07T07:01:56.512Z","repository":{"id":78131235,"uuid":"434727475","full_name":"jazzdotdev/sample-lighttouch-app","owner":"jazzdotdev","description":"Example Lighttouch app to demonstrate the uses of Lighttouch","archived":false,"fork":false,"pushed_at":"2021-12-03T20:38:39.000Z","size":84,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-07-30T05:24:29.121Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jazzdotdev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-12-03T20:38:18.000Z","updated_at":"2021-12-05T19:48:31.000Z","dependencies_parsed_at":"2023-02-27T18:30:18.742Z","dependency_job_id":null,"html_url":"https://github.com/jazzdotdev/sample-lighttouch-app","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jazzdotdev/sample-lighttouch-app","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jazzdotdev%2Fsample-lighttouch-app","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jazzdotdev%2Fsample-lighttouch-app/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jazzdotdev%2Fsample-lighttouch-app/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jazzdotdev%2Fsample-lighttouch-app/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jazzdotdev","download_url":"https://codeload.github.com/jazzdotdev/sample-lighttouch-app/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jazzdotdev%2Fsample-lighttouch-app/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29188304,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-07T05:07:31.176Z","status":"ssl_error","status_checked_at":"2026-02-07T05:06:15.227Z","response_time":63,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-06T11:18:55.467Z","updated_at":"2026-02-07T07:01:56.493Z","avatar_url":"https://github.com/jazzdotdev.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Getting started with Torchbear , Speakeasy and lighttouch\n\n## What is Torchbear ?\n\nTorchbear is web framework build in rust, to create a general-purpose programming environment. Torchbear is the kernel of lighttouch.\nYou will need to [install torchbear.](https://github.com/foundpatterns/torchbear#install)\n\n## What is Speakeasy ?\n\nSpeakeasy is a concise and complete software stack meant for general purpose problem solving.\n\n### Speakeasy syntax\n\nSpeakeasy works with the PUC-Rio interpreter, using  Lua for basic data structure and controls with additional functions fitting a broad range of use cases. And it is enhanced with  Torchbear's built-in modules , to which you can check a list of all of the included functions they have in the Torchbear's bindings documentation.\n\n## What is Lighttouch ?\n\nLighttouch is a framework that makes complex application development simpler. It does this through broad use of component-oriented design intended to offer programmers a well-researched alternative to starting with a blank canvas.\nYou will need to [install lighttouch.](https://github.com/foundpatterns/lighttouch#installation)\n\n\n## Building your first app in lighttouch\n\nalthough the core of lighttouch , Torchbear is build in rust , lighttouch apps are written in a simplier code syntax with lua.\nLighttouch is a framework that looks forwards to simplify the development of webpages, the front-end is handle as themes and the backend is handle as packages, both will be explain now.\n\n## Packages\n\nLighttouch backend is handle in the form of Packages; packages are Lighttouch's main unit of addon functionality. They leverage event-driven, rule-based programming.\n\nThis basically means that packages have actions, events, and rules. Following a simple event driven interface\n\n* **the rules** represent the url configuration , path name, valid atributes, and priority of check in comparison with other paths, is like an if conditional to control the path flow\n\n* **the actions** represent all the logic needed for the corresponding url, any requests, database actions, custom logic etc.\n\n* **the events**  represent the connection between the rules and the actions, these are defined in the events.txt of the package.\n\n### Events\n\nEvents are very simple. They get loaded into a global list by reading each package's `events.txt` file. They can be disabled in a `disabled_events.txt` file.\nThey control the connection between actions and rules. \n\n#### Structure of the event driven code\n\nIn order for the packages events to work they must be declared in the file `events.txt` that exist within the package, in here the name of each event of the package will be defined separated by a new line.\nLike in this example:\n\n```txt\nget_document_form\nrequest_document_html\nrequest_document_edit_form\nlist_documents_html\nlist_subdocuments_html\n```\n\n#### Packages Rules\n\nin a package the rules represent the configuration for the url paths of an action\nthe format to create on consists in declaring  first `priority` , `input_parameter` and `events_table` , at the beginning of the file.\n\n* `priority` is a number to implicitly declare the order of relevance of the url , it directly affects in which order the rules are check in order to resolve an url.\nThis allows for custom control of the behavior of the url, for example to set  urls that will respond to a different action if a parameter is send.\n\n* `input_parameter` name of the variable that is received as the request, should be set to ‘request’ unless a different name is necessary\n\n* `events_table`\narray of names of all the events  that correspond to this rule , this allows for a rule to execute more than one action when the url is called. Because when the rule is executed it will call all the actions that belong to the events declared in the events_table\n\n#### Request URL configuration\n\nto configure the url a series of rules are set with the use of logicals `and` and `or` to define the necessity of a rule or if it is optional. This makes the rules to have an if like syntax that if is true it will call the actions that correspond to the rule. The options that can be used to build an url are:\n\n* `request.method` , it can be any [http method](https://developer.mozilla.org/es/docs/Web/HTTP/Methods) type; like “GET”, “POST”, “PUT”, “DELETE” , etc.\n\n* `#request.path_segments` , number of path segments the url has, for example `/home/users` is 2 path segments\n\n* `request.path_segments[n]` : is a string, where n is any number minor or equal to the amount of path segments, with this it can be specified exactly which name will have each segment of the url\n\n* `request.headers[\"name\"]:match(\"value\")` , here name and value are any two strings that are checked in the header of the element when the request is made. Use example:\n\n```lua\nrequest.headers[\"accept\"]:match(\"html\")\n```\n\n* `models[request.path_segments[n]]`  , checks that the path segment at n (n being any number) belongs to a valid model name , models and their use will be explained below\n\n* `uuid.check(request.path_segments[n])`  , checks that the path segment at n (n being any number) is valid uuid string , uuid being the identifier used by contentdb which will be explained below.\n\n* `request.query.name`, `name` can be any string that belongs to a valid url param; this rule checks that among the send params there is one with the specified name.\n\nExample of a valid lighttouch rule:\n\n```lua\npriority = 2\ninput_parameter = \"request\"\nevents_table = [\"witness_html\"]\n\nrequest.method == \"GET\"\nand\n#request.path_segments == 0\nand\nrequest.query.witness\nand\nuuid.check(request.query.witness)\n```\n\n#### Package actions\n\nthe actions represent the logic that will be executed once the rules that corresponds to its event is called, at the beginning of the file the must always be the following parameters:\n\n* `event` , is an array that should hold one element with the name of the event that it belongs to.\n\n* `priority`, number to implicitly determined the priority level of the action, should be equal to the one in the rules\n\n* `input_parameters` is an array with the name of all the input parameters it will received , it should always have “request”.\n\nExample of the parameters of an action:\n\n```lua\nevent = [\"issues_request_received\"]\npriority = 1\ninput_parameters = [\"request\"]\n```\n\nafterwards all the code and logic to be performed in this view is executed there must be a return. In the case that this action is one of many that where called by the same rule it may not have a return, but one of the called actions must have a return.\n\nThe return is a table that contains a header and a body , ready to be a json response.\nIn case of being a normal html view it must be specified to `render` and html , which receives the route to the html in the current theme, and a table of variables to render in the html.\n\nExample of action return of a html:\n\n```lua\nresponse = {\n    headers = {\n        [\"content-type\"] = \"text/html\",\n    },\n    body = render(\"index.html\", {\n        iname = name,\n    })\n}\n\nreturn response\n```\n\n#### Code modularity\nIn order to import or execute code from different files in Lua the keyword `require` must be used. And the  path to the file is defined as they are packages dependencies, for example: we have the file `build.lua` in the following path  `packages/utils/build.lua` in order to add that code inside an actions file, it would need the following syntax: `require “packages.utils.build.”` to properly include the file.\n\n## Themes and Style engine\n\nLighttouch apps handle the frontend by the use themes and tera templates\n\n### Themes\n\nThe way lighttouch handles the frontend is by the use of a series of themes that are defined in the themes folder of the application.\nEach theme can be as complex as the whole layout of a page or as simple as singular html component that can be reused.\nThe themes are composed by a folder that contains the info.yaml file that contains the theme name and dependencies to other themes (parent themes), the html files that are treated as templates, css and any other folders or files that may be used to keep the code organized\n\nthemes are automatically registered by lighttouch in the application, the application launches using a singular theme. Still to have access to the components of other themes these themes must be declared a parents of the main theme.\n\n#### Tera\n\nLighttouch uses The template language [Tera](https://tera.netlify.com/docs/templates/), to control the designing of the frontend, Tera allows to show variables , use filters for variable , create render conditionals, use of for methods to iterate over data.\n\nTo include html elements and to allow that a template can extend form another template even if the template doesn't exist in the current theme and it belongs to a parent theme.\n\nwith this in consideration the front-end layout can be very organized by spliting each element in different template files and even split more complex elements into a separated theme to improve the re usability of the html.\n\nThe Tera template also allows to treat html as objects that contain blocks of content and that can extend from other html elements\n\n#### Calling HTML\n\nWhen and html element is call to be render from the back-end or is included in the template as such:  `{% include \"component.html\" %}` , lighttouch will automatically look for the template in the  current theme and if it is not found it would search for it in the parent themes iterating over them in the same order that they were declared.\nGraphic example of the search:\n\n* looking for the component `el.html` example:\n|-- Current Theme :x:\n| ---- Parent theme 1 :x:\n| ------ Parent theme 2  :heavy_check_mark: `el.html` **found**\n| -------- Parent theme 3  :heavy_exclamation_mark: **Never Reached**\n\nit is important to know that the order of declaration of the parent theme matters when the app is call to include an html element , because if in different themes a file location and name repeats, lighttouch will use the first one it founds\n\n##### Including elements in the html\n\nUsing the keyword include:\n\n```tera\n  {% include \"chunks/footer.html\" %}\n```\n\nyou can include in a templates all the contents of a different template to organize the code of the layouts more easily\nalso the include is not limited to html filesyou can include the contents of any file that you want as longs as the contents are readeable by html\nfor example you can include a css file to be added inside style tags in the header\n\n```html\n    \u003cstyle type=\"text/css\"\u003e\n      {% include \"css/styles.css\" %}\n    \u003c/style\u003e\n```\n\n##### Tera template Blocks\n\nwith the use of the blocks the re usability of html templates is very easy to achieve, in the following example it can be seen the base.html layout that other templates can extend from\n\n```html\n    \u003c!DOCTYPE html\u003e\n    \u003chtml\u003e\n        \u003c!-- grand grand parent --\u003e\n        \u003chead\u003e\n            {% block head %}\n            {% endblock head %}\n            \u003ctitle\u003e\n                {% block title %}\n                {% endblock title %}\n            \u003c/title\u003e\n        \u003c/head\u003e\n        \u003cbody\u003e\n            \u003cdiv id=\"header\"\u003e\n                {% block header %}\n                    \u003c!-- Header --\u003e\n                {% endblock header %}\n            \u003c/div\u003e\n            \u003cdiv id=\"content\"\u003e\n                {% block content %}\n                    \u003c!-- Content of any page --\u003e\n                {% endblock content %}\n            \u003c/div\u003e\n            \u003cdiv id=\"footer\"\u003e\n                {% block footer %}\n                    \u003c!-- footer --\u003e\n                {% endblock footer %}\n            \u003c/div\u003e\n        \u003c/body\u003e  \n    \u003c/html\u003e\n```\n\nand then for a template to use would be in the following way:\n\n```html\n    {% extends \"layouts/base.html\" %}\n    {% block content %}  \n        {{ super() }}\n        \u003cdiv site_content id=\"page_content\"\u003e\n            Site Content\n\n            Lorem Incididunt sunt excepteur esse in laboris.\n            Laboris eiusmod mollit quis id nulla eu occaecat d\n            olor Lorem do dolore aliqua exercitation anim.\n            Est anim incididunt reprehenderit elit ex incididu\n            nt ipsum enim veniam sunt anim irure.\n            Irure do minim elit nulla sint.\n        \u003c/div\u003e\n    {% endblock content %}\n```\nas you can see in this example there is the call to super inside the content block , this is call for the template to add any content that is in the content block of the parent template.\n\n##### Extending html\n\nthe extension feature is similar to what in Object Oriented programming languages is known as inheritance, this allows for the same layout to be used and only change the content within the layout. \nThe declaration for the extension must be done at the beginning of the file, and the syntax to extend from a file in the same theme it must be declared specifying the path to the file in the theme:\n\n```tera\n{% extends \"chunks/modal.html\" %}\n```\n\nalso If you wish to extend from a template that exists in the parent theme of your current theme that is also possible by adding `^/` at the beginning of the path. Ligttouch witll perform a search to find the html for Tera to extend, this search is executed the same way it is done for the **include html** will perform a search for a template that is in the described location in one of the parent themes.\n\n```tera\n{% extends \"^/chunks/modal.html\" %}\n```\n\n\n###### _style folder and files\n\nto improve readability of an html with styles the styles are written in different css classes and then added to the html, still  in some cases we can end up with an html element that contains too many classes and is hard to read.\n\nIn order to improve html readability lighttouch uses the _style syntax which consist in using an unique name for the class group that wants to be used, a _style folder , a folder for the template with the template name template.html as the folder name, and the use of .txt files with the element tag and unique name, for example div main_page.txt , yes with the empty space, this .txt will contain the name of all the classes of the respective element in the html,  the classes can be separated by enter or spaces, lighttouch uses the _style syntax by matching the file exact name with an element in the html it that matches the name of the folder the file is contained at.\nthe use of this causes to have a very minimalist html that's easy to read, and all the css classes that have been declared in the files will will be automatically added to the html once it is rendered:\n\n``` html\n    \u003cdiv centered_container \u003e\n        \u003ca blue_button href=\"/?witness={{ id }}\"\u003e\n            Witness\n        \u003c/a\u003e\n        \u003ca blue_button href=\"/{{model}}/\"\u003e\n            Go to list\n        \u003c/a\u003e\n        \u003ca yellow_button href=\"/{{model}}/{{id}}/edit\"\u003e\n            Edit\n        \u003c/a\u003e\n    \u003c/div\u003e\n```\n\nin this example there are 3 _style identifiers `div centered_container`, `a blue_button`, `a yellow_button` each of this identifiers contains a file inside the template folder with all the css classes of the element, for this example in the previous html these are the files used:\n\n* div centered_container.txt\n\n    ```txt\n    text-center\n    px-4\n    py-4\n    ```\n\n* a blue_button.txt\n\n    ```txt\n    bg-blue-500\n    rounded-full\n    py-2\n    px-4\n    hover:bg-blue-600\n    hover:text-white\n    ```\n\n* a yellow_button.txt\n\n    ```txt\n    bg-yellow-500\n    rounded-full\n    py-2\n    px-4\n    hover:bg-yellow-600\n    hover:text-white\n    ```\n\nthis improves the readability of the html and in order to keep a better organization of the styles.\n\nThe whole project layout would look like the following\n\n-root project folder\n    -themes\n        -main-theme\n            index.html\n            -_style\n                -index.html\n                    div container.txt\n\n## Settings file lighttouch.scl\n\nthe `lighttouch.scl` file is configuration file where settings are defined using scl ( [a simpl configuration language](https://github.com/foundpatterns/scl) ) , some are obligatory like: `theme` , `log_level` , `sitename`.\n\n```scl\n    theme = \"main theme name\",\n    log_level = \"trace\",  # log level for development\n    sitename = \"name of the site\",\n```\n\nany other setting value is completely optional and depends what you want to do, in here you can defined any secret key or api codes that your app uses to avoid having them in any place that could exposed to the user.\n\nAlso a value can be set to include another .scl file to load the information as fields in that setting variable.\n\nExample of a  `lighttouch.scl` file:\n\n```scl\n    settings = {\n        theme = \"found-patterns-theme\",\n        log_level = \"trace\",\n        sitename = \"Found Patterns Studio\",\n        slideshow = \"c800a360-d198-4a87-877e-b353f7dd0a9d\",\n        chat = include \"chat.scl\",\n    }\n```\n\nchat.scl contents:\n\n```scl\n    header_title = \"My Chat\"\n\n    header_image = \"https://avatars0.githubusercontent.com/u/43634206?s=200\u0026v=4\"\n```\n\nthe values set in settings can be accessed in the packages code with the syntax `settings.name_of_the_property` .  Making setting have a behavior of a key word defined lua table , also known as a dictionary in other programming languages.\n\n## Machu Pichu dependency manager\n\nMachu pichu is dependency manager used by torchbear in order to have better control of the dependencies in a project.\nThe configuration is established in the `manifest.scl` file which is at the root of the project.\n\nThe file has the imports dict where the name of the packages is define and where they will be downloaded.\n\nAlso bellow for each package an url must be defined to where the project will be fetch, it should be an url to a Git repository where the package is stored.\n\nExample of a `manifest.scl` file\n\n```scl\n    imports = {\n        send-file-package = \"packages/send-file-package\",\n        lighttouch-html-interface = \"packages/lighttouch-html-interface\",\n        lighttouch-json-interface = \"packages/lighttouch-json-interface\",\n    }\n\n\n    send-file-package = {\n        url = \"https://github.com/lighttouch-packages/send-file.git\",\n    }\n\n    lighttouch-html-interface = {\n        url = \"https://github.com/lighttouch-packages/html-interface.git\",\n    }\n\n    lighttouch-json-interface = {\n        url = \"https://github.com/lighttouch-packages/json-interface.git\",\n    }\n```\n\nonce the file is ready run the command `mp unpack` and machu pichu will automatically donwload the packages and place them in their corresponding folder.\nTo read further about the **machu pichu** package manager you can check the repository [machu pichu](https://github.com/foundpatterns/machu-picchu)\n\nNote: is important to know that the dependencies declared in the manifest.scl are treated as such and are assumed that they wont go through changes or will be edited by the use in anyway.\nThats why running the command `mp unpack` will override any changes that were done to the files in that where added this way with machu pichu.\nSo if you are working in development with the project and also developing the dependencies is recommended that you manually add the dependencies where you need it so you can edit it without the risk of your changes being overwritten.\n\n## ContentDB database and models\n\nTorchbear comes with the database ContentDB which is a document store database, it is NoSQL, these means all the entries are files that are saved within the project folder and use uuid to identify each entry.\n\nContentDB has all the functionalities needed from file searching to filtering, and even declaring refences to other documents.\n\n### Models\n\nAlso lighttouch allows the use of models, inside the packages that are a definition of an object in a .scl file and they are stored in the folder `models` of any package.\nTo use the models is need to implement the packages of `html-interface` and `json-interface` allowing to create documents that have the fields declared in the models .scl file.\nAn example of models file is the following `message.scl`\n\n```scl\n    description=\"Message\"\n    fields={\n        title={\n            required=true,\n            type=\"string\",\n        },\n    }\n```\n\n### Built in packages for models handling\n\nin order to use a packages models there must be implemented to light touch packages\n\n* [The html interface](https://github.com/lighttouch-packages/html-interface)  which is a ready to be used html UI for the CRUD of a model, this package depends on the `json-interface` package\n\n* [the json interface](https://github.com/lighttouch-packages/json-interface) , the json interface provides a ready to be used api to create and request for documents.\n\nOnce the model file is created it is ready to used, to interact with ui it is show in the url path with the same name of the model in the case of the example above with the `message` model the url  path in the app is `/message`.\n\n### Built in themes\n\n* **base-theme**: even though the use of base theme is totally optional and you can develop your own custom views for the handling the models views, [base-theme](https://github.com/lighttouch-themes/base-theme)  already comes with a ready to be used interface to the handling of models , all you need to do is the correct setup (explained in the following segment) .\n\n### Setting up  html interface in your project main theme\n\nhtml-interface package UI is already implemented in the base-theme of lighttouch to use you only need to create a folder called chunks in your project and in there create the following the corresponding files to handle the models and include the views from base-theme, (Note: your theme must have base theme as parent), the files to be created and the view they need to add are the following:\n\n* `show_document.html` for the view of a document , to add base-theme view add into the file the following:\n\n    ```tera\n    {% include \"chunks/show_document/show_document_content.html\" %}\n    ```\n\n* `model_form.html` for the creation and update of a document, to add base-theme view add into the file the following:\n\n    ```tera\n    {% include \"chunks/model_form/model_form_content.html\" %}\n    ```\n\n* `list_documents.html` for listing all the corresponding documents, to add base-theme view add into the file the following:\n\n    ```tera\n    {% include \"chunks/list_document/list_documents_content.html\" %}\n    ```\n\nand that's it. all that is left is to create is model and to access its interface go to the url of the same name of the model file, example:\n\nthe model file `project.scl` will respond to the url `www.my_root_url.lorem/project`  from the root URL , (`localhost:3000/project` in development).\n\n#### referencing a document\n\nhtml-interface supports for a document model to reference another, to define it in the model it just needs a field with the same name as the model file to be referenced this field should be type uuid.\n\nExample:\n`comment` model references `post` model to this a field must be added in the comment.scl model file\n\n```scl\n    description = \"Comment\"\n        fields = {\n        title = {\n            type = \"string\"\n        },\n        body = {\n            type = \"string\"\n        },\n        post = {\n            type = \"uuid\"\n        }\n    }\n```\n\n### Custom use of contentdb and the models\n\nLighttouch has build in packages and themes that use contentdb and models, but also this functionalities can be used to build more custom behavior with all the function that contentdb possesses.\n\nConcepts:\nStores: Contentdb documents are stored in the “content” folder of the project, and inside the “content” folder are the “store” folders, these are folders that have an uuid for name, inside the store folder are saved all the documents of contentdb.\nBy default each new app generates a new store identifier and works with one store folder altough you can work with multiple store folders.\n\nContentDB\nAmong the more basic functionalities of contentdb one can name:\n\n* `contentdb.walk_documents (_store_id, fn)` receives the uuid of the document store if nil it will walk all the stores and a callback function that will be called with each document in the store.\nThe function must have the in the following order:\nuuid of the file\nfields of the file\nbody of the file (is an abstraction of the field body in the file)\nstore same store as the search was call if a store was given\n\n    ```lua\n    function (file_uuid, fields, body, store)\n    end\n    ```\n\nInside this function it can declared all the logic and conditionals to work the documents in the store from search to filtering etc…\n\n*`contentdb.read_document(document_uuid)` receives an uuid and returns the document it belongs to.\n\n*`contentdb.write_file (store_id, file_uuid, fields, body_param)` writes a new document with the given attributes it will be saved in the stored defined with the uuid given , it will save with all the fields this being a simple key table with only values , fields can not have subtables, and body param is the content of the body in the document\n\n*Note ContentDB currently doesnt have a build in delete document although lighttouch has it, consider doing a PR with those changes\n\nModel\nthe model interface is easy to use and has two main uses in actions and in rules:\n\n* Action use: inside the code exists the global variable `models` that is key table that contains all of the registered models in the app so callling `models[‘model-name’]` will give the definition of the model from the model.scl (fields, description, etc...)\n\n* Rule use: using `models[request.path_segments[1]]` will check if the first path segment belongs to a model name, using this logic you can build url that check if they have a valid model name.\n\n## API request\n\nexecuting api request to any rest or authenticated api service is easy with the use of the Lighttouch HTTP Interface\n\nligttouch uses torchbear http module to execute HTTP methods to a server\nthe syntax to execute them in the back-end is the following\n\n```lua\n    local response = send_request({\n        uri = 'https://jsonplaceholder.typicode.com/todos/1',\n        method=\"get\",\n        headers={\n            [\"content-type\"]=\"application/json\",\n        },\n    })\n```\n\nthis simple way one can execute all types of requests to a server","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjazzdotdev%2Fsample-lighttouch-app","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjazzdotdev%2Fsample-lighttouch-app","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjazzdotdev%2Fsample-lighttouch-app/lists"}