Software Engineering Stories

Aurora for serverless Laravel

Wed, 07 Jul 2021 00:00:00 +0100

The why, the how and the what

An open source, alternative to Laravel Vapor. For instructions for how to this up, see https://stories.rdok.co.uk/2021/06/serverless-laravel/#setup

Use this repository to automate creating a serverless Laravel with Aurora MySQL environment.

It uses AWS SAM with GitHub CI/CD actions to create the AWS resources, including the Aurora & Laravel Lambdas.

Aurora

Aurora has the capability to auto pause after a given amount of time with no activity. During testing, it took around 30s for it to resume after paused.

Private Links

Private Link VPC endpoints are a better alternative to NAT Gateways. Laravel lambdas use said private links to connect to Aurora, S3, and Secrets Manager AWS resources.

Network bandwidth is cheaper than NAT Gateway by four times.
More secure than NAT Gateway as the connection always stays in AWS private network.
Laravel & artisan fetch the secrets with database credentials on each cycle using a custom provider.
AWS does not allow duplicate private links DNS for secrets manager. As such, said private link are re-used for test and prod environments.

Secrets

Using IAM auth the Laravel lambda would not need to use a password when connecting to the database. This would also remove the need to rotate the database secrets. However, Aurora does not support IAM auth. Instead, SecretsManager are used.

Secrets rotation goes outside the scope of this repo. It requires creating a lambda to do so.

CI/CD

The CI/CD user assumes the role with relevant authorisation for creating the relevant resources.
For a new environment it takes ~15 minutes to build everything, while ~2 minutes to re-deploy any simple change.
Migrations automatically run through the Laravel artisan lambda on each deployment.
test environment is auto deployed for any change on main branch.
Developers have to manually trigger prod environment deployments.

Costs

Cost almost 2 dollars every day for the private link VPC endpoints. Minor to no costs for Aurora when paused.
To ensure low costs, the test environment is auto deleted every midnight.

Serverless Laravel

Sat, 12 Jun 2021 00:00:00 +0100

Production Showcase Source Code

The why, the how and the what

Use this repository when you want to automate creating a serverless Laravel environment.

It uses AWS SAM to create the AWS resources including:

Route 53 entries && SSL certificates
CloudFront
API Gateway for Lambda & Artisan
Assets S3 bucket for static files
Storage S3 bucket for internal files

It also makes use of GitHub actions for CI/CD automation.

Setup

Fork rdok/serverless-laravel template
Update the repository secrets with AWS credentials & others.
Update environment variables of artisan.yml & deploy.yml.
The IAM policies required for the CI/CD user are outside the scope of this post. However, you can reference the automated policies for the showcase here.
Deploy using Deploy Github action.
Run artisan commands using the Artisan GitHub action.

Pre-requisites

To automate the creation of the subdomain & it’s certificate.

An existing base domain & wild card certificate.

This Github Sample is by rdok

.github/workflows/deploy.yml view raw

BASE_DOMAIN_ROUTE_53_HOSTED_ZONE_ID: ${{ secrets.BASE_DOMAIN_ROUTE_53_HOSTED_ZONE_ID }}
BASE_DOMAIN_WILD_CARD_CERTIFICATE_ARN: ${{ secrets.BASE_DOMAIN_WILD_CARD_CERTIFICATE_ARN }}

Future additions

The following Laravel features will be supported in future posts:

Aurora serverless MySQL database
Broadcasting through SNS
Job dispatching through SQS
Scheduling through additional Lambda

Environment variables

Instruct Laravel how to load static assets & access storage bucket:

This Github Sample is by rdok

template.yaml view raw

Variables:
  APP_KEY: !Ref AppKey
  APP_STORAGE: /tmp
  AWS_PUBLIC_BUCKET: !Ref Assets
  MIX_ASSET_URL: !Join [ '', [ 'https://', !Ref DomainName, '/assets' ] ]
  ASSET_URL: !Join [ '', [ 'https://', !Ref DomainName, '/assets' ] ]
  LOG_CHANNEL: stderr
  FILESYSTEM_DRIVER: s3
  AWS_BUCKET: !Ref Storage

Domain Certificate

CloudFront only supports ACM certificates in the US East (N. Virginia) Region. As such, a separate stack is created in the us-east-1 region.

This Github Sample is by rdok

template-certificate.yml view raw

