DEV Community: Segun Olaiya

Feature testing with PHPUnit and things to avoid

Segun Olaiya — Thu, 06 Jun 2024 09:45:33 +0000

I’ve had the opportunity to see many feature tests in PhpUnit that lack the fundamentals of a proper Unit test. We will discuss how to write tests properly and ensure that our tests are valuable. Before we begin, if you are unfamiliar with PHPUnit or Testing as a concept no worries, I’ll give a brief background.

In today’s changing world, where we have embraced a continuous delivery and integration of our services and products, they often change frequently. Whether changed by the original author/maintainer, or by someone else. It is therefore imperative that we have some kind of safety, some tests that ensure that the behaviour of the service remains the same except intentionally modified.

But there are different types of tests, Unit Tests, Feature Tests, Integration Tests, Performance Tests and so on. In this post, I want to focus on how we should write Feature tests the right way.
Feature tests are types of tests that validate different variations of a feature. Feature tests ensure that users see and experience what you want them to experience. I believe feature tests can also qualify as integration tests.

Always make sure your tests are independent of each other

let's take a scenario, where a user will call a simple get endpoint that would be handled by a service. Take a look at the test below:

    class OrderServiceTest extends TestCase
    {
        private $user = null;
        private $service = null;

        public static function setupBeforeClass(): void
        {
          $this->user = User::factory()->create([
                  'permissions' => []
          ]);
          $this->service = new OrderService($this->user);
        }

        public function test_get_order_service_throws_when_user_does_not_have_access()
        {
            $this->expectException(UnauthorizedException::class);
            $this->service->get();
        }
    }

As you can see, in the setupBeforeClass( ) we are instatiating the service which depends on the $user.

When you have just 1 test in this file, this is fine, however, this becomes a bad idea when you have multiple tests. The given test does not control the instatiation of the service. Therefore it is possible for other tests to modify the $this->user or $this->service while this test is running.

Also, this test does not paint the full picture of an actual user journey when they try to call the order get endpoint. So to decouple the test we can have something like this:

    public function test_get_order_service_throws_when_user_does_not_have_access()
    {
        $user = User::factory()->create([
                'permissions' => []
        ]);
        $service = new OrderService($this->user);
        $this->expectException(UnauthorizedException::class);
        $service->get();
    }

As you can see, the test now has the complete setup of what it needs before its assertions. This test does not depend on anything else and is easy to understand what needs to exist before this exception can be thrown.

Note that this does not mean that using setupBeforeClass( ) is bad, we can always setup things that the entire tests generally need and is guaranteed to be needed in exactly the same way like an instance of a mock.

Do not test too many things at once

When we have a complex feature that does a number of things. We can easily write 1 test that handles many assertions, this makes it feel like that singular test will cover all the scenarios. - Don’t do this.

Having atomic tests that focus on a single flow with a couple of assertions is more valuable and easier to understand by others.

Typically, the easiest way to divide a huge feature/method to multiple independent tests is to think about all the code paths, if statements, exceptions, and external service calls and try to test them in each test.

Note that the combination of all these tests eventually still gives you a full feature test.

Only Mock 3rd Party services

Mocking is a process used in testing when the feature being tested has external dependencies. The purpose of mocking is to isolate and focus on the code being tested and not on the behaviour or state of external dependencies.

We should only be mocking 3rd party services in our tests, 3rd party services are external systems like APIs or SDKs that are been used in the test. These tools are what we do not have control over, hence needs mocking.

Avoid mocking the Database, other methods in the application and so on. This is important because again, we are writing a feature test and not a unit test.

Avoid Huge test files

I know this may be subjective, but it is actually good for our future selves. Imagine having a failing feature test and having to look for the test in a 4K lines of code and wondering if the test is failing because of some flaky test above or below it.

If you have a major feature you can create a folder just for that feature and have different test files which would have similar test scenarios in them and are grouped together. This way - when such a scenario needs to change, it would be very clear which test needs to be included, modified or deleted in context.

Avoid tests using other features to Setup

Tests typically follow the GIVEN-WHEN-THEN approach. It is always easy to see the context given to a test in the first few lines (typically considered setup) for that test.

