Forem: Cherif Bouchelaghem

Dependency Injection without classes

Cherif Bouchelaghem — Sat, 06 Jan 2024 10:17:10 +0000

Dependency Injection (DI) is a pattern that enhances the maintainability, scalability, and testability of your code. In TypeScript, we can leverage higher-order functions to implement Dependency Injection seamlessly, promoting a more modular and flexible codebase.

While it may sound like a complex pattern, many tools out there make it look very complicated. However, the reality is that DI is simply passing parameters, mostly to the constructor. As Rúnar Bjarnason casually once said, dependency injection is "really just a pretentious way to say 'taking an argument.'"

To provide a short and easy example, let's imagine we are working on a cab (taxi) Uber-like application. We've received a request to implement a rides pricing feature. For the sake of this article, the only rule is that the price of a ride must be $2 per kilometer for a given route.

Example

The distance from my house address to the airport is 20 KM for the available itinerary.
The price returned by the application should be 20 * 2 = $40.

We'll follow the domain model:

type Address = {
  street: string;
  city: string;
}

type Route = {
  origin: Address;
  destination: Address;
};

type Itinerary = {
  route: Route;
  distance: number;
}

type PricedRide = {
  itinerary: Itinerary;
  price: number;
}

However, the implementation of the ride pricing feature needs to know the itinerary to calculate the price based on the distance. The route itinerary can be fetched using a third-party service like Google Maps, Google Addresses, or others. Let's assume we haven't made a decision on which service to use.

Implementation using class-based Dependency Injection:

Since the itinerary 3rd-party service provider is not known yet, we can abstract it behind an interface and inject it into the class that calculates the price as a constructor parameter, like the following:

interface ItineraryService {
  getItinerary(route: Route): Promise<Itinerary>
}

class RideService {
  constructor(private itineraryService: ItineraryService) {}

  async priceRide(route: Route): Promise<PricedRide> {
    const itinerary = await this.itineraryService.getItinerary(route)
    const price  = itinerary.distance * 20;
    return {
      itinerary,
      price
    }
  }
}

Let's break down the code above

ItineraryService is an interface that exposes the getItinerary method signature. The implementation details of that interface can be done once a decision is made on what itinerary service provider to use, or even use a fake implementation.
RideService class has a constructor that takes an ItineraryService implementation instance. It doesn't matter what the concrete implementation to use is since it respects the interface contract.
RideService exposes the priceRide method that takes a Route object and returns a promise of a PricedRide object after getting an itinerary for the passed route.

I kept the code short by removing some details like error handling.

Towards function-based DI

Now let's try to get rid of that verbose class-based version and replace it with another version that uses just functions. Since DI is basically passing parameters and functions are first-class citizens in JavaScript and TypeScript, we can just use a function to calculate the price and pass the itinerary fetching dependency as a function as well. The class-based code can be refactored to:

const priceRide = async (route: Route, getItinerary: Function): Promise<PricedRide> => {
  const itinerary = await getItinerary(route)
  const price  = itinerary.distance * 20
  return {
    itinerary,
    price
  }
}

The code is now shorter and simpler, isn't it?

We have a small issue in the function implementation above: getItinerary function type accepts any function. Let's fix this by adding the following type to our domain model:

type GetItinerary = (route: Route) => Promise<Itinerary>

Dependencies First, Data Last

If we want to mimic the class-based approach, we can just FLIP the order of the priceRide function arguments like the following:

const priceRide = async (getItinerary: GetItinerary, route: Route) => {
  const itinerary = await getItinerary(route)
  const price  = itinerary.distance * 20
  return {
    itinerary,
    price
  }
}

Flipping the arguments order as above is more of a functional style, where the input data are always set as the last function argument. This will allow us to partially apply priceRide.

Partial application

It is a functional programming concept that can be applied to create a new function by just passing some arguments to a function. For example, we can use lodash.partial to get a new function from our priceRide like the following:

const partialPriceRide = _.partial(priceRide, getItinerary) // create a function with a dependency
async partialPriceRide(route) // -> ride price

Where getItinerary and route are concrete implementations.