Certificate:
  Type: AWS::CertificateManager::Certificate
  Properties:
    ValidationMethod: DNS
    DomainValidationOptions:
      - DomainName: !Ref DomainName
        HostedZoneId: !Ref BaseDomainRoute53HostedZoneId
    DomainName: !Ref DomainName

Storage

Instruct Laravel to properly get AWS credentials by adding the AWS session token:

This Github Sample is by rdok

laravel/config/filesystems.php view raw

'token' => env('AWS_SESSION_TOKEN'),

CI/CD

CI/CD uses AWS SAM to build & deploy AWS resources:

This Github Sample is by rdok

.github/workflows/deploy.yml view raw

sam deploy \
  --region "eu-west-1" \
  --s3-bucket "${{ steps.env.outputs.cicd-bucket-laravel }}" \
  --s3-prefix "${NAME}" \
  --stack-name "${{ steps.env.outputs.stack-laravel-name }}" \
  --capabilities CAPABILITY_IAM \
  --no-fail-on-empty-changeset \
  --no-confirm-changeset \
  --parameter-overrides \
    CertificateARN="${CERTIFICATE_ARN}" \
    AppKey="${APP_KEY}" \
    DomainName="${{ steps.env.outputs.domain-name }}" \
    WildcardCertificateARN="${BASE_DOMAIN_WILD_CARD_CERTIFICATE_ARN}" \
    BaseDomainRoute53HostedZoneId="${BASE_DOMAIN_ROUTE_53_HOSTED_ZONE_ID}"

Cyberpunk 2077 R6 Config Editor

Sat, 05 Jun 2021 00:00:00 +0100

Cyberpunk2077 R6 Config editor, is a Windows app built on Python.

Why & How

Use this app to customize your Cyberpunk 2077 experience and immersion.

It modifies the game configuration files for player movement & other gameplay characteristics.

TDD

I build this app entirely using test driven development, since the first code line.

A huge advantage, shown almost immediately, when having to re-design the architecture due to additional unexpected complex customisations.

Without the tests, there would have been less freedom to change the architecture to conform with new requirements.

This Github Sample is by rdok

tests/test_main.py view raw

def test_it_renders_the_gui(self):
    self.gui.mainloop.assert_called_once()

def test_it_renders_remap_walk_frame(self):
    self.gui.render_walk_frame.assert_called_once()

def test_it_renders_crafting_frame(self):
    self.gui.render_crafting_frame.assert_called_once()

CI/CD

The CI/CD pipeline runs on GitHub’s Windows 2019 servers.

It consists of running linter, unit tests, building the pyinstaller and the Windows executable app.

It builds pyinstaller natively, to lower the probability of TotalVirus Scanning marking it as false-positive virus. A requirement from NexusMod commitment to testing each file uploaded against viruses.

This Github Sample is by rdok

.github/workflows/cd.yml view raw

- name: Build pyinstaller
  run: |
   python -m pip install --upgrade pip
   git clone --depth 1 --branch v4.1 https://github.com/pyinstaller/pyinstaller
   cd .\pyinstaller\bootloader\
   python ./waf all
   cd ..
   python setup.py install

Serverless GraphQL Implementation

Sat, 29 May 2021 00:00:00 +0100

Create a serverless GraphQL implementation ready production, including CI/CD.

Developers should be able to just clone, add AWS credentials, and deploy away using GitHub Actions.

Implementation details

Use apollo-server-lambda npm package to serve the Apollo GraphQL through AWS Lambda.
It exposes the API to the Apollo implementation.

This Github Sample is by rdok

src/main.js#L1 view raw

const { ApolloServer, gql } = require('apollo-server-lambda');

GraphQL playground

The playground provides a GUI for making GraphQL requests. E.g. GitHub’s Playground

When running locally, the playground is enabled by default. However, if you wish to have the playground available when deploying to AWS infrastructure, there is an additional step to take.
Instruct the Lambda, when the requested HTTP method is GET, to server playground UI:

This Github Sample is by rdok

src/main.js view raw

return server.createHandler()(
  { ...event, path: event.requestContext.path || event.path },
  lambdaContext,
  callback,
);

CORS

Modify the AWS SAM template to allow all CORS.

This Github Sample is by rdok

template.yml#L5 view raw

ApiGatewayApi:
  Type: AWS::Serverless::Api
  Properties:
    StageName: "Prod"
    Cors: "'*'"

Minimalistic AWS SAM PHP

Sat, 22 May 2021 00:00:00 +0100