Setup should be as basic and direct as possible. Do not use other service methods to do a setup, just because the internal implementation for that service is doing the same expected setup that is needed.

The obvious reason for this is still related ot independence, your test should be as independent as possible without been at risk of failing just because a completely unrelated feature was modified. If you have to insert records to the database to set some context, do not use a register( ) method for example even though it does the same insert as you expect. You should always cary out all the setup manually without calling existing methods.

Avoid Logic / Code Complexities in your assertions

When you have to do assertions that may be alot, lets say asserting that an array in a particular order, it is always a good idea to do this manually. Take a look at the set of assertions below:


    $this->assertEquals('One', $reponse[0]);
    $this->assertEquals('Two', $reponse[1]);
    $this->assertEquals('Three', $reponse[2]);

It is very easy to see things like this and say, Oh, I can just do a foreach( ) and have 1 $this->assertEquals( ) . Avoid that. This is because you don’t want your test carrying unnecessary logic when it should just focus on behaving as the user and as close to that as possible.
Tests have to be clear, it needs to be as clean, simple and straightforward as possible.

Do not expose private properties as public just because of the tests

When a class has private properties and you do like to validate their state in a give test, avoid setting them as public. Create a getter instead.

Infact, often times, these kind of properties can be implicity tested, for example, if the value of such property is eventually going to be written to the database, then you can check the database.
When the feature itself is been highly modified just because of the tests, you should already know that something is not right.

In conclusion, feature tests should always focus on ensuring that the feature is used right, it should be as simple, independent and straightforward as possible.

I tried to json_decode a string in scientific notation

Segun Olaiya — Sun, 11 Feb 2024 19:29:28 +0000

I spent 6 hours trying to work on a bug ticket assigned to me. It turns out the code has been trying to json_decode a floating-point number in scientific notation.

Okay, let me give some context, we have this method somewhere in a Utils.php file:

function is_value_empty($value): bool {
    $value = json_decode($value ?: '');
    if (!is_array($value)) {
        return empty($value);
    }

    $has_non_empty_value = false;
    foreach ($value as $row) {
        if ($has_non_empty_value) {
            break;
        }

        $has_non_empty_value = !empty($row);
    }

    return !$has_non_empty_value;
}

The job of this method, in the context that it is been used, is to check if the $value passed is empty. But it also needs to check the following:

if [] is passed, it needs to return true
If ['', ''] is passed it still needs to return true.
If a JSON encoded array with falsy values is passed it still needs to return true

Now the issue we were facing was that a certain user was trying to validate if 0E86023 was empty or not.

As you can see, the first thing this method does is to attempt a json_decode( ). It then checks if it successfully decodes the value. If the decoded value is not an array, it simply use the php empty( ) method and that's it.

The issue with 0E86023 or any floating-point number is that, if this expresssion is executed:

json_decode('0E86023')

We would get a floating point response from php as 0.0

Psy Shell v0.11.22 (PHP 7.4.33 — cli) by Justin Hileman
> json_decode('0E86023')
= 0.0

>

But this number might look like its exactly 0.0. But its not, its a number very very close to zero but not exactly zero. Therefore checking empty(json_decode('0E86023')) would return false.

This is why this method has been failing for the user and they have not been able to update their information with a value like 0E86023.

For a quick fix, I added a simple if statement on top of the method like so:

function is_value_empty($value): bool {
    if (is_numeric($value)) {
        return false;
    }

    $value = json_decode($value ?: '');
    if (!is_array($value)) {
        return empty($value);
    }

    $has_non_empty_value = false;
    foreach ($value as $row) {
        if ($has_non_empty_value) {
            break;
        }

        $has_non_empty_value = !empty($row);
    }

    return !$has_non_empty_value;
}

It's interesting that this happened in a case where thousands of other records are been successfully updated but this particular user kept complaining that they could not use the feature.

So yea, not sure which is weird, json_decode( ) or empty( )

Use same Dockerfile for Dev & Production

Segun Olaiya — Thu, 08 Feb 2024 12:02:18 +0000

In many projects that are containerized, especially in cases where development is also done locally with docker-compose, teams often have two Dockerfiles, 1 for Development, the other for Production. If you happen to have multiple environments like pre-prod, staging and so on, some teams could have different Dockerfiles for these environments.

