Web Applications - freeCodeCamp.org

How to Perform Performance Testing on Your Web Applications

Oluwatobi — Mon, 26 Feb 2024 19:52:39 +0000

Performance testing is an important yet underrated field of software development. And it’s a must-have skill that can help you prevent common software failures that occur in production applications.

Performance testing is a routine software practice which is carried out to determine the stability of a system in terms of scalability, reliability, and data management, among other parameters.

In this tutorial, I'll walk you through what performance testing entails, and the common tools used for backend testing. We'll also walk through a demo performance testing project together.

The tutorial is simplified and suitable for beginners, mid-level developers, and professional developers. Being proficient in performance testing is fundamental to growing as a backend developer, and this guide will serve as a good review even if you're more advanced in your career. With that said, let's dive in.

Prerequisites:

Intermediate knowledge of Node.js
Basic knowledge of JavaScript operations
Knowledge of API development\

What is Performance Testing?

Performance testing serves quite a lot of purposes – one of the most important of which is to test system efficiency in performing and sustaining tasks. It also serves as a standard you can use to compare systems of varying efficiency and builds and enables you to choose the most effective one.

Performance testing also helps reveal vulnerabilities. State-of-the-art testing tools are well optimized to efficiently analyze the code to detect any errors. They're quick to highlight the areas where these errors occur.

The end goal of performance testing is dependent how you're using the application. It might be concurrency-oriented or transaction rate-oriented, depending on whether the app involves end users or not.

Performance testing could also involve load testing, which is usually carried out to evaluate the behavior of a web service under a specific expected load. Other types of testing you can do include integration testing, spike testing, soak testing, and stress testing.

Examples of Performance Testing Tools

There are many tools commonly used to test the efficacy and latency of web applications. In this section, I'll discuss some of the popular tools used, and highlight their strengths and use cases.

Jest

Jest is a multi-platform testing tool used to assess the correctness of JavaScript-based applications. It's the one we'll be using in this demo.

Jest was initially created to test the efficiency of React applications, but has since been extended to test the efficiency of Node.js apps as well. It also offers a code coverage feature.

Mocha

Mocha is a concise asynchronous JavaScript-based testing tool for Node.js applications. It is also used with assertion libraries such as [Chai]( https://www.npmjs.com/package/chai) and [should]( https://www.npmjs.com/package/should).

Pythagora

Pythagora offers a unique integrating testing feature to help test how different part of the application works together. It also has a code coverage feature.

Artillery

Artillery is a stack agnostic testing tool. This means it can be used for multiple web applications based on different programming languages and still produce an optimal test outcome.

This tool provides efficient load testing features which help to determine the optimal status of the application when exposed to a large load of traffic. It also checks the speed at which an app responds to a user request without crashing.

Ava

Ava is a JavaScript-based performance unit testing tool used to test the efficacy of Node.js applications. It works asynchronously, running multiple concurrent tests to determine the suitability of multiple code units.

Loadtest

Loadtest is a special Node package which is used to load test Node.js applications. It evaluates their ability to cope with requests of varying volumes and it evaluates for efficiency and concurrency.

Apache J-meter

Apache J-meter offers load-testing features for web applications. It has an in-built IDE to enable interaction with the user. It is multithreaded, increasing its ability to mimic several users.

There are other testing tools which are also useful. But in this tutorial, we will be utilizing Jest to test our back-end application.

Demo Project

Install Jest

We'll now perform a unit test on our code using the Jest testing tool. To do this, you'll need to install the Jest package in your code folder. Type npm install jest in the command prompt. A success message will be displayed when the installation is completed.

Configure `package.json`

In this tutorial, we'll test the efficiency of some selected routes in our Node.js application. This will necessitate writing different unit tests for each route and evaluating its correctness.

Now let’s optimize our file structure to successfully unit test our application. Navigate to the package.json file and edit it to include the following code:

"scripts": {
    "test": " jest",
    "start": "nodemon index.js"
  },

Modifying the package.json file to include this code ensures that the Node.js server recognizes Jest as our default unit testing tool for the project. By so doing, any time we enter npm test in the command prompt, Jest gets activated.

Set up the test environment

Create a folder in the root directory named “tests”. This helps the Jest operator locate the specific files housing the routes to be tested.

Within the test folder, create a test file. The file can be named whatever you prefer, but the suffix .test.js should be added to enable Jest to recognize it and execute it.

After completing these steps, let’s get into the core details of unit testing in our project.

Run the unit tests

The demo project we'll test in this tutorial is an eBook library application which contains some functions such as a get all books route, Get a single book route, upload a book route, and delete a book route. We'll create unit tests for the GetAllBooks route in the example below, and then you can try to create your own for the other routes.

So firstly, we'll import the book database into the test.js file like this:

const Book = require('../models/Book')

The code above imports and initializes our default book MongoDB database model.

Then we'll import the functions that we'll test in each route:

const Book =  require("../models/Book")

async function GetAllBooks (req, res)  {
    try {
const allBooks =  await Book.find();
res.status(200)
res.send(allBooks)
    }
    catch (err) {
res.status(500)
res.send(err) 
    }
}
module.exports = {GetAllBooks};

const {GetAllBooks} = require("../controllers/Books");

The code above imports the getAllBooks function from a controller folder.

Having imported the function, let's now go ahead to setup our Jest unit test function.

jest.mock("../models/Book");

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

it("it should return all the books in the database", async () => {

Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));

  await GetAllBooks(req, res);


expect(res.status).toHaveBeenCalledWith(200);

expect(res.send).toHaveBeenCalledTimes(1);
});

First of all, Jest offers you the ability to create a fake database by copying the structure of the default database. This is known as mocking. This enables the unit test to operate faster and eliminate the lag that comes with getting responses from large databases.

Testing which involves the real database is referred to as end-to-end testing as opposed to unit testing.

Here's how you can do that in Jest:

jest.mock("../models/Book");

The code above illustrates database mocking. In order to get a faster unit test, we have to mock the existing Book database model we're using in our application.

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

The above code contains the default sample requests and response objects. The sample response object contains both the status and send functions, which return a defined output if executed successfully or not.

it("it should return all the books in the database", async () => {
Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));
  await GetAllBooks(req, res); 
expect(res.status).toHaveBeenCalledWith(200);
expect(res.send).toHaveBeenCalledTimes(1);
});

Now the It function contains a short description of what the test should be about. This is then coupled to an anonymous asynchronous function which contains a mock implementation of the database model with some dummy data.

After that, the getAllBooks request is triggered and executed with a null request passed to it and the format of the response object is included.

The expect statement returns passed if the function satisfies the requirements expected. For this code, the requirements are that the response object should return a status code of 200 and the response.send object should be called at least once with the response object included. If it fails, a failed status will be returned.

Tests passing

You now know the basics of how to unit test functions. You can also try to test the delete book route, upload a book route and find a specific book route.

Conclusion

In this tutorial, you've been able to harness the usefulness of testing tools in optimizing your web applications.

You've learned about various testing tools available and their use cases, and you also implemented a unit test in a web application.

Following the steps highlighted in this tutorial, you will be able to perform unit tests on your coding projects.

I sincerely hope you learned something new and enjoyed this tutorial. Until next time, keep on coding.

How to Build Web Apps with Nuxt and Laravel

Abdulrahman Yusuf — Wed, 07 Feb 2024 10:59:00 +0000

The Laravel framework is one of the most widely used technologies in the web development ecosystem. It's relatively straightforward, and it's easy to use for building websites.

Laravel is built upon PHP, a popular web programming language that’s used in over 75% of websites on the web. So knowing how to use a framework like Laravel can help make you a sought-after developer – and it also makes building websites and applications more seamless.

Nuxt is a Vue.js framework used for building rich and interactive web applications. It lets you choose between different rendering modes depending on the application requirements you want to build. You can choose between building a fully server-rendered app or client-rendered app. Nuxt also offers a mixture of both rendering modes, making applications much more powerful, efficient, and interactive.

In this article, you'll learn how to build full-stack applications using Nuxt and Laravel by building a Book Library App. The app will comprise a library API that we'll build using Laravel and a frontend using Nuxt.

We’ll talk about:

Installing and setting up Laravel
Creating database models
Migrations
Controllers
API Testing
Form Validations
Data Fetching in Nuxt

And more. Get ready, and let's dive in.

Prerequisites

PHP and Composer are installed on your local machine.
Node.js is installed on your local machine.
yarn or npm installed on your local machine (npm comes pre-installed with Node).
A text editor installed, like VSCode.
Basic knowledge of HTML, CSS, JavaScript, and the terminal.
Basic knowledge of PHP, Vue.js, and TypeScript.

How to Set Up Laravel on Your Machine

To begin the Laravel installation, open your terminal and bootstrap a new Laravel project using the command below:

composer create-project laravel/laravel library-api && cd library-api && code .

This command creates a new Laravel project in your directory. cd's into it, and open up VSCode using the code . command. (If you happen to be using a different editor, you can remove that command and open the directory manually).

To test your Laravel server and ensure everything works, let’s test the server by using the php artisan serve command in the terminal. This should make your API available on port 8000 and accessible in your browser.

Laravel Starter Application

How to Build the Book Library API

We will be creating a simple CRUD endpoint for our book library, that is the API should be able to achieve the following:

Create new book entries
Get a list of all the book entries in the database
Edit previously added book entries
Delete book entries from the database

Setting up the database

Laravel comes with a variety of databases you can use during development. By default, it automatically creates a configuration setup for MySQL. But for simplicity, we’ll be making use of a SQLite database in this tutorial.

Open the .env file in your root directory, change the DB_CONNECTION value from mysql to sqlite, and comment the remaining database configurations as you can see below:

Environmental Variables (available in .env file)

Laravel automatically helps create the SQLite database when the migrations command is run. We’ll do that in a bit after creating our database models.

Creating the Book model

When you're building backend APIs, a model acts as a template that’s used to set up your database tables. It contains high-level instructions for how the tables and columns should be created.

In Laravel, you can use the command below to create a Book model:

php artisan make:model Book -m

This creates your Book model in the app/models directory and also creates a new migration file for you in the database/migrations directory.

Navigate to the migrations directory and open the newly created migrations file. It should be in the format current_date_create_books_table.php like you can see below:

Default Migrations

Edit the up function and add the following content:

$table->string('title');
$table->string('author');
$table->string('isbn');
$table->date('published_date');
$table->text('cover_image')->nullable();
$table->foreignIdFor(User::class);

Your migrations file should look like this now:

Updated Migrations

In summary, you added new fields to be created for the Book tables. Title, author, and isbn all have a data type of string, while published_date and cover_image have data types of date and text, respectively.

You also made the cover_image nullable, that is the field can be left out whenever a new book entry is created.

Lastly, you imported the User class and made it a foreign key to your Book table, creating a many-to-one relationship with the User table.

Now, let’s create your tables by running the migrations file with the command below:

php artisan migrate

You should get a prompt in the terminal asking if you want to create your SQLite database before the migrations. Select yes and press enter to proceed with the migrations.

Once the migration has been run successfully, navigate to the Book model and paste in the following code:

 /**
* The attributes that are mass assignable.
*
* @var array
*/

protected $fillable = [
    'user_id',
    'title',
    'author',
    'isbn',
    'published_date',
    'cover_image'
];

This will allow mass assignment when passing data into the model (passing the data as a whole instead of individually). Your Book model should look like this now:

Updated Book Model

Creating the Book controller

The controller is responsible for housing the business logic for any API being created. The implementation logic for how we want to perform any CRUD operations with the library API will live here.

Laravel also provides a command for you to make this easier for developers. Paste the command below in your terminal to create our book controller:

php artisan make:controller BookController

This should be accessible at app\Http\Controllers\BookController.php. Replace the content of your BookController class with the code snippet below:



namespace App\Http\Controllers;

use App\Models\Book;
use Carbon\Carbon;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Storage;


class BookController extends Controller
{
    public function store(Request $request)
    {
        $data = $request->validate([
            'title' => 'required|string',
            'author' => 'required|string',
            'isbn' => 'required|string|unique:books',
            'published_date' => 'required|string',
            'cover_image' => 'nullable|image|max:2048',
        ]);

        try {
            $published_date = Carbon::parse($data['published_date'])->toDateString();
            $data['published_date'] = $published_date;
            $data['user_id'] = 1; // Making the assumption the id of the user is 1 
        } catch (\Exception $e) {
            return response()->json(['Error' => 'Bad Request'], 400);
        }

        $book = new Book($data);

        if ($request->hasFile('cover_image')) {
            $coverImage = $request->file('cover_image');
            $coverImageName = time() . '.' . $coverImage->getClientOriginalExtension();
            $coverImage->move(public_path('images'), $coverImageName);
            $book->cover_image = $coverImageName;
        }

        $book->save();

        return response()->json(['message' => 'Book added successfully'], 201);
    }

    public function index()
    {
        $books = Book::all();

        return response()->json(['books' => $books], 200);
    }

    public function update(Request $request, $id)
    {
        $book = Book::findOrFail($id);
        $data = $request->all();

        try {
            $published_date = Carbon::parse($data['published_date'])->toDateString();
            $data['published_date'] = $published_date;
            $data['user_id'] = $book->user_id;
        } catch (\Throwable $th) {
            Log::error('Error ', $th);
            return response()->json(['Error' => 'Bad Request'], 400);
        }

        $book->update($data);

        if ($request->hasFile('cover_image')) {
            // Delete the previous cover image if it exists
            if ($book->cover_image) {
                Storage::delete('public/images/' . $book->cover_image);
            }

            $coverImage = $request->file('cover_image');
            $coverImageName = time() . '.' . $coverImage->getClientOriginalExtension();
            $coverImage->storeAs('public/images', $coverImageName);
            $book->cover_image = $coverImageName;
            $book->save();
        }

        return response()->json(['message' => 'Book updated successfully'], 200);
    }

    public function destroy($id)
    {
        $book = Book::findOrFail($id);

        // Delete the cover image if it exists
        if ($book->cover_image) {
            Storage::delete('public/images/' . $book->cover_image);
        }

        $book->delete();

        return response()->json(['message' => 'Book deleted successfully'], 200);
    }
}

Defining the API Routes

Routing is one of the most important parts of building an API. Routes serve as access points through which developers, clients, or any other services can access an API.

The Laravel router allows you to register any routes that correspond to any HTTP verb being requested.

Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

Navigate to the routes/api.php file and create the following routes for your API:

Route::post('/books', [BookController::class, 'store']);
Route::get('/books', [BookController::class, 'index']);
Route::put('/books/{id}', [BookController::class, 'update']);
Route::delete('/books/{id}', [BookController::class, 'destroy']);

Testing the API

Now, it’s time to test your API and ensure all your endpoints are accessible and working as expected.

Run the Laravel server using the command below:

php artisan serve

You can test the API using any API client of your choice. We have quite a number of popular options to choose from – Postman, Insomnia, Thunder Client, and so on. I’ll be using Thunder Client here.

We’ll test for all CRUD operations in your API client by confirming if all your objectives for your API are met.

Creating a new book

Create book endpoint

Getting a list of books

Get books endpoint

Editing a book

Edit book endpoint

How to Build the Nuxt Frontend

Setting up a new Nuxt app is as simple as running the command below:

npx nuxi@latest init nuxt-library-frontend

Open the newly created project when you’re done installing all the dependencies and start the development server using this command:

npm run dev

Your Nuxt app should now be accessible on port 3000:

Nuxt Starter Page

This is what your frontend should look like at the end of the tutorial:

Sample of our completed application

I’ve created some boilerplate code to help with the Nuxt frontend setup. This will enable us to focus on the implementation logic for consuming the Laravel API rather than spending time setting things up and styling.

For knowledge's sake, I created the UI components for the app using shadcn-vue. It consists of an amazing collection of accessible, reusable UI components that you can customize to your taste. Check out the installation steps for more details on how easy it was to set up for the Nuxt app.

It also comes with an installation of the Tailwind CSS utility library that’ll we'll use for styling in this tutorial.

Clone the boilerplate setup from the GitHub repo here so we can get started.

Navigate to pages/index.vue and replace the content of the index page with this:

We’ll need to create a new folder called utils in your root project which will contain two files: constants.ts and types.ts. Paste the following code snippet in your constants.ts file:

export const API_BASE_URL = "http://localhost:8000";

And the following in your types.ts:

export interface BookProps {
     id?: number;
     title: string;
     author: string;
     isbn: string;
     published_date: string;
     cover_image?: string;
     user_id?: number;
     created_at?: string;
     updated_at?: string;
}

