Docker on entangledDEV

VSCode Dev Container Configurations

Tue, 21 May 2024 00:46:23 +0000

VSCode + Dev Containers are a great way to create custom environments without modifying our actual system.

They provide a consistent development environment, ensure dependencies are managed correctly, and make it easy to share setups with your team.

Here are some configurations you can use to create them.

Vapor

{
    "name": "Swift",
    "image": "swift:latest",
    "features": {
        "ghcr.io/devcontainers/features/common-utils:2": {
            "installZsh": "false",
            "username": "vscode",
            "userUid": "1000",
            "userGid": "1000",
            "upgradePackages": "false"
        },
        "ghcr.io/devcontainers/features/git:1": {
            "version": "os-provided",
            "ppa": "false"
        }
    },
    "runArgs": [
        "--cap-add=SYS_PTRACE",
        "--security-opt",
        "seccomp=unconfined"
    ],
    "customizations": {
        "vscode": {
            "settings": {
                "lldb.library": "/usr/lib/liblldb.so"
            },
            "extensions": [
                "sswg.swift-lang",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    },
    "remoteUser": "root",
    "postCreateCommand": "apt-get update && apt-get install -y libssl-dev libsqlite3-dev zlib1g-dev make && rm -rf toolbox && git clone https://github.com/vapor/toolbox.git && cd toolbox && make install && cd .. && rm -rf toolbox"
}

Scala

{
	"name": "Scala",
	"image": "mcr.microsoft.com/devcontainers/java:1-21-bullseye",

	"features": {
		"ghcr.io/devcontainers/features/java:1": {
			"version": "none",
			"installMaven": "false",
			"installGradle": "false"
		}
	},
	"postCreateCommand": "curl -fL https://github.com/VirtusLab/coursier-m1/releases/latest/download/cs-aarch64-pc-linux.gz | gzip -d > cs && chmod +x cs && yes | ./cs setup && echo 'before start run source ~/.profile'",

	"customizations": {
		"vscode": {
			"extensions": [
				"scala-lang.scala",
				"streetsidesoftware.code-spell-checker"
			]
		}
	}
}

A Simple Full-Stack iOS App Example

Tue, 09 Jan 2024 18:04:28 -0800

One of the benefits of using Swift is its excellent performance and low memory footprint. This is a key point when doing backend programming.

The future of Swift in Linux looks promising. With Swift 5.9, there will be better error logging, and Apple is developing a new open-source cross-platform testing framework with swift-testing that will replace XCTest and works on Linux too.

Let’s hope this encourages more backend systems to be written in Swift.

In this tutorial, we’ll explore how to code a backend in Vapor and establish its connection to a simple iOS app. I hope this example serves as a good starting point for learning about the interaction between mobile and backend systems.

Getting Started: Tech Stack Overview

Backend

Some mobile developers prefer using auto-managed backend solutions like Firebase and may not pay much attention to the server side. Nevertheless, I believe that understanding the basic programming and concepts used in the backend can enhance your comprehension of the entire system. This understanding enables us to create solutions that are not only more efficient but also better integrated.

Framework

Backend programming is a complex topic with various frameworks in the market. In the Swift world, the most widely used backend framework is Vapor.

Vapor is an excellent solution for building backend systems. It utilizes a non-blocking, event-driven architecture built on top of Apple’s SwiftNIO. This offers us great performance, allowing us to create complex systems that scale well.

Keep in mind that some third-party services may not have a ready-to-use Swift/Vapor API. This can introduce additional complexity when integrating these services.

Database

For the database, we are using PostgreSQL. This database is an open-source relational database and offers great performance with a lot of useful features for any needs we could have.

To install and run our database, we are going to use Docker with a docker-compose file. This is great because we can start a database in seconds and allows us to replicate our configuration in different environments.

App

We use SwiftUI with modern concurrency (async/await), implementing a Network layer to manage requests, and follow the MVVM architecture to organize our code.

This approach enables us to delve into modern iOS development, providing insights into how all elements interconnect and respond to changes.

Coding the Backend

Installing docker

Let’s start our project by installing docker, we need it to create the database and the container for our vapor app.

We can use Homebrew to install it via the terminal, or just get it from the Docker site.

If you decide to use Homebrew, we need to have brew installed and run the following command on the terminal:

brew install --cask docker

Open Docker and let’s continue.

Creating and running the database

To set up our PostgreSQL database, we’ll need to create a docker-compose.yml file and define its configuration. Follow these steps:

Create a file named docker-compose.yml in your project directory.
Add the following configuration to the docker-compose.yml file:

version: '3'

services:
  postgres:
    image: postgres:latest
    container_name: postgres
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    ports:
      - '5432:5432'
    networks:
      - fullstack-ios-net

volumes:
  postgres_data:

  networks:
    fullstack-ios-net:
        driver: bridge

volumes will tell Docker to create the persistance layer with the given name for us, so we don’t need to specify any directory.

Open a terminal in the directory containing the docker-compose.yml file.
Run the following command to start the database container:

docker-compose -p database-vapor up -d

You can change the container name by replacing database-test with your preferred name. The -d flag runs the container in detached mode, freeing up the terminal.

This will create a running database locally, ready for us to use in our backend.

To confirm that the database is running, execute the command docker ps in your terminal. Alternatively, you can check Docker Desktop if it is installed on your system.

Since we are running separate containers for the database and the vapor app, we need to get the network in which the database is attached, to do so let’s run:

docker network ls

In my case, the network created for this container is called database-vapor_fullstack-ios-net. We’ll use this network for the vapor app, so keeps your network name saved.

To check the containers attached to a network run: docker network inspect <network_name/ID>.

To delete a network run the command: docker network rm <network_name/ID>.

Here’s an example of the resulting database running on my system:

Creating the Vapor Container

Let’s move on to the exciting part – building our Vapor app. For this process, we’ll leverage a development container with VSCode, a fantastic tool that helps maintain a clean local environment and ensures reproducibility for every project.

Feel free to adjust this according to your style and preferences!

Follow these steps to create your empty vapor container:

Create a root directory for the vapor container.
Inside the root directory, create a new directory called .devcontainer.
Inside .devcontainer, create a new file called devcontainer.json and add the following:

{
    "name": "Vapor",
    "image": "swift:latest",
    "runArgs": [
        "--name=vapor-local-devcontainer",
        "--network=database-vapor_fullstack-ios-net"
    ],
    "postCreateCommand": "bash .devcontainer/vaporinstall.sh",
    "customizations": {
        "vscode": {
            "extensions": [
                "sswg.swift-lang",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    }
}

We are adding this container to the same network as the database, this will allow communication between the two containers.

Create the Vapor installation script vaporinstall.sh file inside the .devcontainer directory.
Add the following to vaporinstall.sh:

#!/bin/bash

echo "Vapor installation is starting"

# Updating and installing packages
apt update && apt upgrade -y
apt install -y make

# Installing Vapor
git clone https://github.com/vapor/toolbox.git
cd toolbox
make install
cd ..
rm -rf toolbox

echo "Vapor installation was successful"

Open the project in VSCode and then select the option Reopen in Container.

To check Vapor is installed, run in a terminal vapor --version.

This will create the container and install vapor inside, you’re ready to code the backend in Vapor!

Finally, let’s check that both containers are under the same network, run this command in the host terminal:

docker network inspect database-vapor_fullstack-ios-net | grep -A 20 "Containers"

There you can check that our two containers are listed in the output under "Containers", we’re good to continue.

Creating a barebone Vapor App

It’s time to create our app inside the container, this is a simple task thanks to the integrated vapor tools:

Run in the container’s terminal the following:

vapor new temperature-api -n

-n will create a barebone project

Enter the new directory cd temperature-api
Run the project swift run

Congratulations, now your Vapor app is up and running. To verify that it works as expected you can check the root endpoint / in the URL mentioned in the terminal, usually http://127.0.0.1:8080/

Creating the Model for the Database

Let’s start by codding the Model that will represent our table!

This step is crucial because we are modeling our problem and it’s important that we discuss this thoroughly to get a model that efficiently defines our data and allow us to have a simple and performant representation of the problem’s data.

This is a really simple app, so we are just storing a given temperature and a related date. Since this is simple to model we’re going to use a simple table containing these values and a unique identifier for each new value.

Installing `Fluent` and `Postgres Driver`

We’re going to use an ORM to communicate with our database, this is a great tool that allow us to stay in Swift when making queries, models and relationships. In our case we decided to use Fluent and a Postgres Driver.

To install them, follow the next steps:

Open Package.swift
Add the following lines in the dependencies array:

  .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"),
  .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"),

Add the following inside the second dependencies array, nested inside targets:

.product(name: "Fluent", package: "fluent"),
.product(name: "FluentPostgresDriver", package: "fluent-postgres-driver"),

If you’re using a different database look into Fluent documentation to find an appropriate driver.

Your Package.swift should look similar to this:

// swift-tools-version:5.9
import PackageDescription

let package = Package(
    name: "temperature-logger",
    platforms: [
       .macOS(.v13)
    ],
    dependencies: [
        // 💧 A server-side Swift web framework.
        .package(url: "https://github.com/vapor/vapor.git", from: "4.83.1"),
        .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"), // added
        .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"), //added
    ],
    targets: [
        .executableTarget(
            name: "App",
            dependencies: [
                .product(name: "Vapor", package: "vapor"),
                .product(name: "Fluent", package: "fluent"), // added
                .product(name: "FluentPostgresDriver", package: "fluent-postgres-driver") //added
            ]
        ),
        .testTarget(name: "AppTests", dependencies: [
            .target(name: "App"),
            .product(name: "XCTVapor", package: "vapor"),

            // Workaround for https://github.com/apple/swift-package-manager/issues/6940
            .product(name: "Vapor", package: "vapor"),
        ])
    ]
)

These new packages will be automatically added to our project.

Creating our Temperature model

The models we define in this step will be used to create the tables in our database.

Create a new file called Temperature.swift in the following path: Sources/App/Models/
Add the following code:

import Vapor
import Fluent

final class Temperature: Model, Content {
    static let schema: String = "temperatures"

    @ID
    var id: UUID?

    @Field(key: "temperature")
    var temperature: String

    @Field(key: "date")
    var date: String

    init() { }

    init(id: UUID? = nil, temperature: String, date: String) {
        self.id = id
        self.temperature = temperature
        self.date = date
    }
}

The property wrappers are defined in Fluent and let us mark the different roles for our database, the names inside @Field are used to represent the name of the columns in the table. The schema at the top will be used as the table name in our database.

Excellent, we have our schema defined.

Connecting the Postgres Database to our Vapor App

Oru next goal is to connect our database to our vapor app and create the schema for our system.

Creating the Migration file

Migrations serve the purpose of defining and applying changes to the database schema. A migration is essentially a set of instructions that describe how to evolve the database structure, creating or modifying tables and their columns.

To create our own migration file follow the next steps:

Create the file CreateTemperature.swift in the path: Sources/App/Migrations/
Add the following code:

// To run migrations, call `swift run App migrate` from the command line

import Fluent

struct CreateTemperature: AsyncMigration {
    func prepare(on database: Database) async throws {
        try await database.schema("temperatures")
            .id()
            .field("temperature", .string, .required)
            .field("date", .string, .required)
            .create()
    }
    
    func revert(on database: Database) async throws {
        try await database.schema("temperatures")
            .delete()
    }
}

The prepare function is part of the migration and specifies what changes to make to the database when applying the migration. In simple terms, it says:

Create a new table named ’temperatures'.
Add an ‘id’ column (which is typically an identifier for each row in the table).
Add a ’temperature’ column of type ‘string’ that is required.
Add a ‘date’ column of type ‘string’ that is also required.
Ensure that all these changes are applied to the database.

The revert function is part of the migration and specifies how to undo the changes made by the prepare function. In simple terms, it says:

Delete the ’temperatures’ table from the database.

Setting-up the Postgres Database

We need to configure the credentials for our Postgres database. To do this we need to open the file configure.swift inside the path: Sources/App/.

Add the packages needed at the top of the file:

import Fluent
import FluentPostgresDriver

Add the following code at the top inside the configure function:

The data for these credentials are defined in the docker-file of the database. If you’re hosting your database in a system other than localhost, use your URL in place of localhost.

// defining the postgres configuration object
let databaseConfiguration = SQLPostgresConfiguration(
    hostname: "localhost",
    username: "user",
    password: "password",
    database: "postgres",
    tls: .disable
)

// applying the configuration
app.databases.use(
    .postgres(configuration: databaseConfiguration), as: .psql
)

// Adding our migration object
app.migrations.add(CreateTemperature())

// Optional, make the logger more verbose
app.logger.logLevel = .debug

Your configuration.swift should look similar to this:

import Vapor
import Fluent
import FluentPostgresDriver

// configures your application
public func configure(_ app: Application) async throws {
    // uncomment to serve files from /Public folder
    // app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))

    // defining the postgres configuration object
    let databaseConfiguration = SQLPostgresConfiguration(
        hostname: "localhost",
        username: "user",
        password: "password",
        database: "postgres",
        tls: .disable
    )

    // applying the configuration
    app.databases.use(
        .postgres(configuration: databaseConfiguration), as: .psql
    )

    // Adding our migration object
    app.migrations.add(CreateTemperature())

    // Optional, make the logger more verbose
    app.logger.logLevel = .debug


    // register routes
    try routes(app)
}

Now stop the app and run the following commands to apply the migrations and get the database connected.

# Stop the project by pressing CTRL + C
swift run App migrate # to start migration

Creating the endpoints

We’re about to finish the backend for our iOS app. This backend is quite simple, it will expose a GET method that will return all the stored temperatures in the database and a post method that will allow us to save a temperature sent from our iOS app.

Since we are only using two endpoints we can add this logic to the file routes.swift, found in the path temperature-api/Sources/App/.

Open the file and add the following modules:

import Fluent
import FluentPostgresDriver

Next, inside the routes function, delete all its body and add this:

 app.get("temperatures") { req async throws in
    app.logger.info("Temperatures GET received.")
    return try await Temperature.query(on: req.db).all()
}

app.post("temperatures") { req async throws -> Temperature in
app.logger.info("Temperature POST request received.")
    let temperature = try req.content.decode(Temperature.self)
    try await temperature.create(on: req.db)
    return temperature
}

Your routes.swift file should look like this:

import Vapor
import Fluent
import FluentPostgresDriver


func routes(_ app: Application) throws {
     app.get("temperatures") { req async throws in
        app.logger.info("Temperatures GET received.")
        try await Temperature.query(on: req.db).all()
    }

    app.post("temperatures") { req async throws -> Temperature in
        app.logger.info("Temperature POST request received.")
        let temperature = try req.content.decode(Temperature.self)
        try await temperature.create(on: req.db)
        return temperature
    }
}

GET Route for “temperatures”:

When the server receives a GET request at the path "/temperatures", it logs an informational message saying "Temperatures GET received.".
It then attempts to retrieve all temperature records from the database asynchronously using try await Temperature.query(on: req.db).all().

POST Route for “temperatures”:

When the server receives a POST request at the path "/temperatures", it logs an informational message saying "Temperature POST request received.".
It then tries to decode the request’s content into a Temperature model object using let temperature = try req.content.decode(Temperature.self).
After decoding, it attempts to create a new temperature record in the database asynchronously with try await temperature.create(on: req.db).
Finally, it returns the created Temperature object as a response.

Congratulations, you’ve finished your backend using Vapor!

Run it with swift run and let’s test it!

Testing our backend

For testing our backend I’m using Postman.

First let’s try the GET, since the database is empty it should return an empty array [].

Now let’s test the POST by adding some data.

Finally, let’s check GET again to verify we get the new stored data from the DB.

Great, our backend is working as expected.

Let’s continue with the iOS app, great work!

Coding the iOS App

Let’s start our iOS app that will connect to our vapor backend.

One of the most used design patters for SwiftUI is MVVM, this stands for Model, View and ViewModel.

Model: Represents the application’s data and business logic. It is responsible for managing and manipulating the data, as well as enforcing business rules.

View: Represents the user interface and is responsible for displaying data to the user. It observes changes in the ViewModel and updates accordingly. In some implementations, the View may also handle user input and pass it to the ViewModel.

ViewModel: Acts as an intermediary between the Model and the View. It contains the presentation logic and transforms the data from the Model into a form that can be easily displayed by the View. The ViewModel often exposes properties and commands that the View can bind to.

The key point is that the ViewModel doesn’t tell the view what to do; it just receives queries from the view. When the data is ready, it notifies the subscribers, mostly views, about the changes. Then, the views that get the notifications can act accordingly with the new data received.

Let’s create a new iOS SwiftUI project in Xcode to continue, we could name it Temperatures App or anything you like.

Creating the Model

Let’s start with the Model, this model would be quite similar to the one in our backend.

Let’s create a new Group called Models and inside this group create a new file called Temperature.swift.

import Foundation

struct Temperature: Codable, Identifiable {
    var id: UUID = UUID()
    var temperature: String = ""
    var date: String = ""
}

This is the model our app will use when creating new temperatures locally. The code acts similarly to the one in the backend; we define a new ID for each new temperature and store the temperature and date for that measurement.

We use Identifiable to make every temperature object uniquely identifiable. This is useful in the SwiftUI ForEach view.

The Codable protocol guarantees that our data can be encoded and decoded, in our case, to and from JSON.

Creating the Network Layer

The network layer is next; this layer will handle the communication with the server.

Creating the Request Protocol

Let’s start by defining a protocol that will tell us the public API for a network request. The network request will handle all the information needed by the network service to perform its work.

Create a new group called Networking and inside create a new file called NetworkRequestProtocol.swift. Then add this code:

import Foundation

protocol NetworkRequestProtocol {
    var url: URL { get }
    var method: String { get }
    var headers: [String: String]? { get }
    var body: Data? { get }
}

As mentioned before, these are the elements we will need to pass to the network manager to be able to send requests to our backend:

The URL of our backend.
The type of HTTP method we want to use.
The headers for our requests.
The body of our request in case of POST.

Creating the Temperature Request

Now let’s conform to this protocol. Create a new file called TemperatureRequest.swift in the Networking group and add the following code:

import Foundation

enum TemperatureRequest: NetworkRequestProtocol {
    case post(temperature: Temperature)
    case get

    var url: URL {
        switch self {
        case .get: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        case .post: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        }
    }

    var method: String {
        switch self {
        case .get: "GET"
        case .post: "POST"
        }
    }

    // no matter the selected case we always return the same header
    var headers: [String : String]? {
        ["Content-Type": "application/json"]
    }

    var body: Data? {
        switch self {
        case .get: nil
        case .post(let temperature): try? JSONEncoder().encode(temperature)
        }
    }

}

We’re making this app simple, so we are not defining custom errors.

enums are great for handling our network request parameters. Here, TemperatureRequest conforms to NetworkRequestProtocol. This is great because we can change our request object with a different one by only conforming to the same protocol. This helps to lower code coupling and improves testability.

The code itself configures the GET and POST method data. In the case of POST, we send the Temperature object and convert it into a proper JSON type for our backend. The rest of the code is self-explanatory.

Creating the Network Service Protocol

As mentioned before, protocols are a great way to lower coupling in code and help with testability because we can create mock objects that can simplify our tests for different parts of the code.

Let’s create a new file called NetworkServiceProtocol.swift in the Networking group and add this code:

import Foundation

protocol NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data
}

As before, we are defining the public API for this object. In this case, we only have one function that will execute the request using the request data we pass.

Creating the Network Service

The Network service is the final component we need to implement in our Network layer. This object is responsible for doing the actual communication with the backend. To configure our request, we pass a TemperatureRequest object with the parameters we need.

In the same Networking group, create a new file called NetworkService and add the following code:

import Foundation

struct NetworkService: NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data {
        // configuring the request
        var urlRequest = URLRequest(url: request.url)
        urlRequest.httpMethod = request.method
        urlRequest.allHTTPHeaderFields = request.headers
        urlRequest.httpBody = request.body

        // performing the request, we wait for the server response
        let (data, _) = try await URLSession.shared.data(for: urlRequest)
        
        // returning the data from the server
        return data
    }
}

In simpler terms the code above does the following:

Implementing the protocol NetworkServiceProtocol
execute function: takes a NetworkRequestProtocol as a parameter and performs a network request to our backend.
URLRequest setup: Inside the execute function, a URLRequest is created using information from the provided NetworkRequestProtocol, such as the URL, HTTP method, headers, and request body.
Network request: The function then uses URLSession.shared to perform an asynchronous network request based on the constructed URLRequest. It awaits the response and extracts the obtained data.
Return data: Finally, the obtained data is returned from the function.

Notice that this layer is not responsible of converting the json data to the proper type for our app.

Creating the View Model

To create the View Model, we need to create a new group called ViewModels and inside this new group create a new file called TemperaturesViewModel.swift. Add the following code to this file:

import Foundation

@MainActor // Runs this code in the main thread to avoid updating the UI outside of it.
final class TemperatureViewModel: ObservableObject {
    @Published private(set) var temperatures: [Temperature]
    private let networkService: NetworkServiceProtocol
    
    // Injecting dependencies
    init(temperatures: [Temperature] = [], networkService: NetworkServiceProtocol) {
        self.temperatures = temperatures
        self.networkService = networkService
    }
    
    /// POST a new temperature to the backend.
    func addTemperature(temperature: String, date: String) async {
        let newTemperature = Temperature(temperature: temperature, date: date)
        let request = TemperatureRequest.post(temperature: newTemperature)
        do {
            let _ = try await networkService.execute(request: request)
        } catch {
            print("Error adding temperature")
        }
    }
    
    /// GET all stored temperatures in the backend.
    func getTemperatures() async {
        let request = TemperatureRequest.get

        // perform request
        do {
            let data = try await networkService.execute(request: request)

            // decode data
            guard let decodedData = decodeData(data: data) else { return }
            print(decodedData)
            // saving data on published var
            temperatures = decodedData
        } catch {
            print("Some error in get")
        }
    }
}

// MARK: - Helper private functions
private extension TemperatureViewModel {
    func decodeData(data: Data) -> [Temperature]? {
        do {
            return try JSONDecoder().decode([Temperature].self, from: data)
        } catch {
            print("Error decoding temperatures")
            return nil
        }
    }
}

This code may seem complex, but in reality, it is just doing two things: sending data back to the server and getting data from the server. This happens in the methods addTemperature and getTemperatures.

Then we are publishing the values with @Published private(set) var temperatures: [Temperature], so any object that subscribes to updates can get a notification for changes in this variable. Notice the private(set), this allows read-only access to the value.

All of this is handled in the main thread to avoid updating the UI in a different thread by marking the object with @MainActor.

addTemperature function: This function is responsible for sending a new temperature to the backend using a POST request:

It creates a new Temperature object with the provided temperature and date.
It creates a TemperatureRequest for a POST request, encapsulating the new temperature data.
It tries to execute the request asynchronously using the networkService.
If an error occurs during the request execution, it catches the error and prints an error message.

getTemperatures function: This function is responsible for fetching all stored temperatures from the backend using a GET request:

It creates a TemperatureRequest for a GET request.
It tries to execute the request asynchronously using the networkService.
If the request is successful, it decodes the received data into an array of Temperature objects using the decodeData function.
It prints the decoded data and assigns it to the temperatures property, which is likely a @Published property that updates the UI when changed.
If an error occurs during the request execution, it catches the error and prints an error message.

Creating the Views

Now it’s time to see something on our phone’s screen. Let’s create a new group called Views. Here, we are going to add all the views for our app.

The system will have two views: one for creating new temps and the other for viewing the current temperatures stored in our system. To manage the navigation of these two views, we are going to use a tab navigation style. Since the tab view doesn’t have a title, we’re going to use a title view that will help us to name our screens. This also allows us to customize the screens to our liking.

So, let’s create these three SwiftUI files inside Views. Let’s call them:

RootView.swift: Our tab view will be here.
PostTemperaturesView.swift: It will display a simple UI to send the data to the server.
GetTemperaturesView.swift: It will display a simple table with the temperatures from the server.
TitleView.swift: A helper view that will display the title of the current view.

Creating `TitleView`

The easiest view for this app is the TitleView. It will be a simple view that displays formatted text on the screen.

Add this code to TitleView.swift:

import SwiftUI

struct TitleView: View {
    let title: String

    var body: some View {
        Text(title)
            .font(.largeTitle)
            .fontWeight(.bold)
            .padding()
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    TitleView(title: "Custom Title")
}

In this view we are just applying some font styles to the given title.

Creating `PostTemperaturesView`

This view will present the user with a button and two fields for the temperature and date. We are implementing some extremely basic validation that will disable the button if both text fields are empty. In a production app, we should validate against edge cases and be more thoughtful.

Add the following code to PostTemperaturesView.swift:

import SwiftUI

struct PostTemperaturesView: View {
    @State private var temperature = Temperature()
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        ZStack {
            VStack {
                TitleView(title: "Post your temperature")
                Divider()
                Spacer()
            }
            VStack {
                inputSection()
                    .padding()
                buttonSection()
            }
        }
    }
}

#Preview {
    PostTemperaturesView()
}

private extension PostTemperaturesView {
    
    /// Checks if the temperature components are empty or not.
    var invalidTemperatureData: Bool {
        temperature.date.isEmpty || temperature.temperature.isEmpty ? true : false
    }
    
    /// Based on the validity of the temperature object, it returns a specific color.
    var buttonBackground: Color {
        invalidTemperatureData ? .gray : .red
    }
    
    func inputSection() -> some View {
        VStack(spacing: 20) {
            TextField("Temperature", text: $temperature.temperature)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
            TextField("Date", text: $temperature.date)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
        }
        .frame(width: 130, height: 120)
        .padding()
        .overlay(
            RoundedRectangle(cornerRadius: 25.0)
                .stroke(.red, lineWidth: 3)
        )
    }

    func buttonSection() -> some View {
        Button {
            Task {
                await temperatureViewModel.addTemperature(
                    temperature: temperature.temperature,
                    date: temperature.date
                )
            }

        } label: {
            Text("POST Temperature")
                .foregroundStyle(.white)
                .frame(maxWidth: .infinity, maxHeight: .infinity)
        }
        .disabled(invalidTemperatureData)
        .frame(width: 230, height: 60)
        .background(buttonBackground)
        .clipShape(RoundedRectangle(cornerRadius: 25.0))
    }
}

Since we are not reusing any of the sub-views, I decided to implement them in private functions. This helps to lower the code complexity since all sub-views will have direct access to the parent view properties.

To call async functions in our views, we need to create an asynchronous context. To do that, we use Task { ... }. Inside a task, we can call our async functions from the view model. The main advantage of this is that we don’t block our UI by waiting for the response.

The rest of the code is self-descriptive thanks to the declarative aspect of SwiftUI.

Creating `GetTemperaturesView`

Since we need to get the current data from the server, I’m attaching a .task action that executes every time the view is rendered. This will download the most up-to-date data from the server. Then we will display this information in a formatted table.

In production apps, it’s important to manage possible errors and inform the users visually about the current state of the task. For this small app, we are not managing that aspect.

import SwiftUI

struct GetTemperaturesView: View {
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        VStack {
            TitleView(title: "Recorded Temperatures")
            Divider()
            List {
                ForEach(temperatureViewModel.temperatures) { temp in
                    row(temperature: temp)
                }
            }
            .listStyle(.plain)
            .task {
                await temperatureViewModel.getTemperatures()
            }
        }
    }
}

