Skip to main content
Deno 2 is finally here 🎉️
Learn more

faster_react

It is a complete framework, with automatic compilation of components for the client side, Server Side Rendering, Hydration and interactive client-side components. Fully compatible with Deno Deploy. It has folders in its structure for automatic inclusion of pages, routes, components and static files. It has automatic reload client side and compilation when framework => "dev":true in options.json. There is also automatic generation of routes based on the file and folder structure. It focuses on performance and practicality. 100% Deno, no Node dependencies.

The project has a simple application example demonstrating each functionality.

About Faster, it is an optimized middleware server with an absurdly small amount of code (300 lines) built on top of Deno’s native HTTP APIs with no dependencies. It also has a collection of useful middlewares: log file, serve static, CORS, session, rate limit, token, body parsers, redirect, proxy and handle upload. Fully compatible with Deno Deploy. In “README” there are examples of all the resources. Faster’s ideology is: all you need is an optimized middleware manager, all other functionality is middleware. See more at: https://github.com/hviana/faster

Contents

Benchmarks

It has 0.9% of the code quantity of Deno Fresh. Benchmanrk command:

git clone https://github.com/denoland/fresh.git
cd fresh
git ls-files | xargs wc -l
# 104132 on version 1.7.1

git clone https://github.com/hviana/faster_react.git
cd faster_react
git ls-files | xargs wc -l
# 1037 on version 10.2

Architecture

This framework uses Headless Architecture [1] to build the application as a whole. Along with this, the Middleware Design Pattern [2] is used to define API routes in the Backend. Headless Architecture gives complete freedom to the developer. This freedom reduces the learning curve of the framework. Despite the freedom, there is an explicit separation between Backend and Frontend. This explicit separation helps programmers. In addition to this, the Middleware Design Pattern is very practical and simple for defining API routes.

App structure

All these application folders are inside the app folder. Remember that any change in these folders will cause the framework to compile, cache, and deliver everything automatically to the client, also updating server-side resources. There is no need to restart the application.

The project has a simple application example demonstrating each functionality.

frontend_pages folder

  • Use only frontend libraries here.
  • You can organize your files into subdirectories here.
  • The .tsx extension is used here.
  • These pages are rendered on the server and hydrated on the client.
  • Routes to these pages are generated automatically. For example, the path localhost:8080/pages/checkout/cart refers to the file app/frontend_pages/checkout/cart.tsx. It is important to note that the initial route will point to app/frontend_pages/index.tsx (ex:localhost:8080=>app/frontend_pages/index.tsx).
  • This file must have a default export with the React Function/Component.
  • This React Function/Component must only have the options input props, which is automatically generated by the framework.
  • The properties passed to the page includes
    • Form-submitted data (or JSON POST) in the options.content attribute;
    • URL search parameters, such as /pages/myPage?a=1&b=2 will result in {a:1, b:2} in the options.search attribute;
    • options.json => framework in the options.framework attribute;
    • backend_pages_props manipulations in the options;
    • Request headers in the options.headers attribute;
    • URL in the options.url attribute;

frontend_components folder

  • Use only frontend libraries here.
  • You can organize your files into subdirectories here.
  • The .tsx extension is used here.
  • This file must have a default export with the React Function/Component.

frontend_scripts folder

  • Use only frontend libraries here.
  • You can organize your files into subdirectories here.
  • Here the extension .ts and .js is used.
  • You are free to make as many exports or calls (including asynchronous) as you want here. Different from frontend_pages frontend_components, the scripts here are not automatically delivered to the client. They need to be imported by the frontend_components or frontend_pages. The intention here is to group common functions/objects for React Functions/Components, such as form field validations. You can also have frontend_scripts in common for other frontend_scripts.

css folder

Application css style files.

  • You can have multiple CSS files and they are automatically compiled.
  • You can organize your files into subdirectories here.

static folder

Files that will be served statically. Routes are generated automatically based on the folder and file structure, for example localhost:8080/static/favicon.ico will match the file app/static/favicon.ico.

backend_api folder

  • You can import your backend libraries here.
  • You can organize your files into subdirectories here.
  • The .ts extension is used here.
  • The file and folder structure is free here and does not influence anything.
  • Here you are also free to define the routes in whatever pattern you want.
  • This file must have a default export with the function (which can be asynchronous).
  • This function has as input parameter an instance of Server of faster.
  • You can do your backend manipulations here. For example, getting data from the database. Including asynchronous calls.
  • Define your custom api routes. For help, see: https://github.com/hviana/faster

backend_pages_props folder

  • Optional for a page.
  • You can import your backend libraries here.
  • You can organize your files into subdirectories here.
  • The .ts extension is used here.
  • Each of these files must have the same folder structure and name as the corresponding page, with the difference in the extension, which here is .ts. For example app/frontend_pages/checkout/cart.tsx should have as a corresponding (if one exists) app/backend_pages_props/checkout/cart.ts here.
  • This file must have a default export with the function (which can be asynchronous) that will handle the options props that will be passed to the page.
  • This function has as input parameter the props that will be passed to the page.
  • Only use JSON serializable data inside props.
  • You can do your backend manipulations here. For example, getting data from the database. Including asynchronous calls.

