Starting this chapter assumes that you are familiar with Lua syntax.

Run the process

After learning how to install CF in the previous section, this section will introduce cf to the runtime mechanism and HTTPD server setup!

Cf is a very typical event-driven development framework based on coroutines encapsulated as APIS, which can rely on event loops to implement a stable runtime environment.

Lua itself provides a powerful table data structure that can build its own so-called “config”, so CF does not provide additional config files for configuration to reduce useless dependencies.

Cf assumes that all business code files are in the script directory, so it is recommended that you classify files under script.

Cf names the script directory for all services as script, and the main.lua file in the script directory will be the entry file. The main. Lua will not actually enter the event loop until it has finished executing.

After executing the script/main.lua file, CF will determine whether the event loop needs to start. If the developer just wants to run print(“hello world”), cf will exit after main.lua is done.

Operational mechanism issues and modular design

Other Lua code can be imported inside the main.lua file for modular design, but it is important to note that when the CF framework uses the require import file, the imported file can only be used for definitions and not for process execution.

What does that mean? For example, when you create an HTTPD instance you create a DB object and initialize it! At this point you can return to design code like the following:

-- mydb.lua
local DB = require "DB"
local db = DB:new {
  host = "localhost",
  port = 3306,
  database = "cfadmin",
  charset = 'utf8'
  -...
}
local ok = db:connect()
if not ok then
  return nil
end
return db
Copy the code
-- main.lua
local db_cls = require "mydb"
--[[
... do your want do
]]
Copy the code

Attempting to do so will result in an error message :” Attempt to yield from outside a coroutine”, which translates to “cannot switch execution rights in a non-coroutine environment “.

This is because the require function’s Call method on the specified script does not allow a temporary switch out of execution, and the operation to initialize the database connection relies on the CF coroutine and asynchronous operation, thus causing the above error.

This can be done by replacing mydb.lua and main.lua with the following:

-- mydb.lua
local DB = require "DB"

local db

return function (a)
  if db then
    return db
  end
  db = DB:new {
    host = "localhost",
    port = 3306,
    database = "cfadmin",
    charset = 'utf8'
    -...
  }
  local ok = db:connect()
  if not ok then
    db:close()
    db = nil
    return nil."Connection failed"
  end
  return db
end
Copy the code
-- main.lua
local get_db = require "mydb"
local db = get_db()
- [[.do your want do
]]
Copy the code

This avoids require’s internal call with a clever function and upvalue approach, where the require returns and the execution reverts back to the coroutine started by CF. This will start the proper initialization.

This is only possible when you rely on REQUIRE to execute a block of asynchronous code, and is generally not a problem in other cases. Good project managers don’t usually have this kind of design.

Use HTTPD library to quickly build lua Web development environment

HTTPD library is a cf built-in Web server based on HTTP 1.1 protocol development! An efficient parser is essential, and the HTTPD library uses the PicoHttpParser to build HTTP contexts.

We assume that you have at least seen the HTTPD library API Reference and know at least the apis described below.

All of the APIS and usage methods here will be found in THE API Reference.

1. Import the HTTP library

Local HTTPD = require “HTTPD” in main. Lua

2. Initialize an HTTPD app object

HTTPD libraries are created using Lua class objects! The new method is provided by default, and the user can use the new method to create an app instance of HTTPD.

local httpd = require "httpd"

local app = httpd:new("app")
Copy the code

3. Register the static file path

HTTPD provides built-in static file lookup capabilities that require users to automatically register static file paths using static methods.

app:static("static".30)
Copy the code

Static indicates that the user wants to use the app/static folder as the root directory for static files.

4. Set the listening port

HTTPD startup needs to specify the port to listen on, default listening on all network cards. Although the first argument is not used, it cannot be null.

app:listen("0.0.0.0".8080)
Copy the code

5. Run

After initialization, the app calls the run method to start the HTTPD server. The code after the run method may never get a chance to execute.

app:run()
Copy the code

6. Run the cf

Run the HTTPD server with the./cfadmin command. If you see something like “Run”, the HTTPD server has been started, otherwise you will receive an error message.

7. Complete code examples

-- script/main.lua
local httpd = require "httpd"
local app = httpd:new("app")

app:static("static".30)

app:listen("0.0.0.0".8080)

app:run()
Copy the code

Experience the

Now, let’s open http://localhost:8080/index.html see if can correctly display the page?

More HTTPD apis

Here you can find more information about the HTTPD library API.

Continue to learn

In the next chapter we will learn how to register routes with CF