DEV Community: Bolaji Ajani

Understand how to use the decorator design pattern (with PHP and JS/TS examples).

Bolaji Ajani — Wed, 05 Nov 2025 13:48:09 +0000

Mastering the Decorator Pattern: Adding Behaviour Without Breaking Code

Bolaji Ajani ・ Oct 26

Full-Text Search: Why Tools Like OpenSearch, Elasticsearch, and Meilisearch Matter

Bolaji Ajani — Fri, 31 Oct 2025 10:48:30 +0000

Search is everywhere, whether you’re looking for a product on Amazon, a tweet on X, or a log entry in your system. But not all searches are created equal. A simple SQL LIKE '%term%' query just doesn’t cut it when your users expect lightning-fast, typo-tolerant, and contextually smart results.

That's where full-text search engines like OpenSearch, Elasticsearch and Meilisearch come in.

In this article, we’ll explore why full-text search matters, how it works behind the scenes, and walk through a hands-on Meilisearch example you can run locally using Docker, Postman, or any other tool capable of making HTTP requests such as cURL.

What is Full-Text Search?

Full-text search allows users to find relevant results based on textual content and not exact matches.

Instead of scanning through every record in a database, search engines analyze and index text data to make it searchable in milliseconds. They understand context to an extent, handle typos, and rank results by relevance, giving users what they mean, not just what they type.

How Full-Text Search Works

Here’s a high-level view of what happens under the hood.

Documents are ingested into the search engine.
They’re tokenized,that is split into searchable terms.
The engine builds an inverted index, mapping words to documents that contain them.
When a user searches, their query is analyzed, scored, and ranked by relevance.

Process Overview

Why Full-Text Search Engines Matter

Search engines exist because users expect relevance and speed. The following are some of the reasons why they are essential:

Speed at Scale - Uses inverted indexes to handle millions of document quickly.
Relevance Scoring - Ranks results by context, frequency, and meaning.
Fuzzy Matching - Finds “interstllar” when you meant “Interstellar.”
Filtering & Sorting - Combine search with advanced filters (price, tags, etc).
Scalability - From single-node lightweight setups to multi-cluster systems.

Choosing the Right Search Engine

There is no one-size-fits all in full-text search, different engines shine in different contexts. Here are some of the most popular ones and why teams choose them:

Engine	Best For	Why It’s a Good Choice
Elasticsearch	Enterprise-scale search & analytics	Proven, battle-tested, and highly extensible with a rich query DSL. Great for logs, metrics, and large datasets.
OpenSearch	Self-hosted analytics and observability	AWS-backed open-source fork of Elasticsearch. Ideal for dashboards, metrics, and log management with built-in visualization tools.
Meilisearch	Developer-friendly instant search	Lightweight, fast, and typo-tolerant by default. Excellent for product catalogs, SaaS apps, and small-to-medium projects.
Typesense	Product and document search	Easy to deploy with automatic typo tolerance and fine-tuned relevance. Perfect for modern web apps and e-commerce sites.
Apache Solr	Legacy or enterprise systems	Java-based, Lucene-powered, and integrates well with Hadoop and big data pipelines. Solid choice for on-premise deployments.
Algolia	Managed search-as-a-service	Fully hosted, fast, and feature-rich with analytics and instant results. Ideal for teams that prefer not to manage infrastructure.
MongoDB Atlas Search	Search within NoSQL documents	Built on Lucene, enables search directly inside MongoDB Atlas. Great for apps already using MongoDB.
PostgreSQL Full-Text Search	Embedded search in relational apps	Built-in text search (`to_tsvector`, `to_tsquery`) with stemming and ranking. Suitable for smaller-scale or internal systems.

When Databases Can Still Handle Search

Sometimes you don’t need a dedicated search engine, your database might already include built-in full-text search capabilities.

Here’s how popular databases stack up for smaller-scale or embedded search needs:

Database	Search Feature	Description
PostgreSQL	`to_tsvector`, `to_tsquery`	Native full-text search with stemming, ranking, and weighting. Great for moderate datasets or apps needing SQL + search in one place.
MySQL / MariaDB	`MATCH() AGAINST()`	Simple full-text search in `MyISAM` and `InnoDB` tables. Works for blogs, products, or smaller data sets but lacks fuzzy matching and relevance tuning.
SQLite	FTS5 Extension	Lightweight full-text indexing for mobile or desktop apps. Perfect for embedded search without a separate service.
MongoDB Atlas Search	Lucene-powered search layer	Provides fuzzy matching, scoring, and highlighting directly within MongoDB Atlas. Useful for document-based applications.
Oracle Database	Oracle Text	Enterprise-grade search supporting structured and unstructured data, but complex to configure and manage.
Microsoft SQL Server	Full-Text Search Service	Offers keyword and phrase search within text columns, suitable for enterprise systems already using SQL Server.

My advice is use your database's built-in search when your dataset is small, self-contained, or doesn't need typo tolerance. Use a dedicated search engine once you need fast relevance scoring, fuzzy matching, and scaling beyond a few hundred thousand records.

Example: Building Search with Meilisearch

Let's set up Meilisearch locally using Docker Compose. We should also be able to index some data, and explore search queries. I've made the assumption that you have docker locally and understand how to use docker.

Step 1: Create docker-compose.yml

version: '3.8'

services:
  meilisearch:
    image: getmeili/meilisearch:v1.24
    container_name: meilisearch
    environment:
      - MEILI_MASTER_KEY=a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w
    ports:
      - "7700:7700"
    volumes:
      - ./data.ms:/meili_data

Run it:

docker-compose up -d

You may skip step 2, and just go to this section where I've included a postman collection file that you can download and import as a collection to run the sample tests included in this article.

Step 2: Add Sample Data

Create a movies.json file

[
  { "id": 1, "title": "Inception", "genre": "Sci-Fi", "year": 2010 },
  { "id": 2, "title": "Interstellar", "genre": "Sci-Fi", "year": 2014 },
  { "id": 3, "title": "The Dark Knight", "genre": "Action", "year": 2008 },
  { "id": 4, "title": "Tenet", "genre": "Thriller", "year": 2020 }
]

Make the following curl request to index the data:

curl -X POST 'http://localhost:7700/indexes/movies/documents' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data-binary @movies.json

Response:

{"taskUid":0,"indexUid":"movies","status":"enqueued","type":"documentAdditionOrUpdate","enqueuedAt":"2025-10-31T08:09:40.644831635Z"}

In order for us to be able to filter results in Meilisearch, we also have to update the index settings with the attribute we need to filter by.

curl -X PUT 'http://localhost:7700/indexes/movies/settings/filterable-attributes' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data-binary '["genre", "year"]'

Response:

{"taskUid":1,"indexUid":"movies","status":"enqueued","type":"settingsUpdate","enqueuedAt":"2025-10-31T09:11:12.86560951Z"}

We also need to configure attributes that are sortable;

curl -X PUT 'http://localhost:7700/indexes/movies/settings/sortable-attributes' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data-binary '["year"]'

Response:

{"taskUid":2,"indexUid":"movies","status":"enqueued","type":"settingsUpdate","enqueuedAt":"2025-10-31T09:19:18.009525346Z"}

You may verify all configured attributes by checking the index settings:

curl -X GET 'http://localhost:7700/indexes/movies/settings' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w'

Response:

{"displayedAttributes":["*"],"searchableAttributes":["*"],"filterableAttributes":["genre","year"],"sortableAttributes":["year"],"rankingRules":["words","typo","proximity","attribute","sort","exactness"],"stopWords":[],"nonSeparatorTokens":[],"separatorTokens":[],"dictionary":[],"synonyms":{},"distinctAttribute":null,"proximityPrecision":"byWord","typoTolerance":{"enabled":true,"minWordSizeForTypos":{"oneTypo":5,"twoTypos":9},"disableOnWords":[],"disableOnAttributes":[],"disableOnNumbers":false},"faceting":{"maxValuesPerFacet":100,"sortFacetValuesBy":{"*":"alpha"}},"pagination":{"maxTotalHits":1000},"embedders":{},"searchCutoffMs":null,"localizedAttributes":null,"facetSearch":true,"prefixSearch":"indexingTime"}