This is exactly the steps to make to use the class-based version:

const rideService = new RideService(itineraryService) // create an object with a dependency
async rideService.priceRide(route) // -> ride price

Great! Now, since partial application is a function that returns a function, instead of using lodash to create our priceRide function, we can define the function like the following:

const priceRide = (getItinerary: GetItinerary): PriceRide => async (route: Route): Promise<PricedOrder> => {
  const itinerary = await getItinerary(route)
  const price  = itinerary.distance * 20
  return {
    itinerary,
    price
  }
}

We need to add PriceRide function definition to the domain model:

type PriceRide = (route: Route) => Promise<PricedRide>

The function now returns a function instead of a promise of PricedRide by taking all dependencies as parameters.
The returned function returns a promise of PricedRide and uses the dependency to fetch an itinerary.
Since priceRide creates a closure, all dependencies are accessible for the returned functions but private for the outside world (like in the class-based version).

Runtime configuration checking

We can take advantage of the priceRide function and add a runtime check that verifies that the passed GetItinerary parameter is really a function:

const priceRide = (getItinerary: GetItinerary): PriceRide => {
  if (typeof getItinerary !== "function") throw new TypeError("Get Itinerary is not a function")
  return async (route: Route): Promise<PricedRide> => {
    const itinerary = await getItinerary(route)
    const price  = itinerary.distance * 20
    return {
      itinerary,
      price
    }
  }
}

The major downside of this approach is that the function creates a closure for every call, which means a new object is created every time we call the function, however this can avoided by calling the function once at the composition root level which will be a topic for another article.

Creating a Ktor Server with Gradle and SDKMAN!: A Step-by-Step Guide

Cherif Bouchelaghem — Sat, 08 Jul 2023 16:25:11 +0000

Ktor, a powerful web framework built with Kotlin, offers a lightweight and flexible solution for building web applications. In this article, we will guide you through the process of creating a Ktor project manually using Gradle and SDKMAN!.
By following the steps below, you'll have a basic Ktor project up and running in no time.

Prerequisites:

Before getting started, make sure you have the following installed on your machine:

Java Development Kit (JDK)
SDKMAN! (Software Development Kit Manager)

Step 1: Install SDKMAN!

SDKMAN! is a convenient tool for managing multiple software development kits, including Gradle. Follow the installation instructions provided at https://sdkman.io/install to install SDKMAN! on your machine.

Step 2: Install Gradle using SDKMAN!

Once SDKMAN! is installed, open a new terminal or command prompt window and run the following command to install Gradle:

sdk install gradle

Step 3: Initialize a New Project Directory

Create a new directory for your Ktor project. Choose a suitable name for your project and navigate to the project directory in your terminal or command prompt.

Step 4: Initialize a Gradle Project

Inside the project directory, run the following command to initialize a new Gradle project:

gradle init --type kotlin-application

This command initializes a new Gradle project with Kotlin support, creating the necessary project structure which looks similar to the following:

.
└── the_app_folder/
    ├── .gradle
    ├── app/
    │   ├── src/
    │   │   ├── main
    │   │   └── test
    │   └── build.gradle.kts
    ├── gradle
    ├── .gitattribute
    ├── .gitignore
    ├── gradlew
    ├── gradlew.bat
    └── settings.gradle.kts
        └── settings.gradle.kts

Step 5: Configure the Gradle Build

Open the build.gradle.kts (or build.gradle) file in a text editor. Modify the file to include the necessary dependencies and plugins for Ktor. Here's an example of a basic configuration:

/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Kotlin application project to get you started.
 * For more details take a look at the 'Building Java & JVM projects' chapter in the Gradle
 * User Manual available at https://docs.gradle.org/7.5.1/userguide/building_java_projects.html
 */

plugins {
    // Apply the org.jetbrains.kotlin.jvm Plugin to add support for Kotlin.
    id("org.jetbrains.kotlin.jvm") version "1.8.21"

    // Apply the application plugin to add support for building a CLI application in Java.
    application
    // add ktor gradle plugin
    id("io.ktor.plugin") version "2.3.2"
}