#Preview {
    GetTemperaturesView()
        .environmentObject(TemperatureViewModel(networkService: NetworkService())) // needed for the preview not to crash
}

private extension GetTemperaturesView {
    func row(temperature: Temperature) -> some View {
        VStack {
            Text("Date: \(temperature.date)")
            Text("Temperature: \(temperature.temperature) \u{2103}")
        }
    }
}

As before, thanks to the declarative nature of SwiftUI, the code is self-explanatory.

Creating `RootView`

Finally, let’s piece together all the views and complete our UI.

This last part is quite simple to implement, thanks to the way SwiftUI works. Add the following code to the file RootView.swift:

import SwiftUI

struct RootView: View {
    var body: some View {
        TabView {
            PostTemperaturesView()
                .tabItem { Label("POST", systemImage: "square.and.arrow.up") }
            GetTemperaturesView()
                .tabItem { Label("GET", systemImage: "square.and.arrow.down") }
        }
        .tint(.red) // change button color in tab
    }
}

#Preview {
    RootView()
        .environmentObject(TemperatureViewModel( networkService: NetworkService()))
}

Here we are creating the tab view and assigning the post and get views we created early in this tutorial.

Configuring the Environment Object

You may have noticed that some of our views need an Environment object. In the preview, the app works well, but if you try to run it, the app will crash because we are only injecting this object into the preview context. Let’s fix that now.