Step 3: Try Different Searches

Simple Search

curl -X POST 'http://localhost:7700/indexes/movies/search' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data '{ "q": "inception" }'

Response:

{"hits":[{"id":1,"title":"Inception","genre":"Sci-Fi","year":2010}],"query":"inception","processingTimeMs":11,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"019a3994-1965-7833-94a8-03fd4553bfeb"}

Fuzzy Search

curl -X POST 'http://localhost:7700/indexes/movies/search' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data '{ "q": "interstllar" }'

Response:

{"hits":[{"id":2,"title":"Interstellar","genre":"Sci-Fi","year":2014}],"query":"interstllar","processingTimeMs":5,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"019a3994-a647-7993-b8b2-d8bd4882d031"}

Filter by year

curl -X POST 'http://localhost:7700/indexes/movies/search' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data '{ "q": "Sci-Fi", "filter": "year > 2010" }'

Response:

{"hits":[{"id":2,"title":"Interstellar","genre":"Sci-Fi","year":2014}],"query":"Sci-Fi","processingTimeMs":12,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"019a398c-7ad4-7522-be38-db9cb7152704"}

Sort by Year (Descending)

curl -X POST 'http://localhost:7700/indexes/movies/search' \
-H 'Authorization: Bearer a4qaSFPIfDbrwviM5XsogCK77Oa-YCtpKP4i6cAxr7w' \
-H 'Content-Type: application/json' \
--data '{ "q": "sci-fi", "sort": ["year:desc"] }'

Response:

{"hits":[{"id":2,"title":"Interstellar","genre":"Sci-Fi","year":2014},{"id":1,"title":"Inception","genre":"Sci-Fi","year":2010}],"query":"sci-fi","processingTimeMs":25,"limit":20,"offset":0,"estimatedTotalHits":2,"requestUid":"019a3996-f4a3-7930-8109-041465231893"}

Download Postman collection

collection

Access Repository on Github

You can find the complete Meilisearch demo, including the Docker setup, sample data and Postman collection, on GitHub.

mastering full text search meilisearch demo

Final Thoughts

Search quietly shapes how people experience your product. When it works well, it feels natural, fast, and almost invisible. Full-text search makes your app return results that are relevant to what users mean, not just what they type. Whether you use Meilisearch, OpenSearch, or PostgreSQL’s text search, choosing the right tool can turn a simple lookup into an experience that feels truly effortless.

Cover Image: by Teslariu Mihai

Mastering the Decorator Pattern: Adding Behaviour Without Breaking Code

Bolaji Ajani — Sun, 26 Oct 2025 07:34:00 +0000

"Open for extension, closed for modification."
This single line from the SOLID principles perfectly captures the spirit of the Decorator Pattern

When you need to extend functionality without touching existing code, the Decorator Pattern is one of the most elegant solutions in software design.

What is Decorator Pattern?

The Decorator Pattern is a structural pattern that lets you dynamically add new behavior to objects without changing their original structure.

Instead of building large inheritance trees, you “wrap” an existing object with one or more decorator classes that each add something new.

Real-World Analogy

Think of a cup of coffee:

You start with a base drink — say, espresso.
You can then add milk, sugar, or cream.

Each addition enhances the coffee’s flavor without changing the core espresso class. That’s the Decorator Pattern in action.

Does the Decorator Pattern Satisfy SOLID Principles?

