Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P7)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P7)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P7): Implementation of Front-end User Authentication Function Based on Muse UI 3.0

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P7): Implementation of Front-end User Authentication Function Based on Muse UI 3.0

Introduce Material Design font and icon files

Since our chat room project front-end interface is based on the Muse UI, while Muse UI based on Material Design realization, so before you start, you need to import documents in view resources/views/index.blade.php of <head> the </head> following new font and icon files introduced between the label:

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700,400italic">
<link rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons">
<link rel="stylesheet" href="//at.alicdn.com/t/font_500440_9oye91czwt8.css">

This is the font and icon library recommended by Muse UI(the last one is the Alibaba icon icon style file, which will be used in the chat room window). After the introduction, refresh the home page and you can see the following icons are rendered:

Note: Muse UI is an elegant Material Design UI component library based on Vue 2.0. It can be likened to Bootstrap, iView, Element and other UI frameworks.

Adjust login and registration interface code to Muse UI 3.0

Click on the "我的" link, prompting you to log in:

Click the "去登录" link to enter the login page to complete user authentication:

At first glance, it may seem that there is no username and password input box, but it is actually the reason for the color overlay of the background image:

But this style and Vue-Webchat renderings slightly different, because we are now installing the 3.0 version of the Muse UI, while the Vue-Webchat using Muse UI version 2.0, it is necessary to resources/js/pages/Login.vue templates do for Muse UI component code Some adjustments:

<div class="content">
  <form action="" name="form2">
    <mu-text-field v-model="username" label="User" label-float icon="account_circle" full-width></mu-text-field>
    <br/>
    <mu-text-field v-model="password" type="password" label="password" label-float icon="locked" full-width></mu-text-field>
    <br/>
    <div class="btn-radius" @click="submit">Sign in</div>
  </form>
  <div @click="register" class="tip-user">Register Account</div>
</div>

...

