Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/lucidarch/laravel-microservice

[DEPRECATED] See https://github.com/lucidarch/lucid
https://github.com/lucidarch/laravel-microservice

laravel microservice php scalable-applications

Last synced: 3 months ago
JSON representation

[DEPRECATED] See https://github.com/lucidarch/lucid

Lists

README 

        
# Lucid • Microservice - Laravel



With the emerging need for separation per concern, microservices emerged to be the trending progression

of what used to be a monolithic application. Especially with Lucid, scale is one of the core concerns that

a microservice is the natural progression of the architecture from its [monolithic counterpart](https://github.com/lucid-architecture/laravel).



It is no coincidence that the different parts of a Lucid monolithic application are called a **Service**, for microservices

are indeed the next progression when applications scale and reach that turning point. Having implemented your application

using Lucid, the transition process will be logically simpler to think about and physically straight-forward to

implement.



To see how it compares to the monolithic application and when to use which, check [Monolith vs. Microservice](#monolith-vs-microservice)



### Join The Community on Slack

[![Slack Status](https://lucid-slack.herokuapp.com/badge.svg)](https://lucid-slack.herokuapp.com)



##### The Lucid Architecture for Building Scalable Applications - Laracon EU 2016

Check out my talk at LaraconEU 2016 where I introduce the concept and application of the Lucid architecture:

[![Abed Halawi - The Lucid Architecture for Building Scalable Applications](http://img.youtube.com/vi/wSnM4JkyxPw/0.jpg)](http://www.youtube.com/watch?v=wSnM4JkyxPw "Abed Halawi - The Lucid Architecture for Building Scalable Applications")



## Installation

To get rolling, you need to create a new project using Composer:

```

composer create-project lucid-arch/laravel-microservice my-project

```



## Getting Started

This project ships with the [Lucid Console](https://github.com/lucid-architecture/laravel-console) which provides an interactive

user interface and a command line interface that are useful for scaffolding and exploring Services, Features and Jobs.



### Setup

The `lucid` executable will be in `vendor/bin`. If you don't have `./vendor/bin/` as part of your `PATH` you will

need to execute it using `./vendor/bin/lucid`, otherwise add it with the following command to be able to simply

call `lucid`:



```

export PATH="./vendor/bin:$PATH"

```



For a list of all the commands that are available run `lucid` or see the [CLI Reference](https://github.com/lucid-architecture/laravel-console).



### 1. Create a Feature

This is the Feature that we will be serving when someone visits our `/users` route.

```

lucid make:feature ListUsers

```



### 2. Create a Job

This Job will fetch the users from the database and will be used inside our Feature to serve them.

```

lucid make:job GetUsers user

```



Open the file that was generated at `app/Domains/User/GetUsersJob.php` and edit the `handle` method to this:



```php

public function handle()

{

    return [

        ['name' => 'John Doe'],

        ['name' => 'Jane Doe'],

        ['name' => 'Tommy Atkins'],

    ];

}

```



In a real-world application you might want to fetch the users from a database, and here is the perfect place for that.

Here's an example of fetching a list of users and providing the ability to specify the limit:



```php

use App\Data\Models\User;



class GetUsersJob extends Job

{

    private $limit;



    public function __construct($limit = 25)

    {

        $this->limit = $limit;

    }



    public function handle(User $user)

    {

        return $user->take($this->limit)->get();

    }

}

```



> NOTE: The namespace for models is `[app namespace]\Data\Models`



### 3. Run The Job

```php

// ...

use App\Domains\User\GetUsersJob;

use App\Domains\Http\RespondWithJsonJob;

// ...

public function handle(Request $request)

{

    $users = $this->run(GetUsersJob::class);



    return $this->run(new RespondWithJsonJob($users));

}

```



The `RespondWithJsonJob` is one of the Jobs that were shipped with this project, it lives in the `Http` domain and is

used to respond to a request in structured JSON format.



### 4. Serve The Feature

To be able to serve that Feature we need to create a route and a controller that does so.



Generate a plain controller with the following command



```

lucid make:controller user

```



And we will have our `UserController` generated in `app/Http/Controllers/UserController.php` which we will use

to serve our Feature in its `index` method.



We just need to create a route that would delegate the request to our `index` method:



```php

// ...

use App\Features\ListUsersFeature;

// ...

class UserController extends Controller

{

    public function index()

    {

        return $this->serve(ListUsersFeature::class);

    }

}

```



In `routes/web.php` add:



```php

Route::get('/users', 'UserController@index');

```



That's it! Now serve the application with `php artisan serve` and visit `http://localhost:8000/users`



### Event Hooks



Lucid exposes event hooks that allow you to listen on each dispatched feature, operation or job. This is especially useful for tracing:



```php

use Illuminate\Support\Facades\Event;

use Lucid\Foundation\Events\FeatureStarted;

use Lucid\Foundation\Events\OperationStarted;

use Lucid\Foundation\Events\JobStarted;



Event::listen(FeatureStarted::class, function (FeatureStarted $event) {

    // $event->name

    // $event->arguments

});



Event::listen(OperationStarted::class, function (OperationStarted $event) {

    // $event->name

    // $event->arguments

});



Event::listen(JobStarted::class, function (JobStarted $event) {

    // $event->name

    // $event->arguments

});

```



---



## Monolith vs. Microservice

In the monolith Lucid application we have multiple services (i.e. Api, Web) and these typically will exist in

`src/Services/Api` and `src/Services/Web` respectively. With the microservice the `src` does not exist, since

it is intended to be one service serving a single purpose, the `app` directory will do.

It will hold the following directories:

- **Data** For all your models, repositories and value objects.

- **Domains** Holds the Domains and their Jobs.

- **Features** The service's Features.



### Directory Structure

| Component | Monolith | Microservice |

|---------|---------|--------------|

|Job | src/Domains/[domain]/Jobs/[job] | app/Domains/[domain]/Jobs/[job] |

| Feature | src/Services/[service]/Features/[feature] | app/Features/[feature] |

| Service | src/Service/[service] | N/A (app) as equivalent |



### Tests

One other significant difference is in the location of tests:



|Component|Monolith | Microservice |

|---------|---------|--------------|

|Job | src/Domains/[domain]/Tests/Jobs/[JobTest] | tests/Domains/[domain]/Jobs/[JobTest] |

| Feature | src/Services/[service]/Tests/Features/[FeatureTest] | tests/Features/[Feature]Test.php |



## How To Choose

It is always [recommended](http://martinfowler.com/bliki/MonolithFirst.html) that you start with a monolith

and work on it until it gets so big that it is crucial to be dissected into single-purpose services (microservices).

It would be challenging to be able to figure out the different services your application would need moving forward.



This project is also useful when you know for sure that your application will not have to deal with multiple Services but you would still like to use Lucid.