S - Single Responsibility: Each decorator adds one specific concern (e.g., logging, caching) to the base object without altering its core behaviour. For example, in a coffee shop system, a MilkDecorator adds milk-related behaviour without changing the base Coffee class's responsibility.
O - Open/Closed: Extend behaviour by wrapping and not rewriting the class. This is where the Decorator Pattern excels. It allows new functionality to be added (extension) by wrapping objects with decorators, without modifying the original class's code. For instance, you can add a SugarDecorator to a Coffee object without touching the Coffee class itself.
L - Liskov Substitution: Decorators can replace the base class since they share the same interface. Decorators typically implement the same base class as the object they decorate, ensuring they can be used interchangeably. For example, a DecoratedCoffee (with milk or sugar) can be used anywhere a Coffee is expected, as long as the decorator correctly implements the interface. However, care must be taken to ensure decorators don't introduce unexpected behaviour that may break contracts.
D - Dependency Inversion: Both base and decorators depend on an abstraction, not each other's implementation. Both the base component and decorators depend on the same abstract interface, allowing flexibility in how components are composed. For example a Coffee implementation, whether it's a base Espresso or a decorated ExpressoWithMilk.

Basic Example (PHP)

Here is a lightweight PHP example:

interface Logger {
    public function log(string $message): void;
}

class FileLogger implements Logger {
    public function log(string $message): void {
        echo "Logging: {$message}\n";
    }
}

abstract class LoggerDecorator implements Logger {
    protected Logger $logger;

    public function __construct(Logger $logger) {
        $this->logger = $logger;
    }

    public function log(string $message): void {
        $this->logger->log($message);
    }
}

class TimestampLogger extends LoggerDecorator {
    public function log(string $message): void {
        parent::log("[" . date('Y-m-d H:i:s') . "] " . $message);
    }
}

class EncryptLogger extends LoggerDecorator {
    public function log(string $message): void {
        parent::log(base64_encode($message));
    }
}

$logger = new EncryptLogger(new TimestampLogger(new FileLogger()));
$logger->log("User logged in");

Output:

Logging: [2025-10-18 21:00:00] VXNlciBsb2dnZWQgaW4=

Class Diagram - Logger

The diagram below visualizes the structure of the Decorator Pattern in our above example.

Logger defines the core interface.
FileLogger implements the interface directly.
LoggerDecorator wraps any Logger instance.
Concrete decorators (TimestampLogger, EncryptLogger) extend the decorator to add new behaviour.

Real-Life Use Case in TypeScript: An Exensible API Client

Now, let's build something that can be used in production, an API Request Handler that can dynamically gain logging, caching or retry capabilities.

Step 1: Define an Interface that all API clients will implement.

interface ApiClient {
  request(url: string): Promise<any>;
}

Step 2: Create a Base HTTP Client

class HttpClient implements ApiClient {
  async request(url: string): Promise<any> {
    console.log(`Fetching from: ${url}`);
    const response = await fetch(url);
    return response.json();
  }
}

Step 3: Create an Abstract Decorator that each decorator will extend

abstract class ApiClientDecorator implements ApiClient {
  constructor(protected client: ApiClient) {}

  request(url: string): Promise<any> {
    return this.client.request(url);
  }
}

Step 4: Add Behaviour-Specific Decorators

LoggingDecorator

class LoggingDecorator extends ApiClientDecorator {
  async request(url: string): Promise<any> {
    console.log(`[LOG] Starting request: ${url}`);
    const result = await super.request(url);
    console.log(`[LOG] Completed request: ${url}`);
    return result;
  }
}

CachingDecorator

class CachingDecorator extends ApiClientDecorator {
  private cache = new Map<string, any>();

  async request(url: string): Promise<any> {
    if (this.cache.has(url)) {
      console.log(`[CACHE HIT] ${url}`);
      return this.cache.get(url);
    }

    console.log(`[CACHE MISS] ${url}`);
    const result = await super.request(url);
    this.cache.set(url, result);
    return result;
  }
}

RetryDecorator

class RetryDecorator extends ApiClientDecorator {
  constructor(client: ApiClient, private retries = 3) {
    super(client);
  }

  async request(url: string): Promise<any> {
    for (let attempt = 1; attempt <= this.retries; attempt++) {
      try {
        return await super.request(url);
      } catch (err) {
        console.warn(`[RETRY] Attempt ${attempt} failed`);
        if (attempt === this.retries) throw err;
      }
    }
  }
}