docker build has a very nice --target option, that could be used to target a specific stage from the Dockerfile.

Let's take a very simple example: let's say we are trying to build a simple frontend app with npm, on Development, we start the app with npm run dev but on production, we need to run npm run generate and then copy the artefacts to Nginx's html folder to run, we would need to have a Dockerfile as below for Development:

FROM node:18-alpine
WORKDIR /usr/src
COPY ./package.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "dev"]
EXPOSE 3000

This is simply a Dockerfile that starts a frontend app with npm run dev exposing port 3000.

However, we typically do not run npm run dev on production, extra steps are required to generate the static files from the application and then these files are served by nginx or any other webserver.

To write the production Dockerfile for this app, we need to build the app and also serve with the desired web server.

Docker Multi-Stage builds

Docker multi-stage builds allows us to use multiple FROM commands in a single Dockerfile, it allows us to selectively copy files from different stages into another.

For our case, we need a base, dev, build and prod stages, we are going to build our app for production with npm run generate and we need to serve the built files with nginx. Our production Dockerfile will therefore look like this:

FROM node:18-alpine AS build
WORKDIR /usr/src
COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run generate

FROM nginx:1.25.1-alpine
COPY --from=build /usr/src/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Notice the AS build on the first stage, all commands before any other FROM is considered a stage on their own.

After running npm run generate in the app, it generates files into /usr/src/dist.

In the second stage, where we are basing that on nginx, we simply copy those files from the build stage using

COPY --from=build /usr/src/dist /usr/share/nginx/html

Updating this Dockerfile to serve both Dev and Production

Now that we have seen multi-stage docker builds in action, we can leverage this by having a base stage, build stage and finally a prod stage.

To achieve this we update the docker file to this:

FROM node:18-alpine as base
WORKDIR /usr/src
COPY ./package.json ./
RUN npm install
COPY . .

FROM base AS dev
EXPOSE  3000
CMD ["npm", "run", "dev"]

FROM base AS build
RUN npm run build

FROM nginx:1.25.1-alpine as prod
COPY --from=build /usr/src/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

There are 4 stages in this docker file.

The `base` stage

In this stage, we build the base image, copying the files from the project and simply doing npm install

The `dev` stage

This is the stage that we want to target if we are building this image for dev. More on how to do this in a bit.

The `build` stage

This stage exists so that the prod stage would be able to copy the generated static files for serving.

The `prod` stage

This is the stage that we would target when building this image for production.

How to target a `stage` in Dockerfile

Finally, now that we have a Dockerfile that can serve dev and production, to build an image that is specific for dev, we use the --target argument as so:

docker build -t mutistage:latest --target=dev

This would make Docker only build up till the dev stage and nothing else.

Similarly to build for production we simply do

docker build -t mutistage:latest --target=prod

With this, we can maintain the same file for these two environments.

Strive to make it Simple

Segun Olaiya — Fri, 12 Jan 2024 13:10:00 +0000

When it comes to Software Engineering, simplicity remains the ultimate sophistication. It has become really important that we emphasize the importance of writing really simple Code. I'm not sure if this post will be a rant, or a call to wake you up, but we'll see about that.

What does it even mean for a piece of software to be implemented with simplicity in mind? What is even considered complexity in an implementation? - Well, I'm not exactly talking about time complexity here, nor am I talking about using tools that have the least possible configuration. I'm talking about thinking simple, thinking with the customer in mind, and thinking with an assumption that your future self might not be that smart.

Simplicity is the art of implementing software with the least possible ambiguity. It is thinking in first principles before anything else. It is attempting to take time to think things through before raising that PR with 6 new npm packages. It is avoiding those confusing smart lines of code, and ultimately writing a maintainable, testable piece of software.

Understanding the Problem you are trying to solve is the first, non-negotiable step in this journey. More often than not, I've seen engineers attempt to start implementing a ticket without fully understanding the ask, and how that ask affects their customers, their future self, or even the codebase at large. Furthermore, understanding involves narrowing the scope of the ask. Always start small, as small as possible, and walk your way up.

