Multiple Applications

Sometimes a project may be divided into multiple sub-projects. For example, an e-commerce platform may be split into three sub-projects: the main e-commerce project, the e-commerce API interface, and the e-commerce admin backend, all of which use the same database configuration.

Webman allows you to structure the app directory as follows:

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 calls the controller and method under app/shop/controller.

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

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

In Webman, you can even structure 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 calls the controller and method under app/controller. When the path starts with api or admin, it accesses the corresponding directory's controller and method.

When using multiple applications, the class namespace must comply with psr4. For example, the file app/api/controller/FooController.php would look something like this:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Middleware Configuration for Multiple Applications

Sometimes you want to configure different middleware for different applications. For example, the api application might need a cross-origin middleware, while the admin application needs a middleware to check for admin logins. The configuration file config/middleware.php may look something like this:

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

The above middleware may not exist; it is only an example illustrating how to configure middleware by application.

The execution order of middleware is Global Middleware -> Application Middleware.

For middleware development, refer to the Middleware Chapter.

Exception Handling Configuration for Multiple Applications

Similarly, you may want to configure different exception handling classes for different applications. For example, in the shop application, you might want to provide a friendly error page when an exception occurs; in the api application, you might want to return a JSON string instead of a page when an exception is thrown. The configuration file for configuring different exception handling classes for each application, config/exception.php, may look like this:

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

Unlike middleware, each application can only configure one exception handling class.

The above exception handling classes may not exist; it is only an example illustrating how to configure exception handling by application.

For exception handling development, refer to the Exception Handling Chapter.