Open the entry point app file. It’s the one named as your app and contains the attribute @main.

Inside the struct, let’s add the view model we will be observing:

@StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

Next let’s change our View entry point to the RootView we just created, and inject the environment object. This will allow access to the ViewModel to RootView and all of its sub-views.

We’re also attaching an initial get to our backend, this will get us an up to date temperatures each time our app starts.

WindowGroup {
            RootView() // change to our RootView
                .environmentObject(temperatureViewModel) // inject the ViewModel
                .task { // When open the app, perform an initial GET to the server.
                    await temperatureViewModel.getTemperatures()
                }
        }

Your file should look like something like this, (your struct may have a different name):

import SwiftUI

@main
struct temperature_logger_App: App {
    @StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

    var body: some Scene {
        WindowGroup {
            RootView()
                .environmentObject(temperatureViewModel)
                .task {
                    await temperatureViewModel.getTemperatures()
                }
        }
    }
}

Congratulations! You just finished the app!

Testing the App

To test the app, you need to have the Vapor app and the database containers running. Verify that they are up and running.

Now, let’s run the app on the simulator and add some temperatures. Then, check the list to see how they update in real-time!

You can also view the logs in our Vapor app to see the requests we are receiving from our app.

Conclusion

In concluding our exploration of building a full-stack iOS application, the versatility of Swift has truly shone through. Swift not only excels in crafting engaging iOS applications but also seamlessly extends its capabilities to backend development, as demonstrated by the integration with the Vapor framework.