Writing simple code comes with detachment from the codebase, oftentimes, I have seen engineers attached to their classes, functions, or whatever. It becomes difficult for them to delete code, refactor a method, or even rename a file. If you are one of those people, please understand that your customers don't care.

The art of simplicity encourages you to actively review previous implementations, taking time to refactor them if you have to, increasing the test coverage in your spare time, or even question your thought process a few months ago. Be bold to remove dead code!

This is 2024, and we now have AI companions, I challenge you today to embrace this reality, whenever you are trying to solve a technical problem, refactoring a piece of code, or adding extra logic to an existing class, and you have this inner voice saying I'm making this way more complex than it should be - please take time to ask an AI companion what it would do, ask it to make it simpler, review its options and expose yourself to more possibilities.

Unfortunately, the technologies, tools, and developer experience products that are most popular today sometimes encourage the most frustrating complexities I can think of. Ask questions, and take time to research alternatives to tools whenever you get a vibe that it's looking way more complex than it should be.

Simplicity is not just about not confusing yourself today. It's about not confusing yourself tomorrow too. There is no honor in frustrating the next engineer joining your team, and the excuse of time is not acceptable, thinking is the hard part, and in my opinion, clear concise consistent thinking is what makes a solid engineer. Avoid the trap of taking the easy way out.

I do not want to mention any technology or give any code examples for a good reason. The first step after reading this for anyone interested is to take time to research and review their past work, and the work of others and evaluate how they can simplify it.

Let me be also clear, simplicity does not imply premature refactoring, enforcing DRY everywhere, or always giving the longest variable or method names. No no, I'm more interested in awakening your thought process and how you take time to think about technical problems first before attempting them.

For not-so-experienced engineers, please read a lot more code, that is how you find patterns and gain insights into the minds of other experienced engineers.

I hope that I've left the world simpler than I met it.

Well, sounds more like a rant, but you get the point.

MySQL: Searching multiple columns at once without LIKE

Segun Olaiya — Mon, 23 Jan 2023 13:26:46 +0000

Have you ever had reason to search across multiple columns at the same time in MySQL? Maybe while responding to a data-table search from the frontend? - Yea me too.

You or your ORM probably generate a query like this:

SELECT
    *
FROM `addresses`
WHERE `address_line_1` LIKE "%NY%"
    OR `address_line_2` LIKE "%NY%"
    OR `city` LIKE "%NY%"
    OR `street_name` LIKE "%NY%"

And then when you have reason to add another condition, such that it has to apply to the query separate from the search conditions, you do have to come up with something like this:

SELECT
    *
FROM `addresses`
WHERE `customer_id` = 1
AND (
    `address_line_1` LIKE "%NY%"
    OR `address_line_2` LIKE "%NY%"
    OR `city` LIKE "%NY%"
    OR `street_name` LIKE "%NY%"
)

The more you update the query, adding joins for example and wanting to also include some columns from the join into the searchable fields, the more this query gets complicated.

Using MySQL LOCATE function

Mysql provides a function called LOCATE - This function returns the position of the first occurrence of a given substring. You can checkout other string functions such as POSITION.

With the LOCATE function, we can cleanup the first query to look something like this:

SELECT
    *
FROM `addresses`
WHERE LOCATE('NY', `address_line_1`) > 0
    OR LOCATE('NY', `address_line_2`) > 0
    OR LOCATE('NY', `city`) > 0
    OR LOCATE('NY', `street_name`) > 0
    OR LOCATE('NY', `street_name`) > 0

The LOCATE function returns the position of the first occurence of the string, in this case NY. And it is case-insensitive.

You are going to say... Well that ain't much of a difference is that?

Simplyfing with Mysql CONCAT_WS

Now the juicy part 😍 - CONCAT_WS

The MySQL CONCAT_WS is a variant of the CONCAT function but can accept a separator. So take for example, to return the full address as a column from our addresses table, we can have a query like this:

SELECT
    CONCAT_WS(' ', `address_line_1`, `address_line_2`, `city`, `street_name`, `street_name`) AS `full_address`
FROM `addresses`

Combining the power of CONCAT_WS and LOCATE we can have a relatively easy search without using a LIKE. Our previous example will then look somewhat like this:

