If you've ever found yourself caught between the modern, blazing-fast world of Astro and the need to integrate legacy PHP code or leverage PHP's ecosystem, you're not alone. Today, I'm excited to introduce astro-php-ssr - a seamless integration that lets you run PHP routes directly inside your Astro SSR applications.

The Problem: Modern Frontend, Legacy Backend

Astro has revolutionized how we build content-focused websites. Its island architecture, zero-JS-by-default philosophy, and incredible performance make it a developer favorite. But what happens when you need to:

• Integrate existing PHP APIs or services
• Work with PHP-based CMSs or legacy systems
• Leverage PHP libraries without rewriting everything in JavaScript
• Gradually migrate a PHP application to a modern stack

Until now, you'd be stuck managing separate servers, dealing with CORS issues, or embarking on costly rewrites.

Enter astro-php-ssr

astro-php-ssr is a lightweight Astro integration that runs .php files directly inside your Astro SSR application using php-cgi or php as a fallback. No separate PHP server required. No complex proxy configurations. Just seamless PHP integration.

Key Features

✅ Seamless Integration - Works with astro dev and production SSR
✅ Full Request Support - Handles GET, POST, and other HTTP methods
✅ Flexible Configuration - Customize PHP binary path and PHP file directory
✅ Zero External Dependencies - Uses your existing PHP installation
✅ TypeScript Support - Full type definitions included

Installation

Getting started is incredibly simple:

npm install astro-php-ssr

Or with your preferred package manager:

yarn add astro-php-ssr
# or
pnpm add astro-php-ssr

Prerequisites: You'll need php-cgi (preferred) or php installed on your system. Check with:

php-cgi -v
# or
php -v

Basic Usage

1. Configure Your Astro Project

First, add the integration to your astro.config.mjs:

import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
import astroPhpSSR from 'astro-php-ssr';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
  integrations: [
    astroPhpSSR({
      phpDir: './php',        // Where your PHP files live
      phpBinary: 'php-cgi'    // Or 'php' as fallback
    })
  ]
});

2. Create Your PHP Directory Structure

your-project/
├── php/
│   ├── api/
│   │   └── hello.php
│   └── contact.php
├── src/
│   └── pages/
│       └── index.astro
└── astro.config.mjs

3. Write Your PHP Routes

Create a simple API endpoint at php/api/hello.php:

<?php
header('Content-Type: application/json');

$name = $_GET['name'] ?? 'World';
echo json_encode([
    'message' => "Hello, $name!",
    'timestamp' => time()
]);

4. Access Your PHP Routes

Your PHP files are automatically served under /php/:

http://localhost:4321/php/api/hello.php?name=Astro

Response:

{
  "message": "Hello, Astro!",
  "timestamp": 1698624000
}

Real-World Examples

Example 1: Contact Form Handler

Create a contact form handler in php/contact.php:

<?php
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $name = $_POST['name'] ?? '';
    $email = $_POST['email'] ?? '';
    $message = $_POST['message'] ?? '';
    
    // Validate
    if (empty($name) || empty($email) || empty($message)) {
        http_response_code(400);
        echo json_encode(['error' => 'All fields are required']);
        exit;
    }
    
    // Process (send email, save to database, etc.)
    mail('admin@example.com', 'Contact Form', $message);
    
    echo json_encode(['success' => true]);
} else {
    http_response_code(405);
    echo json_encode(['error' => 'Method not allowed']);
}

Use it in your Astro component:

---
// src/pages/contact.astro
---

<form action="/php/contact.php" method="POST">
  <input type="text" name="name" placeholder="Your Name" required />
  <input type="email" name="email" placeholder="Your Email" required />
  <textarea name="message" placeholder="Your Message" required></textarea>
  <button type="submit">Send</button>
</form>

Example 2: WordPress REST API Bridge

Integrate WordPress content without exposing your WordPress installation:

<?php
// php/api/posts.php
$wp_url = 'https://your-wordpress-site.com';
$endpoint = '/wp-json/wp/v2/posts';

$response = file_get_contents($wp_url . $endpoint);
header('Content-Type: application/json');
echo $response;

Fetch in your Astro page:

---
// src/pages/blog.astro
const response = await fetch('http://localhost:4321/php/api/posts.php');
const posts = await response.json();
---

<div>
  {posts.map(post => (
    <article>
      <h2>{post.title.rendered}</h2>
      <div set:html={post.excerpt.rendered} />
    </article>
  ))}
</div>

Example 3: Database Operations

Access your MySQL database using PHP's native drivers:

<?php
// php/api/users.php
$db = new PDO('mysql:host=localhost;dbname=mydb', 'user', 'pass');

$stmt = $db->query('SELECT id, name, email FROM users LIMIT 10');
$users = $stmt->fetchAll(PDO::FETCH_ASSOC);

header('Content-Type: application/json');
echo json_encode($users);

Advanced Configuration

Custom PHP Binary Path

If your PHP installation is in a non-standard location:

astroPhpSSR({
  phpDir: './php',
  phpBinary: '/usr/local/bin/php-cgi'
})

Multiple PHP Directories

You can structure your PHP files however you like within the phpDir:

php/
├── api/
│   ├── v1/
│   │   └── users.php
│   └── v2/
│       └── users.php
├── admin/
│   └── dashboard.php
└── public/
    └── info.php

Access them at:

• /php/api/v1/users.php
• /php/api/v2/users.php
• /php/admin/dashboard.php
• /php/public/info.php

Performance Considerations

astro-php-ssr spawns a PHP process for each request using CGI. While this works great for:

• Low to moderate traffic sites
• Development environments
• Internal tools and dashboards
• API endpoints that don't need millisecond response times

For high-traffic production applications, consider:

• Caching PHP responses
• Using PHP-FPM for long-running PHP processes
• Rate limiting your PHP endpoints
• Offloading heavy computation to background jobs

Use Cases

This integration shines in several scenarios:

1. Legacy Integration: You have an existing PHP codebase and want to modernize the frontend without a complete rewrite

2. Gradual Migration: You're moving from PHP to a modern stack and need both worlds to coexist

3. PHP-Specific Libraries: You need functionality that's only available in PHP (certain payment gateways, legacy APIs, etc.)

4. Content Management: Integrating with PHP-based CMSs like WordPress, Drupal, or custom systems

5. Prototyping: Quickly spin up backend functionality using PHP's extensive ecosystem

Limitations & Considerations

• Requires PHP: Your deployment environment must have php-cgi or php installed
• CGI Performance: Each request spawns a new PHP process (consider PHP-FPM for production)
• Session Management: PHP sessions work, but coordinate with Astro's session handling
• File Uploads: Supported through standard PHP $_FILES handling

Deployment

Deploying to Vercel/Netlify

These platforms don't support PHP out of the box. Consider:

• Using Vercel/Netlify for static Astro content
• Deploying PHP portions to a PHP-friendly platform
• Using serverless PHP options

Deploying to VPS/Traditional Hosting

This is where astro-php-ssr really shines:

1. Ensure PHP is installed: sudo apt install php-cgi
2. Build your Astro project: npm run build
3. Run with Node: node dist/server/entry.mjs

Works perfectly on DigitalOcean, Linode, AWS EC2, or any VPS with Node.js and PHP.

Roadmap

Future enhancements I'm considering:

• PHP-FPM support for better performance
• Built-in caching layer
• Request/response logging
• Hot reload for PHP files in development
• More granular error handling

Try It Yourself

Want to see it in action? Check out the live demo:

Or install it in your project:

npm install astro-php-ssr

Conclusion

astro-php-ssr bridges the gap between Astro's modern, performant frontend architecture and PHP's mature, extensive ecosystem. Whether you're integrating legacy code, gradually migrating to a modern stack, or just need PHP's specific capabilities, this integration makes it seamless.

The web development landscape doesn't have to be all-or-nothing. Sometimes the best solution is bringing the best of both worlds together.

Links

• 📦 npm Package
• 💻 GitHub Repository
• 🐛 Report Issues
• 🎯 Live Demo

Have you used astro-php-ssr in your project? I'd love to hear about your experience! Drop a comment below or open an issue on GitHub.

Introduction to the Project

We implemented theme switching to toggle direction switching to toggle between LTR and RTL layouts. While MUI provides straightforward RTL support for components, React-Grid-Layout’s lack of native RTL compatibility became an issue, particularly as users switched between LTR and RTL. The key technologies and libraries used in our project include:

• React: For building the user interface.
• Material-UI (MUI): For pre-built components and styling.
• React-Grid-Layout: For creating a draggable and resizable grid layout.
• Redux: For state management.
• Lodash: For utility functions like throttling and debouncing.

The RTL Issue with React-Grid-Layout

While react-grid-layout is a powerful library for creating responsive grid layouts with drag-and-drop capabilities, it lacks built-in support for RTL layouts. React-Grid-Layout uses absolute positioning and CSS transforms to position elements within the grid. For an LTR layout, these positions are calculated from the top-left corner of the grid, with elements positioned using positive translate values for X and Y coordinates. However, for RTL, the library does not invert the X-axis positions to start from the top-right, causing widgets to overflow out of view when switched to RTL mode  especially on larger screens. This issue stems from the library's internal calculations, which assume an LTR context.

Community Discussions and Attempts

Many developers have faced similar challenges. On GitHub, issues like Issue #682 and Pull Request #875 highlight attempts to introduce RTL support. Some have proposed modifying the library's core code, while others suggest workarounds using CSS transformations. 
Our attempt involved solving this issue without modifying the core code since our project needed to be sustainable.

Example from the Community

One user shared a solution that involved reversing the order of grid items based on the locale:

const getLayout = (locale) => {
  let layout = [];
  if (locale !== 'ar') {
    // Standard LTR layout generation
  } else {
    // Reverse the grid items for RTL
  }
  return layout;
};

However, modifying the grid generation logic can be complex and doesn't address dynamic changes in direction and some solution even required using the i8n library.

Initial Observations and Attempts

Upon inspecting the DOM, I observed that each grid item has a transform: translate(x, y) style applied. While in RTL mode, the x value causes the widgets to overflow to the right. I observed via trial and error that by simply adding a negative sign to the x value, the widgets align correctly:

/* Before: While in RTL direction*/
transform: translate(300px, 20px);

/* After adding negative sign in RTL  */
transform: translate(-300px, 20px);

Implementing a Temporary Solution with useEffect

An initial attempt involved using a useEffect hook to programmatically adjust the transform styles of all the widgets by targeting the class whenever the direction changed:

const isRTL = theme.direction === 'rtl'                                                        
 
useEffect(() => {
  const adjustTransforms = () => {
    const gridItems = document.querySelectorAll('.react-grid-item');
    gridItems.forEach((item) => {
      const transform = item.style.transform;
      if (transform) {
        const [x, y] = transform.match(/-?\d+/g).map(Number);
        const adjustedX = isRTL ? -x : x;
        item.style.transform = `translate(${adjustedX}px, ${y}px)`;
      }
    });
  };

  adjustTransforms();
}, [isRTL]);

While this solution aligned widgets correctly in RTL mode initially, it had several limitations:

• Temporary Adjustment: Each time the layout changed or the user toggled direction, the transform values would revert, causing widgets to jump back to their original positions.
• Non-Persistent Behavior: The useEffect only provided a temporary fix, and the layout would revert if users attempted to resize or drag elements.

Challenges with Dragging in RTL

Even with the temporary fix in place, a bigger issue surfaced when trying to drag widgets in RTL mode. Modifying X-axis positions programmatically while dragging caused runtime errors:

TypeError: Cannot assign to read-only property 'x' of object '#<Object>'

This error stemmed from attempting to modify immutable properties within the library's internal layout structure. React-Grid-Layout relies on specific drag-and-drop logic to calculate and update X and Y positions, and our solution of adding a negative X value clashed with the library’s internal handling.

Exploring Advanced Solutions