repositories {
    // Use Maven Central for resolving dependencies.
    mavenCentral()
}

dependencies {
    // Align versions of all Kotlin components
    implementation(platform("org.jetbrains.kotlin:kotlin-bom"))

    // Use the Kotlin JDK 8 standard library.
    implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")

    // This dependency is used by the application.
    implementation("com.google.guava:guava:31.0.1-jre")

    // Use the Kotlin test library.
    testImplementation("org.jetbrains.kotlin:kotlin-test")

    // Use the Kotlin JUnit integration.
    testImplementation("org.jetbrains.kotlin:kotlin-test-junit")

    // add ktor dependencies
    implementation("io.ktor:ktor-server-core")
    implementation("io.ktor:ktor-server-netty")
    implementation("ch.qos.logback:logback-classic:1.2.11")
}

application {
    // Define the main class for the application.
    mainClass.set("<your-package-name>.AppKt")
}

Step 6: Create the Application Entry Point

Create a new Kotlin file in the src/main/kotlin directory with the name Application.kt. Inside the file, add the following code:

/*
 * This Kotlin source file was generated by the Gradle 'init' task.
 */
package sdkman.gradle.ktor.tut

import io.ktor.server.application.*
import io.ktor.server.response.*
import io.ktor.server.routing.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*

fun main() {
    embeddedServer(Netty, port = 8080) {
        routing {
            get("/") {
                call.respondText("Hello, Ktor!")
            }
        }
    }.start(wait = true)
}

This code sets up a simple Ktor application with a single route that responds with "Hello, Ktor!" when accessing the root URL.

Step 7: Run the Application

In the terminal or command prompt, navigate to the project directory and run the following command to start the Ktor application:

gradle run

Congratulations! You have successfully created a Ktor project using Gradle and SDKMAN!. Your Ktor application is now running and accessible at http://localhost:8080. Feel free to explore and customize the project based on your specific requirements.

Conclusion:

In this article, we walked through the step-by-step process of creating a Ktor project manually using Gradle and SDKMAN!. By leveraging SDKMAN!, you can easily manage your Gradle installation, ensuring you have the latest stable version. Combine Gradle's powerful build capabilities with Ktor's flexible features to build robust and scalable web applications with ease. Happy coding with Ktor, Gradle, and SDKMAN!!

Using Docker for Slim 4 application development environment

Cherif Bouchelaghem — Sun, 22 Aug 2021 16:59:59 +0000

In the first part of the series we write a small Slim 4 application to know how the framework works, however in real world applications we need to know how to deal with more complicated problems instead of printing a message on a web page.

I believe, as software developers we need to prepare the work environment first and because we have a number of environments where the code we wrote will be running we need to be sure that those environment characteristics are common to minimize the number of surprises.

Also, as team members, having the same development environment could be helpful to ensure we are all having the same results without any impact from the local environment.

Fortunately, Docker can help to achieve those goals.

Create docker directory

Create a new directory named docker, this directory will contain Docker containers definitions and doesn’t have to be named docker:



$ mkdir docker

Define a PHP 8 container

1- Inside the docker directory, add a new subdirectory named php:



$ mkdir -p docker/php

2- Create a new Dockerfile (yes without extension) file



touch docker/php/Dockerfile

Open the php Dockerfile and add the following instructions:



FROM php:8.1-fpm

RUN apt update \
    && apt install -y zlib1g-dev g++ git libicu-dev zip libzip-dev zip libpq-dev \
    && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \
    && docker-php-ext-install intl opcache pdo pdo_pgsql \
    && pecl install apcu \
    && docker-php-ext-enable apcu \
    && docker-php-ext-configure zip \
    && docker-php-ext-install zip

WORKDIR /var/www/slim_app

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

RUN git config --global user.email "you@example.com" \
    && git config --global user.name "Your Name"

Note: Make sure to replace git credentials in the last two lines with your git credentials

The instructions above will scaffold a PHP container from a PHP 7.4 FPM image and:

Install PHP extension that our Slim application depends on
Sets the working directory of the container to /var/www/slim_app
Install composer

Define a NGINX web server container

