Category: Uncategorized

Interest-rate volatility is one of the most important factors anyone considers when taking out or changing their mortgage. One of the main things volatility can influence is the term of the mortgage, which can also vary significantly based on where you live. For example, in areas such as the Netherlands mortgages periods are typically significantly longer than those issued here in the United Kingdom, with 15-20 year terms not being unusual. One rather obvious benefit of this is that purchasers are shielded against rising rates — the inverse being that if rates fall you’re stuck with what you started on. A potentially more subtle downside to this is that you can’t benefit from any changes to your loan-to-value ratio; as you pay your mortgage off your mortgage your LTV decreases which may allow you to apply for better rates. This challenge is further compounded by the fact that you don’t pay a static amount of interest every month due to mortgage amortisation, which we’ll discuss this more below.

Some newer lenders have made efforts to offset this, such as the Dutch firm April who have recently started issuing mortgages which automatically adjust your LTV as you pay them off — though interestingly don’t provide much marketing information on just how much of a difference this can actually make. In the UK, shorter fixed-rate periods are more common so we potentially benefit from LTV changes automatically as fixed period cycles are shorter. Again however, the impact of this in relation to how these changes can interact with your mortgages overall cost isn’t always made abundantly clear. The case we’re going to be discussing here specifically, is how rate-changes can impact your overall mortgage cost can vary quite a bit based on when they happen over the lifetime of the mortgage.

Some context on mortgage amortisation

Mortgage amortisation is the process by which lenders ensure that your mortgage payments remain stable over time. Without this in place, as you paid off more of the principal of the mortgage the percentage of interest being charged each month would amount to a different price as it would constantly be calculated against a different amount.

In order to calculate the overall mortgage schedule, we only need two functions :
i. The total monthly payment each month
ii. The amount that month that is going towards the monthly principal (the amount of interest being the difference)

$${\displaystyle \begin{array}{c}i=interestRate\\ n=numberOfMonthsRemaining\end{array}}$$ $${\displaystyle \begin{array}{c}totalMonthlyPayment=loanAmount({\displaystyle \frac{(i\times (1+i{)}^2)}{(1+i{)}^n-1}})\end{array}}$$ $${\displaystyle \begin{array}{c}PrincipalPayment=totalMonthlyPayment-(outstandingLoanBalance\ast (i/12)))\end{array}}$$