To address the flickering and performance issues caused by the continuous adjustments, a MutationObserver was introduced to monitor changes and re-apply the transformations:

useEffect(() => {
  let isAdjusting = false;

  const adjustTransforms = throttle(() => {
    if (isAdjusting) return;
    isAdjusting = true;
    // Adjust transforms
    isAdjusting = false;
  }, 100);

  const observer = new MutationObserver(() => {
    if (!isAdjusting) {
      adjustTransforms();
    }import { throttle } from 'lodash';

useEffect(() => {
    const adjustWidgetTransforms = throttle(() => {
        const gridItems = document.querySelectorAll('.react-grid-item');
        gridItems.forEach((item) => {
            const transform = item.style.transform;
            if (transform && transform.startsWith('translate')) {
                const values = transform.match(/translate\(([^)]+)\)/)[1].split(', ');
                const x = parseFloat(values[0]);
                const y = parseFloat(values[1]);

                const adjustedX = isRTL ? -x : x;
                item.style.transform = `translate(${adjustedX}px, ${y}px)`;
            }
        });
    }, 100);

    const observer = new MutationObserver(adjustWidgetTransforms);
    observer.observe(document.querySelector('.react-grid-layout'), { attributes: true, subtree: true });
    
    return () => {
        observer.disconnect();
        adjustWidgetTransforms.cancel();
    };
}, [isRTL]);
  });

  const config = { attributes: true, attributeFilter: ['style'], subtree: true };
  const gridItems = document.querySelectorAll('.react-grid-item');
  gridItems.forEach((item) => observer.observe(item, config));

  return () => observer.disconnect();
}, [isRTL]);

While this approach improved the fix slightly, it still faced limitations:

• Performance Overhead: MutationObserver added a significant performance overhead by constantly monitoring layout changes, leading to lag and, in some cases, browser crashes.
• Inconsistent Behavior: Even with throttling, the widgets’ positions would still flicker between LTR and RTL positions, resulting in an unstable user experience.

The Final Approach: Keeping the Grid LTR

Given the challenges with manipulating the grid's direction and the internal complexities of the library, and after several unsuccessful attempts, we decided on an alternative approach. A more sustainable solution was adopted: Keep the react-grid-layout container in LTR mode and adjust only the inner contents of the widgets to be RTL.

Why This Approach Works

Since users primarily interact with the inner content of widgets (e.g., text, icons), applying RTL styling to these contents achieves the desired look. Meanwhile, React-Grid-Layout remains in LTR, ensuring that positioning, dragging, and resizing behaviors are not disrupted. The Dashboard Layout and other wrap around components can have their directions switched and the internal components of the React Grid Layout can also have their internal components switched while leaving Just the ReactGridLayout alone to function as is.

In practice, this approach is effective because users can still rearrange widgets freely without worrying about grid alignment. The internal contents align properly, and the grid layout remains stable.

• Simplicity: By not altering the grid's core behavior, we avoid conflicts with drag-and-drop functionality.
• Consistency: Widgets remain draggable and resizable as intended.
• Flexibility: Inner widget contents can be easily adjusted to match the desired text direction.

Implementing the Solution

Forcing LTR on the Grid Layout

Wrap the ResponsiveGridLayout component and set its direction to LTR:

<div style={{ direction: 'ltr' }}>
  <ResponsiveGridLayout {...gridProps} style={{ direction: 'ltr'}} >
    {/* Grid items */}
  </ResponsiveGridLayout>
</div>

Adjusting Widget Contents

For each widget, wrap its contents with a container that conditionally applies RTL styling based on the application's direction:

const Widget = ({ isRTL, children }) => (
  <div style={{ direction: isRTL ? 'rtl' : 'ltr' }}>
    {children}
  </div>
);

Use the Widget component in the grid items:

<ResponsiveGridLayout {...gridProps} style={{ direction: 'ltr'}}>
  <div key="widget1">
    <Widget isRTL={isRTL}>
      {/* Widget 1 contents */}
    </Widget>
  </div>
  <div key="widget2">
    <Widget isRTL={isRTL}>
      {/* Widget 2 contents */}
    </Widget>
  </div>
  {/* Additional widgets */}
</ResponsiveGridLayout>

Example of a Widget Component

Here's an example of a simple widget that adjusts its content direction:

const TextWidget = ({ isRTL, text }) => (
  <div style={{ direction: isRTL ? 'rtl' : 'ltr', padding: '10px' }}>
    <p>{text}</p>
  </div>
);

Use it within the grid:

<div key="textWidget">
  <TextWidget isRTL={isRTL} text="Hello, World!" />
</div>

Benefits of This Solution

• Drag Functionality Preserved: Since the grid remains in LTR, dragging and resizing work without additional adjustments.
• Content Alignment: Widget contents correctly align according to the text direction.
• Scalability: New widgets can be added without modifying the grid logic.

Conclusion

Implementing RTL support in libraries that don't natively support it can be challenging. While initial attempts at manipulating the grid's transformations provided temporary fixes, they introduced new issues with interactivity and performance. By keeping the grid layout in LTR and adjusting only the inner components, we achieve a balance between functionality and user experience.

In this project, the lack of RTL support in React-Grid-Layout led us through several iterative solutions, from adding negative signs to transform values, to using useEffect, MutationObserver, and throttling. Ultimately, forcing React-Grid-Layout to stay in LTR mode while applying RTL styling only to widget contents provided a stable, user-friendly solution.

This approach is a robust and scalable solution for projects that require RTL support in React-Grid-Layout. It allows developers to meet the visual requirements of RTL languages while maintaining the library’s inherent layout and drag functionality. This approach ensures that users can interact with the dashboard as intended, regardless of the text direction, and sets a foundation for supporting RTL languages in a scalable and maintainable way.

References

• React-Grid-Layout GitHub Issue #682
• React-Grid-Layout Pull Request #875
• React-Grid-Layout RTL Support Discussions
• GitHub Issue #141
• React Grid Layout Library - NPM
  Github Issue #453
  Github Issue #96

Recently, I built a component library for the Terakota project. I made use of Storybook which stands out as a superb tool for effective documentation and component cataloging. Setting up the storybook in/for an existing project has been heavily treated. I used a pseudo atomic structure in setting up the structure for the component stories architecture. I would focus on issues I faced for which solutions are not readily available on search engines. Storybook is storied for it's ability to handle MDX, JS and TS files as well as other file formats for the effective integration of component stories. However, integrating MDX files into Storybook isn't always straightforward. I'll share  challenges I faced with including and excluding specific file types such as MDX in Storybook, the solutions I tried, the errors I encountered, and how I eventually resolved the issue. 

• Storybook Version: v7
• Node Versions: v18
• Associated Technologies: React | TypeScript 

The Challenge

The goal was simple: configure Storybook to include all MDX files in our project's sidebar, except those beginning with a certain phrase e.g.'codefile'. Subsequently we also discovered ways to exclude other file types or formats in the course of bringing about the solution. This requirement seemed straightforward but led to a significant hiccup in our configuration process.

Initial Setup and Issue

Here’s the initial configuration setup in our .storybook/main.(js/ts) file:

```

import type { StorybookConfig } from "@storybook/react-webpack5";

const config: StorybookConfig = {
stories: [
"../src/**/*.mdx",
"../src/**/*.stories.@(js|jsx|mjs|ts|tsx)",
],

addons: [

"@storybook/preset-create-react-app",

"@storybook/addon-links",

...

"@storybook/theming",

],

framework: {

name: "@storybook/react-webpack5",

options: {},

},

docs: {

autodocs: "tag",

},

};

export default config;

```

Here’s the initial configuration setup in our .storybook/manager.(js/ts) file:

```

import { addons } from '@storybook/addons';

import { create } from '@storybook/theming';

import logo from '../src/res/icons/terakota-logo-text.png';

const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;

addons.setConfig({

theme: create({

base: prefersDark ? 'dark' : 'light', // Or 'dark', depending on your preference

// Branding options

brandTitle: 'Sample',

brandUrl: 'https://sample.live',

brandImage: logo, 

}),

```

However, this setup didn’t work as expected. Including the line;   "../src/**/[!codefile]*.mdx", in the stories config of the manager.js file was supposed to exclude files like codefile.mdx but instead, it caused errors and didn't exclude the files correctly.

In the Sidebar image below, we have a Story folder; Data/Charts. The Charts stories has two files; Usage.mdx and Charts.ts. The content of the Usage.mdx file is imported into the Charts.ts file as a sub documentation and we would rather not have it appear in the sidebar. Here, we will apply the various code solutions and show you how you can keep the Usage file out of the sidebar OR keep the charts file out of the sidebar.


 

Troubleshooting and Debugging

Upon encountering errors, we leveraged console logging to understand what files were being processed:

```

const glob = require('glob');
const path = require('path');

// Use an absolute path for clearer debugging 
const projectRoot = path.resolve(__dirname, '../src');
const mdxFiles = glob.sync(`${projectRoot}/**/*.mdx`);

console.log("All MDX files found:", mdxFiles);

const filteredMdxFiles = mdxFiles.filter(file => {
  const filename = path.basename(file);
  const isExcluded = filename.startsWith('usage');
  console.log("Testing file:", file, "Excluded:", isExcluded);
  return !isExcluded;
});

console.log("Filtered MDX files:", filteredMdxFiles);

const config = {
  stories: [
    "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)", 
    ...filteredMdxFiles.map(file => path.relative(projectRoot, file)), // Convert back to relative paths
  ],
};

```

This helped us identify that the pattern used wasn’t excluding files as intended. Instead, it seemed to misinterpret the exclusion pattern.

Finding the Solutions

Excluding MDX:
After several trials and understanding more about glob patterns and Storybook’s interpretation of them, we refined our approach. We corrected the path handling by ensuring that paths were transformed relative to the correct base directory:

```

main.ts

import type { StorybookConfig } from "@storybook/react-webpack5";

const glob = require('glob');

const path = require('path');

const projectRoot = path.resolve(__dirname, '../src'); // Adjust as necessary to point to your project root

const storiesRoot = path.relative(projectRoot, path.resolve(__dirname, '../src/stories'));

const mdxFiles = glob.sync(`${projectRoot}/**/*.mdx`);

const filteredMdxFiles = mdxFiles.filter(file => !path.basename(file).startsWith('usage'))

.map(file => path.relative(storiesRoot, file)); // Convert to relative paths from the stories directory

const config: StorybookConfig = {

stories: [

"../src/**/*.stories.@(js|jsx|mjs|ts|tsx)",

...filteredMdxFiles,

],

addons: [
...

```

This adjustment ensured that only the intended MDX files were included, and those starting with 'usage' were successfully excluded. This solution also works across most recent versions 
of Storybook including version 6.

Excluding .js or other stories: this aspect involved changes to the manager.js file as well as changes to the stories file, in this case; charts.stories.ts.
We included a filer which is seemingly only available in Storybook >=v7, and this filter allows you to add a tag using Storybook's addOn features. When this tag is added to the story,
the story will be automatically excluded from the sidebar. The word tag used for this example is 'pattern'

```
manager.js

...

brandImage: logo, 

}),

sidebar: {

filters: {

patterns: (item) => {

return !item.tags.includes('pattern');

},

},

},

});

```

in the charts.stories.ts file, we add the tag like so

```

import React from 'react';

import type { Meta, StoryObj } from '@storybook/react';

import AgeDemographyChart from '../../../components/stats/charts/ageDemography';

import Usage from './usage.mdx';

const meta: Meta = {

title: 'Data/Charts/Charts',

component: AgeDemographyChart, // Specify a default component for the stories file

parameters: {

layout: 'centered',

githubUsername: 'GabrielOnike',

},

tags: ['pattern'],

// tags: ['autodocs'],

} satisfies Meta<typeof AgeDemographyChart>;

export default meta;

...

```