SELECT
    *
FROM `addresses`
WHERE LOCATE('NY', CONCAT_WS(' ', `address_line_1`, `address_line_2`, `city`, `street_name`, `street_name`)) > 0

With this approach, you can add or remove columns that are searchable really easy. Infact you could make it dynamic by accepting searchable columns from your frontend or API.

On performance, the LOCATE method is also slightly performant compared to the LIKE.

Let me know what you think on this approach!

Deploying a Laravel App on AWS App Runner

Segun Olaiya — Tue, 17 Jan 2023 10:21:22 +0000

Deploying a containerized app gets easier everyday as cloud providers release new products. One of such products by AWS is AWS App Runner.

AWS App Runner is a fully managed container application service that lets you build, deploy, and run containerized web applications and API services without prior infrastructure or container experience.

Ever want to just deploy an app without the Kubernetes or complex networking overhead? Or have a couple of services to maintain without alot of configuration? - Try AWS App Runner. Read more Here

Following this tutorial

For ease of following this tutorial, I have created a default Laravel app with all the files referenced in this post. Click Here to view the public github repo.

Dockerizing Laravel

Let's start with a Docker file. In this post, I will be using php7.4. In the root of your Laravel application, create a Dockerfile. See example Here

Other deployment related files

If you look at the contents of the Dockerfile above, /app/deploy folder was referenced. This folder contains files for nginx, superiviser and a run script that would start the laravel app. Click here to copy the contents of this folder to your local Laravel app.

Build and run your image

To ensure your docker image works locally, run docker build . to build your image.

When this builds successfully, you can find your image when you execute docker images on your cli.

Since the docker image exposes port 80, you can test your image by running:


 run -p 8000:80 <image id>

(Ensure you pass valid database credentials or modify .env.example with reachable database credentials)

Setting up AWS App Runner

Now let's setup AWS App Runner. First of, AWS App Runner has an automatic deployment option, what this means is that, once our docker repository changes, our app automatically deploys. This is one of the simplicity that makes this product easy to use.

AWS Elastic Container Registry

Since we want to automate the entire process, we would be pushing our image automatically to AWS Elastic Container Registry.

If you don't have an existing repository for your app, go ahead and create one. I will be creating a repository called laravel-aws-app-runner

Take note of the URI, we would need it later.

Setting up Github Actions

For us to automatically build our images and push to ECR from Github we would be using Github Actions

Let's start by adding 2 secrets to our Github repo, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. These two values would be used by the actions to access AWS. Ensure you set your AWS credentials that has access to the ECR you just created.

In your repo, create a Github actions file /.github/production.yml just like this

Take note of the ECR_REPOSITORY key, update the value to the name of the repository you created in ECR.

The Github actions tries to checkout the code, login to AWS, build the image and then push it up to the ECR repository.

Note that it also runs only when there is changes to master, feel free to change this configuration if you want a different branch.

You may push an empty commit to master to trigger your actions if it has not already been triggered. On your Actions tab, you should see a successful Github Actions run.

Creating an AWS App Runner Service

Finally, we have our image pushed to ECR, a Github action to update the image when we merge to master, we can now create a service on App runner that would automatically listen for changes on ECR and update our App.

On AWS, search for AWS App Runner and click on Create Service

If AWS App runner is not available in your preferred region, you may consider using a different region where this product is available.

In the Source and Deployment Select Container Registry and Amazon ECR as the provider. Choose the correct repository in the list and the default tag is latest according to our Github actions configuration.

As you can see, it is actually possible to reference a different docker repository outside of AWS ECR.

In Deployment settings, select Automatic - This is very important, with automatic, when our ECR image changes, the service will automatically be deployed.

If you already have a service role, feel free to choose one of them, other than that you can simply select Create a new service role

Then click on Next.

On the Service settings, this is where we configure Environment variables, the CPU & RAM of the service, and the port exposed by the Docker image.

Add all the env and values for your service, set the port to 80 (Except the Docker file port has been updated). Feel free to change the virtual CPU to 2vCPU, for now i'll leave the default.

I generally leave the Auto Scaling, Health Check Security, Observability and Tags tabs with the default configuration from AWS, but if you are an experienced AWS user and want custom configuration, feel free to modify these tabs to what you want.