Save the pages/index.vue file. You should be able to see this result in your browser:

Scaffolding the library frontend with Nuxt

Now, we need to create a side drawer and a dialog for adding new books and deleting added books from the database, respectively.

Create a new file called BookDrawer.vue in the component's root and add the following code in there:

Create another file called DeleteBookDrawer.vue and add the following code content to it:

Import the newly created files in your index page as you can see below:

Now, we need to create a system for opening and closing the drawer and dialog, respectively. We’ll be creating a ref to track the open/closed state for the drawer and dialog components in your index page. Paste the following code content in the script stage to enable that:

Update the Edit and Delete buttons in your index page to include the toggle handler:

Include the toggleAddDrawer in your Add Book button too:

Save the file changes and view in your browser. You should have the drawer active now:

Add New Book Drawer

Moving on, we need to be sure the EditDrawer and Delete Dialog work. We’ll create a temporary array of mock book data to test that so you can see the result on your page. Update the value of the books ref to the data you have below (and don’t forget to update the books ref value to an empty array – that is books = ref([])):

const books = ref([
     {
       title: "Atomic Habits",
       author: "James Clear",
       isbn: "XYEOUIUEHEJ2902",
       published_date: "2020-09-01",
       cover_image: "",
     },
     {
       title: "The Power of Habits",
       author: "Charles Duhigg",
       isbn: "WIUIQUEWHSDBSD28",
       published_date: "2012-02-28",
       cover_image: "",
     },
]);

Save the changes and check out the EditDrawer and DeleteDialog in action:

Delete dialogue

EditDrawer

How to Integrate the Laravel API in the Frontend

Getting all books in the library

So far, we only have the UI of our frontend working, and the data being displayed is not from the API. To make the app fully dynamic, you'll need to make an HTTP request to the server to get all the data you need for your page.

Update the body of the fetchBooks function in the index page to the following code:

const fetchBooks = async () => {
 try {
   isLoading.value = true;
   const response = await $fetch<{ books: BookProps[] }>(
     `${API_BASE_URL}/api/books`
   );


   books.value = response.books.sort(
     (a, b) =>
       Number(new Date(b.created_at as string)) -
       Number(new Date(a.created_at as string))
   );


 } catch (error) {
   console.log(error);
 } finally {
   isLoading.value = false;
 }
};


onMounted(() => {
 fetchBooks();
});

Basically, you're calling your fetchBooks function when the page mounts using one of the lifecycle hooks available in Vue.js. When the function is called, it executes the instruction you created in the body:

Set the loading state of the app to true.
Make a GET HTTP request to the books endpoint of your API and set the response to the books ref you created earlier.
When the request-response has been completed, set the loading state of the app back to false to indicate to the user the process has been completed.

Save the changes, and you should see the results in the browser:

Fetching the book list

Creating a new book

For your book creation to be successful, you need to include the logic for creating a book in your BookDrawer. Add the following code in the BookDrawer.vue file:

...

const isSubmitting = ref(false);


const addNewBook = async (data: any) => {
 const response = await $fetch(`${API_BASE_URL}/api/books`, {
   method: "POST",
   body: data,
   headers: {
     Accept: "application/json",
   },
 });
 return response;
};


const onSubmit = async () => {
 try {
   const formData = new FormData();
   Object.keys(form).forEach((key) => {
     // @ts-ignore
     if (form[key]) {
       formData.append(key, form[key as never]);
     }
   });
   isSubmitting.value = true;
   const data = await addNewBook(formData);
   closeDrawer(false);
   emit("refresh-data");
 } catch (error) {
   console.log(error);
 } finally {
   isSubmitting.value = false;
 }
};

...

Similar to the implementation for fetching your books, the only difference here is that you're making a POST HTTP request instead. You use this method whenever you need to mutate data on the server.

Creating a new book

Editing a book

Update your BookDrawer with the following code to enable editing of the books that have been added:

Update the save button with the toggle handler also:

And here's the result:

Updating a book

Deleting a book

Paste the following in the DeleteBookDialog.vue file:

const refreshData = () => emit("refresh-data");
const closeDialog = () => emit("update:open", false);


const deleteBook = async () => {
 await $fetch(`${API_BASE_URL}/api/books/${props?.book?.id}`, {
   method: "DELETE",
 });
 closeDialog();
 refreshData();
};

This works fine also:

Deleting a book

Conclusion

Building full-stack web apps with Laravel and Nuxt is a very rewarding experience as you can enjoy the benefits and rewards from the best of both worlds.

Since Laravel is a feature-rich backend framework, it comes with many modules and packages that you can install whenever a feature or implementation needs to be worked on.

And Nuxt, as a Vue framework, gives you the superpower of building single-page applications that are fast, accessible, and responsive, giving end-users a delightful experience.

In this tutorial, we went over how we can build full-stack applications using Nuxt and the Laravel framework. I hope you were able to learn something new and are excited to explore this further. Feel free to reach out if you have any questions or ideas.

The full code for the tutorial can be found in the GitHub repo here.

Resources

Laravel Docs
Nuxt Documentation
Shadcn-vue, ready-made UI components that can be copy-pasted anytime
Vue Docs

How to Work with Third-Party APIs in React by Building a Crypto Exchange Rate Web App

Chidera Humphrey — Wed, 10 Jan 2024 15:24:13 +0000

Working with APIs is crucial to any web application. And as a frontend developer, knowing how to connect your apps with third-party APIs is an important skill to have.

In this article, you'll learn how to connect your app and fetch data from a third-party API by building a crypto exchange web application in React.

Prerequisites
How to Set Up the Project
How to Build the UI
How to Fetch Data with React Query
How to Display Data in the UI
Error Handling
Conclusion

Prerequisites

This tutorial assumes you have foundational knowledge of React. Also, you should be able to work with Axios, specifically for making API calls.

Also, you will need an API key from RapidAPI to follow along with this tutorial.

How to Set Up the Project

Initialize a new React project

Use the following command to initialize a new React project using Vite: npm create vite@latest

Then follow the prompts that come after.

Vite is a build tool that enables fast reloading of your React apps. For more information on Vite, you can check out their official documentation.

Install the necessary dependencies

For this tutorial, you will need a few packages:

Axios: a library for making promise-based API calls.
react-query: a data fetching library that handles caching, loading, and error state of our API call.
antd (Ant Design): a UI library of pre-built React components.

Use the following command to install these packages: npm install react-query antd axios

Set up your project structure

In this section, you are going to create some folders inside the src folder. This is to keep your app structure clean and easy to work with.

Inside the src folder, create a new folder called components.

Inside of the components folder, create three folders: fetchData, UI, and currencies.

With the project setup out of the way, let's move to building the application.

How to Build the UI

In this section, you are going to create the UI of the app. There will be little to no logic.

Navigate to the UI folder inside the components folder.

Create a new file, ExchangeRateUI.jsx, inside of the UI folder.

Add the following code inside the ExchangeRateUI.jsx file:

import { Typography, Card } from "antd";

export function ExchangeRateUI(props) {
 return (
   <div className="exchange-rate-ui">
     <Card
       extra={3}
       bordered={false}
       style={{ width: 350, backgroundColor: "#4d4add", color: "#fff" }}
       size="default"
     >
       <Typography.Paragraph style={{ color: "#fff" }}>BitcoinTypography.Paragraph>
     Card>
   div>
 );
}

In the code above, you used the Card and Typography components of the Ant Design UI library to create the UI of our app.

Next, navigate to the currencies folder and create a currencies.jsx file.

Add the following code inside currencies.jsx:

export const cryptocurrencies = [
  { value: "BTC", label: "Bitcoin" },
  { value: "ETH", label: "Ethereum" },
  { value: "BCH", label: "Bitcoin Cash" },
  { value: "XRP", label: "Ripple" },
  { value: "SOL", label: "Solana" },
  { value: "ADA", label: "Cardano" },
  { value: "BNB", label: "Binance Coin" },
];

export const fiatCurrencies = [
  { value: "USD", label: "US Dollar" },
  { value: "GBP", label: "British Pound" },
  { value: "EUR", label: "Euro" },
  { value: "NGN", label: "Naira" },
  { value: "CNY", label: "Chinese Yuan" },
  { value: "RUB", label: "Russian Ruble" },
  { value: "SGD", label: "Singaporean Dollar" },
];

In the code above, you created two arrays, fiatCurrencies and cryptocurrencies, and exported those arrays. They will be used by the Ant Design Select components.

Next, create a file, ExchangeRate.jsx, inside the components folder.

Add the following code inside the ExchangeRate.jsx file:

import { useState } from "react";
import { Typography, Select } from "antd";
import { cryptocurrencies, fiatCurrencies } from "./currencies/currencies.jsx";
import { ExchangeRateUI } from "./UI/ExchangeRateUI.jsx";

function ExchangeRate() {
  const [fromCurrency, setFromCurrency] = useState(cryptocurrencies[0].value);
  const [toCurrency, setToCurrency] = useState(fiatCurrencies[0].value);

  const handleFromCurrencyChange = (e) => {
    setFromCurrency(e);
    console.log(e);
  };

  const handleToCurrencyChange = (e) => {
    setToCurrency(e);
    console.log(e);
  };

  return (
    <section className="exchange-rate">
      <Typography.Title style={{ color: "#4d4add" }} level={2}>
        Exchange Rate
      Typography.Title>
      <Typography.Text>
        Get the latest exchange rate of cryptocurrencies in your favorite
        currency
      Typography.Text>
      <section className="select-group" style={{ display: "flex", marginTop: "1rem", gap: "1rem", justifyContent: "space-around" }}>
        <Select defaultValue={cryptocurrencies[0].value} options={cryptocurrencies} onChange={handleFromCurrencyChange} />
        <Select defaultValue={fiatCurrencies[0].value} options={fiatCurrencies} onChange={handleToCurrencyChange} />
      section>
      <section style={{ marginTop: "1rem" }}>
        <ExchangeRateUI />
      section>
    section>
  );
}

export default ExchangeRate;

In the ExchahgeRate component, you imported the fiatCurrencies and cryptocurrencies arrays from the currencies folder. The fiatCurrencies and cryptocurrencies arrays are used by the Select component to render the selected currencies you wish to convert.

The useState hook is used to keep track of the selected currencies.

The return statement renders the ExchangeRateUI component.

Update your App.jsx file with the following code: import ExchangeRate from './components/ExchangeRate.jsx' function App(){ return ( ) } export default App;

If you followed each step correctly, your web app should look like this:

GIF of the crypto app UI

Now that the app's UI is set up, let's move on to implementing the data fetching logic.

How to Fetch Data with React Query

In this section, you are going to implement the data fetching logic.

Replace the code in the App.jsx file with the following code:

import { QueryClient, QueryClientProvider } from "react-query";
import ExchangeRate from "./components/ExchangeRate.jsx";

const queryClient = new QueryClient(); // Instantiate a new QueryClient instance

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ExchangeRate />
    QueryClientProvider>
  );
}

export default App;

In the code above, you created a queryClient using QueryClient() from react-query. The queryClient is passed to the QueryClientProvider via the client props. This allows the child components to have access to the queryClient, which will be used for data fetching.

React-query comes with good default configurations, but you are going to alter some of these default configurations. This is to avoid rate limiting due to excessive requests to the API.

Replace the queryClient declaration with the following code in your App.jsx:

// previous code

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      method: "GET", // Default HTTP method for queries
      refetchOnWindowFocus: false, // Disable automatic refetching on window focus
      refetchInterval: 60000, // Refetch queries every 60 seconds
    },
  },
});

// remaining code

In the code above, you are stopping the component from refetching when you refocus on the web page. Also, you are increasing the background refetching time to six seconds.

After making the changes, your App.jsx should look like this:

import { QueryClient, QueryClientProvider } from "react-query";

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      refetchOnWindowFocus: false, // Disable automatic refetching on focus
      refetchInterval: 60000, // Refetch queries every 60 seconds
    },
  },
});

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ExchangeRate />
    QueryClientProvider>
  );
}

export default App;

Next, you are going to create the data fetching function in the fetchData folder.

Create a new file called fetchData.jsx in the fetchData folder.

Add the following code in the fetchData.jsx file:

import axios from 'axios' 

export function getExchangeRate(fromCurrency, toCurrency){ 

    const options = { 
        method: 'GET', 
        url: 'https://alpha-vantage.p.rapidapi.com/query', 
        params: { from_currency: fromCurrency, function: 'CURRENCY_EXCHANGE_RATE', to_currency: toCurrency }, 
        headers: { 'X-RapidAPI-Key': 'YOUR API KEY', 'X-RapidAPI-Host': 'alpha-vantage.p.rapidapi.com' } 
    }; 

    return axios.request(options)
        .then(res => { return res.data; })
        .catch((err) => { return err; }) 

}

In the code above, you used Axios to fetch data from the AlphaVantage API through RapidAPI.

Remember to replace YOUR API KEY with your API key from RapidAPI.

Navigate to your ExchangeRate component, and add the following code:

import { useQuery } from 'react-query';
import { getExchangeRate } from './fetchData/fetchData.jsx';

function ExchangeRate() {
  // previous code

  const dependencies = {
    fromCurrency: fromCurrency,
    toCurrency: toCurrency,
  };

  const { data, isLoading, isError, error } = useQuery({
    queryKey: ["exchangeRate", dependencies],
    queryFn: () => fetchData(fromCurrency, toCurrency),
    staleTime: 1000 * 60,
    retry: 1,
    retryDelay: 6000,
  });

  // further code
}

In the code above, you used the useQuery hook to fetch the exchange rate data with specified parameters.

The useQuery hook returns an object with many properties – but the following are the properties that are of interest:

data: holds the fetched data.
isLoading: indicates if the data is still being fetched.
isError: indicates if an error occurred during fetching.
error: contains the error details if there's an issue.

The queryKey is an array representing a unique identifier for this query, and staleTime sets the cache to consider data stale after a minute. retry and retryDelay control retry attempts.

Let's look at the data property.

The data property is the response object that is successfully returned from our call to the AlphaVantage API.

The data property looks like this:

{
  "Realtime Currency Exchange Rate": {
    "1. From_Currency Code": "BTC",
    "2. From_Currency Name": "Bitcoin",
    "3. To_Currency Code": "USD",
    "4. To_Currency Name": "United States Dollar",
    "5. Exchange Rate": "44138.96000000",
    "6. Last Refreshed": "2024-01-05 00:16:03",
    "7. Time Zone": "UTC",
    "8. Bid Price": "44138.96000000",
    "9. Ask Price": "44138.97000000"
  }
}

We are only interested in the 5. Exchange Rate property of the data property as it contains the exchange rate.

Since we only need the 5. Exchange Rate, pass it as props to the ExchangeRateUI component.

After making the changes, your ExchangeRate component should look like this:

import React, { useState, useEffect } from 'react';
import { Typography, Select, Spin } from 'antd';
import { cryptocurrencies, fiatCurrencies } from './currencies/currencies.jsx';
import { ExchangeRateUI } from './UI/ExchangeRateUI.jsx';
import { useQuery } from 'react-query';
import { fetchData } from './fetchData/fetchData.jsx';

function ExchangeRate() {
  const [fromCurrency, setFromCurrency] = useState(cryptocurrencies[0].value);
  const [toCurrency, setToCurrency] = useState(fiatCurrencies[0].value);
  const [currencySymbol, setCurrencySymbol] = useState("Bitcoin");

  const handleFromCurrencyChange = (e) => {
    setFromCurrency(e);
    console.log(e);
  };

  const handleToCurrencyChange = (e) => {
    setToCurrency(e);
    console.log(e);
  };

  useEffect(() => {
    const fromCurrencyLabel = cryptocurrencies.find(currency => currency.value === fromCurrency)?.label;
    setCurrencySymbol(fromCurrencyLabel);
  }, [fromCurrency]);

  const dependencies = { fromCurrency: fromCurrency, toCurrency: toCurrency };
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ["exchangeRate", dependencies],
    queryFn: () => fetchData(fromCurrency, toCurrency),
    staleTime: 1000 * 60,
    retry: 1,
    retryDelay: 60000
  });

  console.log(data);

  return (
    <section className="exchange-rate">
      <Typography.Title style={{ color: "#4d4add" }} level={2}>Exchange RateTypography.Title>
      <Typography.Text>Get the latest exchange rate of cryptocurrencies in your favorite currencyTypography.Text>
      <section className="select-group" style={{ display: "flex", marginTop: "1rem", gap: "1rem", justifyContent: "space-around" }}>
        <Select defaultValue={cryptocurrencies[0].value} options={cryptocurrencies} onChange={handleFromCurrencyChange} />{' '}
        <Select defaultValue={fiatCurrencies[0].value} options={fiatCurrencies} onChange={handleToCurrencyChange} />
      section>
      <section style={{ marginTop: '1rem' }}>
        {isLoading ? (
          <Spin tip="Fetching results" spinning size="large" />
        ) : isError ? (
          <div>Error: {error.message}div>
        ) : (
          <div>
            <ExchangeRateUI price={data["Realtime Currency Exchange Rate"]["5. Exchange Rate"]} dataObj={dependencies} currencySymbol={currencySymbol} />
          div>
        )}
      section>
    section>
  );
}