The collaboration between the iOS app and the Vapor backend illustrates the straightforward nature of Swift in the development landscape. The use of Docker for containerization further streamlined the setup, enabling a hassle-free configuration of a PostgreSQL database synchronized with the Vapor app. This amalgamation of Swift, Docker, and Vapor reflects the smooth interplay of modern development tools.

This experience emphasizes Swift’s adaptability, not just in the iOS environment but also in Linux setups, where it effortlessly integrates and collaborates with container technologies like Docker. Swift emerges as a pragmatic choice for end-to-end development.

As we wrap up the journey of creating a full-stack iOS application, it’s worth acknowledging Swift’s role in orchestrating various technologies. It showcases how Swift fosters a developer-friendly environment, encouraging innovation and blurring the lines between frontend and backend development. Here’s to the practicality of Swift and the possibilities it unlocks in the ever-evolving landscape of software development!

Containerize Haskell

Thu, 21 Dec 2023 11:43:00 +0000

Let’s continue our exploration of the wonders of local development with containers.

This time, we’ll delve into the world of Haskell programming. Instead of burdening your local environment with the entire toolchain, we’ll opt for a more streamlined approach: creating a dev container. This example will illustrate how effortlessly you can integrate new tools and programming languages without causing any disruptions to your local system.

What is Haskell