For networking, which is quite important for your service to have access to other resources on your VPC. Your incoming network traffic has to stay as public endpoint if not your service would not be available on the internet.

If you would like to change your outgoing access, feel free to do that, but for now, i'll leave both with the defaults.

One major reason you may change your outgoing access later is because of your database connections as it would most likely be behind a security group in a custom VPC.

Now that we have all the configurations (mostly all defaults 🙈) We can now go ahead to create & Deploy the service.

After successful deployment, you should have a running service as displayed above.

Handling failed deployment

Just incase your deployment fails, you can view the application logs in Cloudwatch to know what the issue is

Once you see the log and figure out what the issue is from the Image, you can delete the failed service and create a new service.

Automatic deployments

Now that we have a running service, every time you push to your master branch and Github actions run, the ECR image would be updated and AWS App runner will automatically deploy the app.

Custom Domains

Obviously you may want to add Custom domain to your service and not use the default AWS domain. You can do that on the Custom Domains tab. Simply follow the instructions.

Conclusion

Once you get a hang of creating services and setting up Github actions to update the ECR Images, you can pretty much do anything you like such as even having Staging environments.

AWS App runner is quite straightforward and eliminates setting up your own ServerLess environment from ground up. And since our applications are containerized, you can pretty much switch to another platform in the future if you have too.

Image or File Uploads in Adonis.js with Cloudinary

Segun Olaiya — Tue, 06 Aug 2019 13:53:45 +0000

I just started working with adonis JS a little over 2 months now. I recently have to use Cloudinary in my project and i searched for the best way to loosely use it so as to maintain the readable, expressive and approachable structure of Adonis.

This tutorial assumes you are already familiar with Adonis and Cloudinary. I will explain my approach in steps below. So let's get Started!

Step 1: Create a new AdonisJS project

Run

adonis new cloudinary-integration