export default ExchangeRate;

In the code above, you used the ternary operator to render different content based on the state of the data fetching.

currencySymbol is used to keep track of the cryptocurrency you're checking the exchange rate of.

Open your console and you should see something like this:

Now that you're done implementing the data fetching logic, let's display the data in the UI.

How to Display the data in the UI

In this section, you are going to add the final touches to the web app.

Update your ExchangeRateUI.jsx file with the following code:

import React from "react";
import { Typography, Card } from "antd";

export function ExchangeRateUI(props) {
  const { price, dataObj, currencySymbol } = props;
  const toCurrency = dataObj.toCurrency;
  let value = Number(price);
  let currencyCode = toCurrency;

  let currency = new Intl.NumberFormat('en-US', {
    style: 'currency',
    currency: currencyCode,
  });

  let formattedCurrency = currency.format(value);

  return (
    <div className="exchange-rate-ui">
      <Card extra={currencySymbol} bordered={false} style={{ width: 350, backgroundColor: "#4d4add", color: '#fff' }} size="default">
        <Typography.Paragraph style={{ color: "#fff" }}>{formattedCurrency}Typography.Paragraph>
      Card>
    div>
  );
}

Let's understand what's going on in the code above.

First, you take the raw price representing the exchange rate, ensure it's treated as a number, determine the currency code, and then format the numeric value into a user-friendly currency string. This formatted currency is used for display in the user interface to provide a clear and standardized representation of the exchange rate.

Next, the formatted currency is displayed within a styled Card component from Ant Design. The Card includes the currencySymbol as an extra element. The background color, width, and text color are styled for a visually appealing UI.

Your app should look like this:

GIF of complete working crypto app

Congratulations. You have built a crypto exchange rate web app in React.

Error Handling

Error handling is a crucial aspect of developing web apps. This is because web apps and software in general can experience crashes and down time.

In React, when your app crashes, it usually shows a white/blank screen. This doesn't make for a good user experience. You'll want to display some kind of information to your users if your app crashes.

In this section, you are going to use the ErrorBoundary component to handle app crashes.

Create a file called ErrorBoundary.jsx in the src folder.

Add the following code in the ErrorBoundary.jsx file:

import React from "react";
import { Typography } from "antd";

export default class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.error("Caught error: ");
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <Typography.Title level={4}>Something went wrong.Typography.Title>;
    }

    return this.props.children;
  }
}

In the code above, you are rendering the message "Something went wrong" if there's an error rendering your app.

Update your index.jsx file with the following code:

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import ErrorBoundary from './ErrorBoundary';

ReactDOM.createRoot(document.getElementById('root')).render(
  <React.StrictMode>
    <ErrorBoundary>
      <App />
    ErrorBoundary>
  React.StrictMode>
);

Visit the React docs for more information on ErrorBoundary.

Conclusion

This article walked you through how to work with third-party APIs in React by building a crypto exchange rate web app.

But don't stop here. You can improve this project by adding a news feature and styling it to your taste. Also, you can decide to support more currencies.

Additional resources

How to Deploy Your Websites and Apps – User-Friendly Deployment Strategies

Ijeoma Igboagu — Wed, 09 Aug 2023 14:23:41 +0000

Deploying your application is a key aspect of software development. Typically, having an app on your local system isn't enough – it needs to be accessible online. So choosing a suitable and user-friendly hosting and deployment plan is vital.

The key to making the right decision lies in understanding the goal of your application. Perhaps it’s a simple website, a one-page app, or it requires serverless or cloud functions. Having clarity about these aspects will significantly ease the deployment process.

In this article, we will look at a few popular methods for deploying your application that will help tackle these challenges.

What we'll cover:

What to consider when deploying a hosting platform
How to deploy a website or app with Render
How to deploy a website or app with Surge
How to deploy a website or app with Vercel
How to deploy a website or app with GitHub Pages
How to deploy a website or app with Netlify
Conclusion

What to Consider when Deploying to a Hosting Platform

There are several factors to take into account when selecting a hosting platform:

Purpose: Before you host your application, consider the technologies you used to build it and how much storage the platform can handle.
Interface: A good interface is essential for a hosting platform. Look for a control panel or dashboard that allows you to easily administer your website.
Reviews: Look at the hosting service's reviews and read what other clients have to say.
Security: To safeguard your website and data, it is essential to have the right security measures in place.
Support: You should always have someone there to help you out when you need it.

Why is Deploying an Application Important?

If you've built an app, there are various reasons you may want or need to deploy it, such as:

It showcases professionalism and credibility to users.
It increases the accessibility of the application to a broader audience.
It enables user interaction and feedback.
It facilitates data analysis and provides insights for informed decision-making.
It identifies areas for improvement in the application.

What's the Benefit of Choosing a User-Friendly Deployment Method?

Opting for a more approachable deployment method brings significant advantages:

Collaboration: When working together as a team, it’s useful to have straightforward methods to deploy your application. This makes collaboration and teamwork easy. These will encourage cooperation throughout the deployment process.
Efficiency: A user-friendly deployment method simplifies the process.
Simplicity: Choosing a hosting platform that is easy to understand will benefit everyone involved.
Reliability: easy to use deployment methods ensure a more reliable application and minimise potential disruptions.

How to Deploy a Website or App with Render

Render provides an interface for quick and straightforward publishing of static web content. Let's now go through how to deploy an app to Render step by step.

Step 1: First, ensure you have deployed your work or code from your editor to your GitHub account.

Step 2: Open a new browser tab and navigate to the Render website.

Render website

Step 3: Select the “GET STARTED” button on Render's home page to get going.

You can use your GitHub, GitLab, or Bitbucket account when signing up. Choose the GitHub option and follow the steps to grant Render access to your GitHub account.
If you already have a Render account, click the “Sign in” button to be redirected to the Sign-in page. You can sign in via email and authenticate using your Google account or your GitHub account.

Sign in page

Step 4: Once you access the dashboard, click the “New” button.

Dashboard of Render

Step 5: Upon doing so, a drop-down menu will appear. It'll show you a comprehensive list of services provided by Render.

List of Services offered by render

Step 6: Clicking “Static Site” from the drop-down menu will lead you to the “Create a New Static Site” page. From there, you can select the repository you wish to host.

Create a New Static Site

Step 7: After selecting the repository you wish to host, you will be directed to the deployment platform. There, you can provide the necessary information to host the application and click the “Create Static Site” button for it to deploy.

Deploying the app using Render

Here's what the final output should look like:

Hosted application

Pros of Deploying With Render

Render has a free tier for hosting basic static websites.
It provides a flexible price structure that ensures transparency and cost-effectiveness.
It makes deployment easy. They provide an interface and connection with standard development tools and platforms. It also supports a wide range of programming languages, frameworks, and databases.
It delivers a variety of integrated features that improve the hosting experience.
It has good customer service support.

Cons of Deploying With Render

Render specializes in static websites, Docker containers, and serverless functions.
For more complex/bigger applications, there's a paid plan. You'll need to go through their price structure and understand the charges related to your usage.
There is a learning curve, especially for newcomers to the platform.

How to Deploy a Website or App with Surge

This friendly platform and tool make it quick and easy to deploy static websites online.

Deploying your static files to surge.sh is easy using the command-line interface (CLI).

This command-line interface (CLI) streamlines the process of hosting and distributing your online projects.

Surge website

Steps to Deploy Your Site Using Surge

First, in the terminal of your project, type the command npm i -g surge.

Then type the command surge.

And that's it! You can deploy your app without logging in into your GitHub account.

To see what you have deployed, first copy the successful link in the terminal. Then paste it into your browser. You should see something like this:

Hosted site with Surge

Like I mentioned before, Surge doesn't need extra code. You can easily deploy your app right from your editor's terminal by typing the command surge.

Pros of Deploying with Surge

Easy to Use: Surge provides a simple deployment for static websites.
Fast Deployment: It has a quick deployment time.
Custom Domains: It allows you to use your domain name for your website.
SSL Support: It provides free SSL certificates.
Support for Single-Page Applications (SPAs): It's well-suited for deploying single-page applications.

Cons of Deploying with Surge

Limited Functions: Surge is designed for static websites.
No Custom Server Configurations: It streamlines the deployment process by abstracting away server configurations.
Premium Features: This platform offers free hosting for basic usage, but you'll have to pay for more features.

How to Deploy a Website or App with Vercel

Vercel is a hosting and deployment platform that specializes in modern web applications.

It is particularly well-suited for single-page applications, serverless operations, and static websites. It integrates with popular frameworks like Next.js and Gatsby.js, making deployments fast and simple.

Steps to Deploy Your Site Using Vercel

First, ensure that you have deployed your work or code from your editor to your GitHub account.

Then open a new browser tab and navigate to Vercel’s website.

Vercel website

Head to the Vercel website and click the “Sign up” button on the homepage.

Sign up using your GitHub account and follow the steps to grant Vercel access to your GitHub account. If you already have a Vercel account, click the “Login” button and enter your login information.
After signing up or logging in, Vercel will request access to specific information from your GitHub account. Review the required permissions and permit Vercel to proceed.

Next, click on “Add New…” on the Vercel dashboard. This action will reveal a drop-down menu. From the menu, select “Project,” which will navigate you to the next page.

Add New Project

On the next page, you will import your repository for deployment.

Vercel Deployment

Here's what the final output should look like:

Hosted site

When deploying your application to Vercel, you may encounter some errors, often caused by routing issues.

To fix this:

Create a file under the root of your application called vercel.json.
Inside the file, write the following code:

vercel.json

{ "rewrites": [{ "source": "/(.*)", "destination": "/" }] }

Inside your editor

Pros of Deploying With Vercel

Collaboration: Vercel offers tools for effective teamwork, access control, and cooperative deployments.
Simple Deployment: it simplifies delivering your web apps with ease.
Preview Deployments: it allows you to share and review changes before they go live. This promotes collaboration and ensures a smooth and efficient workflow.
Scalability and Performance: It still guarantees great performance even with a large number of people using it.
Git Integration: it makes Git integration easy.

Cons of Deploying With Vercel

If you are new to Vercel, you must understand how to deploy and configure your application. Reading Vercel’s documentation can help you get up to speed.
Vercel is great for small to medium-sized projects, but it may not be the best fit for large-scale applications with complex backend needs. In such cases, developers may need a hosting solution that offers more customization and scalability.

How to Deploy a Website or App with GitHub Pages

GitHub Pages is a straightforward and cost-free hosting service. You can use it to host static web pages or documentation.

You can publish your site using GitHub Pages by submitting your code to a GitHub account and setting up a repository. Let's go through the process now.

Steps to Deploy Your Site Using GitHub Pages

To use GitHub Pages to host your website, follow these simple steps:

First, go to GitHub's website.

Github website

Then create a GitHub repository. If you don’t have a GitHub account, you'll need to click on “sign up”, or just click “sign in” if you already have an account.

Github sign in button and sign up buttons

Create a new repository by clicking the New button in the upper-right corner of your GitHub profile.

Creating a new repository

Give your repository a name that reflects your website.

Repository name

Once you have finished the previous step, go back to your Editor. Copy the generated code and paste it into your editor.

Code generated from new repository

The code in the image above is generated when creating a new repository.

Go to the settings page of the newly created repository.

Clicking on settings

Click on the settings option to redirect to the settings section. Locate and click on “Pages” in the left-hand side menu.

GitHub pages section on the settings page

To access GitHub Pages, click on the “Pages” section. Once you’re on the GitHub Pages section, click in the drop-down menu and choose either the “master” or “main” branch. Remember to save your selection.

Enabling GitHub Pages to host your site

Refresh the page to find the link leading to your published website.

Seeing your hosted site

Pros of Deploying With GitHub Pages

GitHub Pages are simple to set up – and you can build your website there.
It's free.
GitHub’s version control system makes it simple to keep track of changes and work with others.
GitHub Pages updates your website’s code whenever you make changes to it.
It offers collaboration on projects with other developers.
It ensures your website is safe through HTTPS (Hyper Text Transfer Protocol) encryption.

Cons of Deploying With GitHub Pages

While GitHub Pages offer many advantages, there are a few considerations to keep in mind:

If your website becomes too large due to file size, this can cause some performance issues.
GitHub Pages may only support simple functions.
Understanding Git, the version control system used by GitHub, is essential for managing your website’s code.

How to Deploy a Website or App with Netlify

Netlify integrates with Git repositories and works well with static web pages and single-page apps.

Steps to Deploy Your Site Using Netlify

First, you'll need to make sure that you have deployed your work or code from your editor to your GitHub account.

Then, open a new browser tab and navigate to the Netlify website.

Netlify website

Head to the Netlify website and click the “Sign up” button on the homepage.

Create an account by signing up with your GitHub, GitLab, or Bitbucket credentials.
Select the GitHub option and follow the steps to grant Netlify access to your GitHub account.
If you already have a Netlify account, click the “Login” button and enter your login information. After signing up or logging in, Netlify will request access to specific information from your GitHub account. Review the required permissions and permit Netlify to proceed.

Once you have finished registering, go to the dashboard where you will host your repository.

Netlify has two ways to host your project:

Drag-n-drop
Importing the source code from your repository to the site.

Using the Drag-n-Drop feature:

Once you have logged in, navigate to the left-hand side of the dashboard and select the “site” option.

Netlify dashboard

Before deploying your project, it’s important to include an “index.html” file. Netlify recognizes this file as the main folder for hosting your project.

Root index.html file

Go back to the website click on “site” and scroll down, you will see the drag-n-drop zone where you can drag and drop your file or you upload the folder.

Netlify drag and drop

By using this feature your project will be deployed.

Importing the source code from your repository to the site:

First, upload your code to GitHub.

Then access the Netlify dashboard.

To access the option (drop-down) menu, click on “Add New Site”. Select “Import existing project.”

Import existing project

When you click on “Import existing project,” the system will direct you to a new page. Then you can import your repository from your GitHub account or any other storage account where you stored your source code.

Connect to Git provider

When you click on this button, it will navigate you to the next page where you can choose the desired repository from the available options.

Choosing repository from Netlify

After selecting the repository, the next step is configuring and deploying your site.

Deploying from Netlify

Here's the result:

Hosted App

When deploying your application to Netlify, you may encounter errors, often caused by routing issues.

To fix this:

Create a file called _redirects, and inside write the following code:

_redirect file

