---
title: "TeqFW: Organizing the Top Level Code"
description: "I develop web applications using my own framework called Tequila Framework ([TeqFW](https://flancer32.com/what-is-teqfw-45da7071fdd4)). One of the distinguishing features of this f"
date: 2024-02-15
---

I develop web applications using my own framework called Tequila
Framework ([TeqFW](https://flancer32.com/what-is-teqfw-45da7071fdd4)).
One of the distinguishing features of this framework is its ability to
develop JS code that can be used unchanged both on the server and in the
browser (for example,
[constants](https://flancer32.com/code-types-in-teqfw-defaults-513f9cacd64c)
or [DTO](https://flancer32.com/dto-in-javascript-3274a3063919)).

Often, developers separate front-end and back-end code into different
npm packages simply because the development requirements for these two
options are different. Front-end primarily deals with interaction with
people (input-output of information), while back-end deals with other
applications (databases, message queues, etc.).

Of course, you can divide the front-end and back-end code at the
directory level within a single npm package:

``` text
src/
  back/
  front/
```

If an application’s code is shared between the front-end and
back-end, you can also add a third directory:

``` text
src/
  back/
  front/
  shared/
```

This directory structure with source files is used in the TeqFW
platform, with the slight difference that all directories and file names
within `./src` use CamelCase notation:

``` text
src/
  Back/
  Front/
  Shared/
    Dto/
      UserAuth/
```

This is because the TeqFW platform constructs its own name
for each ES6 module in the application, and these names are then used by
the Object Container for [dependency
injection](https://flancer32.com/ioc-in-vanilla-javascript-es6-1b2e701f331d).
For example, a file `./src/Shared/Dto/UserAuth/Permission.js` depending
on the npm package settings may have the name
`Vendor_App_Shared_Dto_UserAuth_Permission`. This approach allows the
Object Container to address any ES6 module within the teq-application.

Such division of the `./src` directory into three directories (`./Back`,
`./Front`, `./Shared`) is mandatory for all npm packages built according
to the TeqFW platform rules. This is because the platform provides web
access from the browser to the sources in the `./Front` and `./Shared`
directories. Therefore, these directories cannot contain ES6 modules
using any server resources (Node.js or npm packages not complying with
TeqFW rules). For example, the following code cannot be processed in the
browser:

``` js
import {existsSync, mkdirSync, rmSync} from 'node:fs';
```

Since there is no file system support from Node.js in the browser.

Examples of existing teq-plugins (npm packages):

- [flancer64/demo-webauthn-pubkey](https://github.com/flancer64/demo-webauthn-pubkey/tree/main/src)
- [flancer64/spa-remote-console](https://github.com/flancer64/spa-remote-console/tree/main/src)
- [teqfw/core](https://github.com/teqfw/core/tree/main/src)

## Summary

Any npm package that is a Tequila platform plugin places its sources in
directories within its root source directory in accordance with this
structure:

``` text
src/
  Back/
  Front/
  Shared/
```

The platform does not impose restrictions on the name of the
root directory (`./src` or `./source`). If there is no code from any
sphere (Front, Back, or Shared) in the npm package, the corresponding
directory is also absent.

I dedicated a separate post to these three directories because it’s not
just a recommendation, but a requirement. Within these three
directories, you can structure files however you like, but such division
of code by [usage
spheres](https://github.com/teqfw/core/blob/main/src/Shared/Enum/Sphere.mjs)
is mandatory for any plugin of the platform.