to create a new adonis project. You should get a fresh adonis project (as at the writing of this post, i'm using version 4.1)

Step 2: Setup an upload controller

Create a new HTTP controller by running

adonis make:controller Upload --type http

and setup a simple index method as shown below


'use strict'

class UploadController {

    async index ({ request, response }) {

        return response.json({status: true, data: 'It Works '})
    }
}

module.exports = UploadController

And of cause update the /start/routes.js by adding a new route

'use strict'

const Route = use('Route')

Route.on('/').render('welcome')

//Add this Route
Route.get('/upload', 'UploadController.index')

Step 3: Implementing Cloudinary

At this point, if you do not have a cloudinary account, head over to https://cloudinary.com to create a free account. We would need three major environment variables from cloudinary.

CLOUDINARY_CLOUD_NAME
CLOUDINARY_API_KEY
CLOUDINARY_API_SECRET

Update your .env file to have these three environment variables. See Screenshot below on where to get them from your cloudinary console.

So your .env file will now look somewhat like this

HOST=127.0.0.1
PORT=3333
NODE_ENV=development
APP_URL=http://${HOST}:${PORT}
CACHE_VIEWS=false
APP_KEY=iBRP92LhBPRKh0rTIcIo2OuyQNbWCY6C
DB_CONNECTION=sqlite
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=root
DB_PASSWORD=
DB_DATABASE=adonis
SESSION_DRIVER=cookie
HASH_DRIVER=bcrypt

#Cloudinary Credentials
CLOUDINARY_CLOUD_NAME=your_cloudinary_cloud_name
CLOUDINARY_API_KEY=your_cloudinary_api_key
CLOUDINARY_API_SECRET=your_cloudinary_api_secret

Next, Let's pull in the cloudinary JS SDK from npm (or yarn).

npm i cloudinary --save

Then, create a file /app/Services/Cloudinary.js with the following code snippet.

'use strict'

const cloudinary = use('cloudinary')
const Env = use('Env')

cloudinary.config({

    cloud_name: Env.get('CLOUDINARY_CLOUD_NAME'),
    api_key: Env.get('CLOUDINARY_API_KEY'),
    api_secret: Env.get('CLOUDINARY_API_SECRET'),
})

module.exports = {

    upload: async (file) => {

        return new Promise(async (resolve, reject) => {

            try{

                let response = await cloudinary.uploader.upload(file.tmpPath, { folder: 'test'})

                resolve({status: true, url: response.secure_url })

            }catch(error){

                reject({status: false, url: error.message })
            }
        })
    }
}

We are returning a promise from an async function called upload which we would be passing a file object to.

Step 4: Using the cloudinary Service

Now that we have our Cloudinary service setup. lets create a method in our app/Http/Controllers/UploadController.js to handle uploads.

Our UploadController.js will now look like this

'use strict'

//Import Cloudinary
const Cloudinary = use('App/Services/Cloudinary')

class UploadController {

    async index ({ request, response }) {

        return response.json({status: true, data: 'It Works '})
    }

    async upload ({ request, response }) {

        //TODO: Validate. Input.

        try{

            if(request.file('image')){

                let cloudinary_response = await Cloudinary.upload(request.file('image'))

                return response.json(cloudinary_response)
            }

            return response.json({status: false, data: 'Please upload an Image.'})

        }catch(error){

            //console.log(error)
            return response.status(500).json({status: false, error: error.message })
        }

    }
}

module.exports = UploadController

one more thing, lets add a route to our new method. Our routes file will now look like so

'use strict'

const Route = use('Route')

Route.on('/').render('welcome')

//Add this Route
Route.get('/upload', 'UploadController.index')
Route.post('/upload', 'UploadController.upload')

Step 5: Testing from Postman

For the purpose of testing, we do not want to use the CSRF protection for now. So in your /config/shield.js Update the csrf key as below so has to exclude the /upload route

csrf: {
    enable: true,
    methods: ['POST', 'PUT', 'DELETE'],
    filterUris: ['/upload'],
    cookieOptions: {
      httpOnly: false,
      sameSite: true,
      path: '/',
      maxAge: 7200
    }
  }

Now to test our upload route and be sure our implementation is working as expected. Try uploading a file from postman as shown below

You should be able to see your newly uploaded file from your cloudinary media library.

That's all folks!

Deploying Node/Express app on a Windows Server

Segun Olaiya — Wed, 03 Jul 2019 14:14:10 +0000

I had this small side project I worked on for a client over a weekend, it was a simple express API.
Everything worked well and good until it was time to deploy! This was my conversation with the client..

Me: Cool so the app is ready, can you send me your staging server details so i can deploy for you?
Client: Yea cool, i will send you an RDP credentials to our Windows VM
Me: Wait what?

Ok jokes apart, lets get straight into it!

Before we continue, you should have a basic knowledge of Setting up a simple Express App and using Nodemon or any other Node Process manager.

To speed things up, i have setup a simple express app with a single endpoint for this demo, please note that the target is not necessarily an introduction to Express but how to deploy an Express based app on Windows.

massivebrains / express-demo

An Express Demo App

express-demo

An Express Demo App

View on GitHub

You can clone the repo to follow along.

Setup the express app on the server

If you are using the sample app that was cloned, run yarn and then yarn start . The app should now start with nodemon. Assuming you have not changed the default port, head over to your browser at http://localhost:3000 . you should see the sample json response as below

{
  status: true,
  data: "Api Works"
}

Setting up a proxy with IIS

Now the app is running locally but not available outside the server. What we want is for the public to be able to reach the app at http://yourdomain.com/app where http://yourdomain.com is our domain.

Step 1

Search and open Internet Information Services (IIS)

Step 2

Expand Sites -> Default Web Site

Right click on Default Web Site and select Add Application

Adding a URL rewrite

Make sure the newly created app is selected under the Default Web Site, click on URL Rewrite from the IIS dashboard on the right.

On the right, click on Add Rule(s) and then select Reverse Proxy

On the inbound rules dialogue box, enter localhost:3000 as illustrated below.

If you changed the port number where the express app is currently running, make sure you use localhost:{port_number}

Click on OK after this.

Now head over to a browser (outside your server) and try to access http://yourdomain.com/api (where http://yourdomain.com) is your actual domain name.

Single Method Controllers in Laravel

Segun Olaiya — Tue, 02 Jul 2019 07:39:16 +0000

We all agree that methods and function should do one thing only. We call this Single Responsibility Principle.

However, the fact that methods should follow SRP does not imply that we should have a controller housing many (almost) independent methods which would result in a very unstructured business logic.

Having a single method controller is a fantastic way of upholding the Single Responsibility Principle. For example, take a look at the controller below

namespace App\Http\Controllers\Api;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
use App\Plan;

class PlansController extends Controller
{
    public function index()
    {
        //Logic to Get All Plans
    }

    public function create(Request $request)
    {
        //Logic to create new Plan
    }


    public function inviteUser(Request $request)
    {
        //Logic to invite user to plan
    }
}

The first thought that would come to mind is that the inviteUser method does not belong to this controller. We should have something like InviteUserController. And that is absolutely what we should do.

From the name of this controller, it is expected to do one thing only - Invite a user to a specific plan.

So we can simply have something like

namespace App\Http\Controllers\Api;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class InviteUserController extends Controller
{

    public function inviteUser(Request $request)
    {
        //Logic to invite user to plan
    }
}

and we should be done right? - Well how about if this could be done better? - Introducing Magic Method __invoke :)