export default {
  data() {
    return {
        loading: "",
        username: "",
        password: ""
    };
  },
  methods: {
    async submit() {
      const name = this.username.trim();
      const password = this.password.trim();
      ...

Rerun the npm run dev compiler front-end resources, and then force a refresh the login page, you can see the following renderings, and still OK:

Incidentally, the registration component resources/js/pages/Register.vue template code to be modified, the logic and Login.vue the same:

<div class="content">
  <form action="" name="form1">
    <mu-text-field v-model="username" label="Username" label-float icon="account_circle" full-width></mu-text-field>
    <br/>
    <mu-text-field v-model="password" type="password" label="Password" label-float icon="locked" full-width></mu-text-field>
    <br/>
    <div class="btn-radius" @click="submit">Signup</div>
  </form>
  <div @click="login" class="tip-user">
    I already have a account
  </div>
</div>

...

export default {
  data() {
      return {
          username: "",
          password: ""
      };
  },
  methods: {
    async submit() {
      const name = this.username.trim();
      const password = this.password.trim();
      ...

Then run npm run dev recompiled front-end resources.

Joint debugging of front-end and back-end registration interfaces

Front-end registration form submission logic

Next, we start with user registration, and jointly adjust the front-end and back-end user authentication related interfaces to open the user registration interface http://webchats.test/#/register:

Commit logic source code by reading the front-end registration form, you can see the logic and back-end is ultimately responsible for registration interface interaction is located resources/js/api/server.js in:

// Registration interface
RegisterUser: data => Axios.post('/register', data),

Referring to our previous backend API functions to achieve certification tutorials route definition, where the backend interface will need to adjust to /api/register, as we are resources/js/api/axios.js already defined baseURL, so here it does not make any adjustments:

const baseURL = '/api';

...

// Request unified processing
instance.interceptors.request.use(async config => {
    if (config.url && config.url.charAt(0) === '/') {
        config.url = `${baseURL}${config.url}`;
    }

    return config;
}, error => Promise.reject(error));

In addition, the front end to the rear end of the data transfer register form further comprises a default avatar URL (corresponding to logically located Register.vue in):

const data = {
    name: name,
    password: password,
    src: src
};
const res = await this.$store.dispatch("registerSubmit", data);

This field can be mapped to the rear end of users the new table avatar fields, in order to simplify the front-end logic, we can assume that the user input is a mailbox account and mailbox rear prefix taken as the user name.

Backend authentication interface adjustment

Corresponding to the app/Http/Controllers/AuthController.php modified rear end user registration process register to achieve the following:

public function register(Request $request)
{
    // Verify registration fields
    $validator = Validator::make($request->all(), [
        'name' => 'bail|required|email|max:100|unique:users',
        'password' => 'bail|required|string|min:6',
        'src' => 'bail|active_url|max:255'
    ]);
    if ($validator->fails()) {
        return [
            'errno' => 1,
            'data' => $validator->errors()->first()
        ];
    }

    // Create user in database and return
    $email = $request->input('name');
    try {
        $user = User::create([
            'name' => substr($email, 0, strpos($email, '@')),
            'email' => $email,
            'avatar' => $request->input('src'),
            'password' => Hash::make($request->input('password')),
            'api_token' => Str::random(60)
        ]);
        if ($user) {
            return [
                'errno' => 0,
                'data' => $user
            ];
        } else {
            return [
                'errno' => 1,
                'data' => 'Failed to save user to database'
            ];
        }
    } catch (QueryException $exception) {
        return [
            'errno' => 1,
            'data' => 'Save user to database exception:' . $exception->getMessage()
        ];
    }
}

We modified the form validation rules and return data format to fit the front-end code. Also, do not forget to modify the App\User model class of $fillable property, the new avatar field:

protected $fillable = [
    'name', 'email', 'password', 'api_token', 'avatar'
];

Restart the Swoole HTTP server for the back-end interface adjustment to take effect:

bin/laravels reload
Modify user interface code to fit Muse UI 3.0

Vue-Webchat this demonstration project is relatively simple piece of processing in the user authentication, user authentication is successful will save user information localStorage, as long as localStorage contained in userid it that the user has been authenticated, userid is the user account, the corresponding logic is saved after user registration or login Finished:

const res = await this.$store.dispatch("registerSubmit", data);
if (res.status === "success") {
    Toast({
        content: res.data.data,
        timeout: 1000,
        background: "#2196f3"
    });
    this.$store.commit("setUserInfo", {
        type: "userid",
        value: data.name
    });
    this.$store.commit("setUserInfo", {
        type: "src",
        value: data.src
    });
    this.getSvgModal.$root.$options.clear();
    this.$store.commit("setSvgModal", null);
    this.$router.push({ path: "/" });
    socket.emit("login", { name });
} else {
    await Alert({
        content: res.data.data
    });
}

But now in this "我的" page error, suggesting that <mu-raised-button> this component registration fails, this is Muse UI 3.0 version of the reason, the new version has been incorporated into this component <mu-button>. So we need to open a user interface where the file resources/js/pages/Home.vue, modify the corresponding component templates code show as below:

<div class="logout">
  <mu-button @click="logout" class="demo-raised-button" full-width>Sign out</mu-button>
</div>

Further, Muse UI 3.0 pair of <mu-list>use has been adjusted, it is necessary to adjust the reference code corresponding to the following components:

<mu-list>
    <mu-list-item button @click="changeAvatar">
      <mu-list-item-action>
        <mu-icon slot="left" value="send"/>
      </mu-list-item-action>
      <mu-list-item-title>Modify avatar</mu-list-item-title>
    </mu-list-item>
    <mu-list-item button @click="handleTips">
      <mu-list-item-action>
        <mu-icon slot="left" value="inbox"/>
      </mu-list-item-action>
      <mu-list-item-title>Sponsor</mu-list-item-title>
    </mu-list-item>
    <mu-list-item button @click="handleGithub">
      <mu-list-item-action>
        <mu-icon slot="left" value="grade"/>
      </mu-list-item-action>
      <mu-list-item-title>Github address</mu-list-item-title>
    </mu-list-item>
    <mu-list-item button @click="rmLocalData">
      <mu-list-item-action>
        <mu-icon slot="left" value="drafts"/>
      </mu-list-item-action>
      <mu-list-item-title>Clear cache</mu-list-item-title>
    </mu-list-item>
  </mu-list>

Then run npm run dev recompiled front-end resources, then refresh "我的" page:

You can see the user center interface that is normally rendered, and the list items also support clicking:

We click the "Logout" button on this page to log out, and then click the "我的" link at the bottom of the page again to enter the login page, and test the call to the login interface.

Joint debugging of front-end and back-end login interfaces

Backend login interface adjustment

And registration function as front-end login screen and function need not be adjusted, and registered the corresponding logic is the same, ultimately through /api/login the login logic interface call back-end user. Backend login interface needs to be adjusted to fit the front end of the login form submission, in app/Http/Controllers/AuthController.php, modify login as follows:

public function login(Request $request)
{
    // Verify login fields
    $validator = Validator::make($request->all(), [
        'name' => 'required|email|string',
        'password' => 'required|string',
    ]);
    if ($validator->fails()) {
        return [
            'errno' => 1,
            'data' => $validator->errors()->first()
        ];
    }

    $email = $request->input('name');
    $password = $request->input('password');
    $user = User::where('email', $email)->first();
    // Token information is returned if the user successfully checks
    if ($user && Hash::check($password, $user->password)) {
        $user->api_token = Str::random(60);
        $user->save();
        return [
            'errno' => 0,
            'data' => $user
        ];
    }

    return [
        'errno' => 1,
        'data' => 'Username and password do not match, please re-enter'
    ];
}

Restart the Swoole HTTP server for the backend modification to take effect:

bin/laravels reload

Test user login function

Then fill in the user information on the front-end login page and click the "Login" button:

After login successfully, it also jumps to the homepage. This time, we clicked the "我的" link at the bottom of the page, but it showed that the authentication was not successful. This is because the account information, the backend interface field and the frontend default interface field are obtained from the returned data after the backend login interface is successfully called. res.data.data.email Does not match, the back-end user account field is , and the front-end access is a non-existent field res.data.name. In addition, the avatar field does not match:

const res = await this.$store.dispatch("loginSubmit", data);
if (res.status === "success") {
    Toast({
        content: res.data.data,
        timeout: 1000,
        background: "#2196f3"
    });
    this.$store.commit("setUserInfo", {
        type: "userid",
        value: res.data.name
    });
    this.$store.commit("setUserInfo", {
        type: "src",
        value: res.data.src
    });
    this.getSvgModal.$root.$options.clear();
    this.$store.commit("setSvgModal", null);
    this.$router.push({ path: "/" });
    socket.emit("login", { name });
} else {
    Alert({
        content: res.data.data
    });
}

Adjust the logic of saving user information after the front-end user logs in successfully

Through this opportunity, we register and login to the back-end interface calls successfully unified gets saved data from back-end to front-end users localStorage, while preserving api_tokenthe field to the front end for future use.

In the first resources/js/pages/Login.vue, modify the back-end interface call log on user information stored after the success localStorage of the relevant code:

const res = await this.$store.dispatch("loginSubmit", data);
if (res.status === "success") {
    Toast({
        content: res.data.message,
        timeout: 1000,
        background: "#2196f3"
    });
    this.$store.commit("setUserInfo", {
        type: "userid",
        value: res.data.user.email
    });
    this.$store.commit("setUserInfo", {
        type: "token",
        value: res.data.user.api_token
    });
    this.$store.commit("setUserInfo", {
        type: "src",
        value: res.data.user.avatar
    });
    this.getSvgModal.$root.$options.clear();
    this.$store.commit("setSvgModal", null);
    this.$router.push({ path: "/" });
    socket.emit("login", { name });
} else {
    Alert({
        content: res.data.message
    });
}

Adjust the response field of the backend user authentication related interface

At the same time, the back-end interface also separates user data from message data:

public function register(Request $request)
{
    // Verify registration fields
    $validator = Validator::make($request->all(), [
        'name' => 'bail|required|email|max:100|unique:users',
        'password' => 'bail|required|string|min:6',
        'src' => 'bail|active_url|max:255'
    ]);
    if ($validator->fails()) {
        return [
            'errno' => 1,
            'message' => $validator->errors()->first()
        ];
    }

    // Create user in database and return
    $email = $request->input('name');
    try {
        $user = User::create([
            'name' => substr($email, 0, strpos($email, '@')),
            'email' => $email,
            'avatar' => $request->input('src'),
            'password' => Hash::make($request->input('password')),
            'api_token' => Str::random(60)
        ]);
        if ($user) {
            return [
                'errno' => 0,
                'user' => $user,
                'message' => 'User registered successfully'
            ];
        } else {
            return [
                'errno' => 1,
                'message' => 'Failed to save user to database'
            ];
        }
    } catch (QueryException $exception) {
        return [
            'errno' => 1,
            'message' => 'Save user to database exception:' . $exception->getMessage()
        ];
    }
}

public function login(Request $request)
{
    // Verify login fields
    $validator = Validator::make($request->all(), [
        'name' => 'required|email|string',
        'password' => 'required|string',
    ]);
    if ($validator->fails()) {
        return [
            'errno' => 1,
            'message' => $validator->errors()->first()
        ];
    }

    $email = $request->input('name');
    $password = $request->input('password');
    $user = User::where('email', $email)->first();
    // Token information is returned if the user successfully checks
    if ($user && Hash::check($password, $user->password)) {
        $user->api_token = Str::random(60);
        $user->save();
        return [
            'errno' => 0,
            'user' => $user,
            'message' => 'User login successful'
        ];
    }

    return [
        'errno' => 1,
        'message' => 'Username and password do not match, please re-enter'
    ];
}

public function logout(Request $request)
{
    $user = Auth::guard('auth:api')->user();
    if (!$user) {
        return [
            'errno' => 1,
            'message' => 'User has logged out'
        ];
    }
    $userModel = User::find($user->id);
    $userModel->api_token = null;
    $userModel->save();
    return [
        'errno' => 0,
        'message' => 'User exited successfully'
    ];
}

Modify the logic of saving user information after the front-end user registration is successful

Review resources/js/pages/Register.vue Related localStorage code is as follows:

const res = await this.$store.dispatch("registerSubmit", data);
if (res.status === "success") {
    Toast({
        content: res.data.message,
        timeout: 1000,
        background: "#2196f3"
    });
    this.$store.commit("setUserInfo", {
        type: "userid",
        value: res.data.user.email
    });
    this.$store.commit("setUserInfo", {
        type: "token",
        value: res.data.user.api_token
    });
    this.$store.commit("setUserInfo", {
        type: "src",
        value: res.data.user.avatar
    });
    this.getSvgModal.$root.$options.clear();
    this.$store.commit("setSvgModal", null);
    this.$router.push({ path: "/" });
    socket.emit("login", { name });
} else {
      await Alert({
        content: res.data.message
      });
}

Modify front-end user logout and clear user information logic

The user authentication logic related to WebSocket will be discussed in the next tutorial. Finally resources/js/pages/Home.vue cleared when the user exits the token data:

async logout() {
    const data = await Confirm({
        title: "prompt",
        content: "Do you have the heart to leave?"
    });
    if (data === "submit") {
        clear();
        this.$store.commit("setUserInfo", {
            type: "userid",
            value: ""
        });
        this.$store.commit("setUserInfo", {
            type: "token",
            value: ""
        });
        this.$store.commit("setUserInfo", {
            type: "src",
            value: ""
        });
        this.$store.commit("setUnread", {
            room1: 0,
            room2: 0
        });
        this.$router.push("/");
        this.$store.commit("setTab", false);
    }
},

Recompile the front-end resources:

npm run dev

Restart the Swoole HTTP server:

bin/laravels reload

Test user login again

Access the login page again, after a successful login, the top of the page will be prompted to log in successfully, go to "我的" page, you can also see the login has been successful, and localStorage you can see in the new token field:

At this point, the front-end and back-end linkage user authentication function has been completed. Next, we will formally begin to enter the code development of real-time chat rooms based on WebSocket.

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P6)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P6)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P6): Establish a Connection Between the Socket.io Client and The Swoole Websocket server

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P6): Establish a Connection Between the Socket.io Client and The Swoole Websocket server

Server transformation plan

After completing the development environment, setting up the back-end Websocket server, and initializing the front-end resources, we then officially started debugging the front-end and back-end interfaces to complete the development of the online chat room function.

The first thing we need to do is to establish a Websocket connection and communication between the client and the server. Here, our Websocket client uses socket.io-client, and the server uses the WebSocket server provided by the Swoole-based LaravelS extension package . socket.io has its own set of connection establishment and data encoding mechanisms, so you must adjust the original Websocket server implementation, otherwise you cannot establish a WebSocket connection.

The LaravelS extension pack is not friendly to the Socket.io client, but another popular Laravel Swoole extension pack Laravel-Swoole has good support for it, and it can even be said that it is a PHP server adaptation of the socket.io client For details, you can refer to its official documentation , so it is natural that we can port this part of its implementation to LaravelS.

The code of this project has been submitted to the Github code repository: https://github.com/nonfu/webchat , you can download the code from here for comparison.

Writing a data parser Parser

The data format sent and received by the socket.io client has its own rules. We need to implement the corresponding data parser on the server according to this rule, in order to decode the received client data before processing the data, and then process it. After that, encode the data before sending it to the client so that the client can parse it correctly.

This part of the logic directly Laravel-Swoole expansion pack copy, first app/services create the directory WebSocket subdirectories for storing WebSocket server-related code, and then the previously created WebSocketHandler handler class to move, at the same time do not forget to change config/laravels.php the profile of WebSocketHandler the path:

'websocket' => [
    'enable' => true,
    'handler' => \App\Services\WebSocket\WebSocketHandler::class,
],

Next, start writing data parser, in app/Services/WebSocket creating an abstract base class directory Parser initialization code as follows:

<?php
/**
 * Data codec abstract base class
 */

namespace App\Services\WebSocket;

use Illuminate\Support\Facades\App;

abstract class Parser
{
    /**
     * Strategy classes need to implement handle method.
     */
    protected $strategies = [];

    /**
     * Execute strategies before decoding payload.
     * If return value is true will skip decoding.
     *
     * @param \Swoole\WebSocket\Server $server
     * @param \Swoole\WebSocket\Frame $frame
     *
     * @return boolean
     */
    public function execute($server, $frame)
    {
        $skip = false;

        foreach ($this->strategies as $strategy) {
            $result = App::call(
                $strategy . '@handle',
                [
                    'server' => $server,
                    'frame' => $frame,
                ]
            );
            if ($result === true) {
                $skip = true;
                break;
            }
        }

        return $skip;
    }

    /**
     * Encode output payload for websocket push.
     *
     * @param string $event
     * @param mixed $data
     *
     * @return mixed
     */
    abstract public function encode(string $event, $data);

    /**
     * Input message on websocket connected.
     * Define and return event name and payload data here.
     *
     * @param \Swoole\Websocket\Frame $frame
     *
     * @return array
     */
    abstract public function decode($frame);
}

Then WebSocket create a subdirectory under the directory SocketIO used to store the relevant code to interact with the client socket.io. The first is the data parser corresponding to the socket.io client SocketIOParser. This class inherits from Parser:

<?php
/**
 * Socket.io corresponding data codec
 */

namespace App\Services\WebSocket\SocketIO;

use App\Services\WebSocket\Parser;
use App\Services\WebSocket\SocketIO\Strategies\HeartbeatStrategy;

class SocketIOParser extends Parser
{
    /**
     * Strategy classes need to implement handle method.
     */
    protected $strategies = [
        HeartbeatStrategy::class,
    ];

    /**
     * Encode output payload for websocket push.
     *
     * @param string $event
     * @param mixed $data
     *
     * @return mixed
     */
    public function encode(string $event, $data)
    {
        $packet = Packet::MESSAGE . Packet::EVENT;
        $shouldEncode = is_array($data) || is_object($data);
        $data = $shouldEncode ? json_encode($data) : $data;
        $format = $shouldEncode ? '["%s",%s]' : '["%s","%s"]';

        return $packet . sprintf($format, $event, $data);
    }

    /**
     * Decode message from websocket client.
     * Define and return payload here.
     *
     * @param \Swoole\Websocket\Frame $frame
     *
     * @return array
     */
    public function decode($frame)
    {
        $payload = Packet::getPayload($frame->data);

        return [
            'event' => $payload['event'] ?? null,
            'data' => $payload['data'] ?? null,
        ];
    }
}

This is used inside the package Packet type communication data analysis processing:

<?php
/**
 * Socket.io communication data parsing underlying class
 */

namespace App\Services\WebSocket\SocketIO;

class Packet
{
    /**
     * Socket.io packet type `open`.
     */
    const OPEN = 0;

    /**
     * Socket.io packet type `close`.
     */
    const CLOSE = 1;

    /**
     * Socket.io packet type `ping`.
     */
    const PING = 2;

    /**
     * Socket.io packet type `pong`.
     */
    const PONG = 3;

    /**
     * Socket.io packet type `message`.
     */
    const MESSAGE = 4;

    /**
     * Socket.io packet type 'upgrade'
     */
    const UPGRADE = 5;

    /**
     * Socket.io packet type `noop`.
     */
    const NOOP = 6;

    /**
     * Engine.io packet type `connect`.
     */
    const CONNECT = 0;

    /**
     * Engine.io packet type `disconnect`.
     */
    const DISCONNECT = 1;

    /**
     * Engine.io packet type `event`.
     */
    const EVENT = 2;

    /**
     * Engine.io packet type `ack`.
     */
    const ACK = 3;

    /**
     * Engine.io packet type `error`.
     */
    const ERROR = 4;

    /**
     * Engine.io packet type 'binary event'
     */
    const BINARY_EVENT = 5;

    /**
     * Engine.io packet type `binary ack`. For acks with binary arguments.
     */
    const BINARY_ACK = 6;

    /**
     * Socket.io packet types.
     */
    public static $socketTypes = [
        0 => 'OPEN',
        1 => 'CLOSE',
        2 => 'PING',
        3 => 'PONG',
        4 => 'MESSAGE',
        5 => 'UPGRADE',
        6 => 'NOOP',
    ];

    /**
     * Engine.io packet types.
     */
    public static $engineTypes = [
        0 => 'CONNECT',
        1 => 'DISCONNECT',
        2 => 'EVENT',
        3 => 'ACK',
        4 => 'ERROR',
        5 => 'BINARY_EVENT',
        6 => 'BINARY_ACK',
    ];

    /**
     * Get socket packet type of a raw payload.
     *
     * @param string $packet
     *
     * @return int|null
     */
    public static function getSocketType(string $packet)
    {
        $type = $packet[0] ?? null;

        if (! array_key_exists($type, static::$socketTypes)) {
            return null;
        }

        return (int) $type;
    }

    /**
     * Get data packet from a raw payload.
     *
     * @param string $packet
     *
     * @return array|null
     */
    public static function getPayload(string $packet)
    {
        $packet = trim($packet);
        $start = strpos($packet, '[');

        if ($start === false || substr($packet, -1) !== ']') {
            return null;
        }

        $data = substr($packet, $start, strlen($packet) - $start);
        $data = json_decode($data, true);

        if (is_null($data)) {
            return null;
        }

        return [
            'event' => $data[0],
            'data' => $data[1] ?? null,
        ];
    }

    /**
     * Return if a socket packet belongs to specific type.
     *
     * @param $packet
     * @param string $typeName
     *
     * @return bool
     */
    public static function isSocketType($packet, string $typeName)
    {
        $type = array_search(strtoupper($typeName), static::$socketTypes);

        if ($type === false) {
            return false;
        }

        return static::getSocketType($packet) === $type;
    }
}

In addition SocketIOParser also introduced strategy for processing the heartbeat connection, so-called heartbeat connection refers to the connection length in order to maintain a connection for communication at predetermined time intervals, which typically are not required for communication processing can be ignored, and there is such a made.

Heartbeat connection policy classes are held in SocketIO/Strategies the directory:

<?php
/**
 * Heartbeat connection processing strategy class
 */

namespace App\Services\WebSocket\SocketIO\Strategies;

use App\Services\WebSocket\SocketIO\Packet;

class HeartbeatStrategy
{
    /**
     * If return value is true will skip decoding.
     *
     * @param \Swoole\WebSocket\Server $server
     * @param \Swoole\WebSocket\Frame $frame
     *
     * @return boolean
     */
    public function handle($server, $frame)
    {
        $packet = $frame->data;
        $packetLength = strlen($packet);
        $payload = '';

        if (Packet::getPayload($packet)) {
            return false;
        }

        if ($isPing = Packet::isSocketType($packet, 'ping')) {
            $payload .= Packet::PONG;
        }

        if ($isPing && $packetLength > 1) {
            $payload .= substr($packet, 1, $packetLength - 1);
        }

        if ($isPing) {
            $server->push($frame->fd, $payload);
        }

        return true;
    }
}

At this point, our communication data parser is all completed. Next, let's look at the encapsulated communication data sending class.

Writing data sending classes Pusher

The reconstructed WebSocketHandler class will bear only routing and controller functions, to business logic related services will be peeled off to complete a separate service unit, comprising sending data, because we need to be uniform encapsulation processing, so that the customer can be End resolution. In the app/Services/WebSocket creation directory Pusher class for data transmission:

<?php
/**
 * Communication data transmission class
 */

namespace App\Services\WebSocket;


class Pusher
{
    /**
     * @var \Swoole\Websocket\Server
     */
    protected $server;

    /**
     * @var int
     */
    protected $opcode;

    /**
     * @var int
     */
    protected $sender;

    /**
     * @var array
     */
    protected $descriptors;

    /**
     * @var bool
     */
    protected $broadcast;

    /**
     * @var bool
     */
    protected $assigned;

    /**
     * @var string
     */
    protected $event;

    /**
     * @var mixed|null
     */
    protected $message;

    /**
     * Push constructor.
     *
     * @param int $opcode
     * @param int $sender
     * @param array $descriptors
     * @param bool $broadcast
     * @param bool $assigned
     * @param string $event
     * @param mixed|null $message
     * @param \Swoole\Websocket\Server
     */
    protected function __construct(
        int $opcode,
        int $sender,
        array $descriptors,
        bool $broadcast,
        bool $assigned,
        string $event,
        $message = null,
        $server
    )
    {
        $this->opcode = $opcode;
        $this->sender = $sender;
        $this->descriptors = $descriptors;
        $this->broadcast = $broadcast;
        $this->assigned = $assigned;
        $this->event = $event;
        $this->message = $message;
        $this->server = $server;
    }

    /**
     * Static constructor
     *
     * @param array $data
     * @param \Swoole\Websocket\Server $server
     *
     * @return Pusher
     */
    public static function make(array $data, $server)
    {
        return new static(
            $data['opcode'] ?? 1,
            $data['sender'] ?? 0,
            $data['fds'] ?? [],
            $data['broadcast'] ?? false,
            $data['assigned'] ?? false,
            $data['event'] ?? null,
            $data['message'] ?? null,
            $server
        );
    }

    /**
     * @return int
     */
    public function getOpcode(): int
    {
        return $this->opcode;
    }

    /**
     * @return int
     */
    public function getSender(): int
    {
        return $this->sender;
    }

    /**
     * @return array
     */
    public function getDescriptors(): array
    {
        return $this->descriptors;
    }

    /**
     * @param int $descriptor
     *
     * @return self
     */
    public function addDescriptor($descriptor): self
    {
        return $this->addDescriptors([$descriptor]);
    }

    /**
     * @param array $descriptors
     *
     * @return self
     */
    public function addDescriptors(array $descriptors): self
    {
        $this->descriptors = array_values(
            array_unique(
                array_merge($this->descriptors, $descriptors)
            )
        );

        return $this;
    }

    /**
     * @param int $descriptor
     *
     * @return bool
     */
    public function hasDescriptor(int $descriptor): bool
    {
        return in_array($descriptor, $this->descriptors);
    }

    /**
     * @return bool
     */
    public function isBroadcast(): bool
    {
        return $this->broadcast;
    }

    /**
     * @return bool
     */
    public function isAssigned(): bool
    {
        return $this->assigned;
    }

    /**
     * @return string
     */
    public function getEvent(): string
    {
        return $this->event;
    }

    /**
     * @return mixed|null
     */
    public function getMessage()
    {
        return $this->message;
    }

    /**
     * @return \Swoole\Websocket\Server
     */
    public function getServer()
    {
        return $this->server;
    }

    /**
     * @return bool
     */
    public function shouldBroadcast(): bool
    {
        return $this->broadcast && empty($this->descriptors) && ! $this->assigned;
    }

    /**
     * Returns all descriptors that are websocket
     *
     * @param \Swoole\Connection\Iterator $descriptors
     *
     * @return array
     */
    protected function getWebsocketConnections(): array
    {
        return array_filter(iterator_to_array($this->server->connections), function ($fd) {
            return $this->server->isEstablished($fd);
        });
    }

    /**
     * @param int $fd
     *
     * @return bool
     */
    public function shouldPushToDescriptor(int $fd): bool
    {
        if (! $this->server->isEstablished($fd)) {
            return false;
        }

        return $this->broadcast ? $this->sender !== (int) $fd : true;
    }

    /**
     * Push message to related descriptors
     *
     * @param mixed $payload
     *
     * @return void
     */
    public function push($payload): void
    {
        // attach sender if not broadcast
        if (! $this->broadcast && $this->sender && ! $this->hasDescriptor($this->sender)) {
            $this->addDescriptor($this->sender);
        }

        // check if to broadcast to other clients
        if ($this->shouldBroadcast()) {
            $this->addDescriptors($this->getWebsocketConnections());
        }

        // push message to designated fds
        foreach ($this->descriptors as $descriptor) {
            if ($this->shouldPushToDescriptor($descriptor)) {
                $this->server->push($descriptor, $payload, $this->opcode);
            }
        }
    }
}

This class is mainly used for business logic processing sent to the client after data processing, including data parsing and unified encapsulation, whether to broadcast, etc.

Writing WebSocket service class

In addition to simple data receiving and sending, our online chat room has many other complex functions, so it is necessary to create a separate service class to implement these functions, such as room join and exit, user authentication and acquisition, data transmission and broadcasting, where the final will call Pusher the class to send data, it can be said that the service class is the core of the WebSocket back-end services, but this tutorial to simplify this section, just copy over an empty placeholder class, more Multifunctionality will be gradually added in subsequent tutorials:

<?php
namespace App\Services\WebSocket;

class WebSocket
{
    const PUSH_ACTION = 'push';
    const EVENT_CONNECT = 'connect';
    const USER_PREFIX = 'uid_';

    /**
     * Determine if to broadcast.
     *
     * @var boolean
     */
    protected $isBroadcast = false;

    /**
     * Scoket sender's fd.
     *
     * @var integer
     */
    protected $sender;

    /**
     * Recepient's fd or room name.
     *
     * @var array
     */
    protected $to = [];

    /**
     * Websocket event callbacks.
     *
     * @var array
     */
    protected $callbacks = [];
}

In this tutorial, in order to simplify the process, we WebSocketHandler directly call the Pusher class to send data to the client to quickly demonstrate establish WebSocket communication connection.

Rewrite WebSocketHandler processors

Finally, we re-implement the code according to the new structure of WebSocketHandler the processor onOpen and onMessage method:

<?php
/**
 * WebSocket service communication processor class
 * Author: College Jun
 */
 
namespace App\Services\WebSocket;

use App\Services\WebSocket\SocketIO\SocketIOParser;
use Hhxsv5\LaravelS\Swoole\WebSocketHandlerInterface;
use Illuminate\Support\Facades\Log;
use Swoole\Http\Request;
use Swoole\WebSocket\Frame;
use Swoole\WebSocket\Server;

class WebSocketHandler implements WebSocketHandlerInterface
{
    /**
     * @var WebSocket
     */
    protected $websocket;
    /**
     * @var Parser
     */
    protected $parser;

    public function __construct()
    {
        $this->websocket = app(WebSocket::class);
        $this->parser = app(SocketIOParser::class);

    }

    // Triggered when the connection is established
    public function onOpen(Server $server, Request $request)
    {
        if (!request()->input('sid')) {
            // Initialize the connection information to adapt socket.io-client, this code cannot be omitted, otherwise the connection cannot be established
            $payload = json_encode([
                'sid' => base64_encode(uniqid()),
                'upgrades' => [],
                'pingInterval' => config('laravels.swoole.heartbeat_idle_time') * 1000,
                'pingTimeout' => config('laravels.swoole.heartbeat_check_interval') * 1000,
            ]);
            $initPayload = Packet::OPEN . $payload;
            $connectPayload = Packet::MESSAGE . Packet::CONNECT;
            $server->push($request->fd, $initPayload);
            $server->push($request->fd, $connectPayload);
        }
    
        Log::info('WebSocket Connection establishment:' . $request->fd);
        $payload = [
            'sender'    => $request->fd,
            'fds'       => [$request->fd],
            'broadcast' => false,
            'assigned'  => false,
            'event'     => 'message',
            'message'   => 'Welcome to chat room',
        ];
        $pusher = Pusher::make($payload, $server);
        $pusher->push($this->parser->encode($pusher->getEvent(), $pusher->getMessage()));
    }

    // Triggered when a message is received
    public function onMessage(Server $server, Frame $frame)
    {
        // $frame->fd Is the client id,$frame->data Is the data sent by the client
        Log::info("From {$frame->fd} Received data: {$frame->data}");
        if ($this->parser->execute($server, $frame)) {
            // Skip heartbeat connection processing
            return;
        }
        $payload = $this->parser->decode($frame);
        ['event' => $event, 'data' => $data] = $payload;
        $payload = [
            'sender' => $frame->fd,
            'fds'    => [$frame->fd],
            'broadcast' => false,
            'assigned'  => false,
            'event'     => $event,
            'message'   => $data,
        ];
        $pusher = Pusher::make($payload, $server);
        $pusher->push($this->parser->encode($pusher->getEvent(), $pusher->getMessage()));
    }

    // Triggered when the connection is closed
    public function onClose(Server $server, $fd, $reactorId)
    {
        Log::info('WebSocket Connection closed:' . $fd);
    }
}

First initialized in the constructor $websocket and $parser attributes, then the connection establishment callback method onOpen , it is determined request data contains sid fields not included the need to send connection initiation information to the client in order to successfully establish WebSocket connection, here we also specify the heartbeat interval time and time-out, the appropriate, we also need to profile config/laravels.php the swoole new configuration the following two items:

'heartbeat_idle_time' => 600,
'heartbeat_check_interval' => 60,

Then call the Pusher class push method to send a welcome message encoded in order to be resolved socket.io end customers.

In the method of the callback message is received onMessage, the first call the Parser class execute method determines whether the heartbeat connection, if the heartbeat connection is skipped if not treated, otherwise decoding the received information, after a simple treatment, and then through Pusher the class push method is sent back to the client.

At this point, the Swoole WebSocket server connection establishment and simple communication logic adapted to the socket.io client have been initially implemented. Next, we need to restart the Swoole WebSocket server for the code to take effect:

bin/laravels restart
socket.io client code tuning

Finally, we revise down socket.io client connection code, open resources/js/socket.js modify the connection establishment code is as follows:

import io from 'socket.io-client';
const socket = io('http://webchats.test', {
    path: '/ws',
    transports: ['websocket']
});
export default socket;

Here we set the server address to be driven by the Swoole HTTP server http://webchats.test, then set the path /ws to connect to the Swoole WebSocket server, and finally set the transport layer protocol to websocket replace the default long polling(polling) mechanism.

In addition Vue front-end components and view files and JavaScript files main entrance app.js also made some minor adjustments, the corresponding code to the code repository https://github.com/nonfu/webchat latest submitted version shall prevail, as in app.js, we printed Log of whether the Socket connection is established:

socket.on('connect', async () => {
    console.log('websocket connected: ' + socket.connected);
    ...

Next, we run npm run dev recompiled resources, access the browser http://webchats.test, you can see through F12 WebSocket connection establishment and communication of the data.

In the console Consoletab you can also see the following logs:

websocket connected: true

Indicates that the connection was established successfully.

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P14)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P14)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P14): Send a Picture Message

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P14): Send a Picture Message