From these we can calculate each month by iteratively calling calc_total_monthly_payment on the balance generated by the previous months output. Quickly testing this, we can see that it works (function implementations below in the main body of the code:

utop # let first_month_total_payment = calc_total_monthly_payment 100000. 0.4 10.
let first_month_principal = calc_total_monthly_principal first_month_total_payment 100000. 0.4
let second_month_total_total_payment = calc_total_monthly_payment (100000. -. first_month_principal) 0.4 9.;;

val first_month_total_payment : float = 11923.3425628468303
val first_month_principal : float = 8590.00922951349639
val second_month_total_total_payment : float = 11923.342562846834

Here we can see that when we recalculate the amount we should be paying each month, it’s outputting the same amount (notice in this case it’s not exactly the same amount, this is due to some floating point arithmetic errors, but it’s good enough for our purposes here, obviously don’t do this in production!).

Main analysis

First, let’s set up a base line case. In this scenario we’re going to imagine a mortgage running with a fixed rate over it’s entire lifetime. To do this we’re going to use the following:

mortgage.ml

open Types
module B = PrintBox

(* stolen from https://github.com/dbuenzli/gg/blob/8f761c278d0b2ee2adb94f9fbc033f1bfd76e536/src/gg.ml#L123-L126 *)
let round_dfrac d x =
  if x -. Float.round x = 0.
  then x
  else (
    (* x is an integer. *)
    let m = 10. ** float d in
    (* m moves 10^-d to 1. *)
    floor ((x *. m) +. 0.5) /. m)
;;

let format_rows (rows : row list) =
  let get_row_arr r =
    let year, month = r.year_month in
    [| B.int year
     ; B.int month
     ; B.float @@ round_dfrac 2 r.payment
     ; B.float @@ round_dfrac 2 r.interest
     ; B.float @@ round_dfrac 2 r.principle
     ; B.float @@ round_dfrac 2 r.loan_balance
     ; B.float @@ round_dfrac 2 r.end_period_balance
    |]
  in
  let rec get_rows rows converted_rows =
    match rows with
    | [] -> converted_rows
    | [ r ] -> get_row_arr r :: converted_rows
    | r :: xr -> get_rows xr (get_row_arr r :: converted_rows)
  in
  let output = get_rows rows [] in
  let output_with_headers =
    Array.of_list
    @@ ([| B.sprintf "Year"
         ; B.sprintf "Month"
         ; B.sprintf "Payment"
         ; B.sprintf "Interest"
         ; B.sprintf "Principle"
         ; B.sprintf "Loan balance"
         ; B.sprintf "End period balance"
        |]
        :: output)
  in
  output_with_headers |> B.grid
;;

let calc_total_monthly_payment principal annual_interest number_of_payments =
  let monthly_interest = annual_interest /. 12.0 in
  let numerator =
    monthly_interest *. Float.pow (1.0 +. monthly_interest) number_of_payments
  in
  let denominator = Float.pow (1.0 +. monthly_interest) number_of_payments -. 1.0 in
  principal *. (numerator /. denominator)
;;

let calc_total_monthly_principal total_monthly_payment outstanding_balance interest_rate =
  let monthly_interest_rate = interest_rate /. 12. in
  total_monthly_payment -. (outstanding_balance *. monthly_interest_rate)
;;

let calculate_rows principal interest_rate term_years =
  let total_number_of_payments = float_of_int @@ (term_years * 12) in
  let calculate_month year month remaining_balance =
    let total_monthly_payment =
      (* calc_total_monthly_payment principal interest_rate number_of_payments *)
      calc_total_monthly_payment principal interest_rate total_number_of_payments
    in
    let monthly_principal =
      calc_total_monthly_principal total_monthly_payment remaining_balance interest_rate
    in
    { year_month = year, month
    ; loan_balance = remaining_balance
    ; payment = total_monthly_payment
    ; interest = total_monthly_payment -. monthly_principal
    ; principle = monthly_principal
    ; end_period_balance = remaining_balance -. monthly_principal
    }
  in
  let rec calc_all_months outstanding_balance year month schedule months_calculated =
    if total_number_of_payments <= months_calculated
    then schedule
    else (
      let next_month_details = calculate_month year month outstanding_balance in
      let next_year = if month == 12 then year + 1 else year in
      let next_month = if month == 12 then 1 else month + 1 in
      let new_outstanding_balance = next_month_details.end_period_balance in
      let updated_schedule = next_month_details :: schedule in
      calc_all_months
        new_outstanding_balance
        next_year
        next_month
        updated_schedule
        (months_calculated +. 1.))
  in
  calc_all_months principal 0 1 [] 0.
;;

let calc_summary principal rows =
  let total_cost =
    let rec calc_total_cost rows sum_so_far =
      match rows with
      | [] -> sum_so_far
      | [ r ] -> calc_total_cost [] (sum_so_far +. r.payment)
      | r :: rs -> calc_total_cost rs (sum_so_far +. r.payment)
    in
    calc_total_cost rows 0.
  in
  { Summary.total_cost;
  principal}
;;

and following plot.ml for plotting our output:

open Owl
open Owl_plplot
open Types

let graph rows =
  let x_axis_months =
    Array.of_list
    @@ List.map
         (fun row ->
           let year, month = row.year_month in
           float_of_int @@ ((year * 12) + month))
         rows
  in
  let end_balance_by_month =
    Array.of_list @@ List.map (fun row -> row.end_period_balance) rows
  in
  let interest_by_month = Array.of_list @@ List.map (fun row -> row.interest) rows in
  let principle_by_month = Array.of_list @@ List.map (fun row -> row.principle) rows in
  let x_axis = Mat.of_array x_axis_months (Array.length x_axis_months) 1 in
  let y_axis_end_balance =
    Mat.of_array end_balance_by_month (Array.length end_balance_by_month) 1
  in
  let y_axis_interest =
    Mat.of_array interest_by_month (Array.length interest_by_month) 1
  in
  let y_axis_principle =
    Mat.of_array principle_by_month (Array.length principle_by_month) 1
  in
  let h = Plot.create ~m:2 ~n:1 "output.pdf" in
  Plot.subplot h 0 0;
  (* Plot.set_foreground_color h 0 50 255; *)
  (* Plot.set_background_color h 0 0 0; *)
  Plot.set_page_size h 1000 1000;
  Plot.(
    plot
      ~h
      ~spec:[ RGB (255, 0, 0); LineStyle 1; Marker "#[0x2299]"; MarkerSize 8. ]
      x_axis
      y_axis_end_balance);
  Plot.(legend_on h ~position:NorthEast [| "remaining-balance" |]);
  Plot.subplot h 1 0;
  Plot.(scatter ~h ~spec:[ RGB (255, 0, 0); LineStyle 1 ] x_axis y_axis_interest);
  Plot.(scatter ~h ~spec:[ RGB (255, 0, 0); LineStyle 2 ] x_axis y_axis_principle);
  Plot.(legend_on h ~position:East [| "interest"; "principle_payment" |]);
  Plot.output h
;;

then our resulting main.ml looks something like:

module B = PrintBox
open Mortgage__Types

let principal = 500000.0
let interest_rate = 0.0591
let term = 20
let rows = Mortgage.calculate_rows principal interest_rate term
let summary = Mortgage.calc_summary principal rows;;

PrintBox_text.output ~style:true stdout @@ Mortgage.format_rows rows;;
print_endline "";;
Mortgage__Plot.graph rows

let () = print_endline (Summary.show summary)

We can see from the configuration in our main, that we’re running against a £500000 mortgage, to be paid over 20 years, at a fixed rate of 5.91%. Running, this produces the following amortisation schedule.

From this we can see that the schedule is doing what it’s meant to be doing; our monthly payments are stable, and we’re slowly paying our way down to a balance of 0. Overall our £500000 mortgage has cost us £853498.

Graphing this out further illustrates this in practice (y = amount paid that month, x = time in months).

This again illustrates the difference in interest vs principal payment accross the lifetime of the mortgage, particularly at the early phase when the bulk of each payment is just going towards interest. In an ideal world we’d want to bring the crossing point much earlier so we’re contributing towards the balance in greater volume earlier on as this will reduce the amount of interest we pay off over the lifetime of the mortgage. To do this we’re going to imagine that each time we calculate the monthly payment, we’re going to recalculate the loan-to-value ratio, and calculate the interest rate based off this. A few changes are required to do this but for brevities sake, let’s just look at the function for calculating interest rate (the full code changes required can be found on my github):

(* static sample rates, pulled from Bank of England data here: *)
(* https://www.bankofengland.co.uk/statistics/visual-summaries/quoted-household-interest-rates                                          *)

let calculate_interest_rate value outstanding_principle =
  let ltv = outstanding_principle /. value in
  if (ltv >= 0.95) then 0.0591
  else if (ltv >= 0.90) then 0.0545 
  else if (ltv >= 0.85) then 0.0503 
  else if (ltv >= 0.75) then 0.0473 
  else  0.0462

Now if we rerun our simulation, we can see the impact of this:

From this we can see a pretty significant reduction in the overall cost of the mortgage by over £61000.

The immediate implications of this are obvious. Factoring in loan-to-value can have a major impact on how much interest you’re paying, which results in more of your monthly payment going towards the loan principle.

In reality it’s obviously not as simple as this and there are countless factors which can be beneficial / detrimental to your individual position, but that’s not to say that this isn’t an unimportant factor. A good example of where this interaction might be beneficial is in areas where asking prices and sales prices don’t match up. Often lenders are restricted to the amount they can lend based on the reported-valuation, forcing buyers to make up the shortfall in cash. Any initial LTV calculation is based off this valuation, however subsequent calculations may be more in line with the sales price, having a significant impact on the LTV. In an environment where interest rates are stable, taking out a shorter term could allow a borrower to re-asses their LTV with their lender earlier, potentially leading to a reduction in rates at an earlier stage in their mortgage.

The code used above is fairly crude in terms of the data it uses but hopefully provides at least a basic illustration of some of the interactions involved. Full source can be found on github.

Please note, any information in the above is not intended nor does it constitute financial, tax, legal, investment, or other advice. Before making any decision or taking any action regarding your finances, you should consult a qualified Financial Adviser.

There’s a couple of choices when looking to build web-servers in OCaml; 2 commonly used choices seem to be postgres and caqti for the database layer, and dream for running the http-server. Both have half decent documentation and a couple of examples in the git repo’s to work off, however caqti recently released a new major version (>2) and dream relies on an older version (<=1.9.0); some fairly hefty breaking changes in this version precludes our using the two together if we want to use the most recent versions of both. One other option for building a web-layer is Opium; this has a very similar, fairly high-level feel to dream. The official docs for opium reference this excellent blog post however again the version of caqti is pretty old; you can get the gist from here but if you’ll run into issues if you try to lift and shift and use caqti >2 so i’ve put together this post which uses the latest version.

Setup

First create a new project

dune init project shorty

Once we’ve got our new project, add the dependencies we’re going to need into our

To install the dependencies we’ll need, update your dune-project file so your dependencies section so it contains the following dependencies

 (depends ocaml dune
  lwt
  lwt_ppx
  core
  caqti
  caqti-lwt
  caqti-driver-postgresql
  ppx_inline_test
  ppx_deriving_yojson
  opium
)

To install all these run opam install ./ --deps-only on your base project directory. This can be run any time you want to add a dependency to this file and saves you running opam install xyz every time. Next, let’s update our project structure a little. Rather than have a single lib directory, to me it makes more sense to split this up as we would in a real project.

mkdir lib/repo
mv lib/dune lib/repo

Our repo directory is going to contain everything we need for interacting with the db layer, so let’s update our library name and add the dependencies we’ll need:

(library
 (name repo)
 (libraries
  caqti
  caqti-driver-postgresql
  caqti-lwt.unix
  yojson
  core
  ppx_deriving_yojson.runtime)
 (preprocess
  (pps ppx_deriving_yojson)))

Next, let’s create a postgres instance we can interact with. In our base directory add a docker-compose.yml file containing the following:

version: '3'
services:
  flyway:
    image: flyway/flyway:6.3.1
    command: -configFiles=/flyway/conf/flyway.config -locations=filesystem:/flyway/sql -connectRetries=60 migrate
    volumes:
      - ${PWD}/sql_versions:/flyway/sql
      - ${PWD}/docker-flyway.config:/flyway/conf/flyway.config
    depends_on:
      - postgres
  postgres:
    image: postgres:12.2
    restart: always
    ports:
    - "5432:5432"
    environment:
    - POSTGRES_USER=example-username
    - POSTGRES_PASSWORD=pass
    - POSTGRES_DB=shorty-db

Note that we’re using flyway for our database migrations; we’re mounting a config file and our migrations directly to this image, let’s create these now:

Create a file docker-flyway.config containing:

flyway.url=jdbc:postgresql://postgres:5432/shorty-db
flyway.user=example-username
flyway.password=pass
flyway.baselineOnMigrate=false

and add a simple migration to get us started to sql_versions/V1__Create_link_table.sql

CREATE TABLE entry (
    short_url varchar(50),
    target_url varchar(50),
    PRIMARY KEY(short_url,target_url)
);

I’ve added the following to a file named nuke_docker_and_restart.sh to allow us to completely tear the db down when we’re done to make it easier to write tests against.

docker-compose rm -f
docker-compose pull
docker-compose up

Running this we can see our database coming up and flyway applying our migrations to create our table to test against.

Database layer and caqti

Before we add our code to interact with the db, i’ve created a Util.ml file containing some helper functions:

let get_uri () = "postgres://example-username:pass@localhost:5432/shorty-db"


let str_error promise =
  Lwt.bind promise (fun res ->
      res |> Result.map_error Caqti_error.show |> Lwt.return)

let connect () =
  let uri = get_uri () in
  Caqti_lwt_unix.connect (Uri.of_string uri)

(** Useful for `utop` interactions interactions. See `README.md`.*)
let connect_exn () =
  let conn_promise = connect () in
  match Lwt_main.run conn_promise with
  | Error err ->
      let msg =
        Printf.sprintf "Abort! We could not get a connection. (err=%s)\n"
          (Caqti_error.show err)
      in
      failwith msg
  | Ok module_ -> module_

Obviously in the real world we would not want to pass in our database credentials like this, but it will do for this example. You can ignore connect_exn, I’ve included examples of how to use this in the repo README.org if you’d like to see how to interact with the db from utop. Next we need to create our Db.ml file, where we’ll house the bulk of our code for interacting with the db.

module Model = struct
  type entry = { short_url : string; target_url : string } [@@deriving yojson]
  type entry_list = entry list [@@deriving yojson]

  let entries_to_json entries = entry_list_to_yojson entries

  let tuple_to_entry tup =
    let a, b = tup in
    let entry : entry = { short_url = a; target_url = b } in
    entry

  let entry_to_json (a : entry) = entry_to_yojson a
end

module Q = struct
  open Caqti_request.Infix

  (*
    Caqti infix operators

    ->! decodes a single row
    ->? decodes zero or one row
    ->* decodes many rows
    ->. expects no row
  *)

  (* `add` takes 2 ints (as a tuple), and returns 1 int *)
  let add = Caqti_type.(t2 int int ->! int) "SELECT ? + ?"

  let insert =
    Caqti_type.(t2 string string ->. unit)
      {|
       INSERT INTO entry (short_url, target_url)
       VALUES (?, ?)
      |}

  let select =
    Caqti_type.(unit ->* t2 string string)
      {|
       SELECT short_url
            , target_url
       FROM entry 
      |}
end

let add (module Conn : Caqti_lwt.CONNECTION) a b = Conn.find Q.add (a, b)

let insert (module Conn : Caqti_lwt.CONNECTION) short_url target_url =
  Conn.exec Q.insert (short_url, target_url)

let find_all (module Conn : Caqti_lwt.CONNECTION) =
  let result_tuples = Conn.collect_list Q.select () in
  Lwt_result.bind result_tuples (fun xs ->
      let out = List.map Model.tuple_to_entry xs in
      Lwt_result.return out)

let resolve_ok_exn promise =
  match Lwt_main.run promise with
  | Error _ -> failwith "Oops, I encountered an error!"
  | Ok n -> n

Let’s break this down a little. First up we have our Model module. In here we’ve housed a couple of basic types. Note that we’ve added [@@deriving yojson] to the back of these; this is a language extension which automatically generates functions for converting to and from json (eg entry_to_yojson ), thus why there’s nothing manually declared with these names!

Next we’ve declared our Q module where we’re adding our queries. Let’s break one of our queries down to clarify exactly what’s going on (I’ve added the return type to the declaration so it’s a little clearer what we’re creating):

  let insert: (string * string, unit, [ `Zero ]) Caqti_request.t =
    Caqti_type.(t2 string string ->. unit)
      {|
       INSERT INTO entry (short_url, target_url)
       VALUES (?, ?)
      |}

One thing to note: Caqti_type.(stuff) is an example of ocaml’s “local open” syntax; effectively all this is doing is

let open Caqti_type in 
stuff

to give us access to Caqti_type‘s scope. Within this scope we can access t2. This function consumes some local types and returns a function

?oneshot:bool -> string -> (string * string, unit, [ `Zero ]) Caqti_request.t

which we then pass our sql statement into. I think it’s worth calling out here the parameters we’re passing to t2 and ->. (ie string string & unit) and not OCaml primitives; In this context string and unit refer to local type declarations within Caqti_type with specific meanings; the docs for these are here. Apparently this is an intentional design pattern however I’ll admit a wariness to this; to me it feels like it’s going to create code that’s more difficult to read. Our Caqti_request.t output is parameterised by (string * string, unit, [ Zero ]) which gives us a nice clear description of how to use our insert request; it takes a tuple of two strings and returns unit. Again, it’s worth noting that OCaml’s syntax for type parameters is “backwards” compared to a lot of languages — eg where in something like scala we’d write List[String] in OCaml this would be String List.

In the next block we’re simply writing some functions which consume connections and some parameters and proxy these through to our queries.

At this point we’ve got some queries which we can use to interact with the database, let’s write some tests to make sure they work. Using the same directory structure as before, we’ll add our tests under lib/repo/db.ml and add our dependencies under lib/repo/dune:

(library
 (name repo_test)
 (inline_tests)
 (libraries repo)
 (preprocess
  (pps ppx_inline_test ppx_assert)))

and

 open Repo.Db.Model

let str_error promise =
  Lwt.bind promise (fun res ->
      res |> Result.map_error Caqti_error.show |> Lwt.return)

let drop_id_from_entry triple = (triple.short_url, triple.target_url)

let%test_unit "PostgreSQL: add (asynchronously)" =
  let ( => ) = [%test_eq: (Base.int, Base.string) Base.Result.t] in
  let will_add a b =
    let ( let* ) = Lwt_result.bind in
    let* conn = Repo.Util.connect () |> str_error in
    Repo.Db.add conn a b |> str_error
  in
  Lwt_main.run (will_add 1 2) => Ok 3

let%test_unit "Able to add to the database" =
  let ( => ) =
    [%test_eq:
      ((Base.string * Base.string) Base.list, Base.string) Base.Result.t]
  in
  let input_url = "hello" in
  let target_url = "Arnie" in
  let add_entry =
    let ( let* ) = Lwt_result.bind in
    let* conn = Repo.Util.connect () |> str_error in
    let* _ = Repo.Db.insert conn input_url target_url |> str_error in
    Lwt_result.bind (Repo.Db.find_all conn) (fun res ->
        Lwt_result.return @@ List.map drop_id_from_entry res)
    |> str_error
  in
  Lwt_main.run add_entry => Ok [ (input_url, "Arnie") ]

To run these:

$ ./nuke_docker_and_restart.sh
# and in another window
$ dune runtest

At this point we’ve got everything we need up and running to interact with our little database, now we’re ready to add our Opium layer. This part is fairly simple, we could add to a lib/controllers/ repo but for the sake of simplicity we’re just going to add everything to our bin/main.ml file and bin/dune the requisite dependencies.

(executable
 (public_name shorty)
 (name main)
 (libraries repo lwt opium)
 (preprocess
  (pps lwt_ppx)))

open Opium
open Repo
open Repo.Db

let convert_to_response entries =
  let as_json = Response.of_json @@ Model.entries_to_json entries in
  Lwt_result.return as_json

let find_all _ =
  Logs.info (fun m -> m "Finding all");
  let get_all =
    let ( let* ) = Lwt_result.bind in
    let* conn = Util.connect () in
    let entries = Db.find_all conn in
    Lwt_result.bind entries convert_to_response
  in
  Lwt.bind get_all (fun r ->
      match r with Ok r -> Lwt.return r | Error _ -> raise @@ Failure "")

let put_entry req =
  Logs.info (fun l -> l "adding entry");
  let insert =
    let open Lwt.Syntax in
    let+ json = Request.to_json_exn req in
    let entry = Model.entry_of_yojson json in
    (* manually declare let* as from Lwt_result as it's also available on the base Lwt *)
    let ( let* ) = Lwt_result.bind in
    let* conn = Util.connect () in
    match entry with
    | Ok e -> Db.insert conn e.short_url e.target_url
    | Error e -> raise @@ Failure e
  in
  let bind_insert insert_response =
    Lwt.bind insert_response (fun bind_response ->
        Lwt.return
        @@
        match bind_response with
        | Ok _ -> Response.of_plain_text "Hooray"
        | Error _ ->
          (* This isn't brilliant, ideally we'd handle different excpetions with specific/ sensible http code *)
            Response.of_plain_text ~status:`Bad_request
              "Oh no something went terribly wrong")
  in

  Lwt.bind insert bind_insert

let _ =
  Logs.set_reporter (Logs_fmt.reporter ());
  Logs.set_level (Some Logs.Info);
  Logs.info (fun m -> m "Starting run");
  App.empty |> App.get "/entry" find_all |> App.put "/entry" put_entry
  |> App.run_command

Opium has a really simple api; App.get and Api.put both have signature

string -> (Request.t -> Response.t Lwt.t) -> App.t -> App.t

where the first parameter is the route we’re binding to then the handler function to call.

Spinning up our app we’re now able to add and view entries in our db over our new server:

# first window 
$ dune exec -- shorty
# second window
$ ./nuke_docker_and_restart.sh
# third window
$ http PUT 127.0.0.1:3000/entry short_url=hello target_url=vinnie
HTTP/1.1 200 OK
Content-Length: 6
Content-Type: text/plain

Hooray

$ http 127.0.0.1:3000/entry
HTTP/1.1 200 OK
Content-Length: 45
Content-Type: application/json

[
    {
        "short_url": "hello",
        "target_url": "vinnie"
    }
]

# send the same value again to test our exception handling
http PUT 127.0.0.1:3000/entry short_url=hello target_url=vinnie
HTTP/1.1 400 Bad Request
Content-Length: 26
Content-Type: text/plain

Oh no something went terribly wrong

Conclusion

Opium and Caqti have both proven really nice libraries to work with, albeit in this simple example. Both are extremely lightweight and easy to get up and running quickly with. I’ve pushed the changes up to github, hopefully this provides an easy-to-use sample project for anyone looking to serve up an api in OCaml.