with the tag added, the chats story will now be excluded from the Sidebar.


The below image show the Sidebar without Usage.mdx file post implementation.

Errors and Pitfalls to Avoid

Throughout this process, several key learnings emerged:

• Verify Path Relativity: Always check that paths are correctly relative to where the Storybook configuration expects them to be.
• Glob Pattern Accuracy: Be meticulous with glob patterns, especially when trying to exclude specific files or patterns.
• Compatibility Checks: Keep an eye on dependency versions, especially with major tools like Storybook, to avoid compatibility issues.

Conclusion

The journey to correctly configure Storybook to handle specific MDX files taught us the importance of understanding tooling deeply, particularly in how paths and glob patterns are handled. This experience not only refined our setup but also deepened our understanding of how Storybook integrates with our development environment, leading to more robust and maintainable configurations.

By sharing this story, I hope to assist others facing similar challenges, making their path smoother and their development process more efficient.

You may visit terakota.live and checkout the Storybook to view this implementation.

• AWS Service: Elastic Beanstalk
• AWS Platform: 64bit Amazon Linux 2/3.6.17
• Rails Versions: v6.0+ to v7.0+
• Ruby Versions: v3.0.4 to v3.2.2

Over the course of time, I have moved several of my applications to the Cloud. One of which is this my blog(Sojourn). While the applications for Cloud technology are vast, this writeup focuses on deployment of a Web Application for the cloud using AWS.  I will be narrating my experience in this process from my perspective deploying Rails applications as a Cloud DevOps Engineer specialising in AWS.
The goal? To deploy a Rails application seamlessly onto AWS Elastic Beanstalk using the AWS console, ensuring a smooth transition from development to production without sacrificing performance or stability.


CONTENTS

Introduction - Why AWS?

• Overview of AWS, Ruby on Rails, AWS Elastic Beanstalk, Puma, and Nginx

Setup and Deployment with AWS

• Initial deployment to AWS Elastic Beanstalk
• Setting up a Ruby on Rails application for deployment 
• Viewing errors with LogFiles

Encountered Problems and Solutions

• Problem 1: Deployment Failures due to Gemfile Issues
• Solution 1: Cleaning and Specifying Gem Versions
• Problem 2: assets:precompile Task Failures
• Solution 2: Environment Configuration and Precompilation
  
  
• Problem: Puma Configuration for AWS
• Solution: Conditional Configuration for Development and Production
• Problem: Nginx Reverse Proxy Configuration
• Solution: Setting Up Unix Sockets and Permissions

Using Github and AWS CodePipeline(CI/CD)

Common Pitfalls and How to Avoid Them

• Understanding AWS Environment Constraints
• Properly Managing Gemfile Dependencies
• Configuring Web Servers for Different Environments

Conclusion

• Summary of Key Takeaways
• Final Thoughts on Rails Deployment to AWS
• Relevant Resources 

1. Introduction

Deploying a Ruby on Rails application involves several key components, each with its own set of configurations and challenges. AWS, with its robust ecosystem, promises scalability, reliability, and a suite of services that cater to various deployment needs. For Rails applications, AWS Elastic Beanstalk and its integration with the Puma web server and Nginx reverse proxy form a powerful triad that can handle the demands of modern web applications. While it is possible to deploy such an application via the command line using SSH, we embark on this deployment using the AWS console which is less complex and more suitable for our needs here. Before deploying this particular Rails 6 application on Amazon Linux 2(AL2), I had unsuccessfully attempted to deploy the same on Amazon Linux 2023(AL3) but after several attempts over the span of weeks, I fell back to the deprecated AL2 which i was much more familiar with before finding success. However, I will still need to deploy on AL3 but that upgrade has been tied to the Applications' upgrade to Rails 7 in the future since the AL2 will be phased out in 2025. I will reserve that process for the Part 2 of this writeup. Note that my attempts at AL3 necessitated the dockerization of the app as well as the use of AL3 specific Gemfiles and setup which still very much linger in this deployment, this writeup and subsequent follow up updates.

2. Initial Setup and Deployment

The deployment process begins with setting up the Rails application for deployment, including configuring the Gemfile and ensuring the application is ready for the AWS Elastic Beanstalk environment. Make sure your project starts and runs successfully on your local/development server before proceeding with your production deployment. Below is a sample Gemfile which achieved deployment success for your pleasure.

```
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '>= 3.0.4', '<= 3.2.2'

gem 'rails', '~> 6.0.3', '>= 6.0.3.6'

gem 'buttercms-rails', '~>1.2.3'

# Use sqlite3 is only used for development not for production

gem 'sqlite3', group: :development

# Postgres(pg) is used for Production; for it to run locally you need the pg client installed on your desktop

gem 'pg'

# nio4r gave errors until its version was specified here

gem 'nio4r', '= 2.7.1', group: :production

gem 'activerecord'

gem 'rake'

# Specific use of Puma to get the app to work in production and development

gem 'puma'

# Use SCSS for stylesheets

gem 'sassc-rails', '>= 2.1.0'

# Transpile app-like JavaScript. Read more: https://github.com/rails/webpacker

gem 'webpacker', '~> 4.0'

# Ruby 3.2.2 bundle update required this Pysch gem to overcome deployment errors on AWS

gem 'psych', '< 4'

# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks

gem 'turbolinks', '~> 5'

# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder

gem 'jbuilder', '~> 2.7'

#Bootstrap JavaScript depends on jQuery. If you're using Rails 5.1+, add the jquery-rails gem to your Gemfile

gem 'jquery-rails'

# Reduces boot times through caching; required in config/boot.rb

gem 'bootsnap', '>= 1.4.2', require: false

# Gem to help manage meta tags

gem 'meta-tags'

group :development, :test do

# Call 'byebug' anywhere in the code to stop execution and get a debugger console

gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]

end

group :development do

# Access an interactive console on exception pages or by calling 'console' anywhere in the code.

gem 'web-console', '>= 3.3.0'

gem 'listen', '~> 3.2'

# Spring speeds up development by keeping your application running in the background

gem 'spring'

gem 'spring-watcher-listen', '~> 2.0.0'

end

group :test do

# Adds support for Capybara system testing and selenium driver

gem 'capybara', '>= 2.15'

gem 'selenium-webdriver'

# Easy installation and use of web drivers to run system tests with browsers

gem 'webdrivers'

end

# Windows and AL platform does not include zone Info files, so bundle the tzinfo-data gem

gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
```

Viewing errors with LogFiles

The most effective way to debug AWS deployments is via the logfiles. These log files can be found in your environment(see Image below). While you can view the last 100 lines of the logfiles in the browser, AWS still requires you to download your log file bundles to enable full view of your log files. I found myself doing alot of log bundle downloads since the last 100 lines is sometimes insufficient to identify an error. One would hope that a future AWS console UI will enable a user to view updated full log files in the browser without having to exit the browser environment.
Some popular log files i had to regularly view in order of frequency include; 
- eb-engine.log (for general deployment errors), 
- cfn-init.log(for prebuild errors associated with your eb-extensions), 
- puma/puma.log(for puma errors to confirm if server is responsive) and
- nginx/nginx.log(for nginx error lookup) 

3. Encountered Problems and Solutions

Problem 1: Deployment Failures due to Gemfile Issues

Solution 1: It's crucial to ensure that the Gemfile is clean and all dependencies are specified with compatible versions to prevent deployment failures. Some of the Gems required for Rails 

Problem 2: assets:precompile Task Failures

Solution 2: Configure the environment properly and ensure all assets are precompiled before deployment. This may involve running precompilation locally or configuring it to run on the server during deployment.

4. Configuring Puma and Nginx

Configuring Puma and Nginx correctly is crucial for the successful deployment of a Rails application on AWS.

