# Design Patterns - A few examples I have used recently

  # What are design patterns in software development?

  One of the best ways to make code easier to read and maintain is to use design patterns. Design patterns are reusable methods and soluitions to common problems in software development.

  For example, in a very simple sense, a method is a design pattern. You may have a snippet of code you reuse throughout an application for concatenating a string. Instead, most developers would create a method that can be called whenever needed.

  The benefits of design patterns like this - using a handy acronym - **RUM**:

  - **Readability** (by reducing the amount of code)
  - **Unit Testing** (by creating smaller units of code)
  - **Maintainability** (by reducing the amount of code)

  **Why are these important?** If you're like me and you're working on multiple projects (at work and personal projects), improving readability and maintainability is a life-saver. Even if you're working alone, you're writing code for your future self - **maintainability matters**.

  ## A few examples

  ### Repository pattern

  Even if you use an ORM in your application, you may still want to use the repository pattern. This is a great way to separate your data access logic from your business logic.

  For example, you may have a `User` model and a `UserRepository` class. The `UserRepository` class would contain methods for accessing the database, such as `getUserById`, `getUserByEmail`, `createUser`, `updateUser`, `deleteUser`, etc.

  **Readability**: no need to multiple database connections throughout your application - instead, you can call the `UserRepository` methods.
  **Unit testing**: you can easily mock the `UserRepository` class and test your business logic. Almost impossible to do this if you're using an ORM directly in your business logic - as I learned in a recent NestJS project.
  **Maintainability**: if you need to change your database connection, you only need to change it in one place.

  ### Presenter Pattern

  I've mainly come across this pattern in Ruby on Rails applications. The presenter pattern is a great way to separate your business logic from your view logic.

  For example, you may have a `User` model and a `UserPresenter` class. The `UserPresenter` class would contain methods for formatting data for the view, such as `fullName`, `avatarUrl`, `createdAt`, etc.

  Views in a fullstack Rails application can become chunky and messy over time. There may be conditional logic, loops, and other logic that doesn't belong in the view - and that doesn't belong in the model or controller either. The presenter pattern is a great way to clean up your views.

  **Readability**: no need to add conditional logic, loops, etc. to your views - instead, you can call the `UserPresenter` methods.
  **Unit testing**: it's much easier to test your view logic when it's separated from your business logic.
  **Maintainability**: views are smaller, logic is encapsulated in the presenter class, and you can easily change the view logic without affecting the business logic.

  ### Service Object Pattern

  Controllers should only be concerned with handling requests and responses. If there's business logic in controllers - e.g. calling a third-party API - it can become messy and difficult to maintain. A preference in this pattern is to move such logic to a service object.

  Service objects aren't restricted to APIs and can hold other business logic like sending emails, processing payments, etc. Then, if a controller needs to use that logic, it simply calls the service object.

  **Readability**: controllers are smaller and easier to read.
  **Unit testing**: it's much easier to test your business logic when it's separated from your controllers.
  **Maintainability**: controllers are smaller, logic is encapsulated in the service object, and you can easily change the business logic without affecting the controller.

  ## Conclusion

  There are many more design patterns out there. I've only covered a few that I've used recently. I hope this article has been useful and you can start using design patterns in your applications.
  

Design Patterns I have used recently: Repository, Presenter, and Service Objects

Design Patterns - a few I have used recently