Unlike the PHP image, only NGINX default configuration is needed inside a subdirectory in docker directory:

Add new `nginx` directory:



$ mkdir -p docker/nginx

Add the default configuration file:



$ touch docker/nginx/default.conf

Edit docker/nginx/default.conf with the following:



server {

    listen 80;
    index index.php;
    server_name localhost;
    root /var/www/slim_app/public;
    error_log /var/log/nginx/project_error.log;
    access_log /var/log/nginx/project_access.log;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\\.php(/|$) {
        fastcgi_pass php:9000;
        fastcgi_split_path_info ^(.+\\.php)(/.*)$;
        include fastcgi_params;

        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;

        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;

        internal;
    }

    location ~ \\.php$ {
        return 404;
    }

}

This is the simplest NGINX required configuration to run a PHP application, note that it maps fastcgi_pass to port 9000 in the PHP container we defined previously.

Let’s compose the containers images

To use the PHP and NGINX defined containers we need to create docker-compose.yml in the root folder of the application:



version: "3.8"

services:
  php:
    container_name: slim_php
    build:
      context: ./docker/php
    ports:
      - '9000:9000'
    volumes:
      - .:/var/www/slim_app

  nginx:
    container_name: slim_nginx
    image: nginx:stable-alpine
    ports:
      - '8080:80'
    volumes:
      - .:/var/www/slim_app
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - php

Let see what we have here for the PHP container:

Unlike the NGINX container configuration, PHP container doesn’t have an image key but a build context in order to use the docker/php/Dockerfile to build the container.
Port 9000 of the computer is mapped to 9000 of the container
Volumes is declared to store the data generated by the container, in the case of this example it will store the Slim application code in the project.

For NGINX

nginx:stable-alpine will be pulled from the docker-hub to build the container.
The port 8080 of the computer is mapped to port 80 of the container.
Declare the required volumes to persist the NGINX default configuration file and the PHP code for the application.

Build the containers

Run the following command to build the containers:



$ docker-compose up -d --build

Once containers are successfully built the terminal should print message like the following screenshot:

To make sure that the containers are up and running open the Docker Desktop app, it should shows that the containers are running like in the screenshot below:

It is possible to use the command line to know the status of the containers:



$ docker ps

Should print something like:

Now if you visit the URL localhost:8080, put the port you configured for NGINX, should run the Slim application we built in the first part.

GitHub repository has the code in this part in development-environment-part-2.

Introducing Slim 4

Cherif Bouchelaghem — Fri, 20 Aug 2021 20:45:52 +0000

Slim framework is a PHP micro framework that could be used to write web applications and web services APIs, unlike other known frameworks like, Symfony, CakePHP or Laravel, Slim doesn’t have any opinion on what templating engine or what ORM should be used, all it provides is a routing system that takes a web request and returns a response depending on the application logic behind the route.

Application initialization using Composer

The article assumes that composer is already installed and the reader knows how to use it in the command line.

$ mkdir slim-from-scratch && cd slim-from-scratch

$ composer init

Is it possible to leave the default answers for the composer questions in the command line.
A composer.json file should be created with the entered value from the command line.

Configure classes autoloading in composer.json

Depending on the composer installed version, a src folder can be created and the autoloading is configured, form me is:

{
    "name": "cherif/slim-from-scratch",
    "autoload": {
        "psr-4": {
            "Cherif\\SlimFromScratch\\": "src/"
        }
    },
    "authors": [
        {
            "name": "Cherif BOUCHELAGHEM",
            "email": "cherif.bouchelaghem@gmail.com"
        }
    ],
    "require": {}
}

The autoloading should be added as above, if the autoloading was not generated automatically, just change Cherif which is my vendor name by your vendor name.

Once the autoload key in composer is configured the following command must be run in order to expose our code to compose autoloader:

$ composer dumpautoload

Install Slim 4

Installing Slim framework 4 is easy as running the following command:

$ composer require slim/slim

The first request handler

In its heart Slim 4 is a PSR-15 middleware dispatcher, it takes a PSR-7 request message and returns a PSR-7 response message using a request handler.
The request handler is just a callback function for a given route that could be in the following signature:

function (RequestInterface $request, ResponseInterface $response, array args) {
// Do whatever we want with the request and return a response
}

Note, RequestInterface and ResponseInterface are provided by the PSR package.

To see this in action, create a public folder in the project root and add an index.php file that will act as the main file for the Slim application.
For now the index.php can have the following code:

require dirname(__DIR__) . '/vendor/autoload.php';

use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;
use Slim\Factory\AppFactory;

$app = AppFactory::create();

$app->get('/', function (RequestInterface $request, ResponseInterface $response, array $args) {
    $response->getBody()->write('Hello from Slim 4 request handler');
    return $response;
});

$app->run();

The code above is short and self explanatory:

The use … is for the dependencies.
$app = AppFactory::create(); is where the Slim application is instantiated
app->get ... is to configure the routes, here we have just a one GET route.
$app->run runs the application and returns a response.

To run the application use your local web server of choice.
I like to use the PHP built in static server like the following:

$ php -S localhost:8000 -t public

The command line is executed from the root folder of the application to point the server to the public directory.
When visiting http://localhost:8000/ in the browser an exception should be throwing in the console saying:

 Uncaught RuntimeException: Could not detect any PSR-17 ResponseFactory implementations. Please install a supported implementation in order to use `AppFactory::create()`.

The exception says that Slim could not be run without providing a PSR-17 implementation, let’s install one.

Install `laminas/laminas-diactoros` for PSR-7 and PSR-17 implementations

PSR-7 and PSR-17 are PHP HTTP messages standards proposed by the community; we can find several implementations for them out there.
laminas/laminas-diactoros is one of the implementations that I usually use, it can be installed using composer as the following:

$ composer require laminas/laminas-diactoros

Now, when the browser page is refreshed, the application response Hello from Slim 4 request handler should be printed.

The source code of this article can be found in GitHub.

That’s it.

Using JavaScript Symbol.toStringTag for objects types description

Cherif Bouchelaghem — Tue, 04 May 2021 13:42:10 +0000

A day ago I asked my developers friends:

How to know a JavaScript object literal type?

Most of the answers of the answers suggested to use instanceof, while this answer works for objects created by using a constructor, it can not work with objects literals or maybe for some reasons developers don't export the object constructor from the module but they provide a factory with object initializer instead.

The use case:

The question was about the following use case:

const user = {
   username: 'johndoe',
   firstname: 'John',
   lastname: 'Doe'
};

It is hard to determine if the object above is in certain type without checking the presence of all the properties, imagine if we have a more than 10 properties or more, it would be exhausting, right?
It is obvious it would be good if we can know that the object is indeed in User type just by a single call.

Using Object.prototype.toString() gives the object type inside square brackets for the built-in types/objects:

console.log(Object.prototype.toString.call(1)); // -> '[object Number]'
console.log(Object.prototype.toString.call('Cherif')); // -> '[object String]'

Or:

const one = 1;
const name = 'Cherif';

console.log(one.toString()); // -> '[object Number]'
console.log(name.toString()); // -> '[object String]'

But for a developer defined objects it gives a [object Object] result, a generic object:

const user = {
   username: 'johndoe',
   firstname: 'John',
   lastname: 'Doe'
};

console.log(user.toString()); // -> '[object Object]'
console.log(Object.prototype.toString.call(user)); // -> '[object Object]'

Symbol.toStringTag to the rescue

Fortunately with the introduction of ES6 Symbols a number of built-in symbols had seen the day make it possible to describe custom objects type by overriding Object.prototype.toString() using Symbol.toStringTag, so to describe a type for our user object we can do the following:

const user = {
   username: 'johndoe',
   firstname: 'John',
   lastname: 'Doe',
   get [Symbol.toStringTag]() {
       return 'User'; // The string tag description
   }
};

console.log(user.toString(user)); // -> '[object User]'
console.log(Object.prototype.toString.call(user)); // -> '[object User]'

Read the string using Symbol.toStringTag:

I would advice to make the check using the Symbol property by using user[Symbol.toStringTag], like this we have the possibility to override toString function for other purposes, and we can just have User string from the string tag instead of [object User] example:

const user = {
   username: 'johndoe',
   firstname: 'John',
   lastname: 'Doe',
   get [Symbol.toStringTag]() {
       return 'User'; // The string tag description
   },
   toString() {
       return `${this.firstname} ${this.lastname}`;
   }
};

console.log(user[Symbol.toStringTag]); // -> "User"
console.log(user.toString()); // -> "John Doe"

All the code examples are in the following CodePen:

See the Pen Symbol.stringTag by Mohamed Cherif Bouchelaghem
(@cherifGsoul) on CodePen.

I hope you find this article useful and helpful, let me know your thoughts in the comments below.

Simulating API responses in VueJS applications using fixtures

Cherif Bouchelaghem — Wed, 04 Mar 2020 16:48:23 +0000

Building frontend web application depends on getting and submitting data from/to the backend, this dependency can slow down the frontend teams to quickly have the UI up and running.

This is a simple and quick tutorial to show how to simulate backend API for VueJS application to solve this issue.

The application

Let’s say we are tasked to build a product catalog in an administration panel for an e-commerce project and we need to have an idea about how the final result of our VueJS based UI will look like without waiting for the backend team to finish the APIs.

For the sake of this tutorial I will demonstrate how to render the products list by just using JavaScript in the browser.

The VueJS code:

The starting code for the application can be downloaded or cloned from this github repository, make sure you are using the starting git branch.

<template>
  <div id="app">
    <h3>Products</h3>
    <ul>
      <li v-for="product of products" :key="product.id">{{product.name}}</li>
    </ul>
  </div>
</template>

<script>
import axios from 'axios';

export default {
  name: 'App',
  data() {
    return {
      products: []
    }
  },
  async created() {
    const response = await axios.get('/api/products');
    this.products = response.data;
  } 
}
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}

li {
  list-style: none;
}
</style>

Introducing can-fixture

can-fixture, a package part of CanJS framework, as its documentation says, can intercept AJAX requests and simulate the response, it can be used to simulate all HTTP methods (GET, POST, DELETE … etc).
For this introductory tutorial, I will show just how to simulate GET method to list the products.

can-fixture should only be used for development and testing purpose and removed when the real backend APIs are ready for production.

For our product catalog, we need that can-fixture returns the available products in order to be listed in the VueJS based application, this can be achieved following those steps:

Install can-fixture as a development dependency:
- npm install --save can-fixture.
Create a fixtures folder inside the application src folder.
Create a products.js file that will host the products fixture.
Add the following code to the products.js file created above:

import fixture from 'can-fixture';

fixture("GET /api/products", () => {
    return [
        {id: 1, name: 'Product 1', 'description': 'A description'}, 
        {id: 2, name: 'Product 2', 'description': 'A product 2 description'},
        {id: 3, name: 'Product 3', 'description': 'A product 3 description'},
    ];
});

export default fixture;

import fixtures/product in the App.vue file

The final App.vue code should look like:

<template>
  <div id="app">
    <h3>Products</h3>
    <ul>
      <li v-for="product of products" :key="product.id">{{product.name}}</li>
    </ul>
  </div>
</template>

<script>
import axios from 'axios';
import './fixtures/products';

export default {
  name: 'App',
  data() {
    return {
      products: []
    }
  },
  async created() {
    const response = await axios.get('/api/products');
    this.products = response.data;
  } 
}
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}

li {
  list-style: none;
}
</style>

When refreshing the browser, the configured products in the fixture should be displayed.

How it works?

The fixture function needs two arguments to have it working:

The method with the endpoint URL
The request handler

The request handler is the most interesting part, which is just a function that returns the needed data, it can hold more complicated logic, like filtering or sorting.
In this example the response is straightforward and holds the data of our product catalog without any logic.

You can check the canjs docs for more details about how can-fixture works.

In future tutorials we will look at how we can use can-fixture to handle more complicated use cases, like searching and filtering.

I hope you find this quick tutorial useful to improve the process and development experience, please let me know your thoughts.