In the last tutorial we demonstrated the release of text/emotional messages in chat rooms. Today we will look at how to post picture messages.

Front-end interaction code

We started from the front end assembly, assembly in a chat room Chat.Vue, the client core logic to send pictures located fileup approach, we need to be adjusted to fit the rear end of the original code based interface Laravel + Swoole of:

fileup() {
    const that = this;
    const file1 = document.getElementById('inputFile').files[0];
    if (file1) {
      const formdata = new window.FormData();
      formdata.append('file', file1);
      formdata.append('api_token', this.auth_token);
      formdata.append('roomid', that.roomid);
      this.$store.dispatch('uploadImg', formdata);
      const fr = new window.FileReader();
      fr.onload = function () {
        const obj = {
          username: that.userid,
          src: that.src,
          img: fr.result,
          msg: '',
          roomid: that.roomid,
          time: new Date(),
          api_token: that.auth_token
        };
        socket.emit('message', obj);
      };
      fr.readAsDataURL(file1);
      this.$nextTick(() => {
        this.container.scrollTop = 10000;
      });
    } else {
      console.log('Must have file');
    }
},

When we click on the camera icon in the chat room, the image upload window will pop up:

After selecting the picture, it will call the above fileup method to upload pictures.

It involves two logic: first calls the back-end interface to upload pictures based on the HTTP protocol and save the message to the messages table, it will send a message to Websocket server after a successful upload, and then by Websocket server broadcasts a message to all online users.