Step 5: Compose the Decorators

async function main() {
  let client: ApiClient = new HttpClient();

  // Add decorators as layers
  client = new RetryDecorator(
              new CachingDecorator(
                new LoggingDecorator(client)
              )
            );

  const data1 = await client.request("https://jsonplaceholder.typicode.com/users/1");
  const data2 = await client.request("https://jsonplaceholder.typicode.com/users/1"); // Cached

  console.log("User:", data1.name);
}

main();

Output

[LOG] Starting request: https://jsonplaceholder.typicode.com/users/1
[CACHE MISS] https://jsonplaceholder.typicode.com/users/1
[LOG] Completed request: https://jsonplaceholder.typicode.com/users/1
[CACHE HIT] https://jsonplaceholder.typicode.com/users/1
User: James Anderson

Class Diagram - API Client

The diagram below shows the layering of decorators around the base HttpClient. Each decorator(Logging, Caching, Retry) wraps another, forming a stack of added behaviour that enhances the base client dynamically.

Advantages & Disadvantages

Advantages	Disadvantages
Flexible runtime composition	Can introduce complexity with many layers
Promotes reusability	Harder to debug due to nested wrappers
Adheres to SOLID	Order of decorators affects behaviour
Avoids deep inheritance	Requires more setup code

When to Use

You need optional features (e.g. caching)
You want to add behaviour without subclassing.
You want to compose behaviours at runtime.

Conclusion

The Decorator Pattern is one of the most flexible tools in a developer's design arsenal. It elegantly combines composition over inheritance with SOLID principles, allowing you to add features on the fly without breaking your existing code.

Whether you're writing PHP backends, TypeScript services or you're working with Java, you're probably using decorators already, maybe without realizing it.

Cover Image: "Cafe Adventure" by Andrew Tanglao

Understanding Laravel Model Observer, and Testing Using the Underlying Model

Bolaji Ajani — Wed, 27 Dec 2023 02:06:32 +0000

In my journey with Laravel, one feature that consistently proves its value is the Model Observer. These observers are not just a neat organizational tool; they are a robust mechanism for reacting to various Eloquent model events – like creating, updating, or deleting models. Just recently, while working on a model with a conditional nullable column, Laravel Observers again demonstrated their efficiency. Let's delve into what Laravel Model Observers are and how you can leverage them effectively in your projects.

What is a Laravel Model Observer?

In Laravel, a Model Observer is a class where you can group listener methods for various Eloquent model events. This pattern, derived from the Observer design pattern, is particularly useful for keeping your model-related logic clean and manageable. It lets you handle model events such as creating, updating, deleting, etc., in a dedicated class, ensuring that your model classes remain lean and focused on their primary responsibilities.

Creating and Registering Observers:

Creating a Laravel Observer is straightforward. Use the artisan command to generate an observer class, ideally naming it after the model it observes. For instance, to create an observer for an Addon model, you would use:

php artisan make:observer AddonObserver --model=Addon

This command scaffolds an observer class in the app\Observers directory. Next, you need to register this observer with the model. This can be done in the boot method of the App\Providers\EventServiceProvider or any custom service provider like so:

use App\Models\Addon;
use App\Observers\AddonObserver;

public function boot(): void
{
    Addon::observe(AddonObserver::class);
}

Alternatively, you can list your observer within the $observers property of the EventServiceProvider:

protected $observers = [
    Addon::class => [AddonObserver::class],
];

Practical Example: Ensuring Data Integrity

Consider an Addon model with varying types, where the one-time type does not require a usable_count. To ensure data integrity and prevent potential issues, we can implement a check in the observer's creating method:

namespace App\Observers;

use App\Models\Addon;
use Exception;

class AddonObserver
{
    public function creating(Addon $addon): void
    {
        if ($addon->type !== Addon::TYPE_ONE_TIME && is_null($addon->usable_count)) {
            throw new Exception(Addon::ADDON_TYPE_REQUIRES_USABLE_COUNT);
        }
    }
}