Automates a serverless PHP Lambda implementation ready production, including CI/CD.

The PHP Lambda function generates a JSON response {"status":"OK."}.

When & Why

Use this as a template to quickstart a serverless PHP based service.

Implementation Details

Use Bref Runtimes Layers, for running PHP on Lambda.

This Github Sample is by rdok

template.yaml view raw

Type: AWS::Serverless::Function
Properties:
  CodeUri: src/
  Layers: ["arn:aws:lambda:eu-west-1:209497400698:layer:php-80:9"]
  Handler: main.php

Composer

bref/bref composer package is required to create communication between the PHP and the Lambda API.
composer.json & composer.lock should be added on the same level as the entry php file.
Finally composer install should be run before deploying the infrastructure.

What are the least privileges required for AWS SAM?

Sun, 22 Nov 2020 00:00:00 +0000

When setting up IAM users for continuous delivery it is difficult to find privileges required using the failed AWS SAM deployment logs. This is due to these errors being too generic, and not specifying the exact resource. This page documents the basic privileges for running AWS SAM with a Lambda, and CAPABILITY_IAM capability.

Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "cloudformation:CreateChangeSet",
                "cloudformation:GetTemplateSummary",
                "cloudformation:DescribeStacks",
                "cloudformation:DescribeStackEvents",
                "cloudformation:DeleteStack",
                "cloudformation:DescribeChangeSet",
                "cloudformation:ExecuteChangeSet",
                "iam:AttachRolePolicy",
                "iam:CreateRole",
                "iam:DeleteRole",
                "iam:GetRole",
                "iam:UntagRole",
                "iam:ListRoleTags",
                "iam:TagRole",
                "iam:PassRole",
                "iam:DetachRolePolicy",
                "lambda:GetFunction",
                "lambda:CreateFunction",
                "lambda:DeleteFunction",
                "lambda:GetFunctionConfiguration",
                "s3:PutObject",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:cloudformation:((region)):((account-id)):stack/((stack-name))/*",
                "arn:aws:cloudformation:((region)):aws:transform/Serverless-2016-10-31",
                "arn:aws:iam::((account-id)):role/((stack-name))-*",
                "arn:aws:lambda:((region)):((account-id)):function:((stack-name))-*",
                "arn:aws:s3:::((deployment-bucket))/*"
            ]
        }
    ]
}

How to find the least privileges for AWS IAM policies

Sat, 21 Nov 2020 00:00:00 +0000

Context & Approach

An effective approach to finding the least privileges for AWS IAM policies is to use AWS CloudTrail. This page provides a detailed how-to; useful for continuous delivery IAM users.

Approach

Use a programmatic access only user, with full permissions. This is to filter out events that trigger from AWS console interaction.
Deploy your CloudFormation infrastructure using this user from your development machine.

⚠ It takes around 10 minutes for these logs to be shown in the AWS CloudTrail. So take a coffee in the meantime.
Visit AWS CloudTrail console, and limit results to the time period since you started the deployment. This ensures you’re not getting unrelated logs.
Filter by username instead of AWS KEY for immediate results. The AWS Key responds with inconsistent results. The probable cause is the eventual consistency. Waiting some time, it starts showing results with AWS Key as well.
Download all the events as CSV; open said file, and order records by column Event name
Start adding permission using these event names
- As per AWS recommended best practise, limit scope to relevant environments.
  - E.g. arn:aws:cloudformation:us-east-1:000000000000:stack/name-production-stories/*
- Categorise permission based on their logical names. This helps with creating a more logical picture in your mind.
- Use inline policies, and if limit reached, start extracting them to normal policies. Saves some time.
- When you need a specific resource, go back to CloudTrail, find the event name. Expanding said log, the event source should have the data in requestParameters.
As you add the permission, delete the event records from the CSV. This greatly speeds up finding events that haven’t been added yet, as there can be dozens of duplicate events.
Remember to also destroy the stack, to find the relevant access policies.

Finally, while still using your development machine, do a final deployment with a user having the new privileges you added on the previous steps. This catches any missing events not logged in CloudTrail, such as TagResource. And it’s the fastest way to trigger & complete the deployment.

Server Testing CI

Mon, 25 Mar 2019 00:00:00 +0000

Pre-requisite, setup, and tests

You’ve been given the quest to automate the process of maintaining a web server’s configurations.

Redirecting www to non-www pages, http to https pages, and a simple health check.

Completing this quest, rewards you with the automated testing process notifying you when the web server configurations misbehave.

You decide to complete this quest by setting up a Jenkins Pipeline. It will run the server tests, and notify you via emails.

Pre-requisite, setup, and tests
Pre-requisites
Setup Pipeline
Server Tests
Jenkinsfile
Summary

Pre-requisites

Nginx, Jenkins, Docker, Jenkins SSH Credentials, Jenkins Secret text for webhook

Setup Pipeline

You login to your Jenkins server. Create a new item, name it, and select Pipeline type.

[ Jenkins -> New Item -> Pipeline & Name -> OK ]

You now find yourself on the configuration page.

You tick the Discard old builds checkbox, to preserve disk space as your current environment has up to 20GB. You also select 30 days to keep builds, and up to 100 builds to keep.
You tick the Do not allow concurrent builds to maintain good server performance.
You tick the Pipeline speed/durability/override checkbox, and select the Performance-optimized custom pipeline level for fast builds.
You tick the GitHub hook trigger for GITScm polling checkbox. Thus you enable the webhook feature.
You tick the Build periodically checkbox
- You insert H 19 * * * so this piple to be executed daily at ~19:30
You select Pipeline script from SCM, to instruct Jenkins to retrieve the Jenkinsfile from the source control.
- You select Git as SCM, add the repository URL, and select credentials giving jenkins access to this repo.
You finally click Save button to complete the configuration.

Server Tests

Codeception is one of the most popular PHP testing Framework. It provides the ability to test web server configurations.

Since you want to test three configurations, you create three codecept test suites.

For example one of these tests verifies http://jenkins.rdok.dev redirects to https://jenkins.rdok.dev/

public function nonWwwHttpRedirectsToNonWwwHttps(Rdok_devTester $I)
{
    $I->wantToTest('non-www http redirects to non-www https.');
    $I->sendGET('http://jenkins.rdok.dev');
    $I->seeResponseCodeIsRedirection();
    $I->seeHttpHeader('Location', 'https://jenkins.rdok.dev/');
}

Then you create the Jenkinsfile that will execute these three testing suites.

Jenkinsfile

pipeline {
    environment {
        AUTHOR_EMAIL = """${sh(
            returnStdout: true,
            script: 'git show -s --format="%ae" HEAD | sed "s/^ *//;s/ *$//"'
        )}"""
    }
    agent {
        docker {
            image 'codeception/codeception:2.5.2'
            args '''
                --volume="$PWD:/app"
                --workdir=/app
                --entrypoint=''
            '''
        }
    }
    stages {
        stage('code-quests.rdok.dev') {
            steps {
                sh 'codecept run codequests_rdok_dev --no-colors'
            }
        }
        stage('rdok.dev') {
            steps {
                sh 'codecept run rdok_dev --no-colors'
            }
        }
        stage('jenkins.rdok.dev') {
            steps {
                sh 'codecept run jenkins_rdok_dev --no-colors'
            }
        }
    }
    post {
        failure {
            mail (
                to: "${AUTHOR_EMAIL}",
                subject: "❌ ${BUILD_TAG} - Failure",
                body: "Job Url: ${env.JOB_URL}"
            )
        }
        success {
            mail (
                to: "${AUTHOR_EMAIL}",
                subject: "✔ ${BUILD_TAG} - Stable",
                body: "Job Url: ${env.JOB_URL}"
            )
        }
    }
}

Finally, you instruct Jenkinsfile to notify the author of the latest commit with the status of the tests. Initially you planned to use a local mail server, however with the Gmail being quite picky, and blocking the mails, you decided to use Mailgun smtp instead.

Summary

In this quest, you managed to setup a Jenkins Pipeline that:

Executes daily, or through GitHub WebHooks
Jenkins pulling the new code from the GitHub
Jenkins triggering the Pipeline
Pipeline verifying the behavior for each of the different web server configurations.
Pipeline notifying the author of the commit used for testing

Setup Jenkins Pipeline

Wed, 20 Mar 2019 00:00:00 +0000

Pre-requisite, setup, and the nightmare

You’ve been given the code quest to learn how to setup a simple Jenkins automation.

Completing this quest, rewards you with the automated release process of your jekyll based blog post, in under 10 seconds.

You decide to complete this quest by setting up a Jenkins Pipeline.

Pre-requisite Software

Jenkins
Docker
Jenkins SSH Credentials
Jenkins Secret text for webhook

Setup Pipeline

You log in to your Jenkins server. Create a new item, name it, and select Pipeline type.

[ Jenkins -> New Item -> Pipeline & Name -> OK]

You now find yourself on the configuration page.

You tick the Discard old builds checkbox, to preserve disk space as your current environment has up to 20GB. You also select 30 days to keep builds, and up to 100 builds to keep.
You tick the Do not allow concurrent builds to maintain good server performance.
You tick the Pipeline speed/durability/override checkbox, and select the Performance-optimized custom pipeline level for fast builds.
You tick the GitHub hook trigger for GITScm polling checkbox. Thus you enable the webhook feature.
You select Pipeline script from SCM, to instruct Jenkins to retrieve the Jenkinsfile from the source control.
- You select Git as SCM, add the repository URL, and select credentials giving jenkins access to this repo.
You finally click Save button to complete the configuration.

The Nightmare

Creating the Jenkinsfile to work with jekyll Docker image turned out to be a nightmare.

Jenkins uses the jenkin user, but the docker image uses jekyll user. Which is a problem because the jekyll user does not have permission to write to the Jenkins workspace. Meaning you cannot use the jekyll gem to build the site.

You manage to solve this problem by changing the ownership of the site in the working space to jekyll.

In order to be able to change the ownership you instruct docker to use the root user. Normally docker image uses root by default, however jekyll/minimal uses jekyll user instead.

After jekyll builds the site, you change the ownership of the site back to jenkins:www-data.

With this work you manage to create the following Jenkinsfile.

Jenkinsfile

pipeline {
    environment {
        SITE_PATH = '/var/www/your-domain/_site'
        JENKINS_UID = 113
        WWW_DATA_GID = 33
        JEKYLL_SID = 1000
        JEKYLL_GID = 1000
    }
    agent any
    stages {
        stage('Build') {
            agent {
                docker {
                    image 'jekyll/minimal:3.8'
                    args '''
                        --volume="$PWD:/srv/jekyll"
                        -u root:root
                    '''
                }
            }
            steps {
                sh '''
                    rm -rf _site && mkdir _site
                    chown -R $JEKYLL_SID:$JEKYLL_GID _site
                    jekyll build
                    chown -R $JENKINS_UID:$WWW_DATA_GID _site
                '''
            }
        }
        stage('Deploy') {
            agent any
            steps {
                sh '''
                    rm -rf ${SITE_PATH}
                    mv -T _site ${SITE_PATH}
                '''
            }
        }
    }
}

Summary

In this quest, you managed to setup a Jenkins Pipeline that:

Starts with you pushing a git commit to GitHub
GitHub doing a POST request to our Jenkins server
Jenkins pulling the new code from the GitHub
Jenkins triggering the Pipeline
Pipeline building the project
Pipeline deploying the project

By configuring the pipeline to be highly efficient, you managed to bring down the build & deploy process to 10 seconds.

Install browser extension in codeception

Sun, 14 May 2017 00:00:00 +0100

Problem, Solution, Implementation & Showcase

We need to run browser UI tests with codeception. However these test are features requiring browser extensions. At this time there is no clear documentation for enabling said extensions on codeception with selenium.

In summary, we need for the codeception to install browse extenion(s) when it initializes browsers.

The Solution

In order to install a chrome extension we need to get it’s source code from the Chrome store, and load it through a yaml configuration file in codeception.

Similarly for firefox, we just need to extract the extension (xpi). However, the geckodriver does not accept arguments like chrome above for loading an extension. Also loading a firefox_profile does not currently work [source_here]. As such we’ll need to build a codeception module, and load the extension there.

The Implementation

You can find a solid template installing extension in codeception at our repo rdok/installing-browser-extension-in-codeception This repo also contains installation scripts which will autodownload all required files for our tests: selenium-server-standalone.jar, chromedriver, geckodriver, as well as the two extensions we install. When executing the composer install command.

If you already know setting up codeception and environements, feel free to skip the rest of the blog and just check the above repository.

Following are descriptions of what I believe to be the major difficulties when instructing codeception to install browser extensions.

Install chrome extension

Download the extension you are interested in. Here’s the way we do it on repo.

adBlockerFile="./tests/_data/adBlock"
adBlockerId=gighmmpiobklfepjocnamgkkbiglidom
mkdir -p $adBlockerFile

wget "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$adBlockerId%26uc" -O "$adBlockerId.zip"
unzip -d $adBlockerFile "$adBlockerId.zip"
rm  -f $adBlockerId.zip

Instruct codeception to add arguments to load the extension directory when initializing the chrome driver.

modules:
  enabled:
      - \Helper\ChromeHelper
  config:
      \Helper\ChromeHelper:
          browser: 'chrome'
          url: 'http://www.detectadblock.com/'
          capabilities:
              chromeOptions:
                  args:
                    - 'load-extension=tests/_data/adBlock'

\Helper\Chrome is a custom codeception module extending the WebDriver module. It is a workaround for an issue with firefox to open a new tab, rather a new window.

Install Firefox Extension

Download the extension you are interested in. Here’s the way we do it in our repo.

wget "https://addons.mozilla.org/firefox/downloads/latest/adblock-plus/addon-1865-latest.xpi" -O "adblocker.xpi"

Instruct codeception to load our own custom FirefoxHelper.

modules:
  enabled:
      - \Helper\FirefoxHelper
  config:
      \Helper\FirefoxHelper:
          browser: 'firefox'
          url: 'http://www.detectadblock.com/'

Currently loading a firefox profile, does not work in codeception. This issue seems to be have been persisted from 2016 Firefox Profile Not Working Properly for Selenium Webdriver #2690

As such, we override the codeception’s initialization of the WebDriver command with our own custom FirefoxHelper:

    public function _initialize()
    {
        parent::_initialize();
        $profile = new FirefoxProfile();
        $profile->addExtension('tests/_data/adblock-plus.xpi');
        $capabilities = DesiredCapabilities::firefox();
        $capabilities->setCapability(FirefoxDriver::PROFILE, $profile);
        $this->capabilities = $capabilities;
    }

Conclusion

The browser installation scripts are quite handy, as every time we execute the composer install command it will upgrade the browser extension. Thus we do not need to manually redownload them in the log term future.
I might setup a docker in the future. This should make the development independent. As it is now, the repo can test drived only by Linux OS Desktops.

Finally, here’s the overall steps you’ll need to take for setting up the repo in your Linux Desktop

git clone https://github.com/rdok/installing-browser-extension-in-codeception
cd installing-browser-extension-in-codeception
composer install
java -jar selenium-server-standalone*
./vendor/bin/codecept run --env chrome
./vendor/bin/codecept run --env firefox

Do not Expect Jobs

Mon, 08 May 2017 00:00:00 +0100

The Problem

Usually on tests where jobs are dispatched the Laravel would throw some kind of exceptions. In order to fix that I would add $this->expectsJobs(SampleJob::class); to the relevant test

And on tests where jobs were not expected to be dispatched, the Laravel would not throw the mentioned
exception.

However, there are some cases, we need to be absolutely sure no job occur. Especially, since Laravel 5.1 there has been instance in which it does not throw the previously mentioned example.

We have to be sure Laravel is not dispatching any Job, or else it would send thousands of invalid emails, as well as spending a lot credits of our account at our email service provider.

In summary, we need an unit test assertion, validating no job is dispatched.

The Solution

Laravel already has an expectsJobs We’ll modify this to feet our need, and insert it to our TestCase.

    private function doesntExpectJobs()
    {
        $mock = Mockery::mock('Illuminate\Bus\Dispatcher[dispatch]', [$this->app]);

        $mock->shouldReceive('dispatch')->never();

        $this->app->instance('Illuminate\Contracts\Bus\Dispatcher', $mock);

        return $this;
    }

The Implementation

The source code is located here
And the expected failing and expected passing tests.

Conclusion

This above code snippet is useful for Laravel 5.1 LTS.

On the other hand the latest version of Laravel (5.4+), has already the above implementation.

Send Daily Transactional Emails

Mon, 01 May 2017 00:00:00 +0100

The Problem

The system needs to send daily emails to its users according to some complex criteria. How do we implement this?

The Solution

The cron job hits daily our system. At such time, the system will call the handler method of the Daily Notification Layer.

The Implementation

The Daily Notification Layer acts as the traffic controller. It controls uses three other layers of the system:

Daily Favorite Shop Notification fetcher. At this layer, the shops are filtered by the required criteria.
Daily Favorite Shop View generator. Generates responsive email view.
Email Api sender. Sends the emails.

Conclusion

The Daily Notification Layer retrieves all the shops, for which it needs to notify users about daily changed. For each of this shops, it generates the relevant email view from the Daily Favorite Shop View generator. Finally, it sends to all interested users, this email view.