The upload image corresponds to this line of code:

this.$store.dispatch('uploadImg', formdata);

The final call to the back-end interface code is located resources/js/api/server.js in:

// upload image
postUploadFile: data => Axios.post('/file/uploadimg', data, {
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded'
    }
}),

We will write this interface in the backend shortly.

Sending a picture message based on Websocket corresponds to this line of code:

socket.emit('message', obj);

This is no different than sending a text message before the code is simply obj there to add a imgfield only.

Image upload interface

Next, we write an image upload interface on the Laravel backend.

In the routes/api.php new route file/uploadimg:

Route::middleware('auth:api')->group(function () {
    ...
    Route::post('/file/uploadimg', '[email protected]');
}

Then create the controller with Artisan commands FileController:

php artisan make:controller FileController

In the newly generated file controller app/Http/Controllers/FileController.php in preparation uploadImage codes are as follows:

<?php
namespace App\Http\Controllers;

use App\Message;
use Carbon\Carbon;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;

class FileController extends Controller
{
    public function uploadImage(Request $request)
    {
        if (!$request->hasFile('file') || !$request->file('file')->isValid() || !$request->has('roomid')) {
            return response()->json([
                'data' => [
                    'errno' => 500,
                    'msg'   => 'Invalid parameter (room number/picture file is empty or invalid)'
                ]
            ]);
        }
        $image = $request->file('file');
        $time = time();
        $filename = md5($time . mt_rand(0, 10000)) . '.' . $image->extension();
        $path = $image->storeAs('images/' . date('Y/m/d', $time), $filename, ['disk' => 'public']);
        if ($path) {
            // If the picture is uploaded successfully, the corresponding picture message is saved to the messages table
            $message = new Message();
            $message->user_id = auth('api')->id();
            $message->room_id = $request->post('roomid');
            $message->msg = '';  // Text message left blank
            $message->img = Storage::disk('public')->url($path);
            $message->created_at = Carbon::now();
            $message->save();
            return response()->json([
                'data' => [
                    'errno' => 200,
                    'msg'   => 'Saved successfully'
                ]
            ]);
        } else {
            return response()->json([
                'data' => [
                    'errno' => 500,
                    'msg'   => 'File upload failed, please try again'
                ]
            ]);
        }
    }
}

This mainly involves image upload and message saving logic. Because we will save the picture to the storage/public next directory, in order to let the picture can be requested through the Web URL, you need to storage create a soft catalog:

php artisan storage:link
Websocket server broadcast

Finally, we in routes/websocket.php the messagechannel complementary picture message processing logic:

WebsocketProxy::on('message', function (WebSocket $websocket, $data) {
    ...
    // Get message content
    $msg = $data['msg'];
    $img = $data['img'];
    $roomId = intval($data['roomid']);
    $time = $data['time'];
    // Message content (including pictures) or room number cannot be empty
    if((empty($msg)  && empty($img))|| empty($roomId)) {
        return;
    }
    // Record log
    Log::info($user->name . 'in the room' . $roomId . 'Post message: ' . $msg);
    // Save messages to the database (except for picture messages, because they were saved during the upload)
    if (empty($img)) {
        $message = new Message();
        $message->user_id = $user->id;
        $message->room_id = $roomId;
        $message->msg = $msg;  // Text message
        $message->img = '';  // Picture message left blank
        $message->created_at = Carbon::now();
        $message->save();
    }
    // Broadcast messages to all users in the room
    $room = Count::$ROOMLIST[$roomId];
    $messageData = [
        'userid' => $user->email,
        'username' => $user->name,
        'src' => $user->avatar,
        'msg' => $msg,
        'img' => $img,
        'roomid' => $roomId,
        'time' => $time
    ];
    $websocket->to($room)->emit('message', $messageData);
    ...

Very simple, just add the picture message field uploaded by the client to the field of the previous broadcast message, without any other logic.

At this point, we can complete the front-end and back-end code for image message sending. Next, we test the sending of image messages on the chat room interface.

Test image message release

Before you start, recompile the front-end resources:

npm run dev

Make front-end code changes take effect. And restart Swoole HTTP and WebSocket server:

bin/laravels restart

Let the backend code changes take effect.

Then, open the chat room in Chrome and Firefox browsers, log in and enter the same room, you can send picture messages to each other in real time:

At this point, we have completed the main function of the chat room. Next, we will optimize the project code, especially the performance and elegance of the back-end WebSocket communication.

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P4)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P4)

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P4): Front-end Resource Initialization