This code throws an exception if an Addon of a certain type is created without the necessary usable_count, thereby safeguarding the application from incorrect data entries.

Testing Observers with Pest PHP

The robustness of Laravel applications often hinges on the effectiveness of our Observers. Testing these Observers thoroughly is crucial, and Pest PHP provides an expressive and elegant framework for this purpose. Let's explore a comprehensive test case that not only tests the Observer but also validates the behavior of the underlying model.

use App\Models\Addon;
use Exception;

test("ensuring addon observer integrity with model testing", function () {
    // Scenario: Creating an Addon without a required usable_count
    $this->expectException(Exception::class);
    $this->expectExceptionMessage(Addon::ADDON_TYPE_REQUIRES_USABLE_COUNT);

    Addon::factory()->create([
        'type' => Addon::TYPE_LIMITED, // This type requires usable_count
        'usable_count' => null         // Omitting usable_count
    ]);

    // Scenario: Successfully creating an Addon without needing a usable_count
    $addon = Addon::factory()->create([
        'type' => Addon::TYPE_ONE_TIME, // This type does not require usable_count
    ]);

    expect($addon)->toBeInstanceOf(Addon::class);
    expect($addon->usable_count)->toBeNull();
});

This test effectively checks the Observer's functionality by interacting directly with the Addon model, ensuring that the Observer enforces the necessary business rules.

Conclusion:

Laravel Model Observers provide a structured way to handle model events and keep your models focused on their core responsibilities. Coupled with rigorous testing, Observers can significantly enhance the reliability and maintainability of your Laravel projects. You might want to visit the official Laravel documentation to read more about what you can do with observers.

Setting up Continuous Deployment for a vue app on a VPS using Github Actions

Bolaji Ajani — Sun, 31 Jul 2022 23:01:00 +0000

Continuous Deployment is a part of the Continuous Delivery process in CI/CD. This process covers the part of deploying the builds to production (or other environments), although to get to this part we must have touched some processes in Continuous Integration. However, this article will majorly be focusing on automatic deployment. It's important to note that there are other configurations and setup that should be done to have a decent CI/CD process. For example, one might setup ways to manage and keep each release on the server.

What you need to get started

The assumption here is you have a github account and you have setup your github repository. It's also assumed that you have a Virtual Private Server that has been provisioned, if you do not have this, you can get it from any of the hosting platform (e.g. DigitalOcean, Linode) that offers this.

Setting Up

We need to set up the server

I'm currently using Ubuntu 20.04.2 LTS for this. It doesn't really matter what OS you use but if your setup has its peculiarities, just try to factor that in your modifications. If you don't already have ssh key pairs generated, do that by running the command below in your terminal.

You can generate the keys on your local machine or on the remote server. If you'll be generating on the remote server run the next line (1.1) of code. If not skip and move to line 1.2.

1.1. ssh username@host where username is your username and host is probably the ip to your host.

Then run;

1.2. ssh-keygen -t rsa -b 4096 -C "email@example.com"

You do not need to specify the flags, by default the best options available will be picked. -t flag represents the algorithm type to use , -b flag represents the size. You could also add an -f flag which takes the filename you want to store the key in. The -C flag is for commenting the keyfile, you can put anything in the comment but it's common to put one's email in.

After running the last command you'll be prompted to enter the file you want to store the keys in, just press enter. You'll be asked to specify a passphrase afterwards, press enter two times to set it up with no passphrase. However, if you specify a passphrase, you'll have to include it in your deploy script.

Add the public key to your authorized keys

Run the command below to append the previously created public key to your authorized_keys. Although you can as well do that manually by copying the public key and opening your authorized_keys file to paste it at the end.

2.1. cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

If you created the keys on your local machine, run the following to copy the key to your remote server or you can as well just do it manually;

2.2. ssh-copy-id -i ~/.ssh/id_rsa.pub username@host

Copy the private key from your server or local machine

Run the following command to do that

3.1. cat ~/.ssh/id_rsa