backend_pages_middlewares folder

  • Optional for a page.
  • You can import your backend libraries here.
  • You can organize your files into subdirectories here.
  • The .ts extension is used here.
  • Each of these files must have the same folder structure and name as the corresponding page, with the difference in the extension, which here is .ts. For example app/frontend_pages/checkout/cart.tsx should have as a corresponding (if one exists) app/backend_pages_middlewares/checkout/cart.ts here.
  • This file must have a default export with the middlewares (which can be asynchronous).
  • These middlewares intercept the page before it is processed. No data here is passed on to the page. To pass data use backend_pages_props. The use here is to check headers (like a token), impose Rate Limits, etc. You can cancel processing of a page by not calling await next() at the end of a middleware function. However, if you want the page to be processed, do not consume the body of ctx.req, or it will cause an error in the framework.
  • For help, see: https://github.com/hviana/faster
  • You can do your backend manipulations here. For example, getting data from the database. Including asynchronous calls. A useful example here is validation of Access Tokens.

backend_files folder

  • You can import your backend libraries here.
  • You can organize your files into subdirectories here.
  • The .ts extension is used here.
  • You are free to make as many exports or calls (including asynchronous) as you want here.
  • The intention here is to group common functions/objects for backend_api, backend_pages_props, backend_pages_middlewares (and backend_files, since you may have backend_files in common for other backend_files) files, such as user validations.

React Router

Routes are for pages only. Since the framework has its own routing system, a third-party routing library is not used. For this, there is a framework helper:

import route from "@helpers/frontend/route.ts";

Examples:

//URL Search params will be passed as properties to the page. In the example, the page props will receive `{options: {search : {a:1}}`
<button onClick={route("/pages/test?a=1")}></button>;

In addition to the URL Search params (which are optional), you can pass more parameters outside of url encoding:

//The page props will receive {options: {search : {a:1}, content: {"example":"exampleStr"}}
<button onClick={route("/pages/test?a=1", { "example": "exampleStr" })}>
</button>;

The parameter must be a JSON-serializable JavaScript object.

//The page props will receive `{options: {search : {a:1} , content: JSONResponse}}`
<button
  onClick={route("/pages/test?a=1", async () => {
    const request = await fetch("/example/json", {
      method: "POST",
      body: JSON.stringify({ "example": "otherExampleStr" }),
    });
    return await request.json();
  })}
>
</button>;

The result of the function must be a JSON-serializable JavaScript object.

Programmatically:

(async () => {
  if (user.loggedIn) {
    await route("/pages/dash", { "userId": user.id, "token": token })();
  } else {
    await route("/pages/users/login")();
  }
});

Packages included

There are several packages included to help you develop React applications. Here are some examples of imports that you can use without configuring anything:

import {/* your imports */} from "react";
import {/* your imports */} from "react/";
import {/* your imports */} from "react-dom";
import {/* your imports */} from "react-dom/server";
import {/* your imports */} from "react-dom/client";
import {/* your imports */} from "react/jsx-runtime";
import {/* your imports */} from "render";
import {/* your imports */} from "htm/react";
import route from "@helpers/frontend/route.ts";
/*
About Faster, it is an optimized middleware server with an absurdly small amount
of code (300 lines) built on top of Deno's native HTTP APIs with no
dependencies. It also has a collection of useful middlewares: log file, serve
static, CORS, session, rate limit, token, body parsers, redirect, proxy and
handle upload. Fully compatible with Deno Deploy. In "README" there are examples
of all the resources. Faster's ideology is: all you need is an optimized
middleware manager, all other functionality is middleware. See more at:
https://deno.land/x/faster
*/
import {/* your imports */} from "faster";
/*
Deno KV file system, compatible with Deno deploy. Saves files in 64kb chunks.
You can organize files into directories. You can control the KB/s rate for
saving and reading files, rate limit, user space limit and limit concurrent
operations, useful for controlling uploads/downloads. Makes use of Web Streams
API. See more at: https://deno.land/x/deno_kv_fs
 */
import {/* your imports */} from "deno_kv_fs";

Creating a project

You can simply download this repository. There is also the command, which requires the git command installed and configured. Command: deno run -A -r "https://deno.land/x/faster_react/new.ts" myProjectFolder. You can make your customizations and configure the server in options.json.

Running a project

It is necessary to execute the command: deno task serve

Deploy

  • Make sure your project is in your own GIT repository.
  • deno install -A --global jsr:@deno/deployctl
  • Delete deno.lock to prevent problems. Be careful that it is often recreated automatically. You may need to close the IDE and close the Deno process.
  • deployctl deploy
  • Remember that for production the option has to be framework => "dev":false in options.json.

References

[1] Dragana Markovic, Milic Scekic, Alessio Bucaioni, and Antonio Cicchetti. 2022. Could jamstack be the future of web applications architecture? an empirical study. In Proceedings of the 37th ACM/SIGAPP Symposium on Applied Computing (SAC ’22). Association for Computing Machinery, New York, NY, USA, 1872–1881. DOI: https://doi.org/10.1145/3477314.3506991

[2] Brown, Ethan. Web development with node and express: leveraging the JavaScript stack. O’Reilly Media, 2019. URL: http://www.oreilly.com/catalog/9781492053484

About

Author: Henrique Emanoel Viana, a Brazilian computer scientist, enthusiast of web technologies, cel: +55 (41) 99999-4664. URL: https://sites.google.com/view/henriqueviana

Improvements and suggestions are welcome!