Building a Live Online Chat Room Based on Laravel + Swoole + Vue (P4): Front-end Resource Initialization

As said at the beginning , the front-end interface of this practical tutorial will be based on the chat room project implemented by the front-end technology stack https://github.com/hua1995116/webchat in order to focus on the development of chat room functions based on Swoole for the convenience of introduction, it will be called Vue-Webchat.

However, Vue-Webchat's front and back ends are implemented based on JavaScript. The front end uses the Vue framework, the back end uses the Express framework, the database uses MongoDB , and the front and back ends of WebSocket communication are based on Socket.io. In the project, we want to use the Laravel framework as the backend to store data in the MySQL database, and the WebSocket server is implemented based on Swoole. In addition, we also want to use Laravel Mix provided by Laravel as a front-end resource compilation tool to replace the native Webpack, so the original front-end code must be appropriately modified.

Front-end code for this project has been submitted to the Github repository: https://github.com/nonfu/webchat.

Front-end directory structure migration

In the Vue-Webchat this project, located in the front-end source code src directory:

Let's delete project Laravel webchat of resources/js all files in a directory, then the Vue-Webchat of src directory migrated:

Here I make the adjustment on the part of the directory structure, such as the original project static/css/reset.css moved to resources/css/reset.css, the original project src/styles style under the code integrated into resources/sass/app.scss in order to better fit Laravel project directory structure. In addition, I will be the original project src directory App.vue and BaseTransition.vue files to the resources/js/layout directory, the original project src directory under the view subdirectory rename pages, this is just personal preference, of course, the corresponding need to modify all of the introduction of the file path.