Haskell, a pure functional programming language, though not as commonly used in the industry, is a powerful language whose fundamentals can significantly enhance your programming skills.

However, Haskell comes with a complex toolchain and numerous dependencies, potentially posing challenges for some systems. If you’re not a professional Haskell developer, the process of installing all these tools may not be worthwhile.

This is where dev containers come to the rescue, allowing you to sidestep these issues while still enabling you to experiment with Haskell. Let’s get started.

Personally, I find Haskell to be a fascinating language that offers valuable insights into novel techniques and encourages a different perspective on problem-solving. Experimenting with Haskell has been particularly enjoyable for me, providing a unique opportunity to broaden my understanding and approach to coding challenges.

Creating the Haskell dev container

As usual, we start by creating our local directory with a child directory called .devcontainer, inside this dir let’s create a new file called devcontainer.json, then add this code.

{
    "name": "Haskell Base",
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
    "customizations": {
        "vscode": {
            "extensions": [
                "haskell.haskell",
                "visualstudioexptteam.vscodeintellicode",
                "visualstudioexptteam.intellicode-api-usage-examples",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    },
    "postCreateCommand": "zsh .devcontainer/installation.sh",
    "runArgs": ["--name", "haskell_devcontainer"]
}

Let’s break down its key elements:

The name field is set to “Haskell Base,” providing a recognizable identifier for this development environment.

The image field points to the Docker image “mcr.microsoft.com/devcontainers/base:ubuntu.” This image serves as the foundation for the development environment.

Within the customizations section, various Visual Studio Code extensions are specified. These extensions enhance the Haskell development experience.

The postCreateCommand field designates a post-creation command that runs after the dev container is set up.

Finally, the runArgs field supplies extra arguments for the docker run command when initiating the dev container. It assigns the name “haskell_devcontainer” to the container for easy identification.

As you may have noticed, we need to create a script to install Haskell in our container. To craft this file, we follow the instructions provided by the Haskell page. This shows us how we can easily configure our container as if it were a standard local installation. This shows the power and simplicity of working with local containers.

Within the .devcontainer directory, create a new file named configuration.sh and insert the following code into this newly created file.

#!/bin/zsh

sudo apt update
sudo apt install -y build-essential curl libffi-dev libffi8ubuntu1 libgmp-dev libgmp10 libncurses-dev libncurses5 libtinfo5

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh

echo 'export PATH="$PATH:$HOME/.ghcup/bin"' >> ~/.zshrc
source ~/.zshrc

echo 'export PATH="$PATH:$HOME/.ghcup/bin"' >> ~/.bashrc
source ~/.bashrc

echo "IMPORTANT: If bash doesn't find cmds, run: source ~/.bashrc"

In this script, we’re simply adhering to the installation recommendations provided by the official Haskell documentation for Linux. no extra steps or magic is needed for the container; we can treat it just like a local installation.

After preparing this, open your project in a dev container, go through the setup process (simply respond with ‘Y’ to all questions), and you’re all set to delve into Haskell on your machine.

Testing Haskell

Let’s create a simple program to test our envirment. Create a new file called “main.hs” and add the following code.

main = do
    putStrLn "What is 2 + 2?"
    x <- readLn
    if x == 4
        then putStrLn "You're right!"
        else putStrLn "You're wrong"

Now let’s run it by importing it to the interpreter

ghci main.hs

The ghci REPEL will open, now let’s run our function by just calling its name inside ghci

main

This will ask you for an input and will print the result

What is 2 + 2?
4
You're right!

Congratulation, your Haskell environment is working correctly!

Conclusion

In this exploration of local development with containers, we’ve ventured into Haskell programming, sidestepping the complexities of the language’s toolchain by creating a streamlined dev container. Despite Haskell’s relative industry underuse, its power for skill enhancement remains evident.

Dev containers prove invaluable, allowing us to experiment freely with Haskell without the hassle of extensive toolchain installations. Crafting a Haskell dev container is straightforward, following the official documentation to seamlessly configure it as a standard local installation.

Our simple program confirms that our setup is working correctly. With this, your Haskell environment is ready for exploration. Happy coding!

Programming inside a Developer Container

Mon, 18 Dec 2023 09:00:30 +0000

Hello devs,

I’ve recently been exploring the synergy between Docker and VSCode for local development. The concept of consolidating code and dependencies into containers has caught my attention. This approach not only establishes a clean slate for each project but also promotes a stateless system, a goal that aligns seamlessly with my coding environment.

To explore these ideas further, let’s create a small project: containerizing an installation of Hugo. This way, we can run our own dev blog anywhere without worrying about configuration and compatibility issues. It sounds great, so let’s dive into the code and make it happen!

What are Dev Containers?

Dev containers, a feature in VSCode, empower us to use local containers for programming, seamlessly configured with both our dependencies and code. This operates under the hood, allowing us to open our projects within these containers and easily push changes to platforms like GitHub.

In essence, we work as if we were coding locally, avoiding any impact on our real system. Once our work is complete, we can delete these containers from our system without any repercussions. The magic doesn’t stop there—having a reproducible environment enhances teamwork among developers. Now, we can ensure the same environment, regardless of the system in use, eliminating the classic “it works on my machine” scenario.

It’s truly magical.

Prerequisites

To make this project, we only need two tools installed in our system:

Docker (local or remote works, in this tutorial we assume it’s installed locally)
Visual Studio Code

I assume you’re familiar with containers, how Docker operates, and have a basic understanding of using Hugo

Creating the Initial Configuration

Let’s kick things off by establishing the working directory for our Hugo blog. Just as we would with any other project, we create a directory to store our code. This directory can be uploaded to GitHub, and you can manage it with Git as usual.

mkdir hugo_blog
code hugo_blog # opens our project in VSCode; if this doesn't work, add the 'code' command to your system

Once our directory is set up, let’s initialize Git to track our changes.

git init

Creating the Configuration for Our Dev Container

After preparing our base project, let’s set up the configuration files for dev containers. These files will be stored in a hidden directory named .devcontainer. Let’s start by creating it.

# Inside our project directory
mkdir .devcontainer

Now, let’s generate the JSON file that VSCode will utilize to configure and create the container for us. This file must be named devcontainer.json and should reside within the .devcontainer directory.

Configuring the Creation of the Container with Hugo

Now, let’s dive into the exciting part: configuring the container creation process with the Hugo toolchain. This step automates the installation of all the necessary components for our project. By doing this, we eliminate the need to worry about configuration and can seamlessly dive into our actual work.

To begin, let’s select a base image for our container. No need to fret about writing any docker-compose or Dockerfile. Everything is taken care of by the dev container.

Microsoft already offers several base images for our dev containers, let’s use their image for our project.

With devcontainer.json, we can specify the VSCode extensions we want installed in our container. Given that we are configuring a Hugo blog, let’s include a spell checker extension.

I’ve opted for alpine, a compact Linux system ideal for containers due to its small memory footprint. Now, let’s incorporate this configuration into our devcontainer.json.

{
    // The name for our Dev Container; note that this is not the actual Docker container name
    "name": "Entangled Dev Blog",
    // We can use any other image as a base, but let's stick with Alpine for this tutorial
	"image": "mcr.microsoft.com/devcontainers/base:alpine",
    // Configure tool-specific properties.
	"customizations": {
		"vscode": {
			"extensions": ["streetsidesoftware.code-spell-checker"]
		}
	},
    // runArgs can execute various commands; here, we use --name to assign a name to our Docker container
    "runArgs": ["--name", "entangleddev_devcontainer"],
}

Great job! Now, to run and work in our dev container, make sure you have the ms-vscode-remote.remote-containers extension installed. Once installed, click on the small >< icon at the bottom left of VSCode and select Reopen in container.

While this approach works, setting up everything manually each time can be tedious. Let’s add some automation to streamline the process. Additionally, we don’t have Hugo installed yet, so there’s a bit more work to be done.

At this point, consider pushing your changes to GitHub. Now, every time you clone your project and open it with VSCode, you can replicate this environment on any computer with Docker.

Installing Hugo

Our devcontainer.json still has some cool tricks up its sleeve—it can run commands once the container is created. This comes in handy for installing the needed dependencies and configuring our environment. To achieve this, we use "postCreateCommand". Unfortunately, this command only accepts a string with all the commands we want to execute in the terminal. Therefore, we’ll create a script to handle all the necessary configurations for us.

Before proceeding, we need to incorporate instructions in our devcontainer.json that will run once the container is created. To do this, replace the existing code in our JSON file with the following updated version:

{
    // The name for our Dev Container; note that this is not the actual Docker container name
    "name": "Entangled Dev Blog",
    // We can use any other image as a base, but let's stick with Alpine for this tutorial
	"image": "mcr.microsoft.com/devcontainers/base:alpine",
    // Configure tool-specific properties.
	"customizations": {
		"vscode": {
			"extensions": ["streetsidesoftware.code-spell-checker"]
		}
	},
    // runArgs can execute various commands; here, we use --name to assign a name to our Docker container
    "runArgs": ["--name", "entangleddev_devcontainer"],
    // Use 'postCreateCommand' to run commands after the container is created.
	"postCreateCommand": "ash .devcontainer/configuration.sh"
}

To install Hugo on Linux, we have several options. For Ubuntu, we could use a Snap (though it might not work inside containers), but we’ll opt for getting a precompiled program from its official GitHub page and configuring it. We’ll be going with the latter.

Let’s start by creating a shell script to handle our configuration. Within the .devcontainer directory, create a new file named configuration.sh and insert the following code:

#!/bin/ash
echo "==> Starting container post-installation"
sudo apk update
sudo apk add --no-cache python3 py3-pip wget git tar
pip3 install requests
python3 .devcontainer/download.py
echo "==> Finished container post-installation"

Here’s a breakdown of what the code accomplishes:

Alpine employs apk instead of apt.
Given Alpine’s minimalist nature, we include the necessary dependencies for our container.
To simplify data retrieval from the GitHub server, we’ll create a Python script named download.py.

Continuing, let’s create our Python script that will handle the download and unpacking of Hugo. Within the .devcontainer directory, create a new file name download.py and insert the following code:

import json
import requests
import os

class HugoInstaller:
    def __init__(self):
        self.response = None
        self.asset_url = ""
        self.keyword = "arm64.tar.gz"
        self.package_name = ""
        self.dir = "/usr/local/bin/hugo_data"


    def start_installation(self):
        self._configure_git()
        self._download_hugo()
        self._unzip_installer()
        self._install_hugo_theme()  


    def _configure_git(self):
        os.system('git config --global user.name "Docker Container"')
        os.system('git config --global user.email "docker-container@local.com"')


    def _download_hugo(self):
        url = "https://api.github.com/repos/gohugoio/hugo/releases/latest"

        self.response = requests.get(url)

        if self.response.status_code == 200:
            json_data = self.response.json()

            assets = json_data["assets"]
            self.asset_url = ""
            
            for asset in assets:
                file_name = asset["name"]
                if self.keyword in file_name:
                    self.asset_url = asset["browser_download_url"]
                    self.package_name = asset["name"]
                    break
            os.system(f"sudo mkdir {self.dir}")
            os.system(f"sudo wget -P {self.dir} {self.asset_url}")
        else:
            print(f"Failed to fetch data. Status code: {self.response.status_code}")


    def _install_hugo_theme(self):
        '''Skip this function if you don't have a theme selected for your Hugo site'''
        os.system("sudo git submodule update --init --recursive")
    

    def _unzip_installer(self):
        hugo_file_path = f"{self.dir}/{self.package_name}"
        os.system(f"sudo tar -xzvf {hugo_file_path} -C {self.dir}")
        os.system(f"sudo mv {self.dir}/hugo /usr/local/bin")
        os.system(f"sudo rm -r {self.dir}")


if __name__ == "__main__":
    installer = HugoInstaller()
    installer.start_installation()

Here’s a breakdown of what the code accomplishes:

HugoInstaller Class Initialization:
- Initializes the HugoInstaller class with default values for properties like response, asset_url, keyword, package_name, and dir.
start_installation Method:
- Calls private methods in sequence to initiate the installation process.
_configure_git Method:
- Configures global Git settings within the container to set user name and email.
_download_hugo Method:
- Fetches the latest release information for Hugo from the GitHub API.
- Parses the JSON response to extract the URL of the Hugo release asset containing the keyword “arm64.tar.gz.”
- Creates a directory (/usr/local/bin/hugo_data) for storing downloaded Hugo assets.
- Downloads the Hugo release asset and saves it in the designated directory.
_install_hugo_theme Method: (warning: call this method with your own theme or skip it altogether)
- Initializes and updates Git submodules, specifically used for installing Hugo themes.
_unzip_installer Method:
- Extracts the downloaded Hugo release asset from its tar.gz format.
- Moves the extracted hugo executable to /usr/local/bin for system-wide access.
- Removes the temporary directory used for the installation process.
__main__ Block:
- Instantiates the HugoInstaller class.
- Invokes the start_installation method to commence the installation process.

Now rebuild your container, and Hugo will be installed. Now, you can start working on your blog inside a container. Commit your changes, and you’re done.

Phew, this was a bit of code, but now you’ve containerized your blog with Hugo. You can clone and start your dev container on any machine you want and begin writing about your awesome development journey.

More Resources

To get more pre-configured images for your dev containers you can check out this GitHub repo by Microsoft here.

Conclusion

This straightforward example serves as a foundation for creating your custom development environment tailored to different purposes. The versatility extends to running docker-compose files for more intricate configurations.

I firmly believe that this stateless approach to local programming will gain increasing significance in the future. It addresses common issues encountered in team collaborations and personal projects by providing a clean system free from pollution. This enables experimentation with diverse tools and languages without compromising our actual systems.

While it’s worth noting a potential drawback of being tied to using VSCode, given its widespread adoption, most developers may find this limitation negligible compared to the considerable benefits.

I hope this inspires you to reconsider your approach to the local programming environment, offering new ways to enhance efficiency and safety in your work or hobby.

Thanks for reading, and happy coding!

How to Create Databases Using Docker

Mon, 18 Sep 2023 19:47:33 -0600

The other day, I needed to set up a PostgreSQL database, and after considering various solutions, I decided to use Docker. In this tutorial, I’ll share the solution that worked for my problem.

Creating a PostgreSQL Database Using Docker Compose

Docker Compose is a powerful tool that allows us to manage multiple containers from a single central point. You might think it’s a bit much for setting up a database, but I found it surprisingly easy to set up and use.

Let’s start!

Creating the docker-compose.yml File

Docker Compose requires a configuration file named docker-compose.yml where we define and configure our containers. Writing this file is straightforward; here’s the one I used for my database:

version: '3'
services:
  postgres-db:
    image: postgres:latest
    container_name: postgres_container
    volumes:
      - "/path_to_local_storage:/var/lib/postgresql/data"
    environment:
      - POSTGRES_DB=my_db
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    ports:
      - '5433:5432'

In the above file:

We define a service named postgres-db containing the PostgreSQL database image.
You can customize the container_name to your preference.
To ensure data persistence and choose a custom storage location, define your preferred local path in the ‘volumes’ section.
Set your database credentials (user, password) and the default database name in the environment section.
The port mapping is configured to use the default PostgreSQL ports. You can adjust this mapping if necessary; the format is local_machine_port:docker port.

Starting the database

To start your database, open a terminal in the directory where your docker-compose.yml is located (or specify a relative path to the file) and run this command (assuming you’re using Docker Compose 2):

docker compose -p example up -d

This command creates the containers defined in the compose file. You can customize the project name with the -p property.

Stopping the database

To stop your database, use this command:

docker compose down

Connecting locally to the database

Connecting to the database locally on your computer is simple. Access http://localhost:5433 using your chosen username and password. While I use DataGrip to connect, any database software can connect to it.

Troubleshooting

During the container creation process, I encountered some common issues, along with their solutions.

Issue: The image exited with code 1.

If your container exits immediately when launched, check the container logs by running:

docker logs my_container_name

I discovered that my data directory contained hidden files that caused this issue. Deleting these hidden files allowed the database to start and function as expected.

Issue: The mounting point is not valid.

If you encounter issues starting the image, it may be related to the local path name. If your path contains spaces, a simple workaround is to enclose the path in double quotes.

Conclusion

By utilizing docker-compose, we can easily start and manage data persistence for our databases. This method provides a straightforward and quick way to create databases with data persistence. I hope this tutorial proves as helpful to you as it was to me.

Happy coding!

Docker on entangledDEV

VSCode Dev Container Configurations

Vapor

Scala

A Simple Full-Stack iOS App Example

Getting Started: Tech Stack Overview

Backend

Framework

Database

App

Coding the Backend

Installing docker

Creating and running the database

Creating the Vapor Container

Creating a barebone Vapor App

Creating the Model for the Database

Installing Fluent and Postgres Driver

Creating our Temperature model

Connecting the Postgres Database to our Vapor App

Creating the Migration file

Setting-up the Postgres Database

Creating the endpoints

Testing our backend

Coding the iOS App

Creating the Model

Creating the Network Layer

Creating the Request Protocol

Creating the Temperature Request

Creating the Network Service Protocol

Creating the Network Service

Creating the View Model

Creating the Views

Creating TitleView

Creating PostTemperaturesView

Creating GetTemperaturesView

Creating RootView

Configuring the Environment Object

Testing the App

Conclusion

Containerize Haskell

What is Haskell

Creating the Haskell dev container

Testing Haskell

Conclusion

Programming inside a Developer Container

What are Dev Containers?

Prerequisites

Creating the Initial Configuration

Creating the Configuration for Our Dev Container

Configuring the Creation of the Container with Hugo

Installing Hugo

More Resources

Conclusion

How to Create Databases Using Docker

Creating a PostgreSQL Database Using Docker Compose

Creating the docker-compose.yml File

Starting the database

Stopping the database

Connecting locally to the database

Troubleshooting

Issue: The image exited with code 1.

Issue: The mounting point is not valid.

Conclusion

Installing `Fluent` and `Postgres Driver`

Creating `TitleView`

Creating `PostTemperaturesView`

Creating `GetTemperaturesView`

Creating `RootView`