Problem: Puma Configuration for AWS
During the deployment process on AWS, a significant hurdle encountered was the configuration of the Puma server in a production environment. The challenge arose when attempting to bind Puma to a Unix socket at /var/run/puma/my_app.sock for communication with Nginx, the reverse proxy server. This setup is typical for production environments to enhance performance and security. However, it led to errors when running the Rails server locally and on AWS.
Example Error:
On AWS, the configuration did not manifest as an error message directly but resulted in a 504 Gateway Timeout error, indicating a failure in communication between Nginx and Puma.
Locally the error manifested as:
Exiting ...rvm/gems/ruby-3.2.2/gems/puma-4.3.12/lib/puma/binder.rb:327:in `initialize': No such file or directory - connect(2) for /var/run/puma/my_app.sock (Errno::ENOENT)

Solutions: Use conditional configuration in config/puma.rb to differentiate between development and production environments, especially for Unix socket bindings. The below can be added to your config/puma.rb file

rails_env = ENV.fetch("RAILS_ENV") { "development" }
if rails_env == "production"
  bind "unix:///var/run/puma/my_app.sock"
  pidfile "/var/run/puma/my_app.sock"
else
  port ENV.fetch("PORT") { 3000 }
end

Creating a Procfile
There was also a need to create a Procfile at the root of the project to enforce a Puma config creation since AWS sometimes hindered this. In the Procfile we placed the following code to create the Puma config and execute it:
web: bundle exec puma -C /opt/elasticbeanstalk/config/private/pumaconf.rb 

Problem: Nginx Reverse Proxy Configuration
The configuration of Nginx as a reverse proxy to forward requests to the Puma server via the Unix socket posed another challenge. The 504 Gateway Timeout error in production was a symptom of misconfiguration or the absence of the Unix socket Puma was supposed to bind to.

Solution: The solution involved ensuring that Nginx was correctly configured to proxy requests to the Unix socket at /var/run/puma/my_app.sock. This required verifying the Nginx configuration files and ensuring they pointed to the correct socket path. Moreover, the .ebextensions script mentioned earlier played a crucial role in creating the necessary directory structure and permissions for the socket file, allowing both Puma and Nginx to communicate effectively.

Using Github and AWS CodePipeline(CI/CD)

Continuous Integration and Continuous Deployment (CI/CD) allow for the automation, testing and deployment of applications in a fluid manner. AWS CodePipeline, in conjunction with GitHub, provides a powerful platform for implementing CI/CD for Ruby on Rails applications. Every time there is a code change AWS CodePipeline automates the build, test, and deployment phases of your application. This section assumes you have a Ruby on Rails application hosted on GitHub and aims to deploy it using AWS Elastic Beanstalk. The stages involve;

- Create a New Pipeline

- Source Stage : Here we use Github version 2, connect to our Github account and add the desired Repo and Branch 

- Build Stage
We Skip the build stage here since our build process is described in our project files

- Deploy Stage: Our deployment provider is Elastic Beanstalk, we select the region of our project and select the application and environment name


- Review and Create

We review all the details provided and proceed to Create the pipeline

Finally our app begins the process of deployment and a successful deployment looks like the image below

5. Common Pitfalls/Errors and How to Avoid Them

• Understanding AWS Environment Constraints: Be aware of the AWS environment's limitations and configurations, such as directory paths and user permissions.
• Properly Managing Gemfile Dependencies: Keep the Gemfile clean and ensure all dependencies are compatible.
• Configuring Web Servers for Different Environments: Use conditional logic in server configuration files to adapt to different environments seamlessly.
  
  

6. Conclusion

Deploying a Ruby on Rails application to AWS Elastic Beanstalk with Puma and Nginx involves understanding and navigating through a series of challenges. By addressing these challenges with the solutions provided, developers can ensure a smoother deployment process and a more robust application environment. This journey underscores the importance of meticulous configuration and an in-depth understanding of both the application's and environment's requirements.

Summary of Key Takeaways

Deploying a Ruby on Rails application to AWS Elastic Beanstalk involves several critical steps and considerations that can significantly impact the success and reliability of your application in a production environment. Here are the key takeaways from our discussion:

• Proper Gemfile Management: Ensuring your Gemfile is correctly managed by specifying gem versions and resolving dependencies is crucial to prevent deployment failures.

• Effective Use of Environment Variables: Leveraging environment variables for configuration settings enables smoother transitions between different environments (development, test, production) and enhances security.

• Asset Precompilation: Understanding and implementing the asset precompilation process is essential for Rails applications to ensure assets are served correctly in production.

• Database Migration: Automating database migrations as part of the deployment process ensures your database schema is always in sync with your application's expectations.

• Conditional Puma Configuration: Setting up Puma with conditional configuration for development and production environments allows for flexibility and prevents deployment issues related to web server configurations.

• Integrating CI/CD with GitHub and AWS CodePipeline: Automating the build, test, and deploy phases through CI/CD pipelines not only saves time but also reduces the risk of human error, ensuring a more reliable deployment process.

RELEVANT RESOURCES
Some of the relevant resources i used to overcome some pitfalls and errors are listed here below for your use. For further exploration in overcoming potential issues and to deepen your understanding of deploying Ruby on Rails applications to AWS, the following resources can be invaluable:

- https://www.stackoverflow.com/questions/40938155/right-way-to-deploy-rails-puma-postgres-app-to-elastic-beanstalk 
- https://stackoverflow.com/questions/39525129/installing-gems-fails-in-deployment-aws-elastic-beanstalk
- https://stackoverflow.com/questions/73012901/deploying-rails-7-app-on-elastic-beanstalks-fails-with-nokogiri-error
- https://stackoverflow.com/questions/72307187/how-to-install-postgresql-client-to-amazon-ec2-linux-machine
- https://stackoverflow.com/questions/65544527/aws-elastic-beanstalk-ruby-on-rails-6-app-deployment-error-with-nginx
- https://stackoverflow.com/questions/30355569/rails-application-deployed-on-elastic-beanstalk-with-puma-fails-502-errors-on/69092359#69092359
- https://stackoverflow.com/questions/66400979/why-am-i-getting-502-bad-gateway-nginx-1-18-0-rails-app-on-elastic-beanstalk
- https://medium.com/swlh/what-should-you-know-about-deploying-a-rails-app-on-aws-elastic-beanstalk-fa47b9d834ed
- https://medium.com/@williamjoshualacey/deploy-rails-app-to-aws-2854b2338708
- https://medium.com/@rachelchervin/aws-elastic-beanstalk-gotchas-with-rails-d23ac21487f7
- https://www.codewithjason.com/deploy-ruby-rails-application-aws-elastic-beanstalk/
- https://bentranz.medium.com/deploy-ruby-on-rails-application-to-aws-elastic-beanstalk-amazon-linux-2-138654b1ce41
- https://bentranz.medium.com/setup-continuous-deployment-pipeline-for-aws-elastic-beanstalk-5f8edb38d872
- https://www.honeybadger.io/blog/rails-6-aws-elastic-beanstalk/
- https://repost.aws/questions/QUvEtL971cSsK0x0De-OTljw/how-can-i-deploy-a-rails-app-slite3-to-aws
- https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ruby-rails-tutorial.html
- https://dev.to/forksofpower/make-the-move-from-sqlite3-to-postgres-in-rails-6-34m2
- https://copyprogramming.com/howto/deploy-rails-app-from-github-to-aws-elastic-beanstalk
- https://dev.to/sname/deploy-rails-app-from-github-to-aws-4kk0
- https://semaphoreci.com/community/tutorials/how-to-deploy-a-ruby-on-rails-application-to-elastic-beanstalk-with-semaphore
- https://benreynolds4.medium.com/gateway-timeout-deploying-rails-application-to-elastic-beanstalk-88bc8a0c9833
- https://www.zshawnsyed.com/2020/06/10/deploying-to-aws/
- https://www.zshawnsyed.com/2020/06/02/setting-up-aws/
- https://www.freecodecamp.org/news/how-to-deploy-a-rails-5-2-postgresql-app-on-aws-elastic-beanstalk-34e5cec3a984/

Well turns out, a lot !

This piece exposes my infrequent foray into farming, my love for growth and development and the way technology affects farming in this time. I also discuss the depth of technological penetration in local farming communities within the scope of this article. I journal the role non-governmental organisations(NGOs) play in the local scene, opportunities abound in the sector, the art of community engagement, penetration and negotiation in a subtle approach.

In short, this piece is about an adventure. 3, 2, 1 ...

Let's dive.

CONTENT

• Introduction
• The Journey
• Engagement
• Farming and Technology
• Issues, Solutions and My Proposal
• Business and Value Chain Prospects            
• Conclusion

INTRODUCTION

My initial incursion in commercial farming as an adult was in the last quarter of 2016, working for a start up in a digital and business support role. My stint there was short but my exposure was wide. It was at this company I first built a business website. At the time, the company ran a budding export company alongside the consulting side of the business. The prior experience of our lead in the field of agri-business influenced our attempt at the agri-export chain. I was a part of this movement. We were trying to export a cash crop with targeted foreign demand at the time. We quickly made connections to export markets. I brought to bear all i knew about farming and started to learn all that was relevant to this agribusiness.

Networking led us to the Agra Innovate trade show in Lagos. An opportunity to network, market and also learn more about the business. It was at this summit I got carried away by the focus on tomato exports. At the time, the hot topic was the over 40% post-harvest loss across the tomato value chain in Nigeria. In Nigeria about 200,000 Nigerian farmers grow more than 1.8 million metric tons of tomatoes per annum on approximately 170,000 hectares, against the demand of 2.3 million MT per annum. This leaves a deficit of at least 500,000 metric tons. These post harvest losses occurred partly due to lapses in preservation, low productivity, poor transportation, near absence of commercial scale technology, imbalances in market forces as well as inadequate post-processing. These issues all came on the heel of a wide spread pest attack which had exposed the porousness of the country to looming dangers of food scarcity. 

Unfortunately, tomato wasn't our primary focus at the trade event. We were focused on another cash crop - Fonio. However, I allowed myself soak information as i went from stall to stall, learning all i could from the event about agribusiness while marketing.

My experience here is noteworthy as it marked my first sojourn into agribusiness. Though unrelated, I had another short but very practical stint in animal husbandry and livestock business almost 2 years thereafter in the ancient city of Ibadan. I may someday detail that sojourn. This tale is for 2019.

Fig. 1 Map View of Kubau

2019 - Kubau

Fast forward to a time in 2019, I was a freelance developer working out of a co-work space in northern Nigeria, I was mostly on my laptop ironing out JavaScript. A friend encouraged me to volunteer for a contract role as a Local Community Trainer (LCT) for an International agri based NGO undertaking a large scale agri project across mostly northern Nigeria. I leveraged on my earlier mentioned foray in agriculture which placed me in good stead.

At the one week training, we learned the goals of the job. That is, reducing post-harvest losses in the tomato value chain to improve smallholder farmer livelihoods in Nigeria. We were to go about this by data gathering and capture, training and retraining of local farmers, Identifying and analysing needs based reports, incentivization and the establishment of communication channels with relevant stakeholders. It sounded like boardroom stuff or the procedure for corporate marketing but this was way way localised and as I would eventually discover, more intricate. Personally, I saw an opportunity to improve my command of the local dialect(Hausa) and engagement/identification of viable business opportunity along the supply chain. It wasn't full-time but required certain amount of hours a week and this was to last through the Dry season. I found out it was possible to merge the time with my computing pursuits. Field days were the toughest. I buckled up for the experience.

We learned the art of community engagement and the necessity to understand and abide by the culture we were to face. These things were key to manoeuvring the tribal dichotomy still prevalent in these parts in order to execute the task. Some of us were familiar with the local culture. We had some indigenous people aiding the work.

However, it is easier said than done.

Thus did I begin my sojourn in Kubau.

THE JOURNEY

We were in teams. My team consisted of a group of 5 with one lead reporter(we sometimes alternate this duty). We were spread across identified communities under local government(s) bordering different states. It was at least a good 3 hours from Kawo, at the fringe of Kaduna main town.  Our mode of transportation: we mostly carpooled. I must mention, it is hard to avoid wear and tear for any vehicle that undertakes a 4 hour journey on very patched-up stretch of road. Irregular car break downs got us accustomed to the public transportation that consisted of ramshackle buses, wagons and space buses at various undefined stops. Then, the aim was getting to the destination and accomplishing the objectives. Also, it is important to know the pronunciation of some bus stops to avoid getting lost. The generally spoken language is Hausa. In the depth of these parts, you'd barely hear a word of English spoken. We drafted reports, made observations, met up at specific times, re-strategised, acted as the link between the communities and the NGOs, while meeting our targets.

Similar teams were distributed across the focus areas. That is, the areas where post harvest losses were most prevalent in the farming regions of northern Nigeria.

Fig 2. Major Tomato farming states with significant Post-Harvest loss in northern Nigeria (2018)

On field days, days like this, I shut my laptop, relegate programming to my mind, wear my boots and pick up a hoe.

ENGAGEMENT

Our first few weeks were subsumed establishing relations with the village/community/farm leaders. For effective coverage, we would split communities and target each scope in twos. Attached with well structured data templates, we probed for relevant information and assembled the data into something cohesive. Our most efficient tech was a customised android tablet, equipped with a detailed custom form app. This device had some offline capabilities that gave room for activities like farm mapping and data collation.

Local heads would usually inquire about our purpose and then connect us with those who can assist within the community. This would include the most literate and effectual individuals for the tasks. It is important to note that here, some of the traditional heads also serve dual functions as religious leaders. On our part, we sieved for suitable leaders and made draft assigns for the parts of the programme. We swiftly began engagement with the farmers and sensitised them on our purpose. We undertook the first of other seminars on enlightenment and then several others on; yield improvement methods, pest control, techniques and tools such as the ZECC setup and Zinc dryer.

Our meetings followed a similar path. Pass the meeting notice to stakeholder, Identify and secure the meeting location, prepare the man power, learning resources(books, pamphlets etc), then send out reminders prior to and on the event. It is worthy to note that we had to work around the farmers schedules as they had market days and days for aggregator interaction or local events and we had to make sure these things don't clash or spill over into our agenda. These meetings also involved light refreshments catered for by the project.

We would plan out the agenda for the seminars and then effect necessary translations even including the learning material even before our journeys. Engagement is not a one off affair but an attempt to establish, if possible, life long in roads into the select farming communities to enable growth monitoring, keep a tab on opportunities as well as provide the farmers with access to resources and information they otherwise would not have known. 

How did i deal with the difficult translations? Here's a pro tip: google translate Hausa is quite an effective tool. I used it to pre evaluate discussions and responses, some of which have now become a part of my vernacular vocabulary.

Fig 3. On a tomato farm in Kubau

FARMING AND TECHNOLOGY

Earlier i mentioned the Dry Season. The Wet season covers the months of May through September in Northern Nigeria. It starts a month earlier and ends two months later in the southern Nigeria. The dry season occurred in the other months. I was engaged toward the ending of the wet season. The seasons are important in farming because they enable long term projections, help with crop rotation and also determine farming schedules; planting, harvesting etc.

Other major cash crops grown in rotation around these parts include; peanuts (groundnuts), sugarcane, onions, soybeans, maize, zobo (hibiscus leaves) etc. These other cash crops play a large role in the living standard of the area and its locals. It is important to note that tomatoes and onions are perishable products but also products that are readily consumed(market availability) all year round. 

Tools: The farmers made use of local farming tools and techniques as stable power is absent in these parts. The power lines also do not extend into the farming communities. This put a cap on the potential farm yields as the seasons count by. These tools include, hoes, cutlasses, sickles, shovels etc. and it is exceedingly labor intensive with farmers heading out to the farm in the mornings and coming back at sun down on farming days. Rough and inadequate landscaping also ensured that mechanical tools wouldn't perform optimally in farming processes.

Irrigation: Water is life and access to water for farming does make the difference between a good harvest, a poor harvest and a terrible outcome. This is why all the farmers cannot grow similar crops over time or the the same location. My community had a small lake which filled with water during the rains and dries up sometime in the dry season. This water source sometimes allowed water out and i suspect was some sort of aquifer. Farm lands located close to the river bank usually enjoyed better harvest. Capable farmers would sometimes make use of water pumping machines and really long hoses to get water into their farms. Incapable farmers made up the larger demographic and suffice to say, irrigation was grossly inadequate and low productivity, rife. In fact, irrigation made up the bulk of interest from farmers who initially mistook our mission for a charity attempt. Hence, crop choice was heavily reliant on the rains from the skies(seasons) even though arable land abound all year round. This meant that there is usually a glut during the rainy seasons when farmers want to take the most advantage of the easy produce and then a period of insufficiency during the dry seasons when farmers opt for non perishable and easier grown cash crops. These were some of the issues we sought to address.  

Fig 4. Preparing a tomato farm and Irrigation

We weren't the only players in the game as several other players and stakeholders had existed long before we came. It is important to take note as they play many roles and influence information penetration, pricing and are also market forces influencing price, market demand and also supply. These players include Aggregrators, Offtakers, Sellers etc. Prominent and established players included the Federal Government and global NGOs via the FADAMA projects, Babban Gona(major aggregator) and local players like Tomato Jos amidst a host of others. Farmers usually sell to reliant aggregators or directly in the open market weekly and it is between these two that prices generally oscillate. The aggregators in turn sell to Off takers who move the goods for export or retail. These transactions are made weekly.

Data was conveniently gathered on all metrics and respective players. This data was outlined in Excel Sheets and custom form templates for easy aggregation of data. The farmers operated via bodies such a co-ops locally called kungiya (group) or Kungiyoyi (groups). Thus, to fine tune our activities especially those involving incentives such as access to finance, technology or policy, we operated through such co-ops facilitated by the farm heads to enable proper communication channels and access.

Farming Tomatoes: Tomato farming can be done on an open farm, greenhouses, gardens, pots and containers. Tomato fruits are then harvested after 60 – 90 days depending on the variety. Tomato seedlings are usually managed in nurseries for 3 – 4 weeks. The major varieties of tomatoes used within the farming communities involved here include;

• Graffiton,
• UTC,
• Rio

... amidst others.

These tomatoes are harvested at the start of the turning stage, giving them about 7 days until full maturity. These 7 days should ideally cater for packaging from farms and then transportation to the middleman and finally to the consumer. This inevitably meant that there is a rush from harvest to get the goods out fast or stand the risk of the items actually going bad. Here i'd like to give a brief insight into transportation and farmer woes. 

In the towns major city, a major market exists at the central market locally called chechenya market. Here is where major retail purchase is made. My farming head regaled me with the tales of farmers who will pour out their tomatoes on the floors of the market and stamp on them with tears in their eyes. Why ? Most farmers saw no need in bringing back unsold produce to their towns because they would have rot. Though this may look like a preservation problem, it is actually a market and supply issue.                                                                                                                                               

In transporting the tomatoes, the farmers were faced with hurdles starting from the packaging of the fruit. Fruits were picked and placed in cylindrical rafia baskets of about 3 sizes ranging from big to medium which are made and sourced locally. The rafia baskets had holes made for air and are also cheap and go for about two dollars(NGN 600 - 850) at the period these events took place. These rafia baskets would be piled to the top like a mountain and are covered with cuts from jute bags to allow air flow.

The rafia baskets posed issues starting from sticking out rafia fibres which would pierce and damage the fruits, thereby hastening the shelf life. Also, bad tomatoes would quickly corrupt other tomatoes thereby hastening the rot process of an entire basket. Though the shape and nature of these baskets allowed for topping up extra produce as well as manoeuvrability while packing them into transport vehicles, this also meant that the produce gets squeezed and is more susceptible to heat and damage which further affects the lifespan. This was another issue we sought to address.

Fig 5. Tomatoes in Rafia baskets set for transportation

Security is key to farming in these parts and though unfortunate, it is important to mention long term schism between farming communities and fula herdsmen. This issue has existed probably long before i was born. It still plagues Nigeria at the time of this piece published. I got to experience it first hand, seeing farmers summoned from their sleep by local calls to rush to their farms to protect it from invaders. I also saw carefully cultivated farmlands trampled and left destroyed by herdsmen who couldn't care less but were much more focused in getting their cows fed. An issue like this is front burner in these communities and can be very easily escalated into violence.   

ISSUES

Major issues which could be immediately tackled stemmed from the storage and preservation to the transportation processes; 

• Preservation
• Storage
• Transportation
• Market and Supply                                                                                                                                                                                                                                                                                                                  

SOLUTIONS AND MY PROPOSALS

To help the farmers tackle these issues, we embarked on sensitization of farmers through regular meet ups and seminars usually hosted in the communities. Some of the solutions we proposed and facilitated were simple but highly effective.

Preservation: Here we sought to show the farmers better techniques. The absence of electrical supply in these communities meant that electrical cold storage such as refrigeration was ruled out. However that isn't the only solution. With abundance of wood charcoal, we introduced and taught about a not well known but effective technique using of wood ash in tomato storage which could prolong the shelf life of tomatoes for as long as 3 months. We also sensitized the farmers on better ways to manage/handle preservation.

Storage: Here we taught about a local way of elongating the tomatoes life span by keeping it cool before transportation. You have seen ZECC at the start of this write up and here we talk about it in detail. ZECC stands for Zero Emission Cooling Chamber. The ZECC is a brick construction (brick construction is popularly known for its cooling effect in building interiors), which is built by creating a rectangular space slightly below ground level. The foundation is dug slightly deeper and the brick walls are built in two columns leaving a light space between each column. This construction is then elevated to about 5 feet above ground level and then clay(known for retaining water) is used to fill up the space between both columns. All these materials are abundant in the locales including sufficient space for erecting this structure. This construction has one or two removable roof structures(depending on the size of the ZECC) which are built with rafia, wood columns and jut bag cutouts which all allow for flow of air and retaining the internal temperature. This construction can be completed in 2-3 days with all materials available. The farmers can then place tomatoes within the hollow/interior and cover with the rafia bags. The clay filling between the columns are then watered morning and night. This enabled the brick walls to have a water 24/7 and maintain temperatures of 14 degrees celsius or less. During a cold harmattan mornings, these constructions could enable 10 degrees which is sufficient to increase shelf life, control heat and improve storage for up to 14 days. This is not a new technology per say as clay pots were a known way to store cool drinking water to quench thirst in equatorial regions where temperatures could hit 40 degrees plus on hot days. I did build a ZECC with my communities and they went ahead to build 2 more during the course. I would address the use of a Zinc Dryer under Market and Supply as it indicates a new paradigm.

Vid 6. How to build a ZECC

Transportation: Though creating a new transport system, fixing horrible roads or buying new vehicles were far beyond our purview, we could however influence aspects of the process such as the cargo process. Here we introduced RPC(Returnable plastic Crates) made from plastic/rubber for storage and cargo. These were meant to be a replacement and help with phasing out for the rafia baskets and they had seemingly more advantages such as a more efficient way to stack or retrieve loaded crates in vehicles. It also kept the tomatoes better preserved as they faced less damage from heat, in storage or while in transit.

Unfortunately, the RPCs signified a bigger change than anticipated. Just as our current road and car width are carryovers from calculations during the era horse-drawn carriages, the rafia baskets play a major role in pricing as basket sizes not weight are a major determinant for pricing. The RPCs also cost upwards or 5 dollars even with our rebate offers. The absence of wide spread use of RPCs meant that the crates weren't actually returnable as farmers who purchased them would have to wait for delivery to get their crates back. It also meant that the farmers would need a new pricing system probably based on weight. The crates were also not easily stackable for retrieval as the bottom dimension matched the top like a square so they wouldn't sink into each other. This signified the start of poor adoption of this newer method of cargo.

I propose a better solution of rafia crates instead, which can be locally made. It will take repurposing the construction materials of the cylindrical baskets and designing them to carry the weight of the former. The rafia crates would still be as cheap as it is locally sourced. The bottom could be made with less width so as to enable better efficient stacking on retrieval.

Fig 7. Stacked RPC Crates

Market and Supply: To solve the issues of supply and market meant two things, tackle the product itself and then target inefficiencies in the demand and supply chain. Starting with the product, we introduced a way for famers to reduce their woes. By this i'm referring to the little tale i told in the farming section above. The Zinc Dryer is a type of solar dryer and DIY solution for repurposing rotting tomatoes which buyers and farmers alike reject and whose only former use was as fertilizer.

The Zinc Dryer takes advantage of the sufficient heat in these zones and the ability of Zinc in retaining this heat to create sun dried tomatoes or tomato powder. This Zinc can be sourced from local zinc roofing sheets which are in fact the cheapest roofing solutions across the country. To construct this, Zinc, wood, gauze, nails,  metal strings and hammers are more than adequate. This structure can be built locally by creating a square wooden frame. At the bottom of the frame is a zinc sheet. A few inches above the bottom, a gauze is placed which is where the tomatoes will lie. a few inches above is another zinc sheet and above that, another zinc sheet. The effect being that as solar heat strikes the zinc sheet, it soaks the heat and passes it to the sheet below ensuring that hot air is circulated at the top layer. This heat then hits the tomatoes on the gauze below, shriveling and drying it up further. The zinc at the bottom ensures that heat isn't lost in this process but is kept circulating to further dry the tomatoes. This process can dry up tomatoes in 30 hours. Of course, there are much more efficient designs for the solar dryer but my described design above is cheap and can be done yourself in a day with the materials available.

The zinc dryer showcases a new paradigm as dried/powdered tomatoes isn't popular in the market even though it is still efficient and nutritious. This is due to the agrarian nature of the country and an averse nature to consuming heavily preserved perishables. Apart from that, other challenges are the final outcome whose color may take on a dull red which doesn't quite portray tomatoes as we know it. These challenges can be overcome somewhat. Whereas, products from the Zinc dryer would mean that dried tomatoes can then be exported to further markets thereby improving supply and storage.

Fig 8. Domestic Zinc Solar Dryer

Inefficiencies in the supply chain include barely functional transport vehicles whose regular breakdowns in inter state transportation meant shorter shelf life for the products. Hopefully with better efficient transport systems, tomatoes could be delivered by train to Benin from Kaduna in less than 24 hours rather than the lucky 48-72 hours currently attainable. I mention Benin at this point because i did attempt to introduce new supply routes to the farmers but absence of capital and risk meant that that venture had to be paused.

BUSINESS AND VALUE CHAIN PROSPECTS

In finding solutions, one cannot extricate the product in the business from the business of the product. I have mentioned ways to improve the products preservation, storage and transportation but we know change is easier said than accepted. 

In improving the value chain, solar dried tomatoes if properly marketed, can be readily adopted with the right packaging. It is also cheaper and easier than processing tomatoes. It cuts out waste and produces joy for the farmer who wants nothing more than the consumption of produce in its entirety.

Markets abound and the dynamics of market demand and supply are ever changing. Finding new markets is also key to stabilising prices during peak and off seasons. One with the right capital and morale can identify and introduce new markets. This will also spur the farmers to grow tomatoes even during the dry seasons.

Greenhouses are not common in Nigeria. This is partly due to the absence of winter but more importantly, knowledge gaps on how green houses work. Before this sojourn, I was partially involved in a bamboo greenhouse project which died prematurely from lack of government interest and poor adaptation. These greenhouse made from Bamboo were cheap and efficient and if constructed in their numbers, could make a great difference in the supply chain.

In improving the value chain, I also propose tackling the irrigation challenges mentioned above as a lasting panacea to this issues. With the availability of aquifers across the country, boreholes can be easily sunk to get water for farming activities. Irrigation is actually the difference between sufficient supply and insufficient supply in these parts. Also the absence of power meant that farmers cannot evolve to industrial processing techniques. Though there is still much room for perfecting the current processes. Tackling these issues calls for government support and intervention though.

There is a lot of room for business opportunities from sale of some mentioned equipments to even sensitization. Though my sojourn here focuses on Tomatoes, these farming communities go way beyond tomato production and are deeply involved in other produce. There are viable cash crops such as soya beans etc. and quite easy ways to capitalize on the markets. For example, purchase of some cash crops during peak seasons can yield over a 100% gain if sold some months later during off season. These a just a few agribusiness tricks i got to learn during this sojourn. Of course the requisite capital and network play a huge role.

There are still a lot of processes that can be mechanised such as destoning of beans or in the separation of bark from crop. These processes are still carried out in very crude manners and affect the final output of the product. These are areas where capital and power supply can make a very huge difference.

CONCLUSION

My sojourn here cannot be complete without mentioning the efficacy of those i worked with from my supervisors, teammates and especially the farming communities who were receptive. I recall Hajia, who was my community farm lead. Hajia took me close and would spur farmers and hands where required to reduce the stress of the job. She also made me improve on the spoken dialect and made worthwhile introductions where necessary while enlightening us on the local field and its players. She gave me valuable information which was necessary for the success of this sojourn and my experience as well. We still speak.

I enjoyed local dishes such as maiyan taushe and masa, during stop overs with my team mates at Zaria, or snacks like Tsakin-pate(pa-tai), awara , alale, maiyan kuka to mention a few which Hajia sometimes prepared or we bought after long farm days.

The ingenuity in farming and taking development beyond the keyboard goes beyond the farm or hectares/acres of land being used. I mentioned earlier that on non farming days, I would be back at my desk writing software code just as i'm writing this piece. In the tech hub/community back in Kaduna town, this ingenuity could also be found as agrarian kids sought solutions to farming problems at home. I got to see a young man in this tech space build an IoT device which could relay livestock data such as temperature levels, livestock count etc. to anywhere or anyone with an internet connection. A farmer could even turn on/off the lights/heating remotely via this very small device which is key in poultry farming. The prospects for technology in improving farming processes are still being pursued. Though i observe that sometimes, talented individuals such as these as sometimes snatched up by the 1st world before they have time to implement or permeate these processes. 

There have been big players who have gone into farming and failed or had are rethink such as the Dangote Group. Worthy of mention is Tomato Jos which has showcased resilience and has carved a space for itself in the tomato processing and supply chain business. Nigerias import policy which enables importation of processed tomatoes also stifles market growth but should not be a determinant in going into this market. Why? because export opportunities abound and i know this from my agri experiences. One does not have to focus on the local market to be able to make proper gains. Even though i see the wisdom of free market, I support a level of control to enable local players and SMEs to survive in unmapped/rugged business terrain(s).

My hope is that this exposé showcases opportunities, issues and spots for improvement. It also shows that farming can be embarked on by anyone with the right drive. There is profit in the sector as a viable motive to engage and improve the community around you. Before the end of this sojourn, I had interacted with over 500 farmers, facilitated 3 ZECCs and some Zinc Dryers, made new friends and built a network within the space and enabled improvement in the agricultural processes and the community as well. Incase you feel there isn't much profit in food, I quote my sister who frequently reiterates that 'feeding can never run out of business because people just have to eat'. That being said, my foray in farming/agribusiness is far from over. 

I have observed that though farming is a long term investment, sadly most people rush in for quick gains thereby loosing sight of what is important in agribusiness. Farming itself teaches patience since a method to hasten the timeline of tomato growth doesn't exist yet. It must follow the natural order as is obtainable in many other spheres of life. I would know this now, being a quasi-farmer myself.

RESOURCES

• Nigerian Climate (wet and dry seasons)
• Zinc Solar Dryers
• Tomato Drying Paper
• Paper on Solar Drying
• Building a ZECC
• Yieldwise and TechnoServe in Nigeria

You may be thinking ? Why React with PHP and how does Shared Hosting, CPanel and NGinx/Apache come into play ?

Well, I possess shared hosting which is managed via an Admin Interface known as CPanel. This shared hosting houses some of my applications. When I made the decision to redesign some of my pages/services while learning React, especially as I got comfortable around the technology, I wasn't ready to move all hosting services to the cloud or otherwise even though this would have been an ideal and the trendy approach.

Also, it would have been pointless shifting several running services because of a few Webpages in this case. I'd rather build out new services on the cloud and migrate the old over time. This is also because i'm quite familiar with PHP servers and still comfortable around it. Continuing to use my shared hosting also saved costs.

Note that I do have services on the cloud. Also note that a lot of traditional hosting companies have moved some of their services on the cloud to take advantage of its benefits.

This is not for a comparison between services but rather for a suitable work around mixing both.                                                                          

Now, I'd decided to see how i can make these different technologies(ReactJS, PHP, CPanel) work together.

My options for doing that included the following approaches:

• Calling React using JavaScripts <script> tag

This option allows me to sprinkle React in an existing application by calling it via JavaScripts' tag only on the pages where I require React. It can be integrated into any technology that can handle JavaScript.

Pros: This is a very lightweight approach as it doesn't ship with all the weight/baggage that comes with the full React setup.

Cons: If you have to ever expand Reacts functionalities within your app, you will spend time having to keep adding modules( which would have been in a full React setup ) to support your project.

• Using the Create React App  method only

You may be familiar with the command above which creates a scaffold for a react App. This is the official out-of-the-box setup and ships with the basic dependencies you will need. It can be packaged and served via varying servers. Usually its backend service is handled with NodeJS and Express and runs mostly on the cloud.

Pros: You don't have to keep installing dependencies and it possesses all the basic things you need to run a fully optimised React App.

Cons: It can ship with the full package so it can get bulky. You probably will have dependencies you may never use. This method is also optimised specially for React so attaching disparate technologies may be a hassle.

• Decoupled Approach

Here, I split up the functionalities I want for only my React App such a building only the user interface(UI) layer in React, calling React only where necessary, minimising the app with React's Build command and running a different/separate backend service. Essentially a mix.

Pros: Lightweight since I only make use of React where necessary. Easier to slowly implement/increase Reacts functionality across an existing system as one can add pages/services at ones own pace. Easier to integrate other existing programmers and technologies.

Cons: Most suitable for programmers skilled across technologies as well as a steep learning curve getting dissimilar technologies to work together. 

As you may bet, I had to go for the 3rd option. Decoupled Approach.

Decoupled

It may interest you to know that my portfolio web application is decoupled with its blogs service as a headless CMS running on Rails in the cloud, PHP for some front and backend services and React for other parts of my UI. They're all linked together with Https.

Hopefully, there'd be an article dedicated to the full intricacies of that journey.

That article is not this article.

However, this piece engages the tail-end aspects of implementing a decoupled service using the specified technologies and focuses on the Key to combining these different technologies which is where it matters most.

System Design

I went about building just the pages i needed for my react app. In my portfolio case, that was my: About, Projects and Contact Pages. 

I left my homepage under PHPs service thereby keeping my entry/index/main page well connected to the rest of my existing services on the shared host.

A majority of my backend also remained firmly in PHP and CPanel's grasp.

Build

Since my homepage already existed in PHP, I had to design the UI and frontend for just my React pages.

I used the Create a React App method for this so as to enable me have access to all node functionalities. I then built the pages accordingly.

When you are sure your react app pages are set and ready for deployment, you should go to your package.json  file in your project folder's root and change your homepage accordingly.

I'm assuming here that you already have a custom domain for your application. Use this domain path for your homepage.

See sample below. 

  "homepage": "https://mywebsite.com",

For deployment, having certified that all my files are set, I use the React Build command to prepare those pages for production. See the command below.

npm run build

This command will create a build folder of my static site but minimised and optimised only with the necessary dependencies thereby reducing app size.

After running this command, my React Applications files packaged in a build folder should look as below

This build folder houses your static entry page index.html  . Servers like Nginx, Apache or Node (express) can be used to serve your project.

In our case, Nginx will handle our sites server but my hosting provider itself is powered mostly by Apache. Yes, you can mix both technologies.

Serving and Deployment

In serving our project, we copy all the files in our Build folder to our projects root  public_html folder.

Note that we copy only the file contents and not the Build folder itself.

We can achieve this using a File Transfer Protocol ( FTP ) or Secure FTP ( SFTP ) or just upload the files via CPanel using the traditional upload approach.

Note that we already have an existing index.php homepage in our root folder.

What your public_html file for a samplesite should look like below.

It is likely that our server will naturally redirect homepage requests to index.html since that file trumps the index.php file or other files formats as well as us, having earlier specified the homepage in our package.json file in our React app.

This, we do not want. So we proceed to change that below.

ReWrite Modules

This is the Key to our aim. So pay close attention here.

Rewrite modules or rules change part or all of the URL in a client request. This is to inform the client of a files location or to control the flow process for file path requests.

The rewrite module rules are placed in a file in our projects root i.e public_html .

This file is simply named .htaccess

.htaccess file is a powerful website file that controls high-level configuration of your website. On servers that run Apache and Nginx, the .htaccess file allows you to make changes to your website's configuration without having to edit server configuration files.

This file will also resides at the very top, at our projects root folder.

If we were to make our react app as the homepage, we would simply paste the code below which tells our server to serve Reacts index.html static file as our homepage.

Note that the .htaccess code below is sufficient to serve your React app straightaway on the server.

See below. 

<IfModule mod_rewrite.c>

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteRule . /index.html [L]

</IfModule>

However,

this is not just what we want.

We already have a homepage which is in PHP. We do not want our React entry page as our homepage.

We want our already existing index.php file to serve as our homepage.

To achieve this, we add some extra rules( dir_module ) to the top of our .htaccess file.

Take note of the file content and where we place the index.php within the code.

These rules identify the Directory's index. The first specifying the homepage and the second indicates the alternative homepage for our Reacts app.

They also specify the file types and the Rewrite conditions. An in-depth review of these codes are beyond our scope.  

See below.

<IfModule dir_module>
 
   DirectoryIndex index.php index.html
   RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(html|htm|php|php3|php5|shtml|phtml) [NC]
   RewriteRule ^index\.html|htm|php|php3|php5|shtml|phtml$ / [R=301,L]

</IfModule>

<IfModule mod_rewrite.c>

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteRule . /index.html [L]

</IfModule>

Voila! Save the file and visit your homepage in your favorite browser. Your index.php should appear as your homepage if you did it right. You can link that page to your static site with Https.

Take Home

The rules specified in the code above will redirect the homepage of our application to the Directory Index first specified within the code.

The second rules in the same file enable the react app to be served and to work appropriately via our server.

We can also use the ReWrite modules to specify Error page redirects ( 404 ) or other such network protocols. 

A while ago I started learning React by applying the technology to personal projects. I soon realised that familiarising myself with its concepts didn’t come without its hurdles.  

I eventually understood how one of Reacts foundational concepts; state, works.  

This article uses solving a challenge to simplify State as a concept in React to a basic form which an intermediate developer and React beginner should understand. I also explore its implementation using props in this tutorial. This article will enable the reader to easily grasp some of the concepts I tackled.

This article hinges on the application of UI in tackling the challenge. To fully grasp this article, one must already be familiar with the set up of React,  HTML, CSS, JSX(JavaScript XML) and JavaScript (JS) ES6+ syntax. However there is still guidance on basic setup herein.

The skill level required to understand this article is listed below.

Skill Level :

• ReactJS: Beginner
• Software Development: Intermediate

The predisposed reader should also have encountered:

• Bash Terminal, Node Package Manager (NPM) and Git

By the end of this article, the ardent reader should understand what State in React is about and even conjure a basic UI implementation using Props.

I go about this article by way of an example. I present a simple challenge I encountered learning React and how going about its solution improved my knowledge of State.  

Challenge  

Enable dynamic display of different information on the left column from varying card components on the right column of the same page on the click of the Image Card/Button.

See Figure 1 below.

                                                                     Figure 1: Our Goal

React Intro 

React in this case is a technology. A type of software championed by facebook which serves the function of improving display UI(User Interface) and UX(User eXperience). It is a library that facilitates easy storage, retrieval and reuse of UI components across a software project. React is known for its speed as it reduces webpage load time significantly through some software magic I’m not about to go into as that goes beyond our focus.

React is straight forward at this point and is quite popular in development circles.

This challenge is encapsulated within a Sandbox to abstract build irrelevancies. This tutorial will still carry those working in an IDE terminal along.

... and so, we begin our journey at the Terminal.  We can navigate to the folder where we'd like to house our project or head home using the cd command(CMD) -

$ cd /home

it could also be

$ cd /home/desktop

OR 

$ cd /htdocs

depending on where we normally house our projects.

In our parent folder is where the engine begins by the push of the CMD -

$ create React App my-app

this generates a general file structure for the folder my-app (this could be any name you wish) in our chosen IDE as shown below

                    Figure 2: Default Folder Structure

the eventual/final file structure of this sample will turn out like this below

                    Figure 3: Final Folder Structure

This tutorial would be conducted mainly in the /src folder.

Next, we clear out extra generated files irrelevant to this project and strip our scaffold to the bare minimum.

Just what we need. We take out:

• app.test.js
• index.css
• logo.svg 

The bash command to execute this is :

$ rm app.test.js index.css logo.svg

APPROACHING THE SOLUTION

In tackling React, we break down our entire code into components. This facilitates ease of understanding our code by segmenting the relationships between different design features. This little project is uses 2 components: SideBarInfo.js and Thumbnail.js         

Our entry page is the file /src/App.js

These are most of what we need and what we'd be working with.

The stylesheets needed are added to the various folders where their related files are housed; /src and  /Components/                                                                                                                                       

We'd go further into the stylesheets below.

Design

The idea is to be able to click on an Item from the COLUMN 2 on the right and have expanded details about it appear on COLUMN 1 on the left.

Keep the Columns in mind as we'd refer to them throughout this piece.

See figure below

                      Figure 4: UI MockUp for our Intended Design

by the design above, we can break down the single page into two columns. This can be achieved by CSS in the stylesheet( styles.css ) . Let's house this in our /src folder

we can create the styles file via the terminal with the CMD

$ touch styles.css

We populate our styles.css file with the design parameters defining our column and classes for the left and the right. This stylesheet would later be invoked in our main page  ../App.js  via JavaScripts import function.

/* styles.css file */

.column {
  padding: 10px;
  height: 250px;
}

.left {
  float: left;
  display: block;
  width: 35%;  
}

.right {
  float: right;
  display: block;
  width: 65%;
}

Components

Now we have our page split in 2 different columns, we can proceed to break down what goes into each column.

The left column ( COLUMN 1 ) will house our first component which is the view for the SideBarInfo which shows details of a clicked item including its corresponding Image and name

from the right column ( COLUMN 2 ) which houses our second component which is the Thumbnail that shows an Item Image and its Name.

Keep in mind that Item List will be stored in an array on our main display page ../App.js  and in this same file is where understanding our Props come into play ( we'd get to this later ).

We navigate to our /src folder and create the folder for our Components  

$ mkdir Components

next we navigate to our /Components  folder where we create the file components and their stylesheet with the CMDs

$ touch SideBarInfo.js Thumbnail.js Sample.css

Thumbnail

We navigate to our ../Components  folder where we focus on the thumbnail component starting with the folder css file ( Sample.css ) which we edit below. This css contains a barebones styling for our Item 

Much ado about naming conventions, we name an Item css class; Work 

furthermore, we'd be referring to Item and Work  interchangeably since Work is how we'll be describing each Item by syntax (more on this later below )                  

Below, we delve into the component stylesheet that defines the parameters of what a single Item in COLUMN 2  should look like. See below.

/* Sample.css file */

.Work .image-container {
  height: 10rem;
  margin-bottom: 1rem;
  border-radius: 30px;
  display: flex;
  flex-wrap: wrap;
  position: inherit;
  width: 100%;
  max-width: 100%;
  flex-direction: column;
  justify-content: center;
  overflow: hidden;
  background: #000;
}

Right now, we imagine a single Item to comprise of a thumbnail which houses/displays a single Item Image. Below this item we will display its corresponding Item name Information in a HTML </div>  tag in our Thumbnail.js file.

See figure 5 below      

               Figure 5: Single Thumbnail Item

Done with the stylesheet, we proceed to work on the Thumbnail.js file, where we 

• import React 
• import our stylesheet ( Sample.css )
• define the Work/Item Props
• placing the Work/Item image in a div and defining its action after a click event
• placing the Work/item name beneath the image 

import React from "react";  //standard import React function
import "./Sample.css";  // we import the sample stylesheet

//below we  create our thumbnail class for this thumbnail component

class Thumbnail extends React.Component {   
  render() {
    return (
      <div>
        <div className="column right">
          <div className="Work"  
// ES6+ onClick handles the click event for an Item Image 
              onClick={(e) => this.props.click(this.props.work)}  > 

// we display the Item Image with its style class
            <div className="image-container"> 
              <img 
                   src={this.props.work.imageSrc}  
                   alt={this.props.work.imageSrc}  /> 
            </div>
//  display the Items' name info 
            <div className=""> 
              <p> {this.props.work.work}</p>
            </div>
          </div>
        </div>
      </div>
    );
  }
}

// below we export this component making it available for use about the Application

export default Thumbnail;  

Having built the thumbnail Component for column 2, we proceed to build the SidebarBarInfo for COLUMN 1.

SideBarInfo

We navigate back to our /component folder where we face the SideBarInfo.js file which will house the layout for what our COLUMN 1 display will look like.

                          Figure 6: SideBarInfo View

Using the same stylesheet, we embark on defining the UI parameters for the SideBarInfo component below in JSX.

• we import the React
• we import the stylesheet
• we define/display the image style and its prop
• we display the Item name and further details

/* SideBarInfo.js file */

import React from "react";  // standard import React function
import "./Sample.css";  // imports the Sample stylesheet 

// below we use a function instead of a class(both can be interchangeable depending on usage)

function SidebarInfo(props) {         
  return (
    <div>
      <div className="Work">
        <h1> NAME </h1>            // random header title 
        <div className="image-container"> // image styling here, props below
          <img //image size override, new image dimensions below
            width="150"
            height="150"
            src={props.imageSrc}
            alt={props.imageSrc}
          />
        </div>
        <p> {props.work} </p> // name of the Item/Work props
        <p> {props.view} </p> // other details:"view" of the Item/Work
      </div>
    </div>
  );
}

// lastly we export the entire component file for recall/reuse across our application
export default SidebarInfo;    

App.js

We navigate back to our /src folder  where we turn our attention to the main page where our App component is a class.

You've been reading about state from the start of this write up. It comes into play at this point where we tie our project together. 

What Is State ?

I see State here as a capsule within a component which contains data that is managed within that component. State determines how a component behaves and is rendered(more on render below). Not all components have/use state and those that don't are referred to as stateless components while those that do are stateful. There are many ways a component can access and manage States' data such as the use of props, setState , useState and Hooks. An In-depth explanation is beyond the scope of this tutorial.

Let's dive into how this comes in.

So, our COLUMN 2 holds a list of items and we've designed the container for a single Item ( Thumbnail.js ) . How then do we list the items and get them to show up in our page ?

We begin our App.js file by establishing a Class component (App) with a Constructor method that accepts props, and has this.state which at the moment, is a container housing an empty object.

This empty object would be filled with our array/list of Items and their details.

class App extends React.Component {
        constructor(props) {
          super(props);
          this.state = { };   
        }
   }

The array of Items are to be referred to as : works, while a single item in the array is titled : work. Works is essentially a dummy list of our items. 

works is an array of our Items comprising of :

• an Id referred to as - ' id'
• a title known as - 'work'
• an image link known as - 'imageSrc'
• one detail known as - 'view'      ( view can hold a link or any string detail )
• a boolean (true or false) value known as - 'selected'  ( this variable will come into play further below ).

*Note* that you feel free to add more details to your Items(Work) array, but here we use only 2 items.

               Figure 7: View of SIdeBarInfo & Items Array

See what I mean below ( The image links used are sourced from Creative Commons )  

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      works: [
        {
          id: 0,
          work: "Work 1",
          imageSrc:
            "https://images.unsplash.com/photo-1584608168573-b6eec7a04fd7?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        },
        {
          id: 1,
          work: "Work 2",
          imageSrc:
            "https://images.unsplash.com/photo-1581665269479-57504728e479?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        }
      ]
    };
}

Now that we have our array captured in State, we can think about how to get these items showing.

Time to bring in render()  I'd briefly recall a couple of things that render() is and i'd leave out what it's not.

• The render function performs the role of displaying specified code in an HTML element such as a <div> . 
• It enables interaction between various components in a React application.                                 
• Using a Prop, render can divulge full or parts of its State and Components' logic to other components.
• A render is triggered once there's any change in the components state (part of the magic that makes React fast and responsive)
• A render can be accessed by the DOM (view layer) and can relay display

In our render function for our App component, we'd display the Column layout and the Items in our State.

We add the code to a render function.

Let's dive

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      works: [
        {
          id: 0,
          work: "Work 1",
          imageSrc:
            "https://images.unsplash.com/photo-1584608168573-b6eec7a04fd7?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        },
        {
          id: 1,
          work: "Work 2",
          imageSrc:
            "https://images.unsplash.com/photo-1581665269479-57504728e479?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        }
      ]
    };

  }

// see the added Render function here below

  render() {
    return (
      <div className="column "> // column style class for this HTML element
        <span>

//NOTE- Reacts class components allows you to call in functions from the same component

// below is SideBarInfo's column (left)            
          <div className="left"> 
                { }    // placeholder for JSX
            </div>  
// below is Thumbnail's column for Items:works array
           <div className="right">  
               { }   // placeholder for JSX
           </div>
        </span>
      </div>
    );
  }
}

Our App component is beginning to fill out. We have our array of items stored in State, we have our Column parameters called in a render function. But we can't see much and have a bug or two.

So, how do we link it all up and display i.e. our stateful App component ( that houses an array of items in state and also renders an empty column arrangement ) + our SidebarInfo functional component (which accepts a prop and returns its data)  +  a single lonely Thumbnail class component ( which renders an empty shell that will contain an Items data ?

*Tip* Class components in React accept props naturally so props doesn't need to be declared but can be called with 'this.props'. Functional components on the other hand have to declare props as in 'function(props)...{props.ObjectName}' (see SideBarInfo.js)

Our COLUMN 2  will house our Items list which would be Thumbnails of the Items currently in our App components state.

Our COLUMN 1 will house a SideBarInfo which can display a clicked Thumbnail and all its data in our state if need be.

We will use 3 functions to go about the logic of linking up our components. All these functions will be in our App component which houses our State. We will call our stylesheet and the other components in our ../App.js   file through JavaScripts import function as well.

The functions we will use are :

• makeWorks() :  this function iterates through the works array and returns each items data in a thumbnail which listens for a click event
• handleCardClick() : this function accepts an id and Thumbnail ( React allows you to call a global component in a function provided it has been imported ).                                                                                It listens for a click event and registers the id of the clicked item while changing its selected value based on the event and the storing it in state. 
• showWorks() :  this functions accepts works , iterates through each one, picks the selected array and displays its data in as a SideBarInfo via props.     

  makeWorks = (works) => {   
  // JavaScripts ES6 map method iterates the array of works and returns an item Thumbnail 
    return works.map((work) => {   
      return (   // returned thumbnail with useful classes and method 
        <Thumbnail
          work={work}
          click={(e) => this.handleCardClick(work.id, e)}
          key={work.id}
        />
      );
    });
  };

// this function below accepts an id and Thumbnail component
  handleCardClick = (id, Thumbnail) => {   
    console.log(id);

// we define works variable below
    let works = [...this.state.works]; 

// our ternary operator below stores the boolean value in the variable
    works[id].selected = works[id].selected ? false : true;   
 
    works.forEach((work) => {  // this ES6 method ensures that unselected values are false
      if (work.id !== id) {
        work.selected = false;
      }
    });

// below we mutate our State by changing the value of selected

    this.setState({   
      works
    });
  };

// vanilla Javascript loops through the works array and uses props to display selected item/work in SideBarInfo

  showWorks = (works) => { 
    let i = 0;
    var w = [];
    while (i < works.length) {
      if (works[i].selected) {
        w = works[i];
      }
      i++;
    }
    return <SidebarInfo imageSrc={w.imageSrc} work={w.work} />;
  };

*Note* Recall that SideBarInfo is a functional component that accepts props. Hence we can call our data from an item in State and use it to populate SideBarInfos shell in one function. We can then return that that function in our render().   [ behold JavaScript Inception ]. Likewise, Thumbnail already defines the work object it accepts via props so when we call it in our App component, we assign it data from our State and allow the component display it. Props are immutable and read-only and cannot be modified or changed like State.

Also, recall the Constructor method ? which accepts props ? Well, our 3 functions shown above are going to go into our App Class and we will bind them to that Constructor method to make state available to these functions. 

below We bind these functions together in state,

call in our component and style imports,

rework our render() to facilitate our display

and call it a day.  

Let's dive

// App.js

// we import components and styling below

import React from "react";
import Thumbnail from "./Components/Thumbnail";     
import SidebarInfo from "./Components/SideBarInfo";
import "./styles.css";

// below we add export method to our App Component 

export default class App extends React.Component { 
  constructor(props) {                         
    super(props);
    this.state = {
      works: [
        {
          id: 0,
          work: "Work 1",
          imageSrc:
            "https://images.unsplash.com/photo-1584608168573-b6eec7a04fd7?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        },
        {
          id: 1,
          work: "Work 2",
          imageSrc:
            "https://images.unsplash.com/photo-1581665269479-57504728e479?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=701&q=80",
          view: "#",
          selected: false
        }
      ]
    };

// we bind the functions to our constructor method like this below
    this.makeWorks = this.makeWorks.bind(this);
    this.handleCardClick = this.handleCardClick.bind(this);
    this.showWorks = this.showWorks.bind(this);
  }

// here comes our functions in shining armor
  makeWorks = (works) => {
    return works.map((work) => {
      return (
        <Thumbnail
          work={work}
          click={(e) => this.handleCardClick(work.id, e)}
          key={work.id}
        />
      );
    });
  };

  handleCardClick = (id, Thumbnail) => {
    console.log(id);

    let works = [...this.state.works];

    works[id].selected = works[id].selected ? false : true;

    works.forEach((work) => {
      if (work.id !== id) {
        work.selected = false;
      }
    });

    this.setState({
      works
    });
  };


  showWorks = (works) => {
    let i = 0;
    var w = [];
    while (i < works.length) {
      if (works[i].selected) {
        w = works[i];
      }
      i++;
    }
    return <SidebarInfo imageSrc={w.imageSrc} work={w.work} />;
  };

  render() {                                                           
    return (  
      <div className="column ">
        <span>
// The JSX below renders our showWorks()-it gives it access to state below. This displays SideBarInfo for the Left COLUMN 1
         
           <div className="left">        
              {this.showWorks(this.state.works)} 
            </div>

// The JSX below renders our makeWorks()-it gives it access to state here. It displays item Thumbnails for the right COLUMN 2
          <div className="right">   
              {this.makeWorks(this.state.works)}  
          </div>
        
        </span>
      </div>
    );
  }
}

// export default App; 
// using the export above is an alternative to adding it to the class above

We can now save our files. Your /index.js file should call your App component and should look as below 

import React from "react";
import ReactDOM from "react-dom";

import App from "./App";

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  rootElement
);

RECAP

This piece tackles a UI display challenge. It goes about this via props, State and onClick in React. Our final view would show a UI display akin to Figure 1.

Lastly, this tutorial only displays 2 items. Feel free to add more Items to your array and play around with the CSS to accommodate your own styling. 

You can view a working version of this tutorial in my SandBox 

As automation through technology trudges along the course of Moores law especially via electrical power, technology, artificial intelligence etc. the ripple effects are bound to be seen on the world and in your local economy especially as regards human capital, growth and labour as we embrace a new phase of industrial and human capital development.

Where you position yourself now may very well impact your socio economic future. You don’t have to live a life of frugality while existing in a world of plenty.

Labour: Toward Sustainable living.

As leaps and bounds are made across sectors including Industry, labour is receiving shock waves.

Industry was once touted the largest employer of labour, ushering a huge new change in human living. It powered mass education via the print and greatly contributed to the world system we have today.

Humans seem to have conquered the surface of the earth. Currently attempting to repair it, they look beyond, with refined technology to build a sustainable future. A future that runs itself while humans are free to pursue higher ventures beyond earth.

You don’t have to live a life of frugality while existing in a world of plenty.

There is lacunae created by the shift in labour/mindset and this can only be filled by a labour market that is largely unavailable. The assembly line form of production has been almost perfected. Labour intensive Industries like agriculture virtually don’t rely on as many human hands to provide produce to feed millions. Optimisation of existing industries and automation of manually intensive labour hold the keys to this paradigm shift.

Already, job prospects abound in the technology sector. Professionals are required to grow this sector and as the demand for innovation increases, so do the job roles.

First world countries are already paving the Tech sector, supplying roles that tend to pay as much as $80,000 to $150,000 per annum for example in the United States. Offers are several times above the the average wage of more traditional labour. Companies are recruiting tech specialists straight from boot camps as computer science graduates are still insufficient to fill this roles.

Career shifts are seeing people who earn as low as $40,000 to $80,000 averagely, shift to the tech sector, to land better roles by boosting automation. In fact, most businesses are now attempting to automate traditional roles in order to increase their ease of business. Governments are not left out as they all attempt to automate to improve transparency and make the processes of running government leaner and faster. In an attempt to make this easier, countries such as Estonia are already adopting special immigrant visa programmes for experienced foreigners to come in and build their tech sectors.

All jobs that can be automated will be automated as a matter of fact. Any job that requires the use of paper or that was affected by the print era is likely to be affected by this tech era. Every form of human communication/interaction is being automated and digitized, from our way of spoken communication to writing.

All jobs that can be automated will be automated as a matter of fact.

Labour dependents are encouraged to learn a skill in the tech sector which will be found useful in the tech space to avail oneself of inherent opportunities. Some of these required skills which can be applied to new roles and already existing roles, include;

• Software Developers — Front End, Back End, Full Stack
• Machine Learning Experts
• Engineering — Cybersecurity, Artificial Intelligence(AI), DevOps and Cloud Architects
• Computer Language experts — Python, Java, JavaScript (especially) amongst others
• Scrum Masters
• Mobile App developers and designers
• Stock and cryptocurrency trading (Derivatives)

People in traditional fields e.g. medicine, engineering are learning new technology in a bid to digitise and simplify their businesses and increase return on investment. A recent example in automation pursuits includes remote surgery through mechanised surgical arms which may be controlled remotely. You may begin to imagine the effects of this on medical tourism.

In an extended practical application, data from human tissue identification and repetitive procedure can be gathered and analysed by AI which could subsequently sequence such procedures and eventually perform such medical procedures by itself. While we are still a long way off, humans are already growing organs which may substitute as replacement to failing body parts through CRISPR, another nascent technology.

The future is exciting depending on your perspective.

There’s an underlying renaissance where human capital and living can be so optimised that with complete access to knowledge, humans may aspire for the stars rather than get lost in everlasting battles for socio-economics.

Reshaping labour can come in an example of merged fields such as a medical student who may code to create a database for storing patients data files and facilitating easier access to that data as a more familiar example.

Learning resources are abound with several of them offering scholarships for interested participants. Effective MOOCs some of which I’ve made use of include; Coursera, Udacity, Lynda, CodeAcademy, Udemy, Khan and recently LinkedIn Learning etc.

Many even offer skill paths and career prospectus on completion of programmes.

Those in the labour market are encouraged to look at this paradigm shift, not with the mindset of despair but with the outlook of opportunity in order to enable them tap into this new burgeoning sector of the labour market.

The new labour market is accessible irrespective of age, race or location. All you have to do is to prove that you can function and execute in your chosen digital field.

Employment of people working in IT occupations is expected to grow 12 percent from 2014 through 2024. 488,500 jobs will be added during this period.

There are openings for career shifts such as those seeking to move from traditional to digital marketing, sales etc. In fact, these makeup the bulk of career prospects in tech. There is also the need for traditional institutions to remodel and optimize themselves to cater to new educational needs or find themselves left behind. This presents another opportunity for transformation.

Human Capital and Growth — A Focus on the developing world

The demand for softer tech skills will continue to rise as tech sectors jobs like cryptocurrency experts, have opened up the field of forex and digital currency trading to otherwise hobbyists and enthusiasts.

These soft skills have created a means of generating income and even countries with unemployed talents and third world status’ can see their GDP increase through incoming forex from available jobs in this sector.

As an example, the increasing adaptation of cloud computing and cybersecurity will bring about increases in employment, a rise in symbiotic fields like healthcare IT, mobile networking etc. Data management as well will also contribute to improving forecasts for the information technology sector.

Governments that are interested in improvements of their economy can begin to train and export skilled labour to 1st world countries in need of skilled workers in exchange for required services rather than the current labour drain with no upsides. Training and retraining of civil servants across sectors and employment of capable experts can bring a shake up to an economy and drive growth.

Governments are encouraged to create enabling environments by providing incentives; from Tax breaks to Special status visas to comprehensive guidelines for remunerations as well as changes in educational curricula to create room for tech/digital fields and to help professionals grow and boost the sector.

Changes aren’t a walk in the park as 3rd world countries may find it difficult to tap into this sector due to absence of critical infrastructure such as unstable power, insecurity and economic challenges. A 3rd world leader may ask where to start from if (s)he can tap into this sector.

An appropriate reply will be to show him/her the opportunities abound in this area. Power problems can be solved by tapping into the sustainable power such as solar panels, lithium batteries and inverters.

In exchange for resources, leaders may negotiate for technology transfer

In exchange for resources, leaders may negotiate for technology transfer in the form of foundational infrastructure such as factories, training and local staff representation rather than stocks or liquid assets whose capital and profits still end up in 1st world banks.

Incubation hubs are also changing communities and what was once internet Cafes are now remodelled as hubs to grow innovation and build wealth. Governments can also create digital zones within states to build tech communities which will impact the zones around them. These zones can be quickly designed with special status’ in mind by giving them electricity to work unhindered, providing security and thereby leading to exponential transformation of environments and countries as a whole.

This equitable arrangement will have a positive effect on urban misalignment and encourage symmetrical growth even to rural areas.

Individuals from the developing world who wish to jump into the new economy will first have to build a new mindset with the understanding that labour with rewards of quality income is no longer an exclusive preserve of the regular 9–5.

One must then train and retrain oneself in their chosen digital field from the wealth of available resources to stay abreast and to tap into the opportunities that abound.

The most beautiful thing about this shift in labour is that workers can work remotely from anywhere and still boost productivity.

In a new world where labour is highly skilled, competitive and qualified workers largely unavailable, individuals can’t expect expertise in one day but the rewards, especially the freedom, is worth the time and effort it takes to build a successful career in these new fields.

This article is originally published in Medium