This is the first of 5 posts in this series.

• Part 0: Introduction (this post)
• Part 1: The User Interface - A look at htmx and Giraffe working together to create the web UI
• Part 2: Bootstrap Integration - A little bit of JavaScript goes a long way
• Part 3: The Data Store - Migration to and usage of LiteDB
• Part 4: Conclusion - Lessons learned and areas for improvement

Background

Around 3 years ago, I wrote an 8-part series called “A Tour of myPrayerJournal”, recounting the decisions and implementation of its initial release. Version 2 did not get its own tour, as it used a similar architecture. There were also some nagging library issues that were never resolved, leading to v2 being an overall unsatisfying step in the evolution of this application.

When Vue v3 was announced, this sounded like a great opportunity, with first-class TypeScript support and a new component syntax that promised better performance and a better developer experience. This past summer, I completed a project with the mature Vue v3 framework, and was generally pleased with the results. Just after I returned to my previously abandoned migration attempt on this project (with early Vue v3 support), I heard about htmx. With a few attributes, and a server that can handle a few HTTP headers, you can build an interactive site, with performance rivaling or exceeding that of the typical Single Page Application (SPA) - or, at this point, so they claimed.

I also picked up LiteDB on another project over the summer, and it worked well. I thought, why not give these technologies a try, and see if I would like the result?

(SPOILER ALERT: I did!)

The Requirements

Requirements for v3 were, for the most part, to update the application to Vue v3. Without rehashing the entire list (see the other intro post), the basic idea is that a prayer request is represented by a card, and this card keeps up with all changes made to it. Also, the system can present the cards that are active, arranged with the oldest action date first, and allow you to tick through the cards. (This is the flow to enable the user to "pray through their list.")

The goal is to remain a minimalist program; the focus should be on prayer, not using a website. To that end, I had envisioned a “one-at-a-time” scenario that would clear out distractions and present the cards in the same order. I had also planned to separate the “last prayed” date from the “last activity” date; currently, updating the text of a request moves it to the bottom of the stack. However, both of these improvements were deferred to v3.1; v3 restores the (adequate) functionality of v1, while being much lighter-weight.

The Tech Stack

This stack did not go through nearly as many iterations as v1.

Giraffe is a library that enables F# developers to create ASP.NET Core endpoints in a functional style. It's a mature library (v1 used Giraffe!), and continues to be improved. It also provides an optional “Giraffe View Engine,” which will get more attention in the user interface post; the views for v3 are produced via this view engine.

htmx is a JavaScript library that asks… well, several questions. Why should links and buttons be the only interactive elements? Why should you have to replace the whole page every time? What would HTML look like if it had been developed the way a typical programming language would be? It uses a small set of attributes to answer these questions differently, making interactive sites possible without writing any JavaScript. (The custom JavaScript file in v3 is 82 lines, including comments - and the majority of that is Bootstrap interaction.)

Since, in the htmx way, the web server returns rendered HTML, the requests can be a bit larger than the equivalent API calls that return JSON for a SPA framework to render. However, this is offset somewhat by the fact that the browser just has to swap that HTML fragment in; the processing is faster and much less complex.

What really swung me over the fence to giving it a shot, though, was a point Carson (the author of the library) made while talking with Carl and Richard on the .NET Rocks! podcast. Having a server render the HTML, and the browser merely displaying it, keeps your application logic on the server; the only JavaScript you need to write is what is required for the user interface. This eliminates a host of synchronization issues with SPAs and their associated APIs - duplicating shapes of data, ensuring calculations are in sync, etc. It also keeps your application logic from needing to be exposed to the public Internet; this doesn't entirely prevent exploits, but the prospective hacker doesn't start with a full copy of your code.

LiteDB could be described as SQLite for documents. Collections of Plain-Old CLR Objects (POCOs) can be stored, retrieved, searched, indexed, and deleted, all while running in the current process, and requiring no separate database server install. While it does not require any special configuration to do this, it does also provide the ability to transform these objects. This gives complete control as to how much or how little transformation you want to specify; and, as we'll see in part 3, this came in handy for this application.

Where We Go from Here

In the next post, we'll take a look at Giraffe, its View Engine, htmx, and how they all work together. The post after that will dive into the aforementioned 82 lines of JavaScript to see how we can control Bootstrap's client/browser behavior from the server. After that, we'll dig in on LiteDB, to include how we serialize some common F# constructs. Finally, we'll wrap up the series with overarching lessons learned, and other thoughts which may not fit nicely into one of the other posts.

Recently, we released version 1.0 of myPrayerJournal, a minimalistic prayer journaling application. This series aims to provide a tour of the code, with several stops along the way:

• Part 0: Introduction (this post)
• Part 1: The Front End - Vue components and routing
• Part 2: State in the Browser - Vuex and getting information from an API
• Part 3: The API - Giraffe and JSON web endpoints
• Part 4: Authentication - Auth0, using information in both app and API
• Part 5: The Data Store - EF Core backed by PostgreSQL, with the DbContext defined in F#
• Part 6: Documentation - GitHub Pages generated on each commit
• Part 7: Conclusion - Lessons learned and opinions based on the development experience

From a technical perspective, this application was going to be a learning experience. We knew we wanted to use a Single Page Application (SPA) framework with an API; we'd built APIs before, but had yet to build a SPA. For front-end frameworks, we started with Angular, went through Aurelia and Elm, then decided on Vue. For the back-end API, we started with Suave, then went live on Node.js with Koa; later, we moved it to Go, and after .NET Core 2.1 was released, landed on Giraffe. The “learning experience” part was a success; through all these attempts, we utilized 5 different languages and 3 different database access techniques.

To understand the requirements, a short explanation of the process will help. “Prayer journaling” is a discipline where a person will write down the things for which they are praying; this provides a defined list to help guide their prayer, and helps them not forget things. Then, as the situation changes, they can record updates, through to the resolution of the situation (also called the request being “answered”). This discipline not only helps to focus efforts, it also provides a record of requests and answers. Although people have successfully used a notebook, or something similar, for a long time, that approach does have some downsides:

• For long term requests, you can run out of room for updates.
• A physical journal can only be in one place at one time.
• Answered requests coexist with unanswered requests, so you have to flip pages past them.
• Books can end up under stacks of other things, falling victim to “out of sight, out of mind.”

Looking to address some of those, the initial requirements started as the first three bullets below. The remaining requirements emerged through using the application as it was being developed.

• List unanswered requests, in a way that they can be marked as prayed or answered, and be updated
• List answered requests, and allow full requests (and their history) to be viewed
• Do the above in a way that will not be distracting
• Allow notes to be recorded for a request; not every update on a situation requires a change in the verbiage of the request
• Allow requests to be “snoozed” (removed from the journal, with a specified date when they will reappear), and list snoozed requests so that the snooze can be expired (returning the request to the journal immediately)
• Allow requests to be prioritized (this became the request recurrence feature)

Armed with these requirements, we will pick up next time with a look at the Vue front end.

Back in 2010, we wrote a web service for the 40/40 Prayer Vigil organized by the Ethics and Religious Liberty Commission of the Southern Baptist Convention. This allowed us to use the content in multiple places. They are doing another vigil this year, but the service we wrote two years ago was not terribly reusable.

This year, we have developed a reusable web service that should hold up for 2014 and beyond. (Acronym alert - non-programmers skip the next sentence.) This one has a REST API instead of SOAP and WSDL, and supports XML, JSON, and HTML output formats. This year, it also supports both English and Español.

The REST API start page is at this URL no longer active. The prayer guides require an output format, a language, the Scripture version, whether the guide is for a day or an hour, and the day or hour number. There are lookup transactions for lists of available output formats, languages, and Scripture versions, and lookups for converting a date to a day number and a date/time to an hour number.

There will be a WordPress plug-in shortly that will utilize this to display the current day or hour's prayer guide directly on your blog; we'll make another post when that is available. Also, starting September 26th (the first day of the vigil), it will be available for display with no login required at the Hoffmantown Prayer and PrayerTracker websites. Developers, the service is available now; if you want to write code to utilize the service, you've got 3 months to make it work!

The Ethics and Religious Liberty Commission of the Southern Baptist Convention is holding a “40/40 Prayer Vigil,” encouraging prayer through the end of October. While some of the prayer is focused on the upcoming elections, the focus is on national revival. They have produced a prayer guide, which details suggestions for prayer over the course of 40 days, beginning September 20th, and for 40 hours, beginning October 29th at 4pm.

We have created a web service to break this guide up into day and hour-sized chunks. The service is at this URL no longer active. There are several ways to retrieve this information.

• GetDay
  This gets one of the 40 days, by the day number. (September 20th is 1, September 21st is 2, etc.) The “day” parameter controls which day is returned.
• GetHour
  This gets one of the 40 hours, by the hour number (10/29 4pm is 1, 10/29 5pm is 2, etc.) The “hour” parameter controls which hour is returned.
• GetDate
  This gets one of the 40 days, by the current date. The “date” parameter controls which day is returned. (The time portion may be given, but it is ignored.)
• GetTime
  This gets one of the 40 hours, by the date/time. The “time” parameter controls which hour is returned.
• GetDayHTML, GetHourHTML, GetDateHTML, and GetTimeHTML
  This is the same as the above 4 calls, except what is returned is a formatted block of text that can be displayed on a web page.

In all cases, if the day/hour/date/time does not match a valid value for the vigil, a null is returned.

If you're not interested in consuming the web service, but you'd like to see the suggested prayer each day, the Hoffmantown Prayer site is displaying the days and hours on Mountain Time. This information is on the front page with no login required.

This web service will be discontinued at some point after December 31, 2010.