Further, a front end JavaScript file entry main.js for renaming app.js.

Front view entry file

The front-end view entry file of the original project is located in the root directory, index.html and the view entry file of this project is located at resources/views/index.blade.php:

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
<head>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="csrf-token" content="{{ csrf_token() }}">

    <link href="{{ asset('css/app.css') }}" rel="stylesheet" type="text/css" />

    <link rel="icon" type="image/x-icon" href="/favicon.ico">

    <title>Laravel学院在线聊天室</title>

    <script type='text/javascript'>
        window.Laravel = <?php echo json_encode(['csrfToken' => csrf_token(),]); ?>
    </script>
</head>
<body>
    <div id="app"></div>
    <script type="text/javascript" src="{{ asset('js/app.js') }}"></script>
</body>
</html>

Accordingly, the need to routes/web.php route the file to adjust the default home page view template:

Route::get('/', function () {
    return view('index');
});
Front-end code adjustment

Next, let's focus on the modifications made to the front-end code to fit the Laravel back-end framework and the Swoole WebSocket server.

Interaction with back-end interface

Interaction with back-end interfaces are packaged in a unified resources/js/api directory, in axios.js the base package provides a library of Axios, and all back-end interface calls are located in server.js, where we need to axios.js be adjusted, adding CSRF Token request header:

import axios from 'axios';
const baseURL = '/api/';

const instance = axios.create();

instance.defaults.timeout = 30000; // 30s timeout on all interfaces
instance.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

// CSRF Token for all request headers
let token = document.head.querySelector('meta[name="csrf-token"]');
if (token) {
    instance.defaults.headers.common['X-CSRF-TOKEN'] = token.content;
} else {
    console.error('CSRF token not found: https://laravel.com/docs/csrf#csrf-x-csrf-token');
}

...

The routing and processing logic that specifically calls the back-end interface is ignored first, and then debug one by one when developing specific functions later.

Interaction with WebSocket server

Vue-Webchat project-based socket.io-client libraries to communicate as a client and WebSocket server, where we follow the client program, but the need to modify the connection configuration, back-end configuration changes to Swoole WebSocket server, modify the resources/js/socket.js code as follows:

// WebSocket request via Socket.io client
import io from 'socket.io-client'
const socket = io.connect(process.env.APP_URL + ':' + process.env.LARAVELS_LISTEN_PORT + '/ws/')
export default socket

And axios as specific call this socket module where the first matter, the development of specific functions to back one by one when debugging.

Adjustment of alias paths

Vue-Webchat item view upon introduction assembly and the module configuration @ path alias, such that:

import {queryString} from '@utils/queryString';

