LOKI

An utility Node server to support frontends development

Table of Contents

1. About The Project
   • Built With
2. Getting Started
   • Prerequisites
   • Installation
3. Usage
4. Roadmap
5. License
6. Contact

About The Project

As a software house, during times, working on various frontends we often get our work stuck by the delay in receiving working backends. So we've built this server: LOKI is infact a temporary sobstitute of backend logic that permit to not stop the development of frontend.

We've built it with various utilities that we've used, and still use on a daily base, to serve frontends with the logic needed.

(back to top)

Built With

• 
• 

(back to top)

Getting Started

• Clone the repo and install requirments.

• npm install

• create .env file following the example.env file

For Dev environment

• npm run dev

Remember that you need to have Redis installed on your machine if you want to use the Redis feature.

(back to top)

FEATURE USAGE

---

• WEB SOCKET

The main purpose of this feature is to create a simple Web Socket connection, after configuring

  WEB_SOCKET_PORT = 'YOUR-WEB-SOCKET-PORT';

in the .env file you can create a Web Socket conntection that will send you a simple response. The response and the interval of response are editabile in config/default.json.

"websocket": {
        "responseMessage": "The response you want",
        "setInterval": false, // Interval selector
        "interval": 5000 // Interval time
    }

---

• LOCAL DATABASE

The main purpose of this feature is to have a mocked and fast editable database so we can fastly create and have ready to use endpoints.

.
├── build                   # Compiled files 
├── config                  # configuration files
├── src                     # Source files
├── static                  # Static files
├── dbDirectory             # Dynamic and Editable database for Local Database Feature <-
├── db.json                 # Plain json database for JSONServer Feature 
├── tsconfig.json          
├── LICENSE
└── README.md

Let's consider two different use cases:

• No backend's endpoints to interrogate

The Local Database feature is useful when there aren't any backend's endpoints to interrogate. Infact you could make the structure of the dbDirectory folder considering that every folder is a callable endpoint and the nesting of these folders compose the endpoint path, and the name of the dbDirectory is the domain of the endpoint.

Let's assume we would like to have a list of users that are working on a project, and assume that the endpoint will look like this one:

hastega.it/v1/projects/projectId/users

So we will build our dbDirectory in this way

.
├─hastega.it                     #dbDirectory name
│ └──v1           
│    └──projects           
│        └── projectId         
│                 └──users
│                     └─.json    #json file with response data
│
.

In order to have a usable response we have to create in our last sub-directory a .json (dot-json) file that will contain the desired response, and finally we could interrogate the following endpoint to fake the backend api.

Considering the following configuration in the .env file

  LOCAL_DATABASE_PORT = 4201;

the fake endpoint

localhost:4201/lcache/hastega.it/v1/projects/projectId/users

will give us the following response:

  "error": false,
  "cache": false,
  "message": "here/'s the fetched data",
  "data": (.json file)

This feature support also the query params but a more comprehensive example of their usage will be provide in the next use case.

• Backend's endpoints to interrogate

Let's consider that the previous example

hastega.it/v1/projects/projectId/users

will response us with the users list. If we will interrogate the endpoint

localhost:4201/lcache/hastega.it/v1/projects/projectId/users

all the dbDirectory structure will be created automatically and also the .json file following the endpoint original response. All the next interrogation will be served by the .json file and its edits, in order to have an easy accessible file to fast edit the response. If in the endpoint will be used query params the file created will have a name with the description of query params:

localhost:4201/lcache/hastega.it/v1/projects/AAA/users?start=1&limit=30

start_1_limit_30.json

and those files will be use in respose on relative endpoint request.

• Usage with https and custom headers

Loki is able to interrogate also custom headers needed endpoints. To correctly pass, without any problems, all the custom headers can be used the middleware setHeader() inside the desired route.

It accepts an array of string and has the role to parse correctly the headers inside the axios config request.

router.get("*", setHeader(["CUSTOM_AUTH_HEADER", "ANOTHER_NEEDED_HEADER"]), getLocalCache);

To semplify the usage you could use also the config/default.json

"localDatabase": {
        "customHeaders": ["CUSTOM_AUTH_HEADER", "ANOTHER_NEEDED_HEADER"],
        "rejectUnauthorized": false,
    }

As you can see there is also another config key rejectUnauthorized that can be set to true to use axios with https request if is needed

• JSON SERVER

writing docs for JSON server usage...

• REDIS SERVER

writing docs for REDIS server usage...

(back to top)

Roadmap

• Made a V1.0.0
• Continue writing docs
• Create classes to change response type
• Enanche handling of errors
• Add additional feature for PUT, POST, PATCH, DELETE methods

(back to top)

License

Distributed under the MIT License. See LICENSE.txt for more information.

(back to top)

Contact

HASTEGA - HASTEGA - connect@hastega.it

David Rainò - CTO - d.raino@hastega.it

Paolo Micheletti - MAINTAINER - p.micheletti@hastega.it

(back to top)