The command will print out the content of the id_rsa file to the terminal. Copy this to somewhere else you can easily access (like your clipboard) later. It should be noted that the name doesn't have to be id_rsa, this depends on what you saved your keys as in the previous step or the kind of algorithm you're making use of. The private key should start with something like -----BEGIN OPENSSH PRIVATE KEY----- and end with -----END OPENSSH PRIVATE KEY-----.

Setup Github Actions Secrets

Go to the the app's github repository, then from there navigate to settings. Then use "New Repository Secret" button repeatedly adding the following parameters.

SSHKEY - Input the key you copied in the previous step.
HOST - Input your server's hostname (i.e ip address).
USERNAME - Input the username you use to ssh into your sserver.
PORT - Input the ssh port no, default is 22.
TARGET - Input your vue app's root path .i.e /var/www/staging
STAGING_ENV - This is optional, and you can name it whatever you want. I use the format ENVIRONMENT_ENV to specify the environment I'm deploying to. If you don't make use of the env file to store environment variables, this should be ignored.
PASSPHRASE - This is optional, if you left the passphrase empty in step 1 above, ignore this.

Add YAML file to configure your repository for automatic deployment

There are couple of ways to go about this. You can do this by going to "actions" tab in your repository and then clicking on the link that says "set up a workflow yourself". Then copy the content of the YAML file that is below into the provided text box. You may change the name of the file to whatevername.yml (in my case, I named it deploy-staging.yml because it's for the staging environment) and then commit it.

However, for easy control, in your local repository, in the root folder create the following .github/workflows/deploy-staging.ymlwhere .github and workflows are directories. After doing this, you can then commit and push the changes to your remote repository.

name: Deploy to Staging

on: 
  push:
    branches:
      - development
jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Copy repository contents to remote server via scp
      uses: appleboy/scp-action@master
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        port: ${{ secrets.PORT }}
        key: ${{ secrets.SSHKEY }}
        passphrase: ${{ secrets.PASSPHRASE }}
        source: "."
        target: ${{ secrets.TARGET }}

    - name: Executing remote command via ssh
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        port: ${{ secrets.PORT }}
        passphrase: ${{ secrets.PASSPHRASE }}
        key: ${{ secrets.SSHKEY }}
        script: |
              cd ${{secrets.TARGET}} && npm install
              printf "%s" "${{secrets.STAGING_ENV}}" > "${{secrets.TARGET}}/.env.staging"
              npm run build:staging

A run through of what the script is doing;

In order not to deploy on every push, we have specified the branch(es) that pushing to must trigger the deploy process. Here, we specified the development branch, however we can specify multiple branches.
The checkout action checks out the repository so our workflow can access it.
scp-action handles the copying of the files from the repository to the remote server using the credentials we have provided via actions secrets. If you left the passphrase empty in step 1 above, remove the passphrase line.
ssh-action handles running the remote command to facilitate the deployment, also using the credentials we provided via actions secret to access the remote server. If you left the passphrase empty in step 1 above, remove the passphrase line.
The commands are quite straightforward
- navigate to the root directory then run npm install to install the dependencies.
- write the environment variables stored in the STAGING_ENV secret into .env.staging file on the remote server [This is an optional line, if it's not applicable to you, remove it].
- build the app using a custom script. I added a custom script, "build:staging": "vue-cli-service build --mode staging", in my package.json to build for the staging environment. If you do not have a special need like me, you might as well change that to npm run build.

After pushing the changes to the specified branch(es). switch to the Actions tab on your repository and you should get something like the below image if all went well. Now, you have successfully deployed your app to your environment of choice.

In the above, we have used the set of actions listed below. You may check them out to learn one or more things you can equally do with them;

NB:

There is a lot you can do with github actions and I would advise we explore this more. Visit the github actions page to learn what we can do and how you can better equip yourself.
This process will also work for other related codebases, albeit with one or more modifications.
I assumed you must have point your server block to the dist directory, this directory is where vue builds the app by default.
Github Actions has limited free minutes and storage for private repositories. You might want to check here to see what is applicable to you.

I hope you find this useful. If you have questions or comments, please drop them below and let's learn together.