Multiple Applications

Sometimes a project may be divided into multiple sub-projects, such as a mall consisting of three sub-projects: main mall project, mall API interface, and mall management backend. They all use the same database configuration.

Webman allows you to organize the app directory in the following way:

app
├── shop
│   ├── controller
│   ├── model
│   └── view
├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

When accessing the URL http://127.0.0.1:8787/shop/{controller}/{method}, it will access the controller and method under app/shop/controller.

When accessing the URL http://127.0.0.1:8787/api/{controller}/{method}, it will access the controller and method under app/api/controller.

When accessing the URL http://127.0.0.1:8787/admin/{controller}/{method}, it will access the controller and method under app/admin/controller.

In webman, you can even organize the app directory like this:

app
├── controller
├── model
├── view

├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

In this case, when accessing the URL http://127.0.0.1:8787/{controller}/{method}, it will access the controller and method under app/controller. When the path starts with api or admin, it will access the corresponding directory's controller and method.

In multiple applications, the class namespace must comply with PSR-4. For example, the file app/api/controller/FooController.php will look similar to this:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Middleware Configuration for Multiple Applications

Sometimes you may want to configure different middlewares for different applications. For example, the api application may require a CORS middleware, and the admin application may require a middleware to check if the administrator is logged in. In this case, the configuration of config/middleware.php might look like this:

return [
    // Global middleware
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // Middleware for the api application
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // Middleware for the admin application
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

The above middlewares may not exist, this is just an example to explain how to configure middlewares according to different applications.

The order of execution for middlewares is global middleware -> application middleware.

Middleware development can refer to the Middleware section.

Exception Handling Configuration for Multiple Applications

Similarly, if you want to configure different exception handlers for different applications, for example, you may want to provide a friendly error page when an exception occurs in the shop application, and return a JSON string instead of a page in the api application. The configuration file config/exception.php for configuring different exception handlers for different applications would look like this:

return [
    'shop' => support\exception\Handler::class,
    'api' => support\exception\ApiHandler::class,
];

Unlike middlewares, each application can only configure one exception handler.

The above exception handlers may not exist, this is just an example to explain how to configure exception handlers according to different applications.

Exception handling development can refer to the Exception Handling section.