/* /index.html 200

Example

Encounter error during deployment which is caused by routing issue

Pros of Deploying with Netlify

Form handling capabilities: Netlify makes handling forms on your websites easy. It has a simple API that allows you to collect and process form submissions. It also integrates with popular form providers like Zapier, Mailchimp, and Slack.
It’s easy to configure custom domains for your websites: it makes it simple to manage your website’s domain and security. It also ensures that your websites are secure with HTTPS.
Web Hosting: Netlify helps you host your websites and applications. It offers static site hosting, allowing you to deploy HTML, CSS, and JavaScript files straight from a Git repository or by drag-and-drop.
Simple Deployment: it makes deploying your website or web app straightforward. When you connect your repository, it will deploy any changes you make.
Continuous Deployment: When you make updates to your source code, Netlify builds and publishes your website for you. This ensures that your website always reflects the latest changes you’ve made.

Cons of Deploying With Netlify

Project size: This hosting platform is an excellent choice for small to medium-sized projects. But you should explore other hosting and deployment options as your website or app grows.
Limited Backend Capabilities: Netlify prioritizes front-end development and static websites. Although it does have some backend functions, it may not be the best option for projects that need complex server-side processing.

Conclusion

In conclusion, deploying an application is crucial so that users can access it and others can see your work. User-friendly deployment methods offer significant benefits, including collaboration, efficiency, simplicity, and reliability.

Here's a quick review of what we've covered here:

Render offers a simple interface, affordable pricing, and built-in features.
Surge offers fast deployment speeds, making deploying static websites a breeze.
Vercel is an expert in creating cutting-edge web apps with scalability and preview deployments.
If you’re looking for an easy-to-use option, consider GitHub Pages. It provides several advantages, including simplicity, free hosting, version control, and HTTPS encryption. But, it has limited functionality and technological limitations for more sophisticated applications.
Netlify is a user-friendly platform that's great for quickly deploying static websites and web apps. It's perfect for projects that want easy setup, automatic deployment, and modern development features

What you choose will depend on the particular needs and objectives of your application and the technical know-how of the developers working on it.

And if you want to improve your Git skills, you can read this Git Command article.

If you found this tutorial helpful, please share it with fellow developers who may also find it interesting. You can also stay updated on my latest projects by following me on Twitter and LinkedIn.

Rendering Patterns for Web Apps – Server-Side, Client-Side, and SSG Explained

German Cocca — Mon, 06 Mar 2023 18:22:40 +0000

Hi everyone! In this article we're going to take a look at the different rendering pattern options available nowadays for web applications.

I'll start by explaining what a rendering pattern is, then go through each of the main options available. Finally we'll compare them, explaining the pros and cons and when one might be more beneficial than another.

Let's go!

What's a rendering pattern?
Different rendering pattern options
Comparing the different patterns
Wrap up

What's a Rendering Pattern?

In web development, a rendering pattern refers to the way in which the HTML, CSS, and JavaScript code is all processed and rendered in a web application or website.

Different rendering patterns are used to achieve different performance and user experience goals. The most common rendering patterns in web development are:

Server-side rendering (SSR): In SSR, the web server generates the HTML content of a web page on the server-side and sends it to the client's browser. This approach can improve initial loading times and SEO (search engine optimization) but can be slower for dynamic content.
Client-side rendering (CSR): In CSR, the client's browser generates the HTML content of a web page on the client-side using JavaScript. This approach can provide a fast and interactive user experience but can be slower for initial loading times and bad for SEO.
Static site generation (SSG): In SSG, the HTML content of a web page is generated at build time and served to the client as a static file. This approach can provide excellent performance and security but can be less flexible for dynamic content.

In summary, a rendering pattern is a strategy for processing and rendering web content in web development. The choice of rendering pattern depends on the specific needs and requirements of a project, such as performance, SEO, user experience, and flexibility.

Now that we have an idea of what a rendering pattern is, let's examine in detail the many options available nowadays.

Different Rendering Pattern Options

Static Websites

A static website is a type of website that consists of a set of HTML, CSS, and JavaScript files that are served to the client's browser without any server-side processing or database integration.

Static websites are typically created using static site generators, such as Jekyll, Hugo, or Gatsby.js. These generators compile templates, markdown files, or other data sources into a set of static files that are then deployed to a web server or content delivery network (CDN).

Static websites are often used for small to medium-sized websites that do not require complex dynamic features or server-side processing. They are easy to deploy, scale, and maintain, as they do not require a server-side application or database.

They also provide excellent security and performance, as the content is served directly from a web server or CDN without any server-side processing.

Static websites can be enhanced with client-side JavaScript, such as React or Vue, to provide interactive features or dynamic content. But any data that is required for these features must be loaded through client-side API requests, as there is no server-side processing to generate or retrieve the data.

In summary, a static website is a type of website that consists of a set of static files that are served to the client's browser without any server-side processing or database integration. They are simple, fast, secure, and scalable, and are suitable for small to medium-sized websites that do not require complex dynamic features or server-side processing.

Single Page Applications (SPAs) with Client Side Rendering (CSR)

A Single Page Application (SPA) is a type of web application rendered with Client-side rendering (CSR). This means that all necessary HTML, CSS, and JavaScript files are loaded at once when the user first loads the page. Then Javascript dynamically updates the content as the user interacts with the page, without requiring a full page reload.

In an SPA, the client-side JavaScript application is responsible for rendering the HTML and processing the user's interactions. The JavaScript application interacts with a backend API to retrieve data and update the user interface dynamically. Typically, this interaction is achieved using AJAX (Asynchronous JavaScript and XML) requests or Fetch API requests.

SPAs provide a fast and interactive user experience because only the necessary content is loaded and rendered dynamically, reducing the need for full page reloads. They also provide a more fluid user experience because the application can respond to user input without refreshing the entire page.

However, SPAs require a more complex setup and may have longer initial loading times compared to server-side rendering (SSR) or static site generation (SSG) approaches.

They also require additional considerations for search engine optimization (SEO) and accessibility, as search engines and assistive technologies may have difficulty indexing or navigating the content.

In summary, a Single Page Application (SPA) or Client-side rendering (CSR) is a type of web application that loads all necessary HTML, CSS, and JavaScript files at once and then dynamically updates the content as the user interacts with the page, without requiring a full page reload.

They provide a fast and interactive user experience but require a more complex setup and additional considerations for SEO and accessibility.

Server Side Rendering (SSR)

Server-side rendering (SSR) is a technique for rendering web pages on the server-side before sending them to the client's browser. In SSR, the server generates the HTML content of a web page based on the requested URL and data, and sends it to the client's browser as a complete HTML document.

SSR provides several benefits, including improved performance, better SEO, and more robust accessibility.

By rendering the HTML on the server-side, SSR reduces the amount of JavaScript code that needs to be loaded and executed on the client's browser. This results in faster initial loading times and better performance on low-end devices or slow networks.

Additionally, SSR enables search engines and social media crawlers to index the web pages more accurately, as the complete HTML content is available on the initial page load. This can improve the visibility and ranking of the website in search engine results pages.

SSR also ensures that the web pages are accessible to users with assistive technologies, such as screen readers or keyboard navigation, as the HTML content is available from the initial page load.

However, SSR has some limitations, such as increased server-side processing requirements and limited interactivity compared to client-side rendering (CSR) or single-page applications (SPAs).

In summary, Server-side rendering (SSR) is a technique for rendering web pages on the server-side before sending them to the client's browser. It provides improved performance, better SEO, and more robust accessibility, but requires more server-side processing and has some limitations in interactivity.

Static Site Generation (SSG)

Static site generation (SSG) is a technique for building web pages by pre-generating HTML, CSS, and JavaScript files at build time instead of rendering them on the server or client-side.

In SSG, a static site generator tool like Jekyll, Hugo, or Gatsby.js is used to compile the website's content from data sources such as markdown files, JSON files, or CMS data, and generate a set of static files that can be served directly to the browser without any server-side processing.

The generated static files can be deployed on a web server or a content delivery network (CDN) and served quickly to the end-users with low latency. SSG offers several benefits such as fast loading times, improved security, and scalability.

Since SSG renders web pages at build time, there is no need to generate pages dynamically on the server or client-side. This reduces the processing overhead and enables faster loading times.

Static sites are also less vulnerable to server-side attacks and require fewer server resources, making them more scalable and easier to maintain.

But SSG has some limitations in terms of dynamic content and interactivity. Since the content is generated at build time, any dynamic data or user interactions need to be handled by client-side JavaScript code or serverless functions.

In summary, Static Site Generation (SSG) is a technique for building web pages by pre-generating HTML, CSS, and JavaScript files at build time instead of rendering them on the server or client-side. It offers several benefits such as fast loading times, improved security, and scalability, but has some limitations in terms of dynamic content and interactivity.

Incremental Static Regeneration (ISR)

Incremental Static Regeneration (ISR) is a technique for building static sites that combines the benefits of both Server-Side Rendering (SSR) and Static Site Generation (SSG).

In ISR, the static site generator tool pre-generates a set of static pages at build time, but also includes additional metadata that enables the pages to be re-generated dynamically on the server-side when requested by the user. This metadata could include information such as expiration times or dependencies on specific data sources.

When a user requests a page that has expired or has dependencies that have changed, the server-side logic can regenerate the page with the updated content and serve it to the user, without requiring a full rebuild of the site.

This enables the site to maintain the benefits of static site generation, such as fast load times and low server processing overhead, while also allowing for dynamic content and personalized experiences for users.

ISR is particularly useful for sites that have content that changes frequently or for sites with a large number of pages that would be inefficient to rebuild in their entirety each time a change is made.

It allows for the best of both worlds: the performance and security benefits of static sites combined with the flexibility and personalization of server-side rendering.

In summary, Incremental Static Regeneration (ISR) is a technique for building static sites that combines the benefits of both Server-Side Rendering (SSR) and Static Site Generation (SSG). It allows for dynamic content and personalized experiences for users while maintaining the performance and security benefits of static sites.

The Concept of Hydration

In web development, "hydration" refers to the process of taking an HTML document that was initially rendered on the server and adding dynamic interactivity to it on the client-side.

Hydration is commonly used in Single-Page Applications (SPAs) that use client-side rendering (CSR).

During hydration, the browser parses the HTML document generated by the server and constructs a Document Object Model (DOM) tree, which represents the page's structure and content.

The browser then executes the JavaScript code that is responsible for adding dynamic behavior to the page, such as event handling, data fetching, and component rendering.

The JavaScript code retrieves the initial state and props of the components from the server-generated HTML and uses them to rehydrate the components on the client-side, effectively turning them into interactive elements.

This process ensures that the initial state of the page on the client-side matches the server-generated HTML and provides a seamless transition from the initial server-rendered view to the interactive client-side view.

Hydration is important for several reasons. First, it provides better performance and user experience by minimizing the time to interactive and enabling the user to interact with the page immediately.

Second, it enables search engine crawlers to access the page's content and metadata, improving SEO.

Finally, it ensures that the content is accessible and usable even if JavaScript is disabled in the user's browser.

In summary, hydration is the process of taking an HTML document that was initially rendered on the server and adding dynamic interactivity to it on the client-side.

It is commonly used in Single-Page Applications (SPAs) that use client-side rendering (CSR) and provides better performance, SEO, and accessibility.

Islands

The Islands pattern is a web development technique that involves breaking down a large, complex web page into smaller, self-contained components, each with its own HTML, CSS, and JavaScript code.

Each component is rendered independently on the server and is then rehydrated on the client-side, allowing it to become interactive.

The term "islands" refers to the individual components, each of which represents a separate island of content and functionality within the larger page.

By breaking the page into smaller islands, each with its own state and behavior, the application becomes more modular, easier to reason about and maintain, and can provide a more seamless user experience.

The Islands pattern is closely related to the concept of hydration because it relies on the same basic principle: rendering static HTML on the server and then hydrating it on the client-side with JavaScript to add interactivity.

In this case, each individual island is rendered on the server with its own static HTML, which is then hydrated on the client-side to enable dynamic functionality.

Hydration in the Islands pattern typically involves using a client-side framework or library to attach event handlers, manage state, and render dynamic content within each component. The framework or library must be capable of rehydrating the component on the client-side, ensuring that the initial state and behavior of the component matches that of the server-rendered HTML.

One benefit of using the Islands pattern with hydration is that it can improve the performance of large, complex web applications by reducing the amount of JavaScript that needs to be downloaded and executed on the client-side. By rendering each component independently on the server and rehydrating it on the client-side, the application can provide a more seamless user experience without sacrificing performance or scalability.

In summary, the Islands pattern is a web development technique that involves breaking down a large, complex web page into smaller, self-contained components, each with its own HTML, CSS, and JavaScript code. It relies on the same principle of hydration as other rendering patterns, rendering static HTML on the server and then adding interactivity with JavaScript on the client-side.

The Islands pattern can improve the performance and scalability of large web applications by reducing the amount of JavaScript that needs to be downloaded and executed on the client-side.

Streaming SSR

Streaming Server-Side Rendering (SSR) is a rendering pattern for web development that involves sending the server-generated HTML to the client as soon as it becomes available, rather than waiting for the entire page to be rendered before sending it.

With traditional SSR, the server would wait for the entire page to be rendered before sending it to the client, resulting in a longer time to first byte (TTFB) and a slower user experience.

Streaming SSR allows the server to send the HTML to the client in chunks as it is generated, providing a faster TTFB and a more responsive user experience.

Streaming SSR is particularly useful for rendering large or complex web pages that take a long time to render, such as e-commerce product pages or news articles.

With streaming SSR, the user can start interacting with the page as soon as the first chunk of HTML is received, without having to wait for the entire page to be rendered.

To implement streaming SSR, the server must use a technique called "chunking" to break the server-generated HTML into smaller chunks and send them to the client as they become available. The client then uses JavaScript to append each chunk of HTML to the page as it is received, effectively streaming the content to the user.

One challenge with streaming SSR is ensuring that the chunks of HTML are sent to the client in the correct order and that the page remains coherent as it is rendered.

To address this, developers may use techniques such as critical CSS, which involves identifying and rendering the most important styles first, or template-based chunking, which involves breaking the HTML into smaller chunks based on templates or components.

In summary, Streaming Server-Side Rendering (SSR) is a rendering pattern for web development that involves sending the server-generated HTML to the client in chunks as it is generated, providing a faster TTFB and a more responsive user experience. It is particularly useful for rendering large or complex web pages.

To implement streaming SSR, the server must use a technique called "chunking" to break the HTML into smaller chunks, and the client must use JavaScript to append each chunk to the page as it is received.

Comparing the Different Patterns

Awesome, so now we have a clear idea of each of the common options available. Let's now quickly go through the main characteristics of each pattern and mention the situations in which each of them might be more beneficial.

Static Websites

Main characteristics:

Pre-built HTML, CSS, and JavaScript files that are served to the client as-is.
No dynamic content, as all content is pre-rendered and does not change.
Fast load times due to the lack of server processing.

Pros:

Extremely fast load times and low server costs.
Great for sites with little to no dynamic content, such as portfolios or blogs.

Cons:

Limited interactivity and functionality, as all content is pre-rendered.
Not suitable for sites that require dynamic content or user input.

Best for:

Sites with limited dynamic content or sites that do not require dynamic functionality.

Single Page Applications (SPAs)

Main characteristics:

All content is dynamically rendered client-side through JavaScript.
Only a single page is loaded, with content updates handled by JavaScript.
Dynamic content can be easily added through APIs.

Pros:

High interactivity and functionality, as all content is dynamic and can be updated without refreshing the page.
Ideal for complex, data-driven applications that require frequent content updates.

Cons:

Slower initial load times due to the need to load JavaScript and dynamically render content.
Can be difficult to implement proper SEO techniques due to the lack of pre-rendered content.

Best for:

Applications that require complex interactivity or frequent content updates.

Server Side Rendering (SSR):

Main characteristics:

Server Side Rendering (SSR) is a process in which web pages are generated on the server and sent to the client as fully rendered HTML.
The server sends a complete HTML response to the client, which includes all the dynamic content, after processing the data on the server.

Pros:

Improved SEO because search engine crawlers can easily parse the complete HTML content.
Better performance because the initial HTML is sent in a single response, which reduces the time for the browser to load and display the content.
Works well for content-rich applications or dynamic web applications that require data to be fetched from APIs.

Cons:

Higher server overhead because every request is processed on the server.
More complex to set up because it requires a server-side framework that supports SSR.
Less interactive because interactions require additional server requests.

Best for:

Applications with content that changes frequently.
Applications with dynamic data that needs to be processed on the server before sending the response.

Static Site Generation (SSG):

Main characteristics:

Static Site Generation (SSG) is a process in which web pages are pre-built as static files during the build process and served to the client as static HTML pages.
The server sends static HTML pages to the client, which includes all the content, without processing any data on the server.

Pros:

Very fast and efficient because static pages can be served from a CDN or cache.
Lower server overhead because the server only needs to serve static files.
Can be deployed on a static file host or serverless environments like AWS Lambda.

Cons:

Not suitable for dynamic content that changes frequently.
Interactions require additional client-side JavaScript.

Best for:

Applications with mostly static content and few interactions.
Applications with limited interactivity.

Incremental Static Regeneration (ISR):

Main characteristics:

Incremental Static Regeneration (ISR) is a hybrid approach between SSG and SSR, where pages are pre-rendered as static HTML pages during the build process, and then the content is regenerated periodically or on-demand as required.

Pros:

Faster time-to-content because static pages are served initially, but content can be updated quickly.
Lower server overhead because static pages can be served from a CDN or cache, and dynamic content is regenerated only when required.

Cons:

Limited dynamic content because content regeneration requires a server request.
Requires a complex caching strategy to ensure that stale content is not served to clients.

Situations:

Applications with content that changes frequently but can tolerate some latency.
Applications with limited dynamic content.

Islands:

Main Characteristics:

The Island rendering pattern refers to rendering parts of the page on the server while other parts are rendered on the client-side.
The server renders the critical content, while the client fetches the rest of the content.
The server-side rendering can improve the initial page load speed and improve SEO.
The client-side rendering can improve the interactivity and reduce server overhead.

Pros:

Faster page load times because the server renders critical content while the client fetches the rest.
Works well for applications that require partial server-side rendering and partial client-side rendering.

Cons:

More complex to set up because it requires a hybrid framework that can support both server-side and client-side rendering.
May result in inconsistencies if the server and client render different versions of the content.

Best for:

Applications with dynamic content that require some server-side processing.
Applications that require a fast initial page load.

Streaming SSR:

Main Characteristics:

The server sends the HTML response in a streaming fashion, which enables the client to start rendering the content as soon as possible.
The client can see content being rendered progressively, which improves the user experience.

Pros:

Improved time-to-content because the client can start rendering the content while the server is still processing the request.
Better user experience because the client can see content being rendered progressively.

Cons:

More complex to set up because it requires a server framework that supports streaming.

Best for:

Applications with large pages or media that require a long time to load.
Applications that require a smooth user experience with minimal waiting time.

Wrap up

Well everyone, as always, I hope you enjoyed the article and learned something new.

If you want, you can also follow me on LinkedIn or Twitter. See you in the next one!

Accessibility Best Practices – What to Remember When Building Accessible Web Apps

Shruti Kapoor — Fri, 16 Dec 2022 21:01:26 +0000

Anyone should be able to use your websites and apps - both people with disabilities and those without. This will make your website accessible.

Think about the last site you built, or your favorite site. Are you confident that anyone can use your site and perform the critical actions it requires? Have you considered folks with motor disabilities, visual disabilities, cognitive disabilities, and auditory disabilities?

Accessibility is often left as an after-thought. When it is time to ship a feature, we do an accessibility test and find out that our site wasn't accessible and do a hacky fix.

Making a site accessible is a huge undertaking. But if we keep accessibility in mind from the get-go, it makes it much easier to build an accessible web app.

In this post, I will go over 5 things you can keep in mind WHILE building your app so you don't have to do a hacky slap together at the end.

5 Things to Remember for Good Accessibility

Semantinc HTML
Tabindex
Aria attributes
Role
Keyboard navigation and screen readers

In short, S.T.A.R.K.

If you need help remembering this, think of Tony Stark.

Let's go through each of these to understand how to use them in your web apps.

What is Semantic HTML?

Using semantic HTML is important for accessibility. This is because assistive technologies such as screen readers are able to interpret what's on the page by parsing the HTML of the page. They enable users to take actions based on the elements.

For example, if a screen reader encounters a button, it signals to the user that they should click on it.

Let's consider some use-cases of what can happen when you don't use semantic HTML:

Creating buttons by using `div` instead of `button`:

divs are container elements, so when a screen reader encounters a div, it automatically thinks it is a presentational element.

When a screen reader user encounters a div that has content or children within it, the screen reader announces role="group" and the user will completely miss that the div is interactive. So make sure you use the proper semantic element for its purpose. You get accessibility for free.

Using CSS to fake headings instead of using `h1-6` tags:

Heading tags such as

and
let an assitive technology know that this is important text, and the screen reader will announce "Heading".

When you use CSS to make a heading instead of using correct semantics, the significance of the text is lost to a screen reader.

So just make sure to use semantic HTML whenever possible.

What is Tabindex?

Adding a `tabindex` makes interactive elements keyboard-navigable. When you add `tabindex` to an element, a user is able to navigate to it using only their keyboard and/or assitive technologies.

You use a tabindex of `0` to set focus to an element in the default tabbing order,

You use a tabindex of `-1` to programmatically focus an element using JavaScript.

Do not assign a value of > 1 to tabindex.

A word of caution though - you should only add `tabindex` to interactive elements. It is not a good practie to add `tabindex` to elements such as `div`.

Instead of adding tabindex in that case, use a semantic element, such as a `button` since semantic elements already are tabbable and do not need an additional `tabindex` value.

What are ARIA attributes?

Aria attributes such as aria-checked, aria-label give additional information to assistive technologies.

Aria attributes are a set of HTML attributes that you use to provide additional information about the purpose and state of elements on a web page. These attributes are especially beneficial to assistive technologies to provide more context and better navigation for users.

Some common aria-attributes include:

aria-label: used to provide a label or name for an element.
aria-hidden: used to indicate that an element should be hidden from assistive technologies. This can be useful for elements that are used for layout purposes but are not relevant to the content of the page.
aria-describedby: used to associate an element with a description, which helps to provide context of an element.
aria-live: used to indicate that an element's content may change dynamically, and that assistive technologies should pay attention to changes in the element's content.

You can use these attributes in combination with each other and with standard HTML attributes to create more accessible and user-friendly web content.

What is the `aria-role` attribute?

You use the aria-role attribute to define the purpose of an HTML element and provide its semantic meaning.

For example, if you are building a grid component with the help of CSS and divs, you can use role="grid" to let assistive technologies know about the semantics of the component.

Some common aria-roles include:

button: used to indicate that an element should be treated as a button.
alert: used to indicate that an element is an alertbox.
presentation: used to indicate that an element is only presentational.

It is important to exercise caution with aria-role. Remember to not overdo it.

Many users with motor disabilities rely on their keyboard and assitive technologies to navigate the web. So it's critical that every component be navigable using a keyboard and screen reader.

You can test keyboard accessibility by navigating a site using only your keyboard. Here are some common keys:

tab key to navigate to different sections of the site.
spacebar to select elements, such as a checkbox.
enter to press buttons.

While testing keyboard navigation, make sure you think about the following:

Focus remains visible: Ensure that you can clearly see which element is being focused on the page. Focus should always remain visible.
Tab order: When tabbing through sections, the order of tabbing should follow the natural flow and logical structure of the website. It should not jump back and forth between sections.
Keyboard traps: Ensure that when navigating with the keyboard, the focus doesn't get trapped on an element. For example, this could happen when a modal is opened, or the focus is navigated to a widget, such as calendar or emoji picker. Ensure that when you select an element in the widget, you are able to navigate back to the site.

Wrapping Up

Overall, testing for accessibility during development is an important part of the process that can help to create more usable and accessible software for all users. Testing for accessibility early helps to provide a great user experience for everyone.

In the next article, I will talk about the various accessibility tools and how to debug an accessibility issue. You can sign up to get it in your inbox here.

Until then, enjoy your holidays!

Feliz Navidad.

What is the Jamstack? Tutorial for Beginners

Damilola Oladele — Thu, 10 Nov 2022 18:30:49 +0000

You may have heard the term Jamstack and have been wondering what it means. Well, the Jamstack is nothing more than a modern way of building web applications.

Jamstack takes advantage of existing technologies – which we'll discuss in a minute. The result is better performance, improved security, and easier scalability for web applications.

In this article, you'll learn what Jamstack means and the benefits of using this approach in your projects.

What is the Jamstack?

Jamstack is a web development architecture. Matt Biilmann, the CEO of Netlify, popularized it with his presentation at Smashing Conference 2016.

Jamstack is an acronym for Javascript, APIs, and Markup, and is a technology stack you use to build your apps.

This is like the MERN stack (MongoDB, ExpressJS, ReactJS and NodeJS) and the MEAN stack (MongoDB, ExpressJS, Angular and NodeJS) – just with different tools.

Now let's discuss the various components of a Jamstack web application:

Javascript

Javascript is the core programming language of the web. It has been around for decades and you can use it both on the client side and the backend with NodeJS.

Javascript is the programming language you use for handling the client side of your Jamstack applications.

APIs

API is an acronym for Application Programming Interface. It's an interface which helps two or more computer programs communicate with each other.

In Jamstack apps, you use APIs to communicate with your backend.

Markup

Markup refers to standard text-encoding systems consisting of a set of symbols inserted into a text document. Examples of markup languages are HTML, XML, and templating languages such as JSX.

In the Jamstack, markup refers to the content of a Jamstack application. Note that we use markup here in its broader sense. It doesn't refer to text content only but also to the assets of the web application, such as images.

Important Features of Jamstack Apps

To consider an application a Jamstack app, it should meet the following conditions:

Distributed Architecture

This refers to the decoupling of the client side from the backend. The client side handles the presentation of the user interface, and the backend handles business logic and data.

Communication between the frontend and backend happens via a dedicated API. This means that a change or upgrade in one will not affect the other. This results in easier maintenance of the entire web application.

Static Sites

It is important for Jamstack applications to serve static web pages and not dynamic ones.

Traditional web applications are dynamic sites. This means that when you request a page, the backend will have to reach a database to retrieve the data. The data is then used to generate HTML files, and then sent back to the client.

The disadvantage of dynamic sites is how long it takes to complete these steps.

For static sites, the pages are already pre-rendered at build time. So every time you request a page, you get the pre-rendered page.

This eliminates the time that dynamic sites spend in obtaining data, generating HTML files, and sending it back to the client. You can serve your static sites from a content delivery network (CDN). This will lead to improved speed and reduced costs.

Examples of static site generators that you can use for your Jamstack web applications include:

NextJS
Gatsby
Hugo
Jekyll
Nuxt

Why Should You Use the Jamstack for your Web Applications?

Let's now discuss some of the reasons the Jamstack web architecture has become so popular in recent times and why you should consider adopting it:

Jamstack Apps Are Scalable

You can serve most Jamstack applications from a CDN. This allows for the speedy transfer of assets needed for loading web pages.

As a result of the distributed nature of CDNs, your web application will also be able to handle more traffic at a reduced cost.

Jamstack Apps Are Easy to Maintain

Jamstack applications are easier to maintain since their client side is decoupled from their backends.

This means that you can maintain one part without requiring major modifications to the other.

Jamstack Apps Load Faster

As stated earlier, serving your site from a CDN increases the speed with which it loads.

Also, in Jamstack applications, web pages are prebuilt, saving time that would normally be spent retrieving and generating HTML files every time you make a request.

Jamstack Apps Are Cheaper

Since Jamstack applications are easier to maintain and deploy, they are cheaper compared to their traditional counterparts.

Jamstack Apps Are More Secure

Since you do not have to constantly maintain a server in Jamstack applications and the pages are constructed on read-only files (that is, the pages are static), you can worry less about the security of your applications.

Conclusion

Despite the fact that more and more projects are being built using the Jamstack architecture, we're still in the relatively early stages of its adoption.

I believe that more large and small businesses will adopt it in the near future in place of costly monolithic architectures.

How to Architect a Full-Stack Application from Start to Finish

Lane Wagner — Tue, 04 Oct 2022 17:49:10 +0000

Software architecture is a massive topic. That said, I think I can give you a simple method you can use to approach the architecture of a full-stack application.

In particular, I want to talk about the order in which you should think about and build out the pieces of a typical web application.

My advice is that for each feature you should:

Design the front-end
Build the front-end
Build the persistence layer (back-end database and data models)
Build the API (back-end application)

The best way is a front -> back -> middle approach.

Why Start with the Front-End?

Assuming you're working with a good product team (or maybe you're a team of one so you are the product team) the most important thing is the end-user experience. As a result, it makes the most sense to start on the front-end.

Only by designing and building the front-end will you learn what kinds of requirements you'll have for the back-end of your application.

The user of front-end code is the customer. The user of back-end code is front-end code.

How Do you Build a Front-End without a Back-End to Connect to?

This is the beauty of starting with the front-end. Start by mocking up all of the data that fills in your UI. For example, instead of writing code like this:

const resp = await fetch(userUrl)
const user = await resp.json()

You would simply write:

const user = {
    id: 1,
    username: "bobbyjoe",
    email: "bobbyjoe@example.com",
    profilePictureUrl: "https://fakewebsite.com/fakeimageurl.jpeg"
}

Then you would write all the rest of the front-end code like you normally would. By the time you're done, you'll know exactly what kind of data you'll need your back-end to store and serve.

And by the time you do get around to building the back-end, you can just swap out those mock JSON objects for fetch requests.

Create the Data Model and Database Schema

Okay, so you've built out the front-end for your new feature, and you've mocked all the data that you've decided will need to be stored on the back-end. Now it's time to decide how you'll model that data inside your database.

I like to go straight from the front-end to the database. This is because the way you store data in the database is more important to get right than the way you serve the data from your API – well, at least if the consumer of your API is your own team (or you).

Obi Wan writing APIs for himself

Changing database schemas is hard. It's much easier to slap a /v2 endpoint on your back-end than to rewrite your persistence layer.

For that reason, thinking about how you're going to store your data, and giving priority to that design, will generally lead to less headache down the road.

Typically, once you have the front-end built you have all the information you need to design a solid database schema.

For example, maybe you know you need:

To store users, each with an email and profile picture
To allow users to join, create, and leave organizations

With that in mind, and assuming you're using a relational SQL database like Postgres, you can probably start with something like:

A users table with id, created_at, email, and profile_picture_url fields
A organizations table with id, created_at, and name fields
A users_organizations table with id, user_id, organization_id, and role fields

Users go in the users table, organizations go in the organizations table, and the users_organizations table is a joining table to keep track of which users are a part of which organizations and what their role is. For example, they might be an admin or a member.

If you're unfamiliar with all this SQL terminology, you can check out my Learn SQL course on Boot.dev.

Lastly, Build the Back-end Application

Now that you know which data your front-end needs, and how you can best model it in your database, you final task is to glue it all together with a back-end API.

Start with the simplest API you can.

Don't build complex joining capabilities to start. Don't build crazy pagination or filtering features if you don't need them. You can always add new endpoints and parameters later in order to fulfill performance needs as they arise. I'm a big fan of optimizing for simplicity first.

Anyhow, that's not to say you won't need anything more complex than a few CRUD endpoints – you might. If you do, at least you have all the information in front of you in order to make a well-informed decision.

Don't build more than what the front-end requires, and try to use the simple data models you created in the database.

With all that in mind, expect to go back and forth on a few things. Don't feel bad if you missed a feature on the front-end and need to go back and add it. Or maybe you overlooked how slow a certain view in your app would load if you store the data in a certain way in your database. This can be an iterative process, and it should be.

One Final Note: Don't Do Waterfall

I want to double stress the fact that you should be doing this on a per-feature basis. I'm not advocating that you plan an entire application up front. You should still be practicing iterative product development.

Good luck, and if you need help learning back-end development feel free to check out what I'm building over on Boot.dev!

How to Deploy a Machine Learning Model as a Web App Using Gradio

Ibrahim Ogunbiyi — Wed, 01 Jun 2022 15:14:51 +0000

You've built your Machine Learning model with 99% accuracy and now you are ecstatic. You are like yaaaaaaaaay! My model performed well.

Then you paused and you were like – now what?

Well first, you might have thought of uploading your code to GitHub and showing people your Jupyter notebook file. It comprises those gorgeous-looking visualizations you created using Seaborn, those extremely powerful ensemble models, and how they are able to pass their evaluation metrics and so on.

But then you noticed that no one is interacting with it.

Well, my friend, why not try deploying the model as a web app so that non-techies can interact with the model, too? Because only programmers like you will likely understand that first approach.

There are several methods for deploying your model, but we will focus on one of them in this article: using Gradio. I can tell you're excited. Well, relax and enjoy, because this is going to be an exciting ride.

Prerequisites

Before beginning this journey, I assume you have the following knowledge:

You know how to create a user-defined function in Python
You can build and fit an ML model
Your environment is all set up

What is Gradio?

Gradio is a free and open-source Python library that allows you to develop an easy-to-use customizable component demo for your machine learning model that anyone can use anywhere.

Gradio integrates with the most popular Python libraries, including Scikit-learn, PyTorch, NumPy, seaborn, pandas, Tensor Flow, and others.

One of its advantages is that it allows you to interact with the web app you are currently developing in your Jupyter or Colab notebook. It has a lot of unique features that can help you construct a web app that users can interact with.

How to Install Gradio

To use Gradio, we must first install its library on our local PC. So go to your Conda PowerShell or terminal and run the following command. If you are using Google Colab you can also type the following:

pip install gradio

We now have Gradio installed on our local PC. Let's go through some of the fundamentals of Gradio so we can become acquainted with the library.

To begin, we must import the library into our notebook or IDE, whichever you are using. We can do this by typing the following command:

import gradio as gr

How to Create Your First Web App

In this tutorial, we'll create an example greeting app to familiarize ourselves with the fundamentals of Gradio.

To do so, we'll need to write a greeting function because Gradio works with Python user defined functions. As a result, our greeting function looks like this:

def greet_user(name):
    return "Hello " + name + " Welcome to Gradio!😎"

We now need to deploy the Python function on Gradio so that it can act as a web app. To do this, we type:

app =  gr.Interface(fn = greet_user, inputs="text", outputs="text")
app.launch()

Let’s walk through and have a grok about what is going on in the above code before we run it.

gr.Interface: This attribute serves as the bedrock of anything in Gradio. It is the user interface that displays all the components that will be shown on the web.

The parameter fn: This is the Python function you created and want to provide to Gradio.

The inputs parameter: These are the components that you wish to pass into the function that you created, such as words, images, numbers, audio, and so on. In our case, the function we created required text, so we entered it into the inputs parameters.

The output parameter: This is a parameter that allows you to display the component on the interface that you want to see. Because the function we created in this example needs to display text, we supply the text component to the outputs parameter.

app.launch is used to launch the app. You should have something like this when you run the above code:

Once the Gradio interface comes up, just type your name and hit submit. Then it outputs the result in the function we created above. Now that we are done with that, let’s go over one more thing in Gradio before we learn how to deploy our model.

We will create a Gradio app that can accept two inputs and provides one output. This app just asks for your name and a value and then outputs your names as well as multiples of the value you entered. To do that just type the below code:

def return_multiple(name, number):
    result = "Hi {}! 😎. The Mulitple of {} is {}".format(name, number, round(number**2, 2))
    return result

app = gr.Interface(fn = return_multiple, inputs=["text", gr.Slider(0, 50)], outputs="text")
app.launch()

Now that we’ve done that let’s quickly go through some of the things we did here that you might not be familiar with.

Input Parameter: In the input parameter we created a list that involves two components, the text and the slider. The slider is also one of Gradio's attributes that returns a float value when you slide across a given range. We used this because in the function we created we are expecting a text and a value.

We have to order the component in the input parameter the way our attributes are ordered in the function we created above. That is, text first before the number. So what we are expecting for the output is actually a string. We just did some formatting in the above function.

Now that we’ve familiarized ourselves with some of the basics of Gradio, let’s create a model that we will deploy.

How to Deploy a Machine Learning Model on Gradio

In this section, I will use a classification model that I've previously trained and saved in a pickle file.

When you create a model that takes a long time to train, the most effective approach to deal with it is to save it in a pickle file once it is finished training so that you don't have to go through the stress of training the model again.

If you want to save a model as a pickle file, let me show you how you can do that. First import the pickle library and then type the code below. Let’s say I just want to fit a model like this:

import pickle

from sklearn.ensemble import RandomForestClassifier
clf = RandomForestClassifier(random_state=42)
clf.fit(X_train, y_train) 

# If you've fitted the model just type this to save it: Remember to change the file name
with open("filename.pkl", "wb") as f:
pickle.dump(clf, f)

Now if you wish to load it you can type the following code as well:

with open("filename.pkl", "rb") as f:
    clf  = pickle.load(f)

Now that we’ve understood that, let’s create a function that we will be able to pass into Gradio so that it can make the predictions.

def make_prediction(age, employment_status, bank_name, account_balance):
    with open("filename.pkl", "rb") as f:
        clf  = pickle.load(f)
        preds = clf.predict([[age, employment_status, bank_name, account_balance]])
    if preds == 1:
            return "You are eligible for the loan"
    return "You are not eligible for the loan"

#Create the input component for Gradio since we are expecting 4 inputs

age_input = gr.Number(label = "Enter the Age of the Individual")
employment_input = gr.Number(label= "Enter Employement Status {1:For Employed, 2: For Unemployed}")
bank_input = gr.Textbox(label = "Enter Bank Name")
account_input = gr.Number(label = "Enter your account Balance:")
# We create the output
output = gr.Textbox()


app = gr.Interface(fn = make_prediction, inputs=[age_input, employment_input, bank_input, account_input], outputs=output)
app.launch()

So let’s unwrap what we have above:

We'll start at the point where we created the input component. You can choose to create the component in the gr.Interface, but in the following code, I built it directly outside of the gr.Interface and then provided the variable into the gr.Interface.

So, if you want to make a component that receives numbers, use gr.Number, and then from the output variable I created, you can pass text as we did earlier in our first app (the " text" string is shorthand for textbox if you don't want to declare the attribute explicitly).

Also I used the label parameter in each component so that the user will know what to do. We are already familiar with the other code mentioned above. And now that we've done that our model is deployed. 🎉🎉😎🥳🥳.

Conclusion

Thank you for reading this tutorial. We covered a lot in this article. Just remember that learning Gradio does not stop here – you can check out more on their website. They have pretty intuitive documentation on how you can create your web app.

Thanks once again for reading. If you enjoyed this article, you can support me by following me on LinkedIn or Twitter. Gracias, and happy deployment😀

How to Use Azure Static Web Apps to Deploy an Angular App

Marco Venturi — Thu, 14 Apr 2022 23:42:23 +0000

CI/CD has changed the way IT teams release new software versions.

In this tutorial I'll share my experience with Azure Static Web Apps – Azure's PaaS solution. I'll show you how you can take advantage of its flexibility to deploy an Angular App just by pushing your code to a Git repository.

There’s a lot of literature about CI/CD on the web, and in this article, I want to focus on Azure Web Apps to show you how it can dramatically simplify your workflow.

If you want to know more about CI/CD, Atlassian’s blog has some good info. And here's a helpful in-depth and project-based guide on the subject.

What do we need for this project?

During this tutorial, we'll use the following technologies and tools:

A GitHub account
Node.js (you can download it here)
Npm (Node.js package manager. Included with Node installation.)
Angular CLI (a command-line interface tool to create, develop and maintain your Angular app. You can download it here.)
Azure account (you can start for free by creating your account here. Once your free trial expires, have a look at the costs you are incurring. Cloud technologies are very powerful and can make your life easier. But they can be expansive if not well managed.)

If you want to follow along with me during this article and replicate what I’m building, you need to be all set with these tools.

What We'll Build Here – the Big Picture

Let’s see how to create our Angular App and deploy it with Azure Web App. We'll create our Angular app locally and push it to a GitHub repository we specifically create for this project.

The repository will have two branches: “main” and “develop”. We'll create a static web app on Azure and connect it to the “main” branch of the repository.

Back to your machine, edit the code and push it to the “develop” branch. Then you merge the “develop” branch with the “main” one and see the new version of your app online.

Just to be clearer, I think a quick list will help us recap every single step:

You'll create your Angular app locally with Angular CLI
You'll push it to a GitHub repository
You’ll create a static web app on Azure and connect it to the “main” branch of the project’s repository
You’ll create a “develop” repository
You’ll edit the app code locally and push it to the “develop” repository
You’ll create a pull request on your GitHub project from “develop” to “main” and merge it
You’ll check if the new app version is available on the web app

Step 1 – Create the Angular App Locally

First, let's create a specific directory on your computer and move into it. I’m on Mac, so I'll open my terminal and type:

mkdir angular_azure
cd angular azure

Once there, create your new Angular app called “angular_app”:

ng new angular_app

Angular CLI asks you a few questions:

We want to add Angular router and we also want to use CSS for styling the app. Once you receive positive feedback from Angular CLI, start your app locally to see if everything is working fine:

ng serve —-open

The option “--open” tells Angular CLI that you want to open the application with your default browser. This means that you don’t need to copy and paste the URL into your browser’s address bar. So, this is what you should see:

Looks like everything is working fine. You can stop the application (Ctrl + C) and move to the next step

Step 2 – Push the Angular App to Your GitHub Repository

You should have created a new repository on your GitHub account dedicated to this project. I called mine “angular-app-with-azure”. If you don’t know how to create a new repository, you can read more about that here.

Once the repository is ready, push your Angular app from your machine to your repository. If you don’t add a README file when creating your repo, you should see the instructions on how to push your code directly on your repository page. However, I'll repeat these instructions also here:

git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/.git
git push -u origin main

Once you run these commands successfully, you should see something like this:

Let’s go ahead now.

Step 3 – Time to Switch to Azure

Now you'll create a brand new Azure Static Web App and connect it to your repository. First of all, enter the Azure portal here, and go to your Resource Group. Then you'll see this:

Hit “create” and you'll see the list of resources available on Azure. Filter resources by “Static Web App” and select it.

Then move to Azure’s wizard to create the resource. Let’s see how you should fill it out.

First of all, choose the subscription and resource group. Then go with the Static Web App details: choose the name – “angular-app” – and stick with the Free plan. Then select your region – mine is “Central US”.

Then go ahead with a few more pieces of information:

You can synch your GitHub account in the “Deployment Details” section, and then specify the Organization, Repository, and branch you'll get your codebase from.

As I said at the beginning of this tutorial, I choose the “main” branch as the production one.

Now let’s focus on the “Build Details”. You'll choose “Angular” as “Build Presets”, and specify that the App is located at the root directory on “App Location”.

Then you'll type the path of the output location (“dist” directory plus name-of-project directory. In my case, it's “dist/angular-app”. This is where Angular CLI locates the build of your project. I spent a lot of time looking for this info and I think it’s good to share it with you).

So, now you're ready to create your Static Web App. Hit “create” and see what happens. This is the overview of my app:

Next, hit the “URL” link and this is what you should see:

Step 4 – Create a New Branch

So now you'll go back to your codebase locally and create your “develop” branch and check it out:

git checkout -b develop

Then go to:

src/app/app.component.html

Edit the code like this:

Pushed to develop
<router-outlet>router-outlet>

And then push the new branch to the remote repository:

git push origin develop

Step 5 – Time to Merge

Your angular App is still online with the old version. You need to merge your "develop" branch to "main" to see the changes online.

Create a pull request on GitHub and merge it. This is what you should see at the end:

Wait a couple of minutes and then you'll see the new version of your app online:

A Quick Recap and Useful Resources

I hope this tutorial showed you how you can easily deploy your code to a production environment with CI/CD and Azure Static Web App.

While practicing with these technologies, I found a lot of interesting content on the web about them. I thought it would be good for you to have all of them in one place:

And don't forget... Keep learning, and keep coding!

How to Build Your First Web App in Julia with Genie.jl 🧞‍♂️

freeCodeCamp — Tue, 01 Feb 2022 21:33:45 +0000

By Logan Kilpatrick

Julia is a high-level, dynamic, and open-source programming language. It's designed to be as easy to use as Python while remaining as performant as C or C++.

Many early use cases for Julia were in the scientific domains where massive computational processing was and still is required. But as the language has continued to grow, more and more use cases are gaining steam (hint: web development).

If you are totally new to Julia and want to get a handle on the syntax before you dive into creating your first web application, check out this article on freeCodeCamp.

It goes over the basics, how to install Julia, steps to install packages, and much more!

We will focus this tutorial on all the necessary steps to build your first web application in Julia from the ground up. So let's begin by checking out the Genie website: https://genieframework.com.

What is Genie.jl? 🧐

Genie is a modern and highly productive web framework written in Julia. In the project's own words:

Genie is a full-stack web framework that provides a streamlined and efficient workflow for developing modern web applications. It builds on Julia's strengths (high-level, high-performance, dynamic, JIT-compiled), exposing a rich API and a powerful toolset for productive web development.

Genie is very similar to the Django Project in that Genie is more than a single framework. Instead, it is an entire ecosystem with extensions and the like.

But why do we need Genie? The simple answer is that as Julia continues to grow in popularity, more and more developers are looking to leverage Julia across their entire stack. Genie provides the ability to deploy websites with Julia code running on the server-side so you can do things like deploy machine learning models as part of your Genie app.

Before we dive into getting started with Genie, you might want to check out a live deployed Genie app to get a sense of what is possible: https://pkgs.genieframework.com.

This project is a community resource where you can query the number of package downloads during a certain time frame for a specific package. Type in "genie" to see the number of daily downloads.

You might also be interested in learning more about other GUI and web development frameworks in Julia. To learn more broadly about the ecosystem, check out this article.

How to Install Genie ⤵️

To get Genie installed, all we need to do is open the Julia REPL and type ] add Genie . This will take care of everything you need. If everything works, you should be able to do:

julia> using Genie

without any issues. You are now all set to begin trying out Genie.

How to Map URLs to Julia Functions 🗺

A core part of the Genie framework is the idea of a router. Routers take the user action of visiting a specific URL and associate it with a Julia function being called.

Let's look at a simple example of this. In the REPL, type the following:

julia> using Genie, Genie.Router

julia> route("/hello") do
           "Hello freeCodeCamp"
       end
[GET] /hello => #5 | :get_hello

In this example, we defined the "/hello" URL to return the text "Hello freeCodeCamp". We can verify that this works by starting the server:

julia> up() # start server
┌ Info: 
└ Web Server starting at http://127.0.0.1:8000 
Genie.AppServer.ServersCollection(Task (runnable) @0x000000011c5c5bb0, nothing)

Now that the server is up and running, we can visit http://127.0.0.1:8000 in our browser. You will notice we get a 404 page, which is expected since the only route we defined was "/hello". So let's add that to the URL and see what we get:

And there we go! Our first step towards building a fully functional web application is complete. We can also confirm that the page is loading correctly by checking the REPL which shows this:

julia> ┌ Error: GET / 404
└ @ Genie.Router ~/.julia/packages/Genie/UxbVJ/src/Router.jl:163
┌ Error: GET /favicon.ico 404
└ @ Genie.Router ~/.julia/packages/Genie/UxbVJ/src/Router.jl:163
[ Info: GET /hello 200

We see the first attempt where the result was a 404 and on the 2nd attempt where we successfully got the response (the 200 message means everything is okay).

Now that we have a basic example working, let's now try and build on this with some more depth.

To do this, we will create a new file. I will be using VS Code but you are welcome to use any IDE you find useful. Before we look at the next piece of code, we need to make sure we shut down the server by typing down() into the REPL.

Okay, onto the next example:

using Genie, Genie.Router
using Genie.Renderer, Genie.Renderer.Html, Genie.Renderer.Json

route("/") do
    html("Hey freeCodeCamp")
end

route("/hello.html") do
  html("Hello freeCodeCamp (in html)")
end

route("/hello.json") do
  json("Hi freeCodeCamp (in json)")
end

route("/hello.txt") do
   respond("Hiya freeCodeCamp (in txt format)", :text)
end

# Launch the server on a specific port, 8002
# Run the task asynchronously
up(8002, async = true)

A lot is going on in this example, so let's walk through what is taking place.

We start by loading in the packages we want. Then, we define 4 different routes. The first one is the index route. So when the user visits http://127.0.0.1:8002 they will see "Hey freeCodeCamp". The routes after the index highlight that each route can give a custom output. In some cases, it can be HTML, in others, it could be JSON or plain text.

The last line of this example showcases the server launching code. As the comment states, we can set the specific port number and choose if we want the routes to run asynchronously or not. We have now successfully created our first Genie Script!

How to Create a Basic Web Service 🕸

Now that we have gotten our hands dirty with the basics, we will now begin to get closer to building a fully-fledged web application.

Before we go all the way there, we are going to take the first step which is creating a basic web service. To do so, we will go into the REPL and switch our current directory to one which is easily accessible. I will use my desktop in this tutorial:

shell> cd Desktop
/Users/logankilpatrick/Desktop

To enter shell mode which is shown above, simply type a ";" into the REPL. Now that we have our active directory set to the desktop in my case, we will use the handy generator function to create the service:

julia> Genie.newapp_webservice("freeCodeCampApp")

[ Info: Done! New app created at /Users/logankilpatrick/Desktop/freeCodeCampApp
[ Info: Changing active directory to /Users/logankilpatrick/Desktop/freeCodeCampApp
    /var/folders/tc/519vfm453fj_x5bmd8pwx9480000gn/T/jl_bO1R8h/FreeCodeCampApp/Project.toml
[ Info: Project.toml has been generated
[ Info: Installing app dependencies
...

The newapp_webservice is a very helpful function that automatically creates all the pieces we need for our first web service. Now that we have a project created, we need to open it up in an IDE (in my case, VS Code). You should see the following if you open up the correct folder:

There are a lot of files created for us automatically. The main one we will look at is routes.jl which is used to create routes as we did in the section above.

The function we called to generate these folders automatically starts the server, so let's take a quick look at the existing landing page by visiting http://127.0.0.1:8000:

As you might notice, my page looks a little different than yours might because I went in and edited the welcome.html page found in the public folder.

As you can see in routes.jl, when the user visits the main URL /, we route them to the welcome page. We can add in additional routes as we did in the section above and expand this. You are welcome to pause here and play around. We already have a pretty robust website setup.

If you take a peek into some of the other folders like config/env, you will see details around setting the port, host URL, and other relevant parameters. Again, feel free to play around there but we will not go into all the detail of those files in this tutorial.

Before we dive into the next topic, let's take a look at a few more of the files generated for our basic web service:

The public folder has all of the front end files (HTML and CSS)
The src folder has the entry point to the web service (in my case freeCodeCampApp.jl)
bin contains some additional dependencies we will again ignore
Manifest.toml and Project.toml are the key Julia files that allow us to maintain our Julia dependencies. When you created the web service, the script automatically activated your current project environment (which is the app we just created). You can verify this by typing "]" into the REPL which will show the active space in blue:

This just means that if we try to add a package, it will add it to the project and manifest file specifically for this project, instead of the globally shared one.

How to Create a Fully Functioning Web App With a Database 💽

Now that we have explored the basics, we are going to dive into a full-on web app. Again, Genie provides some nice functions to get us started. Before we create it, we will need to navigate back to the desktop:

shell> pwd
/Users/logankilpatrick/Desktop/freeCodeCampApp

shell> cd ..
/Users/logankilpatrick/Desktop

shell>

Remember, you can type ; to enter the shell mode and backspace to exit the shell mode. Now, let's create the app:

julia> Genie.newapp_mvc(Genie.newapp_mvc("freeCodeCampMVC"))
   Resolving package versions...
   ...

You will be prompted to choose a database backend. For this example, we will use SQLite:

If you want to use a different database backend, feel free to do so as well. But note that you will need to create the database file automatically. Genie only creates an SQLite file for you.

We now have a MVC app created. But you might be asking yourself, what is an MVC?

The Model-View-Controller paradigm is very common across application development. In the interest of not getting into the weeds on it, I will refer you to this post where you can read about the details. From our perspective as developers, there is not much impact.

Just like we did when we created the last project, we need to open it in the IDE again:

Again, we will see much of the same stuff as before with the new addition of the app folder which will contain a lot of critical code. We can see what the new project looks like by typing:

julia> loadapp()

julia> up()

and then navigating too: http://127.0.0.1:8000.

Next up, we will need to connect our database to the web app we created. To do this, head to db/connection.yml and edit the following section:

env: ENV["GENIE_ENV"]

dev:
  adapter: SQLite
  database: db/freeCodeCamp_courses.sqlite

You can leave the rest of the fields blank for now. Then, we need to run:

julia> include(joinpath("config", "initializers", "searchlight.jl"))

which will load the database configuration. Next up, we will continue to configure the database such that we can save data from our app into persistent storage.

We begin this process by creating a new resource:

julia> Genie.newresource("course")

Once we have defined a resource, the next step is to go and edit the database migrations table which can be found at db/migrations/2022020115190055_create_table_courses.jl in my case.

By default, the table is already populated with some placeholder text based on the last few commands we ran. It should look something like this:

We will edit the file to match the specific scheme we want. This will be entirely dependent on the application itself. Since I am making courses on this site, I will enter all of the course details as follows:

module CreateTableCourses

import SearchLight.Migrations: create_table, column, columns, pk, add_index, drop_table, add_indices

function up()
  create_table(:courses) do
    [
      pk()
      column(:title, :string, limit = 200)
      column(:authors, :string, limit = 250)
      column(:year, :integer, limit = 4)
      column(:rating, :string, limit = 10)
      column(:categories, :string, limit = 100)
      column(:description, :string, limit = 1_000)
      column(:cost, :float, limit = 1000)
    ]
  end

  add_index(:courses, :title)
  add_index(:courses, :authors)
  add_index(:courses, :categories)
  add_index(:courses, :description)

end

function down()
  drop_table(:courses)
end

end

Again, these are arbitrary and can be whatever you want them to be.

It is worth noting that adding the index is optional. The reason you would add it is that it speeds up the queries, but there are other tradeoffs and you can't actually load all the columns as indexes. You can read more about some of these tradeoffs here and here.

Now that we have the database table updated, we need to propagate these updates. To do so, we will use SearchLight.jl which functions as our app's migration system:

julia> using SearchLight

julia> SearchLight.Migration.create_migrations_table()
┌ Info: 2022-02-01 07:37:11 CREATE TABLE `schema_migrations` (
│       `version` varchar(30) NOT NULL DEFAULT '',
│       PRIMARY KEY (`version`)
└     )
[ Info: 2022-02-01 07:37:11 Created table schema_migrations

julia> SearchLight.Migration.status()
[ Info: 2022-02-01 07:37:20 SELECT version FROM schema_migrations ORDER BY version DESC
|   | Module name & status                     |
|   | File name                                |
|---|------------------------------------------|
|   |                 CreateTableCourses: DOWN |
| 1 | 2022020115190055_create_table_courses.jl |

julia> SearchLight.Migration.last_up()
[ Info: 2022-02-01 07:37:29 SELECT version FROM schema_migrations ORDER BY version DESC
[ Info: 2022-02-01 07:37:29 CREATE TABLE courses (id INTEGER PRIMARY KEY , title TEXT  , authors TEXT  , year INTEGER (4) , rating TEXT  , categories TEXT  , description TEXT  , cost FLOAT (1000) )
[ Info: 2022-02-01 07:37:29 CREATE  INDEX courses__idx_title ON courses (title)
[ Info: 2022-02-01 07:37:29 CREATE  INDEX courses__idx_authors ON courses (authors)
[ Info: 2022-02-01 07:37:29 CREATE  INDEX courses__idx_categories ON courses (categories)
[ Info: 2022-02-01 07:37:29 CREATE  INDEX courses__idx_description ON courses (description)
[ Info: 2022-02-01 07:37:29 INSERT INTO schema_migrations VALUES ('2022020115190055')
[ Info: 2022-02-01 07:37:29 Executed migration CreateTableCourses up

We have now successfully completed the migrations. If you were to make a change to the schema, you would need to re-run the commands above for those database changes to take effect.

The last step in this process is to define our model. This will allow us to create objects in Julia code and then save them to the database we just defined. We need to navigate to app/resources/courses/Courses.jl or the equivalent path to make these final updates:

module Courses

import SearchLight: AbstractModel, DbId
import Base: @kwdef

export Course

@kwdef mutable struct Course <: AbstractModel
  id::DbId = DbId()
  title::String = ""
  authors::String = ""
  year::Int = 0
  rating::String = ""
  categories::String = ""
  description::String = ""
  cost::Float64 = 0.0
end

end

Again, this should be the same as the content you previously defined. To make sure this worked, we can do:

julia> using Courses
[ Info: 2022-02-01 07:43:51 Precompiling Courses [top-level]

and then try creating a course via:


julia> c = Course(title = "Web dev with Genie.jl", authors="Logan Kilpatrick")
Course
| KEY                 | VALUE                 |
|---------------------|-----------------------|
| authors::String     | Logan Kilpatrick      |
| categories::String  |                       |
| cost::Float64       | 0.0                   |
| description::String |                       |
| id::DbId            | NULL                  |
| rating::String      |                       |
| title::String       | Web dev with Genie.jl |
| year::Int64         | 0                     |

We have successfully created our first object! But it is not saved to the database right away. We can verify this by doing:

julia> ispersisted(c)
false

so we need to run:

julia> save(c)
[ Info: 2022-02-01 07:47:04 INSERT  INTO courses ("title", "authors", "year", "rating", "categories", "description", "cost") VALUES ('Web dev with Genie.jl', 'Logan Kilpatrick', 0, '', '', '', 0.0) 
[ Info: 2022-02-01 07:47:04 ; SELECT CASE WHEN last_insert_rowid() = 0 THEN -1 ELSE last_insert_rowid() END AS LAST_INSERT_ID
true

and now the course is saved! But to really test this out, we need the user to be able to create a course. Let's head back to routes.jl and enable that:

using Genie, Genie.Router, Genie.Renderer.Html, Genie.Requests
using Courses

form = """

  
  

  

"""

route("/") do
  html(form)
end

route("/", method = POST) do
  c = Course(title=postpayload(:name, "Placeholder"), authors=postpayload(:author, "Placeholder"))
  save(c)
  "Course titled $(c.title) created successfully!"
end

We started by defining a simple HTML form (nothing new or exciting here), then, we made it so the default route / renders the HTML form. Lastly, we create another route for the / URL, but specifically for the POST method. Inside that route, we create a new course by pulling the info we want from the form out of the payload via postpayload.

You can try this by navigating back to: http://127.0.0.1:8000

You can try and enter some of the details and then press submit. To make sure the submissions worked, you can do:

julia> all(Course)
[ Info: 2022-02-01 08:10:19 SELECT "courses"."id" AS "courses_id", "courses"."title" AS "courses_title", "courses"."authors" AS "courses_authors", "courses"."year" AS "courses_year", "courses"."rating" AS "courses_rating", "courses"."categories" AS "courses_categories", "courses"."description" AS "courses_description", "courses"."cost" AS "courses_cost" FROM "courses" ORDER BY courses.id ASC
┌ Warning: 2022-02-01 08:10:19 Unsupported SQLite declared type INTEGER (4), falling back to Int64 type
└ @ SQLite ~/.julia/packages/SQLite/aDggE/src/SQLite.jl:416
┌ Warning: 2022-02-01 08:10:19 Unsupported SQLite declared type FLOAT (1000), falling back to Float64 type
└ @ SQLite ~/.julia/packages/SQLite/aDggE/src/SQLite.jl:416
3-element Vector{Course}:
 Course
| KEY                 | VALUE                 |
|---------------------|-----------------------|
| authors::String     | Logan Kilpatrick      |
| categories::String  |                       |
| cost::Float64       | 0.0                   |
| description::String |                       |
| id::DbId            | 1                     |
| rating::String      |                       |
| title::String       | Web dev with Genie.jl |
| year::Int64         | 0                     |

 Course
| KEY                 | VALUE       |
|---------------------|-------------|
| authors::String     | Logan K     |
| categories::String  |             |
| cost::Float64       | 0.0         |
| description::String |             |
| id::DbId            | 2           |
| rating::String      |             |
| title::String       | Test course |
| year::Int64         | 0           |

which should show that the entries were saved in the database.

Wrapping up 🎁

Wow, that was a lot. We covered a tremendous amount of ground in this single tutorial.

With that said, there is even more to learn about Genie. I highly suggest checking out the docs here, which has lots more tutorials on topics like REST API's, Authentication, and much more.

Getting help with Genie.jl 🚨

If you run into issues with this tutorial or when using Genie, please post a question on Stack Overflow with the genie.jl and julia tag or on the Julia Discourse. After that, feel free to tweet the link to the question at me and I will do my best to help: https://twitter.com/OfficialLoganK.

What Items Should Be Configurable in an Application?

freeCodeCamp — Wed, 27 Oct 2021 20:30:15 +0000

By Kenneth Angelo Reyes

Configuration is an essential part of every application. It helps enhance an application's flexibility and maintainability.

With this in mind, it's very important that developers are able to correctly identify what items should be in configuration.

In this article, I'll walk you through 8 items that should be configurable in your applications.

Define "Configuration"

We will not be aligning with any existing platforms out there.

For the context of this article, an application configuration has the following characteristics:

A set of simple or complex values that can affect an application's behavior
Values can easily be changed without requiring any code deployment

With that out of the way, let's go to our list!

The "Configurables"

Here are the 8 items that should be configurable in your applications.

Magic Numbers

These are special numbers that are used in certain displays, validations, or business rules.

Examples:

Number of days before an SLA (Service Level Agreement) is breached
Number of decimal places when rendering a currency

URLs

When connecting to 3rd-party services, there's no knowing when their URLs will change. It's best to keep these values configurable. Additionally, configurable URLs can help you control the value in different environments.

Examples:

API Endpoints
External websites

Feature Toggle

This is helpful when there is a feature that's already in production, but which can only be enabled after a certain time.

An example of this is a feature that can only be enabled after a live stream event. Normally, this can be a Boolean value, but you can also use Date Time for this. This just means that the feature will automatically be enabled once that time has passed.

Regex Patterns

Some Regex patterns, especially those used in validation, have the potential to change regularly.

An example of this is phone number validation. Initially, your application might allow phone numbers from several countries. Then, perhaps a change in requirements came about where you now have to allow only phone numbers from specific countries.

If your validation pattern is in configuration, then you can quickly make this change.

Special Dates

Not the romantic ones! In some applications, there's a need to "block" certain dates from being selected by users.

A perfect example of this are public holidays. Since these dates can change regularly, they should be placed in configuration.

Connection Strings

Database connection strings should never be placed in your code! When you place connection strings in configuration, you'll also be able to set a different value per environment.

Formulas

For finance-related applications, making formulas configurable is very important. For these type of applications, adapting to policy or regulatory changes as soon as possible is a must.

Special Messages

This may be more applicable to non-CMS applications. In some cases, the regular changes in text messages are tied to legal or regulatory policies. Therefore, these messages should be easy to update.

A good example of this is an announcement that shows whether the application is currently facing any issues or is under maintenance.

Conclusion

These are the 8 items that I believe should be configurable in every application. I'm sure you have other items on your mind. Let me know! Looking forward to hearing from you.

Glad you reached the end of this article. I hope you learned something new from me today.

_Cover photo from Unsplash_

MVC Architecture – What is a Model View Controller Framework?

Jessica Wilkins — Fri, 24 Sep 2021 17:36:14 +0000

Model–View–Controller is a popular software pattern used to break up the logic of your application into three different components.

In this article, I will break down the three components behind the MVC pattern, provide some history, and show you how it can be used in an application.

History of the Model–View–Controller Pattern

The MVC pattern was first introduced in 1979 by computer scientist Trygve Mikkjel Heyerdahl Reenskaug. He wanted to come up with a solution on how to break up a complex user application into smaller manageable components.

The MVC pattern was first used in the programming language Small Talk. One of the original names for the pattern was going to be Model-View-Editor but it was changed to Model-View-Controller.

Throughout the 1980's and early 90's, the MVC pattern was primarily used in desktop applications. But by the late 1990's, it became pretty popular within web applications.

In today's web applications, the MVC pattern is a popular design choice for organizing your code.

Here is a list of a few popular web frameworks that use the MVC pattern.

Ruby on Rails
ASP.NET MVC
Laravel
Angular

What are the three components behind the Model–View–Controller?

This is a basic breakdown of the MVC pattern:

Model – This is responsible for the data logic behind the application
View – This is what the user sees and interacts with in the application
Controller – This acts as the brains behind the application and communicates with the Model and View.

How does the MVC pattern work in a web application?

To better understand how the MVC pattern works, it would be best to show you in a demo application.

This MERN (MongoDB, Express, React, Node) stack application greets a fictional office manager and shows them a table of recently hired high school coaches.

It also shows which coaches have not completed their TB tests, Covid vaccines, new coach application, and background checks.

The office manager can send reminder emails to those coaches who are missing their documents.

The Model Component

The Model is responsible for the data logic of our application. I am using MongoDB for the database of coaches.

I first had to define the properties that will be applied to each coach in the database. Each coach will have a name, email, program, application, backgroundCheck, tbTest and covidTest.

const coachSchema = new Schema({
    name: {
        type: String,
        trim: true,
        maxLength: 32,
        required: true
    },
    email: {
        type: String,
        trim: true,
        maxLength: 32,
        required: true,
        unique: true
    },
    program: {
        type: String,
        trim: true,
        maxLength: 32,
        required: true
    },
    application: {
        type: Boolean,
        required: true
    },
    backgroundCheck: {
        type: Boolean,
        required: true
    },
    tbTest: {
        type: Boolean,
        required: true
    },
    covidTest: {
        type: Boolean,
        required: true
    }
}, { timestamps: true })

type:Boolean represents a true or false value for the application, backgroundCheck, tbTest and covidTest properties.

If the coach has any of those four properties marked as false, then that means they haven't completed that part of the application process.

I created seven entries for our coach database and that information is being stored in MongoDB Atlas.

Here is an example of one of the database entries.

The Controller component is going to communicate with the database and get the necessary information to send to the View component.

The View Component

The View component is responsible for all of the visual aspects of the application. I used React to display this data to the user.

When the application first loads, you see a welcome message displayed on the screen.

When you click on the View Dashboard button, it takes you to the coaches table and missing documents list.

The View is not communicating directly with the database because our Controller is doing that. The Controller provides that information to the View so it can be displayed on the page.

This is what the code looks like when the View makes a fetch call to get the data from the Controller:

await fetch('https://mvc-project-backend.herokuapp.com/coaches')

We then use the map() method to go through each coach and display their name, email address, and program in the table.

    coachData.map(data => (
                        <tr key={data._id}>
                          <td>{data.name}td>
                          <td>{data.email}td>
                          <td>{data.program}td>
                        tr>
                      ))

For the missing documents section, we fetch data from the backend to get the list of coaches who are missing applications, TB tests, Covid vaccines and Background Checks.

We use the map() method again to display the names for each category.

When the Send reminder email button is clicked, that information is sent from React to the backend. The Controller is responsible for sending the email and communicating with the View on whether or not the message went through.

Based on the information it receives from the Controller, the View will display a success message or failure message to the user.

The Controller Component

The Controller communicates with both the Model and View components and takes care of all the logic for our application. This section of the code was built in Node.JS and Express.

The Controller is going to get that complete list of coaches from the Model and send that information to the View.

The Controller is also responsible for filtering through the Model and providing the lists of coaches who have not completed the four missing document categories.

All of that data is sent to the View so it can be displayed to the user.

For the email functionality, the Controller is responsible for checking to make sure the sender's email is valid before sending the email.

I used Nodemailer here to send the emails.

   transporter.sendMail(mailOptions, (err) => {
        if (err) {
            console.log(`Applications: There was an error sending the message: ${err}`)
            res.json({ status: 'Email failure' })
        } else {
            console.log(`Applications Success: Email was sent`)
            res.json({ status: "Email sent" });
        }
    })

If the email was successful in going through, then the user is notified and the email message shows up in the demo email account.

If there is an error in sending the message, then the Controller will send that information to the View so the error message can be displayed to the user.

Conclusion

Model–View–Controller is a popular software pattern used to break up the logic of your application into three different components.

While the MVC pattern was initially used in desktop applications, it became popular to use in web applications during the late 1990's.

The Model is responsible for the data logic behind the application.

The View is what the user sees and interacts with in the application.

The Controller acts as the brains behind the application and communicates with the Model and View.

Web frameworks that use the MVC pattern include, Ruby on Rails, ASP.NET MVC, Laravel, and Angular.

Dynamic Navigation in Next.js – How to Render Nav-Items Dynamically in a Next App

freeCodeCamp — Thu, 16 Sep 2021 17:32:33 +0000

By Caleb Olojo

I've lately been noticing a pattern in React applications: developers protect certain routes on a web app from unauthorized users.

In such cases, the navigation item (nav-item) on the navigation bar/Header of the web won't be visible to an unauthorized user.

In this short guide, we're going to take a look at how to do this in NextJS. We are going to render a nav-item dynamically on the navigation bar of a simple webpage that we'll be building here.

Prerequisites

Before you read this article any further, you should have some basic knowledge of:

How React works
NextJS, a production ready framework of React.
Conditional rendering in React.
PropTypes checking in React
import and export statements in JavaScript. You can take a look at this article to get familiar with it.

Getting Started

Since this article focuses on Next.js, we'll start by creating a Next.js project. Type the command below in your terminal to install it:

npx create-next-app [name-of-your-webapp/website]

The command above gets all the dependencies we need to get our Next app up and running in no time.

Keep in mind that the file structure of a Next app is quite different from the ubiquitous create-react-app architecture.

Let's take a look at the important files that we will be interacting with in this article:

|--pages
|   |-- _app.js
|   |-- index.js
|   |-- about.js
|   |-- blog.js
|   |__ services.js
|--src
|   |-- components
|   |      |-- Header.js
|   |      |__ NavItem.js 
|   |-- data.js
|__

The file structure above is an excerpt of the files in the Next.js app architecture. Now let's see what's going on here.

The Components in Our Next.js App

We'll take a look at all the components you see above and their roles. We'll start by breaking down the files in the pages folder.

_app.js: this is the root file of the code base. It is quite like the index.js file in create-react-app. Here, you can apply any global style(s), add new themes, provide context to the whole application, and so on.

import Head from "next/head";
import React from "react";

function MyApp({ Component, pageProps }) {
  return (
    <React.Fragment>
      <Head>
        <meta name="theme-color" content="#3c1742" />
      Head>
      <Component {...pageProps} />
    React.Fragment>
  );
}

export default MyApp;

The snippet above shows the content of _app.js. The Head component that gets imported from "next/head" is so we can add document titles to the unique pages and a lot of meta tags for the sake of SEO.

index.js: Nextjs abstracts away the need to start using BrowserRouter from the react-router-dom library to set up the routes in your applications. Instead, any file that is inside the pages folder becomes a route. index.js becomes accessible at https://localhost:3000/ once we start the development server with npm run dev.

You might notice that we've already imported the Header component from the src/component folder. Do not fret. We'll get to that section soon.

import Head from "next/head";
import Header from "../src/components/Header";

export default function Home() {
  return (
    <>
      <Head>
        <title>Caleb's article examplestitle>
        <link rel="icon" type="image/ico" href="/img/goals.ico" />
      Head>
      <Header />
      <section>
        <h1>Home Pageh1>
        <section id="contact">
          <h3 className="section-title">Contact Ush3>
          <p className="section-body">
            You can Contact us via our various social media handles
          p>
        section>
      HomeWrapper>
    
  );
}

The remaining page components: about.js, blog.js and services.js can be accessed at http://localhost:3000/about, http://localhost:3000/blog and http://localhost:3000/about respectively

How to Map Array Items onto the Header Component

Instead of hard-coding the user interface of the nav-bar, we can use JavaScript's map() function to render a list of items on the Header component.

To do this, we need to move into the data.js file in the src: source folder. We'll create an array of objects that will hold the information or items that we would like to render.

The snippet below shows the list of items we want to render. Notice that the last object has a path property that is quite different from the others. Instead of a "/contact" value, it has a "#contact" value. This is because the contact section is on the home page.

export const navLinks = [
  { name: "Home", 
   path: "/" 
  },
  {
    name: "About Us",
    path: "/about",
  },
  {
    name: "Services",
    path: "/services",
  },
  {
    name: "Blog",
    path: "/blog",
  },
  {
    name: "Contact Us",
    path: "#contact",
  },
];

Let's continue on to create the Header component by mapping the array of objects that we have in data.js. To do that, we have to import the array from that file so we can have access to its properties.

import React from "react";
import { navLinks } from "../utils/data";
import Link from "next/link";

export default function Header() {
  return (
    <header>
      <div className="brand">
        <h3>Exampleh3>
      div>
      <nav>
        {navLinks.map((link, index) => {
          return (
            <ul>
              <Link href={link.path}>
                <li key={index}>{link.name}li>
              Link>
            ul>
          );
        })}
      nav>
    header>
  );
}

With what we have in the snippet above, if we click on the "Contact Us" nav-item, the current route will be: https://localhost:3000/#contact.

The browser scrolls to the HTML element that has an id of "contact". If there isn't any such section, nothing is being scrolled to in the viewport.

That is why we need to render this particular nav-item only on pages that have the corresponding section. Let's take a look at how to achieve that in the next section.

How to Conditionally Render the Nav-Item with the Next.js `useRouter` Hook

We have to know when another page/route is currently active or "in-view" in a browser tab so that we can set a condition for rendering the nav-item in the appropriate page.

Fortunately for us, Next's useRouter hook lets us do that. Let's see how:

import React from "react";
import { useRouter } from "next/router";
import propTypes from "prop-types";

const NavItem = ({ item }) => {
  const router = useRouter();
  return <>{router.pathname === "/" ? item : ""};
};

export default NavItem;

// proptypes check
NavItem.propTypes = {
  item: propTypes.string,
};

The snippet above is quite straightforward. We're passing item as props to the NavItem component so that it makes it dynamic to use in any case, not for the contact nav-item only.

See how we assigned the useRouter() hook to the router variable? With that, we can access the properties of the hook itself. You can read about the properties of the hook here.

router.pathname === "/" ? item : ""

The ternary operation above checks if the pathname of the page is equal to the homepage, that is "/".

If the result is true, it assigns the value as props to the component (which will always be a string, because of the prop validation check). If not, it assigns an empty string to the component, which in turn ends up as nothing in the Header component.

Final Touches

Now, let's edit the last item in the navLinks array to look like the following:

import NavLink from "./NavLink";

export const navLinks = [
  { name: "Home", 
   path: "/" 
  },
  {
    name: "About Us",
    path: "/about",
  },
  {
    name: "Services",
    path: "/services",
  },
  {
    name: "Blog",
    path: "/blog",
  },
  {
    name: <NavLink item="Contact Us" />,
    path: "#contact",
  },
];

Conclusion

Here's the end result of what we've been building. You'll see that I added some content to illustrate the smooth scroll behaviour to the contact section.

At the click event of the other routes, the contact nav-item isn't on the Header anymore.

Thank you for reading this article! I hope it has helped you gain insight on how to render UI dynamically, based on certain conditions. Kindly share this piece with your peers.

Laravel Subdomains – How to Create and Manage Subdomains in Your Apps

Zubair Idris Aweda — Thu, 16 Sep 2021 17:19:06 +0000

Modern web applications usually perform more than one function. They often have more than one section, offer more than one service, and have a couple of clients.

But the more functionality the app has, the clumsier your route paths will get.

What if there was a way to separate all these parts into smaller components with better and cleaner routes? Something that users could easily access and use independently, under the same website?

Fortunately, there is such a way: Subdomains.

What is a Subdomain?

Credit: Electroica Blog

Here's a basic definition of a subdomain:

A subdomain is, as the name would suggest, an additional section of your main domain name. You create subdomains to help organize and navigate to different sections of your main website. Within your main domain, you can have as many subdomains as necessary to get to all of the different pages of your website.

So let's say you have a website called mysite.com. You have a blog section, a store section, and a general website section for about and contact pages. The website could have subdomains like blog.mysite.com and store.mysite.com, where the main website would use the main domain.

Why Should You Use Subdomains?

Subdomains are pretty useful, and here are some of their main advantages:

Users can easily remember you website domains, which means they'll likely use your site more.
You'd be able to split your large application into smaller groups, so it will be easier to manage, debug, and update or upgrade.
Subdomains also allow for personalisation – for example, a blog app could give each user their own subdomain (like username.domain.com).
Subdomains also let developers test version of their application before pushing to production. You could have a beta.site.com to preview changes before deploying them to the main site.

Let's see how all this works by building an actual project and testing it out.

How to Create New Laravel Project

I have Docker setup on my laptop, so I'll be using the Sail setup that Laravel ships with.

curl -s "https://laravel.build/example-app" | bash

You can use any other method you feel comfortable with. See the docs for help.

Start the Laravel Server

./vendor/bin/sail up -d

How to Configure the Route Files

In your web.php file, you can define individual routes with their domain (or subdomain) like this:

Route::get('/', function () {
    return 'First sub domain';
})->domain('blog.' . env('APP_URL'));

Now you can access the page at blog.domain.com.

But more often than not, you'll have more than one path in an application, like a domain and subdomains. So, it's a good idea to use a route group to cover all the routes in the same domain or subdomain.

Route::domain('blog.' . env('APP_URL'))->group(function () {
    Route::get('posts', function () {
        return 'Second subdomain landing page';
    });
    Route::get('post/{id}', function ($id) {
        return 'Post ' . $id . ' in second subdomain';
    });
});

Now, all the routes for the domain can be handled in one place.

How to Make Subdomains Dynamic

As I mentioned earlier, you can use subdomains to allow personalisation in web applications, so they need to be dynamic. For example, Medium gives authors domains like username.domain.com.

You can do this easily in Laravel as subdomains may be assigned route parameters just like route URIs. This allows you to capture a portion of the subdomain for usage in your route closure or controller.

Route::domain('{username}.' . env('APP_URL'))->group(function () {
    Route::get('post/{id}', function ($username, $id) {
        return 'User ' . $username . ' is trying to read post ' . $id;
    });
});

In this example, you could have a domain like zubair.domain.com with route parameters, too.

Route Service Providers

For very large applications, the web.php could get a bit messy if the routes keep increasing. It is best to split the routes into different files, preferably by subdomain.

In your RouteServiceProvider.php file, you'll see this code in the boot method:

public function boot()
    {
        $this->configureRateLimiting();

        $this->routes(function () {
            Route::prefix('api')
                ->middleware('api')
                ->namespace($this->namespace)
                ->group(base_path('routes/api.php'));

            Route::middleware('web')
                ->namespace($this->namespace)
                ->group(base_path('routes/web.php'));
        });
    }

This is Laravel's default route configuration to separate API routes from web routes. We'll use this same file to separate subdomains.

Add the following to the method:

Route::domain('blog.' . env('APP_URL'))
                ->middleware('web')
                ->namespace($this->namespace)
                ->group(base_path('routes/blog.php'));

This is telling Laravel that whenever someone hits the blog.domain.com endpoint, look for the route in the blog.php (that we are yet to create).

We can go on to create the blog.php file in the routes folder, and add the following content:



use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return 'Route using separate file';
});

At this point, you're done with all the code! All that's left is some server configuration.

Server Configuration

If you're using a service such as Laravel Valet, it is way easier to setup.

In the root directory of your project, run:

valet link domain
valet link blog.domain

And if you're not using Laravel Valet, you can add this to your /etc/hosts/ file:

127.0.0.1       domain.test
127.0.0.1       blog.domain.test

This is basically just mapping the domain to the IP.

Summary

Now you know how to set up and manage subdomains in your Laravel apps. You can find all the code for this article here.

If you have any questions or relevant advice, please get in touch with me to share them.

To read more of my articles or follow my work, you can connect with me on LinkedIn, Twitter, and Github. It’s quick, it’s easy, and it’s free!

Web Applications - freeCodeCamp.org

How to Perform Performance Testing on Your Web Applications

Prerequisites:

Table of Contents:

What is Performance Testing?

Examples of Performance Testing Tools

Jest

Mocha

Pythagora

Artillery

Ava

Loadtest

Apache J-meter

Demo Project

Install Jest

Configure package.json

Set up the test environment

Run the unit tests

Conclusion

How to Build Web Apps with Nuxt and Laravel

Table of Contents:

Prerequisites

How to Set Up Laravel on Your Machine

How to Build the Book Library API

Setting up the database

Creating the Book model

Creating the Book controller

Defining the API Routes

Testing the API

Creating a new book

Getting a list of books

Editing a book

How to Build the Nuxt Frontend

{{ book.title }}

How to Integrate the Laravel API in the Frontend

Getting all books in the library

Creating a new book

Editing a book

Deleting a book

Conclusion

Resources

How to Work with Third-Party APIs in React by Building a Crypto Exchange Rate Web App

Table of Contents

Prerequisites

How to Set Up the Project

Initialize a new React project

Install the necessary dependencies

Set up your project structure

How to Build the UI

How to Fetch Data with React Query

How to Display the data in the UI

Error Handling

Conclusion

Additional resources

How to Deploy Your Websites and Apps – User-Friendly Deployment Strategies

What we'll cover:

What to Consider when Deploying to a Hosting Platform

Why is Deploying an Application Important?

What's the Benefit of Choosing a User-Friendly Deployment Method?

How to Deploy a Website or App with Render

Pros of Deploying With Render

Cons of Deploying With Render

How to Deploy a Website or App with Surge

Steps to Deploy Your Site Using Surge

Pros of Deploying with Surge

Cons of Deploying with Surge

How to Deploy a Website or App with Vercel

Steps to Deploy Your Site Using Vercel

Pros of Deploying With Vercel

Cons of Deploying With Vercel

How to Deploy a Website or App with GitHub Pages

Steps to Deploy Your Site Using GitHub Pages

Pros of Deploying With GitHub Pages

Cons of Deploying With GitHub Pages

How to Deploy a Website or App with Netlify

Steps to Deploy Your Site Using Netlify

Using the Drag-n-Drop feature:

Importing the source code from your repository to the site:

Pros of Deploying with Netlify

Cons of Deploying With Netlify

Configure `package.json`

Creating buttons by using `div` instead of `button`:

Using CSS to fake headings instead of using `h1-6` tags:

let an assitive technology know that this is important text, and the screen reader will announce "Heading".

When you use CSS to make a heading instead of using correct semantics, the significance of the text is lost to a screen reader.

So just make sure to use semantic HTML whenever possible.

What is the `aria-role` attribute?