This project canceled this configuration and was introduced directly through relative paths:

import {queryString} from './utils/queryString';

All involve @ local path references should be adjusted, mainly in the pages Vue components under a subdirectory.

Front-end style compilation adjustments

As mentioned earlier, JavaScript files of this project is the entrance app.js, CSS resource file in my original project introduced here out of all, integrated into the webpack.mix.js lower compiled by Laravel Mix:

mix.js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css')
    .styles([
        'resources/css/reset.css',
        'public/css/app.css',
        'node_modules/muse-ui/dist/muse-ui.css'
    ], 'public/css/app.css');

Add front-end dependencies to package.json

Next, we add the front-end code involved in all new dependencies to the project under the root directory package.json in which:

"devDependencies": {
    "axios": "^0.18",
    "cross-env": "^5.1",
    "file-loader": "^4.2.0",
    "jquery": "^3.2",
    "laravel-mix": "^4.0.7",
    "lodash": "^4.17.5",
    "muse-ui": "^3.0.2",
    "popper.js": "^1.12",
    "resolve-url-loader": "^2.3.1",
    "sass": "^1.23.1",
    "sass-loader": "7.*",
    "socket.io-client": "^2.3.0",
    "stylus": "^0.54.7",
    "stylus-loader": "^3.0.2",
    "timers": "^0.1.1",
    "url-loader": "^2.2.0",
    "vivus": "^0.4.5",
    "vue": "^2.6.10",
    "vue-cropper": "^0.4.9",
    "vue-picture-preview": "^1.3.0",
    "vue-router": "^3.1.2",
    "vue-style-loader": "^4.1.2",
    "vue-template-compiler": "^2.6.10",
    "vuex": "^3.1.1",
    "xss-filters-es6": "^1.0.0"
}

And then run the npm install install all front-end dependent libraries.

Of course, all the above front-end code migrations and adjustments have been submitted to the Github repository, you can download the corresponding resources directly to the local here: https://github.com/nonfu/webchat.

Compile front-end resources

Finally, in the root directory of the project npm run dev to compile all of these resources through the front Laravel Mix:

After the compilation is successful, next, we will start debugging the interaction between the front-end interface and the back-end interface, which will be explained in subsequent tutorials.