# Getting started with testing in Ruby on Rails

  ## A quick guide to getting started with testing in Ruby on Rails

  ### Why should you test your code?

  It might seem obvious to those working in software development already, but if you're a beginner and still learning, you might be wondering why it's so important. Here are some reasons why you should test your code:

  - **Automation**: You can run your tests automatically, so you don't have to manually test your code every time you make a change. Doubly so if you've setup a CI/CD pipeline, like with [GitHub Actions](https://www.agslambley.dev/blog/6) or CircleCI.
  - **Documentation**: Tests are a form of documentation, and can help you understand how your code works, and how it's supposed to work. In the past two jobs I've had, I've been able to use the tests to understand how the code works, and how it's supposed to work, without having to ask anyone.
  - **Confidence**: You can be confident that your code works as expected, and that you haven't broken anything. This is especially important if you're working on a large codebase, or if you're working on a team with multiple developers. Another thing to consider, is if you're working on platform changes, e.g. upgrading Rails or cloud providers, you can be confident that your code still works as expected.

  In short, testing your code is a good idea, and you should do it. It saves time, frustration, and money - all of which are important at work or personal projects.

  ### What should you test?

  This is an interesting topic and there's some division on the extent of tests you should write. Some believe you should test everything, others that you should only test the important parts.

  There are definitely strategies you can use to help you decide what to test:

  - **Test levels**: There are [3 levels](https://en.wikipedia.org/wiki/Software_testing#Testing_levels): Unit, Integration and System testing. What you're responsible for will vary by workplace and team, but in general, as a developer you need to be writing at least unit tests. These are tests that test a single unit of code, e.g. a method or function. Integration tests test how multiple units work together, and system tests test the entire system, e.g. the website.
  - **Regression testing**: This is a technique that seeks to test new features for old bugs. It's sometimes an unintended consequence of a change that another piece of functionality breaks. Regression testing can be as simple as running all your tests after making a change, or as complex as having a suite of tests that test for possibly recurring bugs.
  - **Test coverage**: Most testing libraries will have a way of measuring how well your tests cover your code. For example, [SimpleCov](https://github.com/simplecov-ruby/simplecov) for Ruby or Jest's `--coverage` flag for JavaScript. This can help you identify areas of your code that aren't tested, and help you decide what to test. Test coverage has a few metrics that like function coverage (the percentage of functions tested), branch coverage (the percentage of branches tested), and line coverage (the percentage of lines tested). Find out more about test coverage [here](https://en.wikipedia.org/wiki/Code_coverage). In general, I try to aim for 90%+ test coverage, but this will vary by project and team.
  - **Feature testing**: This is another word for automated testing of the front-end, e.g. checking that images are displayed, button actions work, etc., all through the power of automated clicks. There's a few tools out there for this, that are all based on [Selenium](https://www.selenium.dev/) webdriver and use a lightweight version of a browser to run the tests. You might come across [Capybara](https://github.com/teamcapybara/capybara) or [Cucumber] (https://cucumber.io/), amongst others.

  ## How to Test in Ruby on Rails

  ### Installation

  [Rspec](https://rspec.info/) is a very common Ruby on Rails testing library. Be careful when you're first creating a new Rails app, as Rails will ask you if you want to use Rspec or not. If you're not sure, I'd recommend saying no, as it's easier to add it later than remove it.

  To install Rspec, add it to your Gemfile:

  ```ruby
  group :development, :test do
    gem 'rspec-rails', '~> 5.0.0' # or whatever the latest version is
  end
  ```

  Then run `bundle install` to install it.

  Next, run the Rspec install generator:

  ```zsh
  rails generate rspec:install
  ```

  You should have a new folder called `spec` in your Rails app. This is where your tests will live. You can run your tests with `rspec` or `bundle exec rspec`.

  ### Writing tests

  Let's say you have a `User` model with a few validations and a `full_name` method:

  ```ruby
  class User < ApplicationRecord
    validates :first_name, presence: true
    validates :last_name, presence: true
    validates :email, presence: true, uniqueness: true

    def full_name
      first_name + ' ' + last_name
    end
  end
  ```

  There are a few things we would want to test here:

  - That a user is valid with a first name, last name and email
  - That a user is invalid without a first name, last name or email
  - That a user is invalid with a duplicate email
  - That the `full_name` method returns the correct value

  For such a simple model, we could write all these tests in one file, but as your models get more complex, you'll want to split them up into separate files. For example, you might have a `user_spec.rb` file for the validations, and a `user_methods_spec.rb` file for the methods.

  For now, let's write all the tests in one file:

  ```ruby
  # spec/models/user_spec.rb
  require 'rails_helper'

  RSpec.describe User, type: :model do
    describe 'validations' do
      it 'is valid with a first name, last name and email' do
        user = User.new(
          first_name: 'John',
          last_name: 'Doe',
          email: 'test@test.com'
        )
        expect(user).to be_valid
      end

      it 'is invalid without a first name' do
        user = User.new(
          last_name: 'Doe',
          email: 'test@test.com'
        )
        expect(user).to_not be_valid
      end

      # ... other invalid tests for last name and email

      it 'is invalid with a duplicate email' do
        user1 = User.create(
          first_name: 'John',
          last_name: 'Doe',
          email: 'test@test.com'
        )
        user2 = User.new(
          first_name: 'Jane',
          last_name: 'Doe',
          email: 'test@test.com'
        )
        expect(user2).to_not be_valid
      end

      describe '#full_name' do
        it 'returns the full name of the user' do
          user = User.new(
            first_name: 'John',
            last_name: 'Doe',
            email: 'test@test.com'
          )
          expect(user.full_name).to eq('John Doe')
        end
      end
    end
  end
  ```

  There's a lot going on here, so let's break it down.

  First, we're requiring `rails_helper`, which is a file that Rspec generates for us. It loads Rails and Rspec, so we can use them in our tests. You can load other files here too, if you need to, e.g. files for factories or helpers functions.

  There are few conventions to note here (that follow the [Arrange-Act-Assert pattern](https://xp123.com/articles/3a-arrange-act-assert/)):

  - **`describe` blocks**: Useful for grouping together similar types of tests, e.g. validations or methods.
  - **`expect`**: This is the main assertion method in Rspec. There are more plenty more that you can read about [here](https://www.rubypigeon.com/posts/rspec-expectations-cheat-sheet/).
  - **`be_valid`**: This is a matcher that checks if the object is valid. There are more that you can read about [here](https://www.rubypigeon.com/posts/rspec-expectations-cheat-sheet/).

  ### Improving your tests

  In this example, there is a fair amount of repition. In software development, repeated code is bad - it leads to difficult to maintain code, and potential bugs. So how can we improve this?

  Factories.

  Factories are reusable pieces of code that can help generate objects for testing. In the example above, we're defining the new user each time in all the tests. Instead, we can delegate that to a factory, and just use the factory in our tests.

  In Rails, there are a few popular options for factories, but the most popular is [FactoryBot](https://github.com/thoughtbot/factory_bot). It's easy to use, and integrates well with Rspec.

  To install it, add it to your Gemfile:

  ```ruby
  group :development, :test do
    # ... other gems
    gem 'factory_bot_rails', '~> 6.2.0' # or whatever the latest version is
  end
  ```

  Then run `bundle install` to install it.

  Next, create a `support` folder in your `spec` folder, and add a `factory_bot.rb` file:

  ```ruby
  # spec/support/factory_bot.rb
  RSpec.configure do |config|
    config.include FactoryBot::Syntax::Methods
  end
  ```

  In the `rails_helper.rb` file, add the following line:

  ```ruby
  # spec/rails_helper.rb
  require 'support/factory_bot'
  ```

  This will load the `factory_bot` methods into our tests.

  After this, we can create a factory for our `User` model - it's up to you where you put it, but I like to put it in a `factories` folder in the `spec` folder:

  ```ruby
  # spec/factories/users.rb

  FactoryBot.define do
    factory :user do
      first_name { 'John' }
      last_name { 'Doe' }
      email { 'test@test.com' }
    end
  end
  ```

  There you have it - a factory for our `User` model. Now we can use it in our tests:

  ```ruby
  # spec/models/user_spec.rb
  require 'rails_helper'

  RSpec.describe User, type: :model do
    describe 'validations' do
      it 'is valid with a first name, last name and email' do
        user = create(:user)
        expect(user).to be_valid
      end

      it 'is invalid without a first name' do
        user = create(:user, first_name: nil)
        expect(user).to_not be_valid
      end

      # ... other invalid tests for last name and email

      it 'is invalid with a duplicate email' do
        user = create(:user)
        user2 = create(:user, email: user.email)
        expect(user2).to_not be_valid
      end
    end

    describe '#full_name' do
      it 'returns the full name of the user' do
        user = create(:user)
        expect(user.full_name).to eq('John Doe')
      end
    end
  end
  ```

  But wait - there's still some duplicated code here. We're creating a user in every test, and we're checking if the user is valid in every test. We can improve this by using Rspec's `subject` methods.

  `subject` is a method that defines the subject of the test. In our case, the subject is the user. We can use these methods to clean up our tests:

  ```ruby
  # spec/models/user_spec.rb
  require 'rails_helper'

  RSpec.describe User, type: :model do
    describe 'validations' do
      subject { create(:user) }

      it 'is valid with a first name, last name and email' do
        expect(subject).to be_valid
      end

      it 'is invalid without a first name' do
        subject.first_name = nil
        expect(subject).to_not be_valid
      end

      # ... other invalid tests for last name and email

      it 'is invalid with a duplicate email' do
        user2 = create(:user, email: subject.email)
        expect(user2).to_not be_valid
      end
    end

    describe '#full_name' do
      subject { create(:user) }

      it 'returns the full name of the user' do
        expect(subject.full_name).to eq('John Doe')
      end
    end
  end
  ```

  One thing that you might be wondering is what's happening on `subject.first_name = nil` and `user2 = create(:user, email: subject.email)`. Factory objects are mutable, so we can change their attributes. This is useful for testing validations - as we can setup the Factory with a valid object and make it invalid by changing an attribute in the tests.

  ## What next?

  What I've covered here is the most basic on unit tests - for a database model. In a real world project, you'll be testing requests, controllers, views, and more.

  If you're still learning, I'd recommend making a simple, working app with full CRUD actions and some basic routes. Then, try to write tests for it and get that test coverage as high as possible. Practice makes perfect, and you'll get better at writing tests the more you do it.
  

A quick guide to getting started with testing in Ruby on Rails

Getting started with testing in Ruby on Rails

# How to get started with GitHub Actions

  Using GitHub actions in my personal projects has changed how think about CI/CD completely. Before, I thought of CI/CD as another 'chore', or something that DevOps engineers do. Sometimes, there can be a disconnect between developers and DevOps engineers, and I think that's because developers don't always understand the value of CI/CD. I know I didn't.

  Now, after giving CI/CD more time - with GitHub Actions in particular - I can see the benefits. I can also see how CI/CD is everyone's concern in a development team - as important as writing tests and documentation.

  But how do you get started? I've written this guide to help you get started with GitHub Actions. I'll show you how to create a simple workflow, and then I'll show you how to use GitHub Actions to deploy a static website to GitHub Pages.

  ## What is/are GitHub Actions?

  GitHub Actions is a CI/CD tool built into GitHub. It's free for public repositories, and it's free for private repositories with up to 2000 minutes of build time per month. It's also very easy to use.

  A workflow is a set of instructions that GitHub Actions will follow. You can create a workflow by creating a file in the `.github/workflows` directory of your repository. The file must be a YAML file, and it must have a `.yml` or `.yaml` extension. Or, you can create a workflow using the GitHub Actions UI in the Actions tab of your repository.

  Workflows can be used to do a number of things. But in its simplest form, a workflow can be used to run a test suite on every push to a branch and prevent failing code from being merged into the branch, for example.

  Here's an example of a workflow that runs a JavaScript test suite on every push to a `testing` branch:

  ```yaml
  name: Run tests # The name of the workflow

  # When should this workflow run? -> on > push > branches > testing
  on:
    push:
      branches:
        - testing # Run this workflow on every push to the testing branch

  # What should this workflow do?
  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        # Checkout the repository
        - uses: actions/checkout@v2
        # Install dependencies
        - name: Install dependencies
          run: npm install
        # Run tests
        - name: Run tests
          run: npm test
          # important one here: if tests fail, fail the workflow
          continue-on-error: false
  ```

  ## How do I create a workflow?

  I'll go over the simplest way of creating a workflow, which is using the GitHub Actions UI in the Actions tab of your repository.

  1. Go to the Actions tab of your repository
  2. Click the 'New workflow' button
  3. Select a workflow template
  4. Edit the workflow
  5. Commit the workflow

  Voila! You've created a workflow.

  Deciding what to put in your workflow is the harder part and you would need to give this some thought. Running tests is one thing, but do you want to run any other actions? e.g. linters or more complex actions like creating pull requests or deploying your application?

  ## How do I use GitHub Actions to deploy a static website to GitHub Pages?

  I'll show you how to use GitHub Actions to deploy a static website to GitHub Pages. This is a good example of how you can use GitHub Actions to deploy your application.

  ### Step 1: Create a workflow

  Follow the steps above but be sure to include the following in your workflow:

  ```yaml
  name: Deploy website # The name of the workflow

  on:
    push:
      branches:
        - main # Run this workflow on every push to the main branch

  jobs:
    build-and-deploy:
      runs-on: ubuntu-latest

      steps:
        - name: Checkout the repository
          uses: actions/checkout@v2

        - name: Build the website
          run: npm run build # or other build actions

        - name: Deploy the website
          uses: JamesIves/github-pages-deploy-action@4.1.1
          with:
            folder: build # The folder that contains the website
  ```

  Change the `on` step to whatever branch you want to trigger automatic deployments from. In this example, I'm using the `main` branch.

  Also consider the build actions you need to run - this is specific for a JavaScript/Node project. You will have different build commands. Think about the commands you run locally when you run your application.

  > Something I found confusing when I was learning about GitHub Actions is that custom `uses` commands are managed and maintained by individuals/groups and not GitHub. So, in this example, the `uses` command is maintained by a user named JamesIves. You can find more information about this command [here](https://github.com/JamesIves/github-pages-deploy-action)

  ### Step 2: Create a `gh-pages` branch

  GitHub Pages will deploy your website to a branch called `gh-pages`. So, you need to create this branch. You can do this by running the following commands in your terminal:

  ```bash
  git checkout -b gh-pages
  git push origin gh-pages
  ```

  ### Step 3: Enable GitHub Pages

  Go to the Settings tab of your repository and scroll down to the GitHub Pages section. Select the `gh-pages` branch as the source and click the 'Save' button.

  ### Step 4: Commit your changes

  Commit your changes and push them to the `main` branch. This will trigger the workflow you created in step 1. You can check the status of the workflow in the Actions tab of your repository.

  # Conclusion

  It's easy to get started with GitHub Actions. My learning journey with CI/CD has only just started and already I feel it gives me peace of mind as a developer. I know my code is running tests and there are checks in place. GitHub Actions also takes the pain out of deploying my applications.

  My next challenge with GitHub actions will be something more complex, like automatically creating PRs when pushing to a pre-prod branch and adding reviewers. Loads more to learn!
  

A quick guide to getting started with GitHub Actions

How to get started with GitHub Actions

# How to create a small microservice app with Ruby on Rails (RoR) and TypeScript React (ReactTS)

  How to use this Tutorial:
  - Read it! There's a lot in here to help with learning and understanding basic microservice architecture e.g. CORS policies
  - Bullet pointed sections are Actions - these are what you need to do
  - Give me any feedback if there are any mistakes in the tutorial

  Advanced Tutorial that requires some basic knowledge in:
  - Ruby on Rails setup (follow the basic tutorial)
  - RESTful APIs and [HTTP Request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
  - PostgreSQL
  - JavaScript

  Technical and installation requirements:
  - Ruby (and rbenv), v3.1.2
  - Ruby on Rails,  v>7.0.6
  - NodeJS, v>16.13.1

  ## Creating the Rails API

  We will use have this folder structure:
  ```
  grad_project
  ├── api # <-- Rails API app
  │   ├── app
  │   │   ├── controllers
  │   │   │   └── api
  │   │   │       └── v1
  │   │   │           └── posts_controller.rb
  │   │   └── models
  │           └── post.rb
  ├── client # <-- ReactTS app
  │   └── src
  ...
  ```

  ### 0. Setup Ruby on Rails (RoR)
  - Install Ruby on Rails (RoR) - [official docs](https://guides.rubyonrails.org/getting_started.html)
  - Instructions vary depending on OS

  ### 1. rails new [API_APP_NAME] --api
  With Ruby on Rails (RoR), the standard `rails new` generator usually creates a full MVC RoR app, with RoR Views.

  In order to use a different Frontend framework, it is best practice to make the RoR app API-only - that is, only Model and Controllers (and other middleware) but no Views.

  You can generate this with:

  ```
  rails new [API_APP_NAME] --api -T
  ```
  __Note__: I usually specify the `-T` flag to prevent autogeneration of `Minitest` unit test, as I prefer to use `RSpec` for tests (more about [RSpec](https://rspec.info/))

  The `--api` flag specifies this is an API-only app, preventing autogeneration of Views

  - Do the usual `bundle install` and other configurations you may do now

  ### 2. Setup and enabling CORS

  Cross Origin Resource Sharing ([CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) is a form of security that checks the origin (URL) of HTTP requests.

  The app that we will build will have two origin URLs - in our local development environment, this will most likely be `localhost:3000` for the RoR app and `localhost:3001` for the ReactTS app.

  As such, you need to update the CORS policy in the RoR app to allow requests from the ReactTS app we will build

  - Add or uncomment `gem 'rack-cors'` in the `gemfile`
  - Run `bundle install`
  - Find this file `config/initializers/cors.rb` and update the `origins` line to `origins '*'` - this will accept requests from any origin. The file should look like this:

  ```
  Rails.application.config.middleware.insert_before 0, Rack::Cors do
    allow do
      origins '*'
  resource '*',
        headers: :any,
        methods: [:get, :post, :put, :patch, :delete, :options, :head]
    end
  end
  ```
  - FOR LATER: we will update the origins later to accept requests from the ReactTS app at whatever port you specify, e.g. `localhost:3001`, as well as for a future deployed app URL (as a comma-delimited list of string URLS)

  ### 3a. Setup test packages (OPTIONAL)

  For automated testing, we will use RSpec ([official docs](https://github.com/rspec/rspec-rails)). It is important to set this up now, as RSpec will autogenerate test files when you generate Models and Controllers later on.

  - Add `gem 'rspec-rails'` to the gemfile
    - best practice is to add it to the `group :development, :test do ... end` block, so the test packages aren't used in the deployed app
  - Also add `gem 'factory_bot_rails'`
    - this is used to programmatically generate instances for automated testing
  - Add `gem 'simplecov'`
    - this is used to generate test coverage reports
    - Read the official docs on how to set this up ([docs](https://github.com/simplecov-ruby/simplecov))
  - Run `bundle install`
  - Run `rails generate rspec:install` to generate boilerplate configurations

  That's all for now.


  ### 3. Generate Post Model, Controller and Routes

  For the purpose of this tutorial, we will create one Post model and one Post controller.

  __Note__: from here, I will be using some shortened commands in RoR, like `rails g` instead of `rails generate`

  - Run `rails g model post title:string content:text`
    - remember this must be singular - this generates a Model (and test file, if you setup RSpec) called Post with title and content fields
  - (OPTIONAL) add validations to the Post model, if needed
  - Run `rails g controller posts index show create update delete`
    - this will generate a `posts_controller` file with empty methods called index, show, create, update and delete.
  - Run `rails db:create db:migrate`
    - you _may_ run into errors here where you need to add a username and password to the `config/database.yml` file.
    - The username provided needs to exist in your PostgresSQL local setup and have permissions to create tables

  We will use RESTful API naming convention best practice for versioning and move the `posts_controller.rb` file to a new folder. You can read more on this [stack overflow post](https://stackoverflow.com/questions/389169/best-practices-for-api-versioning).

  - In the `controllers` folder, create a new folder `api`
  - In the `api` folder, create a new folder called `v1`
  - Move the `posts_controller.rb` to the `v1` folder
  - In the `posts_controller.rb` file, change `class PostsController < ApplicationController` to `class Api::V1::PostsController < ApplicationController`

  To help with learning, we will add some comments to the `posts_controller.rb` file to show where these methods should route to:

  ```
  class Api::v1::PostsController < ApplicationController
    # GET /posts
    def index
    end

    # GET /posts/:id
    def show
    end

    # POST /posts
    def create
    end

    # PATCH/PUT /posts/:id
    def update
    end

    # DELETE /posts/:id
    def destroy
    end
  end
  ```

  Now it's time to update the `routes.rb` file:
  - In the `routes.rb` file, add:
  ```
  namespace :api do
    namespace :v1 do

    end
  end
  ```
  - In the :v1 block, add `resources :posts, only: [:index, :show, :create, :update, :delete]`
    - The `resources` keyword handles the route mapping, so you don't need to specify each HTTP request method

  ### 4. Seed the database
  At the moment, we don't have any data in the db to test our `post_controller.rb` endpoints.

  We will create/update the `db/seeds.rb` file to create a few posts for us to test
  - At the top of the `db/seeds.rb` file add `require 'faker`
  - Let's create 10 posts using Ruby's `times` iterator, add this block:
  ```
  10.times do

  end
  ```
  - In that block, add a `post` variable that we will create a Post instance in:
  ```
  post = Post.create(
    title: Faker::Lorem.sentence(word_count: 3),
    content: Faker::Lorem.paragraph(sentence_count: 2)
  )
  ```
  - (OPTIONAL) add some `print` statements to the file to get feedback when instances are created e.g. add `print 'Created #{post}'` in the Post.create block

  The seed file should look something like this:
  ```
  require 'faker'

  10.times do
    post = Post.create(
      title: Faker::Lorem.sentence(word_count: 3),
      content: Faker::Lorem.paragraph(sentence_count: 2)
    )
    print 'Created #{post}'
  end
  ```
  - Run `rails db:seed` to seed the database

  ### 5. Add callbacks and private methods to the Post controller

  There's one more thing that can improve the `posts_controller.rb` file - callbacks and private methods.

  - Add a `before_action` callback to the `posts_controller.rb` file:
    - This will run the `set_post` method before the `show`, `update` and `destroy` methods
  ```
  before_action :set_post, only: [:show, :update, :destroy]
  ```
  - Add a private method `set_post` to the `posts_controller.rb` file:
    - This will find the Post instance by the `:id` param in the URL
  ```
  private

  def set_post
    @post = Post.find(params[:id])
  end
  ```
  __NOTE__: place all your private methods at the bottom of the controller file, below the `private` keyword

  We also need to add a `post_params` method to the `posts_controller.rb` file.

  Why? This is a security measure to prevent malicious users from sending requests with extra parameters that we don't want to be saved in the database.

  - Add a private method `post_params` to the `posts_controller.rb` file:
    - This will only allow the `title` and `content` parameters to be saved in the database
  ```
  def post_params
    params.require(:post).permit(:title, :content)
  end
  ```

  Whenever you add new fields to the database, you will need to update this method to allow those fields to be saved.

  ### 6. Write the CRUD methods in the Post controller

  Now we can write the CRUD methods in the `posts_controller.rb` file.

  - In the `index` method, add:
  ```
  @posts = Post.all
  render json: @posts
  ```
  - In the `show` method, add:
  ```
  render json: @post
  ```
  - In the `create` method, add:
  ```
  @post = Post.new(post_params)

  if @post.save
    render json: @post, status: :created
  else
    render json: @post.errors, status: :unprocessable_entity
  end
  ```
  - In the `update` method, add:
  ```
  if @post.update(post_params)
    render json: @post
  else
    render json: @post.errors, status: :unprocessable_entity
  end
  ```
  - In the `destroy` method, add:
  ```
  @post.destroy
  ```
  __NOTE__: notice that we don't need to render anything in the `destroy` method, as the Post instance is already deleted

  - (OPTIONAL) write tests for the CRUD methods in the `posts_controller_spec.rb` file

  ### 7. Test the API endpoints (Manually)

  Using a third party app called [Postman](https://www.postman.com/), we can test the API endpoints we just created.

  - Open Postman and create a new request
  - Set the request method to `GET` and the URL to `localhost:3000/api/v1/posts`
  - Click `Send` and you should see a list of all the posts in the database
  - Do the same for the other request methods, `POST`, `PATCH/PUT` and `DELETE` with the appropriate URLs and HTTP request methods

  This is an important step to test the API endpoints before we move on to the ReactTS app.

  ### 7a. Adding custom endpoints

  We can also add custom endpoints to the `posts_controller.rb` file.

  For example, we can add a `search` endpoint that will search for posts with a specific title.

  - In the `posts_controller.rb` file, add:
  ```
  def search
    @posts = Post.where('title LIKE ?', '%#{params[:title]}%')
    render json: @posts
  end
  ```
  - In the `routes.rb` file, add to the `:v1` block:
  ```
  get '/search', to: 'posts#search'
  ```
  - (OPTIONAL) write tests for the `search` method in the `posts_controller_spec.rb` file

  __NOTE__: in the case of a Search endpoint, you may want to use a gem called [pg_search](https://github.com/Casecommons/pg_search) to improve the search functionality

  # Checkpoint 1 - Rails API

  At this point, you should have:
  - A Rails API app with a Post model, controller and routes
  - CRUD methods for the Post model
  - Seed data in the database
  - (Optional) tests for the CRUD methods
  - (Optional) a custom Search endpoint

  Additionally, after manually testing the endpoints, you should be able to see the JSON response in Postman.

How to create a Ruby on Rails API only backend for use with a JS frontend framework

Creating Ruby on Rails and TypeScript React app - Part 1

Part 1 of 4 - Creating Ruby on Rails and TypeScript React app

# How to create a small microservice app with Ruby on Rails (RoR) and TypeScript React (ReactTS)

  How to use this Tutorial:
  - Read it! There's a lot in here to help with learning and understanding basic microservice architecture e.g. CORS policies
  - Bullet pointed sections are Actions - these are what you need to do
  - Give me any feedback if there are any mistakes in the tutorial

  Advanced Tutorial that requires some basic knowledge in:
  - Ruby on Rails setup (follow the basic tutorial)
  - RESTful APIs and [HTTP Request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
  - PostgreSQL
  - JavaScript

  Technical and installation requirements:
  - Ruby (and rbenv), v3.1.2
  - Ruby on Rails,  v>7.0.6
  - NodeJS, v>16.13.1

  ## Creating the ReactTS app

  React is a JavaScript library for building user interfaces. It is a popular choice for Frontend frameworks.

  TypeScript is a superset of JavaScript that adds static typing to the language. It is a popular choice for Frontend frameworks.

  We will write the ReactTS app in TypeScript, as it is a more robust language than JavaScript.

  There's a lot to learn about React and TypeScript, so I won't go into detail here. You can read more about [React](https://reactjs.org/docs/getting-started.html) and [TypeScript](https://www.typescriptlang.org/docs/handbook/intro.html) in the official docs.

  ### 1. Create the ReactTS app

  We will use the `create-react-app` generator to create the ReactTS app.

  - Run `npx create-react-app [REACT_APP_NAME] --template typescript`
    - This will create a ReactTS app with TypeScript
  - Run `npm install` to install the dependencies
  - Create a `.env` file in the root directory
    - This will be used to store environment variables
  - Add `REACT_APP_API_URL=http://localhost:3000/api/v1` to the `.env` file
    - This will be used to store the API URL
  - Add `PORT=3001`
    - This will be used to store the port number for the ReactTS app
  - Add `.env` to the `.gitignore` file
    - This will prevent the `.env` file from being pushed to GitHub
  - Run `npm start` to start the ReactTS app
    - You should see the ReactTS app running on `localhost:3001`

  ### 2. Setup the ReactTS app

  We will use:
  - [Bootstrap](https://getbootstrap.com/) for styling
  - [Axios](https://axios-http.com/) for HTTP requests.
  - [react-router-dom](https://reactrouter.com/web/guides/quick-start) for routing

  We're using TypeScript, so we will also need to install the types files for Bootstrap and Axios.

  - Run `npm install react-bootstrap@next`
  - And install types file `npm install @types/react-bootstrap@next`
    - This will install the latest version of React Bootstrap
  - Run `npm install axios`
  - And install types file `npm install @types/axios`
    - This will install Axios
  - Run `npm install react-router-dom`
  - And install types file `npm install @types/react-router-dom`
    - This will install React Router DOM

  These are the core dependencies we will use for the ReactTS app.

  ### 3. Create the ReactTS app folder structure and basic routing

  We will use have this folder structure:
  ```
  grad_project
  ├── api # <-- Rails API app
  ├── client # <-- ReactTS app
  │   ├── public
  │   │   ├── index.html
  │   │   └── ...
  │   ├── src
  │   │   ├── components
  │   │   │   ├── [COMPONENT_NAME]
  │   │   │   ├── ...
  │   │   ├── pages
  │   │   │   ├── [PAGE_NAME]
  │   │   │   ├── ...
  │   │   ├── Types
  │   │   │   ├── [TS types files]
  │   │   ├── App.css
  │   │   ├── App.test.tsx
  │   │   ├── App.tsx # <-- routes
  │   │   ├── index.css
  │   │   ├── index.tsx # <-- entry point
  │   │   ├── react-app-env.d.ts
  │   │   ├── reportWebVitals.ts
  │   │   └── setupTests.ts
  │   ├── .env
  │   ├── .gitignore
  │   ├── package.json
  │   ├── README.md
  │   └── tsconfig.json
  ```
  The way that `create-react-app` works is that it will create a `public` and `src` folder for you, with some boilerplate files.

  `index.tsx` is normally the entry point of the app (i.e. the first file that is run and the element with `id=root` where the app renders). `App.tsx` is also automatically generated and is the main component that is rendered in `index.tsx`.

  We will create a `components` and `pages` folder in the `src` folder, as well as some other files.

  - Create a `components` folder in the `src` folder
  - Create a `pages` folder in the `src` folder
  - (OPTIONAL) Create a `__mocks__` folder in the `src` folder
    - This is where we will store mock data for testing
  - (OPTIONAL) Create a `__tests__` folder in the `components` folder and `pages` folder
    - This is where we will store tests for the components and pages

  For the routing, we will use React Router DOM.

  - In the `App.tsx` file, add:
  ```
  import { Routes } from 'react-router-dom';
  import { HomePage } from './pages/HomePage';
  [...other imports like Navbar custom component]

  export const App = () => {
    return (
      <>
        <NavbarComponent />
        <Routes>
          <Route path='/' element={<HomePage />} />
        </Routes>
      </>
    );
  };
  ```
  - In the `pages` folder, create a `HomePage` file
  - In the `HomePage` file, add:
  ```
  import React from 'react';

  export const HomePage = () => {
    return (
      <div>
        <h1>Home Page</h1>
      </div>
    );
  };
  ```

  When you run the app, you should see the Home Page.

  You may want to reorganise the folder structure later on, e.g. move stylesheets to a `styles` folder, but for now we will keep it simple. If you do move the stylesheets, for example, you will need to update the `import` statements in the components and pages.

  ### 3a. Setup Jest (OPTIONAL)

  We will use Jest ([official docs](https://jestjs.io/)) for testing.

  - Run `npm install jest`
  - And install types file `npm install @types/jest`
    - This will install Jest
  - Create a `jest.config.js` file in the root directory
    - This is where we will configure Jest
    - An example config file is:
  ```
  module.exports = {
    preset: 'ts-jest',
    testEnvironment: 'jsdom',
    setupFilesAfterEnv: [
      '@testing-library/jest-dom/extend-expect'
    ],
    transform: {
      '^.+\.(js|jsx|ts|tsx)$': 'babel-jest',
    },
  };
  ```
  - Add `jest.config.js` to the `.gitignore` file
    - This will prevent the `jest.config.js` file from being pushed to GitHub
  - Add `'test': 'jest --watchAll --verbose'` to the `scripts` block in the `package.json` file

  ### 4. Create the ReactTS app components

  We will create the following components:
  - `Navbar`
  - `PostList`
  - `PostItem`
  - `PostForm`

  #### 4a. Create the `Navbar` component

  - In the `components` folder, create a `Navbar.tsx` file
  - In the `Navbar.tsx` file, add:
  ```
  import React from 'react';
  import { Navbar, Container, Nav } from 'react-bootstrap';

  export const NavbarComponent = () => {
    return (
      <Navbar bg='dark' variant='dark'>
        <Container>
          <Navbar.Brand href='/'>Grad Project</Navbar.Brand>
          <Nav className='me-auto'>
            <Nav.Link href='/'>Home</Nav.Link>
          </Nav>
        </Container>
      </Navbar>
    );
  };
  ```
  - In the `App.tsx` file, add:
  ```
  import { NavbarComponent } from './components/Navbar';

  // update the the App component with the NavbarComponent
  export const App = () => {
    return (
      <>
        <NavbarComponent />
        <Routes>
          <Route path='/' element={<HomePage />} />
        </Routes>
      </>
    );
  };
  ```

  When you run the app, you should see the Navbar on the Home page.

  #### 4b. Create the `PostList` component

  - In the `components` folder, create a `PostList.tsx` file
  - In the `PostList.tsx` file, add:
  ```
  import React, { useState } from 'react';

  export const PostList = () => {
    const [posts, setPosts] = useState([]);

    const getPosts = () => {
      try {
      const res = await axios.get(`${process.env.REACT_APP_API_URL}/posts`);
      setPosts(res.data);
      }
      catch (err) {
        console.log(err);
      }
    }

    return (
      <div>
        <h1>Post List</h1>
        <p># of posts: {posts.length}</p>
      </div>
    );
  }
  ```

  We will add the PostItem component later.

  There's a lot to learn about state and hooks in React, so I won't go into detail here. You can read more about [useState](https://reactjs.org/docs/hooks-state.html) and [useEffect](https://reactjs.org/docs/hooks-effect.html) in the official docs.

  You may want to consider using useEfffect to fetch the data from the API based on certain criteria (e.g. page load, when some other state has been updated), but for now we will just use the `getPosts` function.

  #### 4c. Create the `PostItem` component

  In order to display the Post data, we will create a `PostItem` component that will be iteratively rendered in the `PostList` component.

  - In the `components` folder, create a `PostItem.tsx` file
  - In the `PostItem.tsx` file, add:
  ```
  import React, { useState } from 'react';

  export const PostItem = ({ post }) => {


    return (
      <div>
        <h3>{post.title}</h3>
        <p>{post.content}</p>
      </div>
    );
  }
  ```
  - In the `PostList.tsx` file, add:
  ```
  import { PostItem } from './PostItem';

  export const PostList = () => {
    // rest stays the same

    // update the return statement to iteratively render the PostItem component
    return (
      <div>
        <h1>Post List</h1>
        <p># of posts: {posts.length}</p>
        {posts.map((post) => (
          <PostItem post={post} />
        ))}
      </div>
    );
  }
  ```

  We're not making the most of TypeScript here, as we're not using any types for the props. We will add this now.

  - In the `Types` folder, create a `PostTypes.ts` file
  - In the `PostTypes.ts` file, add:
  ```
  export interface Post {
    id: number;
    title: string;
    content: string;
  }
  ```
  You will need to update this interface if you add more fields to the Post model.

  - In the `PostItem.tsx` file, add:
  ```
  import { Post } from '../Types/PostTypes';

  // add the type to the props
  export const PostItem = ({ post }: { post: Post }) => {
    // rest stays the same
  }
  ```

  TypeScript will now throw an error if you try to pass in a prop that is not of type `Post`.

  #### 4d. Create the `PostForm` component

  We will create a `PostForm` component that will be used to create and update posts.

  - In the `components` folder, create a `PostForm.tsx` file
  - In the `PostForm.tsx` file, add:
  ```
  import React, { useState } from 'react';

  export const PostForm = () => {
    const [title, setTitle] = useState('');
    const [content, setContent] = useState('');

    const handleSubmit = (e) => {
      e.preventDefault();
      const post = {
        title: title,
        content: content,
      };
      console.log(post);
    };

    return (
      <div>
        <h1>Create Post</h1>
        <form onSubmit={handleSubmit}>
          <div className='mb-3'>
            <label htmlFor='title' className='form-label'>
              Title
            </label>
            <input
              type='text'
              className='form-control'
              id='title'
              value={title}
              onChange={(e) => setTitle(e.target.value)}
            />
          </div>
          <div className='mb-3'>
            <label htmlFor='content' className='form-label'>
              Content
            </label>
            <textarea
              className='form-control'
              id='content'
              rows={3}
              value={content}
              onChange={(e) => setContent(e.target.value)}
            ></textarea>
          </div>
          <button type='submit' className='btn btn-primary'>
            Submit
          </button>
        </form>
      </div>
    );
  };
  ```

  Consider using react-hook-forms to handle form validation and submission. Find out more info here: https://react-hook-form.com/

  You can opt to add a button to the `PostList` component to open the `PostForm` component in a modal, or you can create a separate `PostCreate` component that will render the `PostForm` component.

  Alternatively, you can use react-router-dom to create a separate page for the `PostForm` component in the `pages` folder. You would add a route to the `App.tsx` file and add a link to the `PostForm` page.

  ### 5. Add the `PostList` component to the `HomePage` page

  At the moment, the `HomePage` page is just rendering a `<h1>` tag.

  We will add the `PostList` component to the `HomePage` page.

  - In the `HomePage` file, add:
  ```
  import { PostList } from '../components/PostList';

  export const HomePage = () => {
    return (
      <div>
        <h1>Home Page</h1>
        <PostList />
      </div>
    );
  };
  ```

  When you run the app, you should see the `PostList` component rendered on the Home page.

  ### 6. Test the ReactTS app (Manually)

  Manually test the ReactTS app by running `npm start` and checking the Home page.

  You should see the `PostList` component rendered on the Home page, and the number of posts in the database and each post title and content rendered.

  You can also try creating Jest tests for the components in the `__tests__` folder.

  # Checkpoint 2 - ReactTS app

  At this point, you should have:
  - A ReactTS app with a `PostList` component that renders the number of posts in the database and each post title and content
  - These components:
    - `Navbar`
    - `PostList`
    - `PostItem`
    - `PostForm`
  - (Optional) tests for the components

  Additionally, after manually testing the app, you should be able to see the `PostList` component rendered on the Home page.

  We still need to finish functionality for Creating, Updating and Deleting posts.

Creating a ReactTS app with a Post component for a Ruby on Rails API

Creating Ruby on Rails and TypeScript React app - Part 2

Part 2 of 4 - Creating Ruby on Rails and TypeScript React app

# How to create a small microservice app with Ruby on Rails (RoR) and TypeScript React (ReactTS)

  How to use this Tutorial:
  - Read it! There's a lot in here to help with learning and understanding basic microservice architecture e.g. CORS policies
  - Bullet pointed sections are Actions - these are what you need to do
  - Give me any feedback if there are any mistakes in the tutorial

  Advanced Tutorial that requires some basic knowledge in:
  - Ruby on Rails setup (follow the basic tutorial)
  - RESTful APIs and [HTTP Request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
  - PostgreSQL
  - JavaScript

  Technical and installation requirements:
  - Ruby (and rbenv), v3.1.2
  - Ruby on Rails,  v>7.0.6
  - NodeJS, v>16.13.1

  ### 7. Add the `PostForm` component to the `PostList` component

  We will add the `PostForm` component to the `PostList` component that will be shown in a modal.

  - In the `PostList` file, add:
  ```
  import { PostForm } from './PostForm';
  import { Modal, Button } from 'react-bootstrap';

  export const PostList = () => {
    // rest stays the same
    const [show, setShow] = useState(false);

    return (
      <div>
        <Button
          variant='primary'
          onClick={() => setShow(true)}
          className='mb-3'
        >Create Post</Button>
        <h1>Post List</h1>
        <p># of posts: {posts.length}</p>
        {posts.map((post) => (
          <PostItem post={post} />
        ))}
      </div>
    );
  }
  ```

  We will use React Bootstrap's Modal component to show the `PostForm` component in a modal.

  - In the `PostList` file, add a functional component called `PostModal`:
  ```
  const PostModal = () => {
    return (
      <Modal show={show} onHide={() => setShow(false)}>
      <Modal.Header closeButton>
        <Modal.Title>Create Post</Modal.Title>
      </Modal.Header>
      <Modal.Body>
        <PostForm />
      </Modal.Body>
    )
  }

  // update the return statement to render the PostModal component
  return (
    <div>
      <Button
        variant='primary'
        onClick={() => setShow(true)}
        className='mb-3'
      >Create Post</Button>
      <h1>Post List</h1>
      <p># of posts: {posts.length}</p>
      {posts.map((post) => (
        <PostItem post={post} />
      ))}
      <PostModal />
    </div>
  );
  ```

  When you run the app, you should see a button that opens a modal with the `PostForm` component.

  ### 8. Add Edit functionality to the `PostItem` component

  If you've opted to handle edits in the `PostItem` component, you will need to add a button to open the `PostForm` component in a modal.

  - In the `PostItem` file, add:
  ```
  import { PostForm } from './PostForm';
  import { Modal, Button } from 'react-bootstrap';

  export const PostItem = ({ post }: { post: Post }) => {
    const [show, setShow] = useState(false);

    const PostModal = () => {
      return (
        <Modal show={show} onHide={() => setShow(false)}>
          <Modal.Header closeButton>
            <Modal.Title>Edit Post</Modal.Title>
          </Modal.Header>
          <Modal.Body>
            <PostForm />
          </Modal.Body>
        </Modal>
      )
    }

    return (
      <div>
        <h3>{post.title}</h3>
        <p>{post.content}</p>
        <Button
          variant='primary'
          onClick={() => setShow(true)}
          className='mb-3'
        >Edit Post</Button>
      </div>
    );
  }
  ```

  When you run the app, you should see a button that opens a modal with the `PostForm` component.

  ### 9. Update `PostForm` to handle Create and Edit functionality

  We will update the `PostForm` component to handle Create and Edit functionality.

  - In the `PostForm` file, add:
  ```
  import React, { useState, useEffect } from 'react';
  import axios from 'axios';
  import { Post } from '../Types/PostTypes';

  export const PostForm = ({ post }: { post?: Post }) => {
    const [title, setTitle] = useState('');
    const [content, setContent] = useState('');

    useEffect(() => {
      if (post) {
        setTitle(post.title);
        setContent(post.content);
      }
    }, [post]);

    const handleSubmit = (e) => {
      e.preventDefault();
      const post = {
        title: title,
        content: content,
      };
      console.log(post);
    };

    return (
      <div>
        <h1>{post ? 'Edit Post' : 'Create Post'}</h1>
        <form onSubmit={handleSubmit}>
          <div className='mb-3'>
            <label htmlFor='title' className='form-label'>
              Title
            </label>
            <input
              type='text'
              className='form-control'
              id='title'
              value={title}
              onChange={(e) => setTitle(e.target.value)}
            />
          </div>
          <div className='mb-3'>
            <label htmlFor='content' className='form-label'>
              Content
            </label>
            <textarea
              className='form-control'
              id='content'
              rows={3}
              value={content}
              onChange={(e) => setContent(e.target.value)}
            ></textarea>
          </div>
          <button type='submit' className='btn btn-primary'>
            Submit
          </button>
        </form>
      </div>
    );
  };
  ```

  We will also need to update the `PostModal` component in the `PostList` component to pass in the `post` prop.

  - In the `PostList` file, add:
  ```
  const PostModal = () => {
    return (
      <Modal show={show} onHide={() => setShow(false)}>
        <Modal.Header closeButton>
          <Modal.Title>{post ? 'Edit Post' : 'Create Post'}</Modal.Title>
        </Modal.Header>
        <Modal.Body>
          <PostForm post={post} />
        </Modal.Body>
      </Modal>
    )
  }
  ```

  We will also need to update the `PostItem` component to pass in the `post` prop.

  - In the `PostItem` file, add:
  ```
  const PostModal = () => {
    return (
      <Modal show={show} onHide={() => setShow(false)}>
        <Modal.Header closeButton>
          <Modal.Title>{post ? 'Edit Post' : 'Create Post'}</Modal.Title>
        </Modal.Header>
        <Modal.Body>
          <PostForm post={post} />
        </Modal.Body>
      </Modal>
    )
  }
  ```

  It's optional but also good practice to refactor the `PostModal` component into a separate file.

  - In the `components` folder, create a `PostModal.tsx` file
  - In the `PostModal.tsx` file, add:
  ```
  import React, { useState } from 'react';
  import { Modal } from 'react-bootstrap';
  import { PostForm } from './PostForm';
  import { Post } from '../Types/PostTypes';

  export const PostModal = ({ post }: { post?: Post }) => {
    const [show, setShow] = useState(false);

    return (
      <Modal show={show} onHide={() => setShow(false)}>
        <Modal.Header closeButton>
          <Modal.Title>{post ? 'Edit Post' : 'Create Post'}</Modal.Title>
        </Modal.Header>
        <Modal.Body>
          <PostForm post={post} />
        </Modal.Body>
      </Modal>
    )
  }
  ```

  - In the `PostList` file, add:
  ```
  import { PostModal } from './PostModal';

  // update the return statement to render the PostModal component
  return (
    <div>
      <Button
        variant='primary'
        onClick={() => setShow(true)}
        className='mb-3'
      >Create Post</Button>
      <h1>Post List</h1>
      <p># of posts: {posts.length}</p>
      {posts.map((post) => (
        <PostItem post={post} />
      ))}
      <PostModal />
    </div>
  );
  ```

  - In the `PostItem` file, add:
  ```
  import { PostModal } from './PostModal';

  // update the return statement to render the PostModal component
  return (
    <div>
      <h3>{post.title}</h3>
      <p>{post.content}</p>
      <Button
        variant='primary'
        onClick={() => setShow(true)}
        className='mb-3'
      >Edit Post</Button>
      <PostModal post={post} />
    </div>
  );
  ```

  When you run the app, you should see a button that opens a modal with the `PostForm` component. The `PostForm` component should be pre-filled with the post data if you're editing a post.

  # Checkpoint 3 - ReactTS app

  At this point, you should have:
  - A ReactTS app with a `PostList` component that renders the number of posts in the database and each post title and content
  - These components:
    - `Navbar`
    - `PostList`
    - `PostItem`
    - `PostForm`
    - `PostModal`
  - (Optional) tests for the components

  Additionally, after manually testing the app, you should be able to see the `PostList` component rendered on the Home page. You should also be able to create and edit posts.

  The remaining CRUD action left is Delete.

Updating your ReactTS frontend to handle Create and Edit functionality

Creating Ruby on Rails and TypeScript React app - Part 3

Part 3 of 4 - Creating Ruby on Rails and TypeScript React app

How to use this Tutorial:
  - Read it! There's a lot in here to help with learning and understanding basic microservice architecture e.g. CORS policies
  - Bullet pointed sections are Actions - these are what you need to do
  - Give me any feedback if there are any mistakes in the tutorial

  Advanced Tutorial that requires some basic knowledge in:
  - Ruby on Rails setup (follow the basic tutorial)
  - RESTful APIs and [HTTP Request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
  - PostgreSQL
  - JavaScript

  Technical and installation requirements:
  - Ruby (and rbenv), v3.1.2
  - Ruby on Rails,  v>7.0.6
  - NodeJS, v>16.13.1

  ### 10. Add Delete functionality to the `PostItem` component

  Delete can be handled in the `PostItem` component with a button.

  - In the `PostItem` file, add:
  ```
  import axios from 'axios';

  export const PostItem = ({ post }: { post: Post }) => {
    // rest stays the same

    const handleDelete = async () => {
      try {
        await axios.delete(`${process.env.REACT_APP_API_URL}/posts/${post.id}`);
      }
      catch (err) {
        console.log(err);
      }
    }

    return (
      <div>
        <h3>{post.title}</h3>
        <p>{post.content}</p>
        <Button
          variant='primary'
          onClick={() => setShow(true)}
          className='mb-3'
        >Edit Post</Button>
        <Button
          variant='danger'
          onClick={handleDelete}
          className='mb-3'
        >Delete Post</Button>
      </div>
    );
  }
  ```

  When you run the app, you should be able to delete posts.

  It's best practice to add a confirmation modal before deleting a post, so that the user can confirm that they want to delete the post.

  - In the `PostItem` file, add:
  ```
  import { Modal, Button } from 'react-bootstrap';

  export const PostItem = ({ post }: { post: Post }) => {
    // rest stays the same
    const [showDeleteModal, setShowDeleteModal] = useState(false);

    const DeleteModal = () => {
      return (
        <Modal show={showDeleteModal} onHide={() => setShowDeleteModal(false)}>
          <Modal.Header closeButton>
            <Modal.Title>Delete Post</Modal.Title>
          </Modal.Header>
          <Modal.Body>
            <p>Are you sure you want to delete this post?</p>
            <Button
              variant='danger'
              onClick={handleDelete}
              className='mb-3'
            >Delete Post</Button>
          </Modal.Body>
        </Modal>
      )
    }

    return (
      <div>
        <h3>{post.title}</h3>
        <p>{post.content}</p>
        <Button
          variant='primary'
          onClick={() => setShow(true)}
          className='mb-3'
        >Edit Post</Button>
        <Button
          variant='danger'
          onClick={() => setShowDeleteModal(true)}
          className='mb-3'
        >Delete Post</Button>
        <DeleteModal />
      </div>
    );
  }
  ```

  When you run the app, you should see a button that opens a modal with the `PostForm` component. The `PostForm` component should be pre-filled with the post data if you're editing a post.

  #### 11. Check the RoR API app and add CORS updates

  You may have some issues creating, editing, and deleting posts at this point.

  This may be due to CORS issues. You can check the Rails API app logs to see if there are any CORS errors.

  We can make some changes to the `posts_controller.rb` file to allow requests from the ReactTS app.

  - In the `posts_controller.rb` file, add:
  ```
  before_action :set_access_control_headers

  # add a new private method

  def set_access_control_headers
    headers['Access-Control-Allow-Origin'] = '*'
    headers['Access-Control-Allow-Methods'] = 'POST, PUT, DELETE, GET, OPTIONS'
    headers['Access-Control-Request-Method'] = '*'
    headers['Access-Control-Allow-Headers'] = 'Origin, X-Requested-With, Content-Type, Accept, Authorization'
  end
  ```

  You will need to update this later if you deploy the app i.e. to add the production URL.

  # Checkpoint 4 - ReactTS app

  You should now have a basic CRUD app with a ReactTS frontend and a Rails API backend.

  You can continue to add more features to the app, such as:
  - Add a Search bar
  - Add pagination
  - Add authentication using Devise and JWT
  - Add a User model
  - Add a Comment model
  - Add a Like model
  - Optimize the app for performance
  - Add tests for the ReactTS app
  - Add tests for the Rails API app
  - Better styling
  - More types for the ReactTS app e.g. `PostListProps`, `PostItemProps`, `PostFormProps`
  - Other pages e.g. About page, Contact page
  - Deploy the app to Heroku and Vercel

  # A Note about Authentication

  If you want to add authentication to the app, you can use Devise and JWT.

  Devise is a popular authentication gem for Rails. JWT is a popular authentication method for APIs.

  - In the `Gemfile`, add:
  ```
  gem 'devise'
  gem 'devise-jwt'
  ```
  - Run `bundle install`
  - Run `rails generate devise:install`
  - Run `rails generate devise User`
  - Run `rails generate devise:controllers users`
  - Run `rails generate devise:jwt_secret`

  This may not work in generating the JWT secret. You can also use `rails secret` to generate a secret key and add it to an `.env` file in the RoR root app. Then you would add `config.jwt_secret = ENV['JWT_SECRET']` to the `devise.rb` file.

  - Run `rails db:migrate`
  - In the `routes.rb` file, add:
  ```
  devise_for :users,
    path: '',
    path_names: {
      sign_in: 'login',
      sign_out: 'logout',
      registration: 'signup'
    },
    controllers: {
      sessions: 'users/sessions',
      registrations: 'users/registrations'
    }
    # rest of the routes stay the same
  ```
  - In the `sessions_controller.rb` file, add:
  ```
  respond_to :json

  def create
    super do |user|
      if request.format.json?
        render json: {
          user: user,
          token: JWT.encode({
            user_id: user.id,
            username: user.username,
          }, ENV['DEVISE_JWT_SECRET_KEY'], 'HS256')
        } and return
      end
    end
  end

  def destroy
    signed_out = (Devise.sign_out_all_scopes ? sign_out : sign_out(resource_name))

    if request.format.json?
      render json: { message: 'Signed out successfully' }, status: :ok
    else
      redirect_to after_sign_out_path_for(resource_name)
    end
  end
  ```

  You will also need to add login forms to the ReactTS app and update the `PostList` component to fetch the posts based on the user.

  Additionally, you may need to add a method to check the JWT received by the RoR API app is valid before allowing the user to access the API endpoints.

  This is one of the trickier parts of the app, so you may want to skip this for now and come back to it later.

Adding the final CRUD action - Delete - to your ReactTS frontend and a note about authentication

Creating Ruby on Rails and TypeScript React app - Final Part

Part 4 of 4 - Creating Ruby on Rails and TypeScript React app

# How to setup reCAPTCHA v2 in a Rails and React app

  ## Introduction

  What is reCAPTCHA and why is it important?

  [reCAPTCHA](https://www.google.com/recaptcha/about/) is a tool designed by Google to help protect websites from spam messages or bots. You've probably seen it before - v2 is the 'I'm not a robot' checkbox or spotting the bridge in a grid of images.

  Scripts, bots and most kinds of automated software can't solve these challenges in a convincingly 'human' way. For example, a bot would take a slow and direct route to a v2 checkbox, while a human may move their mouse around the page, click on other elements, and take a few seconds to check the box.

  As developers, we want to reduce the amount of 'noise' messages we receive via forms on our websites. reCAPTCHA is a great tool for doing this.

  ## Getting started

  You should go to the [reCAPTCHA admin console](https://www.google.com/recaptcha/admin/create) and create a new site. You'll need to enter a label (for your own reference) and the domain of your website. You can also choose which reCAPTCHA version you want to use - we'll be using v2.

  > NOTE: for development purposes, you can add `Localhost` to the list of domains. This will allow you to test reCAPTCHA on your local machine.

  Once you've created your site, you'll be given a site key and a secret key. Keep a note of these - we'll need them later.

  # Adding reCAPTCHA to your Frontend app

  In this short guide, I will be using NextJS and React with TypeScript.

  We'll be using the [react-google-recaptcha](https://www.npmjs.com/package/react-google-recaptcha) package to add reCAPTCHA to our React app.

  If you're using a different Frontend, you'll need to find a package that works for you. But, the process remains similar:

  - Add the respective package to your project
  - Import the package into your app/component
  - Add the reCAPTCHA component to your form
  - Add the reCAPTCHA site key to your app - via an `.env` file or other secret management tool

  In the frontend, we will be using the reCAPTCHA element (tickbox in this case) which creates a token that we can send to the backend for verification. Although you can verify the token on the frontend, it's best practice to do this on the backend.

  ## Adding the reCAPTCHA component

  - Save the site key to an environment variable i.e. in a `.env` file
    - In your React app, you can save this variable as `REACT_APP_RECAPTCHA_SITE_KEY`.
    - In a NextJS app, you will need to prefix the variable with `NEXT_PUBLIC_` i.e. `NEXT_PUBLIC_RECAPTCHA_SITE_KEY`. Why? Read more [here](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables#bundling-environment-variables-for-the-browser).
  - You can create a separate component for the reCAPTCHA element, or add it to your form component. In this case, we will add to the form component.
  - Import `ReCAPTCHA` from the `react-google-recaptcha`
    - package: `import ReCAPTCHA from 'react-google-recaptcha'`
  - Add the reCAPTCHA element:
  ```jsx
    <ReCAPTCHA
      ref={}
      sitekey={process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY}
      onChange={}
    />
  ```
  - The `ref` prop is used to reset the reCAPTCHA element. We'll use this later.
  - The `sitekey` prop is the site key we saved earlier.
  - The `onChange` prop is a function that will be called when the user completes the reCAPTCHA challenge. We'll use this to save the token to state.
  - We will use `useState` to save the token to state:
  ```tsx
    const [recaptchaToken, setRecaptchaToken] = useState<string | null>(null);
  ```
  - We will also use `useRef` to create a reference to the reCAPTCHA element:
  ```tsx
    const recaptchaRef = useRef<ReCAPTCHA>(null);
  ```
  - Add a function to handle the captcha change - let's call it `handleCaptchaChange`:
  ```tsx
  const handleCaptchaChange = (value: string | null) => {
    if (value === null) {
      return;
    }
    setRecaptchaToken(value);
  };
  ```
  - Now, edit the reCAPTCHA element to use the `recaptchaRef` and `handleCaptchaChange`:
  ```tsx
    <ReCAPTCHA
      ref={recaptchaRef}
      sitekey={process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY}
      onChange={handleCaptchaChange}
    />
  ```

  Hopefully, at this point, the reCAPTCHA should render on your form. If not, try restarting your console.

  One thing I had to do to get the initial reCAPTCH to work was to wrap the reCAPTCHA in a conditional statement. In TypeScript React apps, `process.env` is not treated as defined, even if it is explicitly defined in your `.env` file.

  ```tsx
    {process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY && (
      <ReCAPTCHA
        ref={recaptchaRef}
        sitekey={process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY}
        onChange={handleCaptchaChange}
      />
    )}
  ```

  ## Resetting the reCAPTCHA element

  We need to reset the reCAPTCHA element when the form is submitted. This is so that the user can't submit the form multiple times with the same token.

  This is where `useRef` comes in. In your form's `onSubmit` function, you can reset the reCAPTCHA element by calling `recaptchaRef.current?.reset()`.

  e.g.

  ```tsx
  // note: I'm using react-hook-form here
  const onSubmit: SubmitHandler<FormValues> = async (data) => {
    // ... other form submission logic

    // check if the user has completed the reCAPTCHA challenge
    if (recaptchaToken ===  || !recaptchaToken) {
      // ... here you can also add a message to the user to complete the reCAPTCHA challenge, or some kind of loading or error handling

      // if not, return early
      return;
    }

    // ... submit request to backend - using a try/catch block
    try {
      // ... submit request to backend
      // NOTE: remember to send the recaptchaToken to the backend for verification
    } catch (error) {
      // ... handle error
    } finally {
      // ... reset the reCAPTCHA element
      recaptchaRef.current?.reset();
    }
  }
  ```

  In summary, use a `try/catch/finally` block (good practice) to make your request and in the `finally` block, reset the reCAPTCHA reference.

  Also, note that you should be sending the reCAPTCHA token to the backend for verification. We'll cover this in the next section.

  # Checkpoint

  You should now have a working reCAPTCHA element on your form. When the user completes the challenge, the token should be saved to state. When the form is submitted, the reCAPTCHA element should be reset - regardless of whether the form is submitted successfully or not.

  # Adding reCAPTCHA to your Backend app

  In my case, I did this in a Rails app. But, the process should be similar for other backend frameworks.

  - Store the server key we generated earlier in an environment variable. You can do this in your `.env` file.
  > In my case, I didn't use the [`recaptcha`](https://github.com/ambethia/recaptcha) gem. This is a route you can take. For educational purposes, I chose to verify the token manually.

  - In your controller, you can create a method to verify the token:
  ```ruby
    def validate_recaptcha
      recaptcha_secret_key = ENV['SERVER_RECAPTCHA_KEY']
      recaptcha_response = params['captcha']

      uri = URI('https://www.google.com/recaptcha/api/siteverify')
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true

      request = Net::HTTP::Post.new(uri.path)
      request.set_form_data(
        'secret' => recaptcha_secret_key,
        'response' => recaptcha_response
      )

      response = http.request(request)

      if response.is_a?(Net::HTTPSuccess)
        data = JSON.parse(response.body)
        return data['success']
      else
        return false
      end
    end
  ```
  - In the above code, this is what happens:
    - We create a URI object for the reCAPTCHA verification endpoint
    - We create a new HTTP object and set `use_ssl` to true
    - We create a new POST request to the reCAPTCHA verification endpoint
    - We set the form data to include the secret key and the token
    - We send the request and parse the response
    - If the response is successful, we return the `success` value from the response body
  - You can then use this method in your controller action for the form submission, e.g.:
  ```ruby
  def some_form_method
    if validate_recaptcha
      # ... do something with the form data
    else
      # ... reject the form submission as the reCAPTCHA token is invalid
    end
  end
  ```
  # Conclusion

  You should now have a working reCAPTCHA on a React form with verification in your backend. Your form is now protected from spam messages and bots. Voilá!

  # Further reading

  - [reCAPTCHA v2 documentation](https://developers.google.com/recaptcha/docs/display)
  

A quick guide to setting up reCAPTCHA v2 in a Rails and React app

Blog