Introduction to openresty front-end development

OpenResty ™ is a high-performance web platform based on Nginx and Lua, which integrates a large number of sophisticated Lua libraries, third-party modules and most dependencies. It is used to easily build dynamic web applications, web services and dynamic gateways that can handle ultra-high concurrency and scalability.

OpenResty effectively turns Nginx into a powerful general-purpose web application platform by bringing together various well-designed Nginx modules (mainly developed by the OpenResty team). In this way, web developers and system engineers can use the Lua scripting language to mobilize various C and Lua modules supported by Nginx to quickly construct high-performance web application systems capable of 10K or even more than 1000K single-machine concurrent connections.

The goal of OpenResty is to let your web services run directly inside the Nginx service, making full use of Nginx's non-blocking I/O model, not only for HTTP client requests, but also for remote backends such as MySQL, PostgreSQL, Memcached, and Redis, etc. All deliver consistent high-performance responses.

The above are the original words copied from the official website. We entered the openresty development journey by writing a hello world

**Download address**
http://openresty.org/cn/download.htmlSome

people will not download windows version, so I will directly give the download address here. It is the latest version. After learning it, you can download the

mac and linux platforms by yourself
https://openresty.org/download/openresty-1.11.2.2.tar.gz

windows platform
https://openresty.org/download/openresty-1.11.2.2-win32.zip

**About installation** For mac and linux installation ,
see here http://openresty.org/cn/installation.html It's ok
, no need to

install . Don't rush to start after the installation

**Start writing code**

Open the conf/nginx.conf file

in Add the following code to the server
```
location /hello {
    default_type text/html;
    content_by_lua '
        ngx.say("hello, world
")
    ';
}
```

something like
this```
http {
    server {
        listen 80;
    server_name localhost;
        location / {
            default_type text/html;
            content_by_lua '
                ngx.say("hello, world
")
            ';
        }
    }
}
```

Now start nginx, and then visit http://localhost/hello, if there is no accident, it should be OK. If you started it before, you need to reload For a moment, the basic operation of nginx will not be introduced here.

Through **ngx.say**, we can output the response text to the client, which can be called multiple times during the entire request cycle. The accepted parameter is a string, and an error will be reported if the table is output.

Another output function is **ngx.print**, which also outputs the response content.

There is a **pit**, that is, calling ngx.say will output an additional line break after outputting our content, but ngx. Print will not. A colleague of mine used lua to output a 200, and then the front end used ajax to call it to determine whether it was 200, life or death was false, and the output content was 200, almost doubting life, fortunately, I was more witty and directly checked the ajax request In the source code, I found that there is one more line in the line number, which is the newline. If you are not careful, you will not be able to see it at all. This pit was stepped on by a colleague of mine. The

above code directly writes the lua code into the nginx configuration, which is not very convenient to maintain, and There is no syntax highlighting when writing code. It is a pain in the ass to prompt these. We take it out as a separate file and put it in a separate lua directory under nginx to facilitate the management of

lua/hello.lua
```
ngx .say("hello, world
")
````

Change nginx.conf to this
```
location / {
     default_type text/html;
     content_by_lua_file lua/hello.lua;
}
```

Then nginx reload, and then look at the effect, it should be the same

Let's modify hello.lua, in hello , add one after world! No., refresh the browser and find that there is no change, this is because the lua code is cached, which leads us to modify the code, we must reload nginx to see the effect, if so, it is crazy, in fact, to solve this The problem is very simple, as long as the lua cache is disabled in nginx.conf, of course, the cache must be turned on on the production line, otherwise the effect will be greatly reduced

Ban lua cache
```
server {
   listen 80;
   server_name localhost;
   lua_code_cache off; # This can be placed under the server or under the location, and the scope of action is different. For simplicity, it is placed here
   location / {
       default_type text/html;
       content_by_lua_file lua/hello.lua;
   }
}
```
After the change, reload nginx, here **key statement** to modify the nginx configuration must be reloaded, otherwise it will have no effect.

Now let's change hello.lua, and then refresh the browser to find that it can take effect in real time.

Observe the above code actually We will also find a problem. If we want to process many requests, don't we need to configure N locations in nginx? We will definitely not do this. Here, we can dynamically specify the lua file name through nginx matching, and we can complete our work. In the background, I will introduce how to create a lightweight mvc framework that belongs to us. Here we will do this first and

change the location to this
```
location ~ /lua/(.+) {
content_by_lua_file lua/$1.lua;
}
` ``

reload nginx

At this time, the request url to access hello world becomes
http://localhost/lua/hello.
Similarly , if we create a welcome.lua in the lua file, we can pass
http://localhost/ lua/welcome to access
and so on , we can add multiple files to handle different requests, and the modification can take effect in real time, the rest is to complete the business code, such as adjusting redis to return data, Or mysql and the like, savvy students can already do a lot of things here