PHP has several Magic methods. Magic methods are named with two underscores at the start, which get called automatically when a particular event happens.

The __invoke() method gets called when the object is called as a function. When you declare it, you say which arguments it should expect. Here's a trivially simple example:

class Human {

  public function __invoke() {

    echo "Sophisticated creature";
  }
}

We can instantiate a Human object, and then just use it like a function:

$victor = new Human();
$victor(); // Sophisticated creature

With this understanding, we can simply rename the inviteUser method of the InviteUserController to __invoke as seen below

namespace App\Http\Controllers\Api;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class InviteUserController extends Controller
{

    public function __invoke(Request $request)
    {
        //Logic to invite user to plan
    }
}

And in the routes file we would no more use the string literal convention to map a route to this controller instead we add the class like

use App\Http\Controllers\Api;

Route::get('/invite', InviteUserController::class)

Let me know what you think about single method controllers!

Credit: lornajane

PS: This is my first blog post on Dev.to

Hi, I'm Massive brains

Segun Olaiya — Wed, 18 Jan 2017 22:05:27 +0000

I have been coding for [3] years.

You can find me on Twitter as @massivebrains00

I live in [lagos].

I work for [company]

I mostly program in these languages: [php].

I am currently learning more about [javascript].

Nice to meet you.

DEV Community: Segun Olaiya

Feature testing with PHPUnit and things to avoid

Always make sure your tests are independent of each other

Do not test too many things at once

Only Mock 3rd Party services

Avoid Huge test files

Avoid tests using other features to Setup

Avoid Logic / Code Complexities in your assertions

Do not expose private properties as public just because of the tests

I tried to json_decode a string in scientific notation

Use same Dockerfile for Dev & Production

Docker Multi-Stage builds

Updating this Dockerfile to serve both Dev and Production

The base stage

The dev stage

The build stage

The prod stage

How to target a stage in Dockerfile

Strive to make it Simple

MySQL: Searching multiple columns at once without LIKE

Using MySQL LOCATE function

Simplyfing with Mysql CONCAT_WS

Deploying a Laravel App on AWS App Runner

Following this tutorial

Dockerizing Laravel

Other deployment related files

Build and run your image

Setting up AWS App Runner

AWS Elastic Container Registry

Setting up Github Actions

Creating an AWS App Runner Service

Handling failed deployment

Automatic deployments

Custom Domains

Conclusion

Image or File Uploads in Adonis.js with Cloudinary

Step 1: Create a new AdonisJS project

Step 2: Setup an upload controller

Step 3: Implementing Cloudinary

Step 4: Using the cloudinary Service

Step 5: Testing from Postman

Deploying Node/Express app on a Windows Server

massivebrains / express-demo

An Express Demo App

express-demo

Setup the express app on the server

Setting up a proxy with IIS

Step 1

Step 2

Adding a URL rewrite

Single Method Controllers in Laravel

Hi, I'm Massive brains

The `base` stage

The `dev` stage

The `build` stage

The `prod` stage

How to target a `stage` in Dockerfile