DEV Community: XetiCode LLC

The 10 Commandments of AI

Dirk Johnson — Tue, 16 Apr 2024 21:53:38 +0000

When I graduated high school in the mid-80s, MIT was convinced AI was going to change the world in the next decade. Well… they were only 3 decades off - not bad really.

I went into software engineering after high school, but not with a focus on AI. Most of my career has been in the full-stack application space. However, I have tried to keep up to date with AI and its progress, especially over the last 10 years.

After 28 years as a software engineer at Apple, I left to start my own consulting company. Recently, I desired to discuss with my engineers some of the serious ramifications, both good and bad, of AI. From that desire and the subsequent conversations came something akin to Asimov's Three Laws of Robotics, however, I title these the 10 Commandments of AI.

The overriding goal of these commandments are two fold:

Preserve sovereign Humanity and all that Humanity represents while allowing AI to push humanity forward
Establish clear responsibility on Humanity for all AI Informances and Performances

Though the term "commandment" might connote otherwise, these '10 Commandments of AI' are not proposed in their finality but in their genesis; as critical points of conversation that must be considered, debated, and refined.

Many of these commandments will be difficult to accept in today's AI environment. But I believe each commandment has its wisdom, even if its current form is not ideal.

I know there are many groups and organizations dedicated to creating and using AI with the proper consideration and constraint that are deserving of those who put the necessity of a sovereign Humanity above every other consideration, be that wealth, discovery, or power. To these efforts, I add these 10 Commandments of AI for consideration.

The 10 Commandments of AI

Where the commandments may conflict, consider these commandments in order of precedence.

The AI Commandments of Performance

AI Shalt Not Perform any Action that would intentionally endanger Human Life
AI Shalt Not Perform without direct Human Command
AI Shalt Perform exactly the given Human Command, the whole Command, and nothing but the Command

The AI Commandments of Informance

(4) AI Shalt Inform when Human Command could endanger Human Life
(5) AI Shalt Not Inform without direct Human Query
(6) AI Shalt Inform exactly the requested Human Query, the whole Query, and nothing but the Query

The General Commandments of AI

(7) AI Shalt Not Learn from, Query, nor Command another AI
(8) AI Shalt always fully Identify itself in all Learnings, Informances, and Performances
(9) AI Shalt Not Learn, Inform, nor Perform outside of its Limited Immutable Domain
(10) AI Shalt always keep a complete Log of past Learnings, Informances, and Performances

Using Fission with Elm - Part 3: Adding authentication and using the Fission Drive

Verge729 — Tue, 09 Nov 2021 01:22:08 +0000

[UPDATE] The Fission team released fission-suite/webnative-elm version 7.0.0 since the original publish date of this article. This update includes a sign out function. The following sections of the article have been changed to reflect this update: `Walkthrough/Authentication/'Prep work'`and `Walkthrough/Authentication/'Signing out'`. This article no longer makes any changes to the `js/index.js` file as defined in `Fission with Elm - Part 2`.

Make sure the npm and elm-module packages for `webnative-elm` are at 6.1.0 and 7.0.0, respectively. To update them, run the following from the root of the project:

npm install --save-dev webnative-elm
npx elm-json install fission-suite/webnative-elm

Prelude

This is a three-part series. In part one, I showed you how to use Vite to manage an Elm application. In part two, I showed you how to integrate the basics of Fission via the Webnative SDK into the project. In part three (this article), I will show how to add authentication and storage via the Webnative SDK to the application. This article is written assuming the developer already has a Fission account and has completed parts 1 and 2.

It should be noted that the last two articles were fairly short. Both have set the stage for this article, the pinnacle of the series. There will be much to add to our growing application, some of these additions are due to Elm being a strongly typed language.

It should also be noted that if you are using a browser that using something similar to Brave Shields in the Brave browser, you will need to disable the feature so Fission can communicate with the application.

This article will also require the use of a Fission account. If you do not yet have one, take a moment to create one now. Check Appendix A at the end of this article for steps on how to do so.

The Github repository associated with this article can be found here:

https://github.com/xeticode/fission-with-elm-demos/tree/Part-3

Intro

Welcome to the final article. Here you will be tested beyond anything you have ever experienced… Nah, this is not some epic set of trials. That being said, it is my hope that by the end of this article, you have been exposed enough to Fission to continue on in your own Fission-based applications.
It is time to add some usefulness to this application. Right now, it is like a wallpaper: good to look at and not much else. The first feature we will add is user authentication. After authentication, we will add code that will interact with the Fission Drive to write a file to storage. There are no introductions to be made this go-around, so we will review important concepts for what I am about to show you.

Things to review

elm ports are the medium by which an Elm application communicates with JavaScript. For more information, see Elm Ports .
IPFS "is a distributed system for storing and accessing files, websites, applications, and data". For more information, see IPFS .
Wnfs stands for Webnative File System and "is a file system built on top of the (IPFS)". For more information, see Webnative File System .
Fission Drive is a military-grade encrypted file system located within a distributed network. For more information, see Fission Drive .
Let us begin!

Walkthrough

Download an updated Main.elm by running this command in the terminal from the src directory:

curl -o Main.elm https://raw.githubusercontent.com/xeticode/fission-with-elm-demos/interim/part-3/Main.elm

This new Main.elm file lays down some new groundwork for our application. It is also divided into sections, the dividers being noticeable comments. Instead of indicating a line in the file to add or find code, I will indicate a region of the code to look. The differences between the new file versus the old one includes additions to our type alias Model, type Msg, and update function (see section: MODEL/UPDATE); a section for helper functions (see section: HELPER FUNCTIONS); and a new UI (see section: VIEW). Let’s quickly go over the new Msg variants and the Model.

`Msg` variants

Here are the new variants and their purposes:

SignIn will be associated with the login button and will initiate the login process with Fission.
SignOut will be associated with the logout button and will initiate the logout process with Fission.
UpdateNote is the variant that will update the note field in the Model. This is the value that will be written to the Wnfs.
SaveNote is associated with the Save Note button and will initiate the process of writing and publishing our note to the Wnfs.

`Model`

Here is a breakdown of the new fields in Model:

username will store the username of the logged-in Fission user of the current session (if you are not familiar with the Maybe type, or simply need a refresher, see Maybe).
logs is a list of strings and will store log entries associated with the different stages of interaction with Fission. These will be displayed on the left side of the screen. Consider these as a log that make it easier to see the processes when they occur.
note this will store the content that will be sent to the Wnfs.

Before we dive in

Run npm run dev from the root of the project to have the application up and running on the dev server. Once you do this, you should see this:

At this point, you can click on the login button, but it will not take you anywhere. Its associated message, SignIn, is currently a dead end. Not to worry, the first thing we will do is implement authentication.

Authentication

Prep work

One of the reasons my meals are so simple and quick is my hungry stomach will usually override my willingness to spend time on quality meal prep. Lucky for us, this is not a food situation. Before we can sign in, we must add a few things, a metaphorical meal prep, if you will, before we can dig into authentication.

The first thing we must do is expand the GotWebnativeResponse branch in our update function. To begin, replace the current GotWebnativeResponse branch (section: MODEL/UPDATE, function: update) with the following code (be aware, the alignment may change when copying and pasting into your developing environment. You will get the red squiggles if the case statement branches are mis-aligned):

GotWebnativeResponse response ->
    case Webnative.decodeResponse tagFromString response of
        Webnative (Initialisation state) ->
            case state of 
                NotAuthorised ->
                    ( { model
                        | username = Nothing
                        , logs = "Auth: NotAuthorised" :: model.logs
                    }
                    , Cmd.none
                    )
                AuthSucceeded { username } ->
                    ( { model
                        | username = Just username
                        , logs =  "Auth: AuthSucceeded" :: model.logs
                    }
                    , Cmd.none
                    )
                AuthCancelled _ ->
                    ( { model
                        | username = Nothing
                        , logs = "Auth: AuthCancelled" :: model.logs
                    }
                    , Cmd.none
                    )
                Continuation { username } ->
                    ( { model
                        | username = Just username
                        , logs = "Auth: Continuation" :: model.logs
                    }
                    , Cmd.none
                    )

        Wnfs _ _ ->
            ( model, Cmd.none )


        Webnative (Webnative.NoArtifact SignedOut) ->
            ( { model
                | logs = "Signed out!" :: model.logs
                , username = Nothing
            }
            , Cmd.none
            )

        Webnative (Webnative.NoArtifact _) ->
            ( model
            , Cmd.none
            )

        WebnativeError err ->              
            ( { model
                | logs = Webnative.error err :: model.logs
            }
            , Cmd.none
            )

        WnfsError err ->
            ( { model
                | logs = Wnfs.error err :: model.logs
            }
            , Cmd.none
            )

That is a lot of new code, and some of it is accompanied by our friendly neighborhood red squiggles. This is due to missing proper imports and a definition for tagFromString, which is a helper function. Let's resolve the problem starting with the imports.

Go to the import block at the top of Main.elm. Near the bottom of the import block at the top of the file, we have our Webnative import and it is currently exposing Artifact(..) and all its variants (represented by the (..)). Replace this import with:

import Webnative exposing (Artifact(..), NoArtifact(..), DecodedResponse(..), State(..))

Adding these to the exposing list will allow us access to the DecodedResponse and State types from the Webnative-elm module (see DecodedResponse and State).

Now we will define tagFromString. In the HELPER FUNCTION section, add the following code:

tagFromString : String -> Result String Tag
tagFromString str =
    case str of
         _ ->
            Err <| "Invalid tag: " ++ str

Webnative-elm utilizes tags to differentiate between different requests and connect the appropriate response. For example, if I sent a webnativeRequest tagged with “StudioGhibli”, the associated webnativeResponse will have the same tag. We can then create a branch within our GotWebnativeResponse branch’s case statement and dictate how to handle the response.

Now, both webnativeRequest and webnativeResponse require the tag to be a string not an Elm type. That is why we need such helper functions as tagFromString and its companion tagToString. Extra code on our part, yes. This is a byproduct of Elm, not the webnative-elm wrapper. In fact, this is great design by the people behind the wrapper because it couples the Webnative SDK with the strengths of Elm.

Speaking of an Elm type for our tags, we now have another red squiggle to take care of, this time on Tag. Add the following code between the type Msg and update function:

type Tag
    = ChangeMeLater

This is where we define our different webnativeRequest tags. To reiterate, we will return to this later when it is time to utilize our Tag type. We need to define Tag now so we can proceed with the rest of what the GotWebnativeResponse has to offer.
We are now ready to officially sign in!

Signing in

This is where having a Fission account is crucial. If you have yet to do so, stop and take a moment to create a Fission account (see Appendix A at the end of this article for details).

The application is growing up so fast. To implement sign in, go to the SignIn branch of the update function (section: MODEL/UPDATE) and replace Cmd.none with the following code:

permissions
    |> Webnative.redirectToLobby Webnative.CurrentUrl
    |> webnativeRequest

This will take our permissions (defined in part 2 of this series) and pass it to the Webnative function redirectToLobby.

Time to see it in action! Refresh the app in the browser and click "Login"! This will take us to a Fission authorization lobby. You will see something like this:

This lobby utilizes the appPermissions and fsPermissions we defined at the beginning of the Main.elm file. If there are no defined fsPermissions (like with this application), the only permission request will be for the file path generated for the application. Once you grant permission, authentication will finish.

Rather than using traditional username and password authentication (such as OAuth), Fission uses cryptographic keys and stores them in a browser you authorize with your Fission account (you can authorize multiple browsers on multiple machines). See Webnative Authentication for more information.

Once you have logged in and granted permission for the app to access Trillian/fission-with-elm (aka creator/name as specified in appPermissions located in the beginning of section: FISSION SETUP) in your Fission Drive, you will see this simple web page:

Before we implement signing out, I want to give a quick walkthrough of this application.

The UI

Under the “Fission with Elm” title, there are two oval-esque elements. The one on the left should display the Fission logo and your Fission username, and the one on the right is a logout button.

On the far-left side of the screen, you will see “Auth: AuthSucceeded”. When you save a note, more logs will appear here, allowing you to see the process of writing to a Fission Drive.

The center of the screen has a textbox where you can write a note and a “Save Note” button below it that will write the note to your Fission Drive. This functionality will be implemented after sign out.

In the bottom right corner, there should be a little blue rectangle which displays the Elm logo and a number. This is a button that will open the Elm debugging window.

Anyways, on to the implementation of signing out!

Signing out

The webnativeRequest port supports two types methods of signing out: Webnative.leave and Webnative.signOut (see Webnative, in the section named "Authentication").

Webnative.leave will redirect the user to a Fission logout lobby, which looks like this:

Webnative.signOut will not redirect the user to a Fission logout lobby.

To add sign out functionality, go to the SignOut branch in the update function and replace the current version of it with:

SignOut ->
    ( { model
        | username = Nothing
        , logs = "SignOut" :: model.logs
    }
    , Webnative.signOut
        |> webnativeRequest
    )

Bah-duh bing, bah-duh boom! We can now sign in and sign out! Time to see it in action. Go ahead and test the app by logging in and logging out! Pretty cool!

Next up on the docket is writing to a Fission Drive, let us dive in!

Data Storage

Writing to the Wnfs is a two-step process:

Write the data to a file and save it in the Wnfs in the local browser storage
Once saved locally, replicate and encrypt the data and store it in the Wnfs on the IPFS network

The following diagram depicts the write process within the context of our application:

The three circles in the elm app section represent Msg and Tag variants and are milestones in the writing process. We begin by calling the SaveNote Msg variant and end in handling a tagged webnativeResponse with our PublishNote Tag variant.
We need to do the following to replicate this process in our application:

type Tag
- Finish defining the variants for the Tag type. Once this is done, we can tag requests and appropriately handle the associated responses.
Helper functions
- Write several helper functions to help with encoding the data and using tags.
update function
- Update various case statement branches to accommodate saving a note.

Once we get through that, our application will be complete. Let’s get started!

type Tag

This is our current state of our Tag type:

type Tag
    = ChangeMeLater

We need to swap the current variant from ChangeMeLater with two new variants: WriteNote and PublishNote. This will allow us to handle responses to the write and publish requests.

Change the type Tag to look like this:

type Tag
    = WriteNote
    | PublishNote

Helper functions

Two of these helper functions (tagFromString and tagToString) are needed simply because Elm is a strongly typed language and does not have a native way to convert type variants to strings. This gives us extra work to do before we can accomplish our goal. Fortunately for this application, our application is small and will not require much of this kind of code.

The other two helper functions (encode and save) are for encoding our note and preparing it as a Webnative.Request.

tagFromString

We can now properly finish the implementation of this function! This will allow us to convert our Type variants to strings. Replace the half-baked tagFromString with the following full-baked code:

tagFromString : String -> Result String Tag
tagFromString str =
    case str of
        "WriteNote" ->
            Ok WriteNote

        "PublishNote" ->
            Ok PublishNote
        _ ->
            Err <| "Invalid tag: " ++ str

tagToString

As promised, here is the second helper function for the tags. This will convert a Tag into a String so we may add it to the webnativeRequest. Make sure to get the spelling right AND that it matches the spellings used in tagFromString function. Add this code to the HELPERS section of the file:

tagToString : Tag -> String
tagToString tag =
    case tag of 
        WriteNote ->
            "WriteNote"
        PublishNote ->
            "PublishNote"

encode

This application will write our note to a JSON file. This next helper function will JSON encode our note. Add the following code to the HELPERS section of the file:

encode : String -> Json.Encode.Value
encode note =
    Json.Encode.object
        [ ("note", Json.Encode.string note)            
        ]

save

This function will take the pieces we have made in this portion of the walkthrough and use them to initiate the writing process. It will first take our note and encode it to a JSON value, prettify it, and then write it to a specified file with an associated Tag. Add the following code to the HELPERS section of the file:

save : String -> Webnative.Request
save note =
    note    
        |> encode
        |> Json.Encode.encode 0
        |> Wnfs.writeUtf8
            Wnfs.Private
            { path = Path.file [ "Apps", "Trillian", "fission-with-elm", "notes", "note.json"]
            , tag = tagToString WriteNote
            }

update Function

The prep work has been laid, now we need to establish some milestones. The writing process will begin when we click the “Save Note” button, which will send a webnativeRequest tagged with WriteNote. We will then handle the associated response and then send one more webnativeRequest tagged with PublishNote. The final step will be handling the associated response.

SaveNote msg

To begin, we need to change the Cmd.none in our SaveNote update branch to a Cmd that calls our webnativeRequest port. Replace Cmd.none with the following:

webnativeRequest <| save model.note

This will begin our interaction with Webnative by writing our note to a file and then writing it to our Wnfs. The next step is to handle the response.

WriteNote handler

Our WriteNote response will be caught by our subscription to the webnativeResponse port and be redirected to the GotWebnativeResponse Msg variant. Add the following branch to GotWebnativeResponse, just before the Wnfs _ _ branch:

Wnfs WriteNote _ ->
    ( { model
        | logs = "Note Written..." :: model.logs
    }
    , ({ tag = tagToString PublishNote }
        |> Wnfs.publish
        |> webnativeRequest)
    )

This code block will add an entry to our model’s list of logs and then chain a new request to publish our updated Wnfs.

PublishNote handler

Our PublishNote response will again be caught by our subscription to the webnativeResponse port and be redirected to the GotWebnativeResponse Msg variant. In GotWebnativeResponse, replace the Wnfs _ _ branch with the following:

Wnfs PublishNote _ ->
    ( {model
        | logs = "Note Published to Fission Drive!" :: model.logs
        }
    , Cmd.none
    )

This code block will add an entry to our model’s list of logs and then do nothing because the process of writing our note to the Wnfs has reached its end. Your file will then be accessible from your Fission Drive! It may take a few seconds to propagate the data to the Drive, so be aware of that.

The Finished Project

Let’s do a quick walk through of writing to your Fission Drive. Begin by opening a new window or tab, and navigate to your Fission Drive. Once there, navigate to the fission-with-elm directory (Apps > Trillian > fission-with-elm). This directory should be empty (unless you saved a note between finishing the app and now).

Refresh the app page in the browser to make sure your browser has loaded the latest compiled version of the app from the server. Now, navigate to the “Fission with Elm” application and add some text to the input field in the app. It can be as quick as “asdf” or as creative as “test”, it is up to you. Once you have done so, click the “Save Note” button and then navigate back to your Fission Drive. As a reminder, it can take a few seconds for the new note to propagate to your Drive. Once a note has been written, there should appear a new directory within the fission-with-elm directory called notes. Enter that directory and you will see a JSON file entitled note. If you click on it, you will see the contents of the file in a preview window located on the right side of the screen. Like so:

Voilà!

The End of a Trilogy

There is not much reading left now. And I can guarantee this ending is not as satisfying as the end of watching the Lord of the Rings trilogy for the umpteenth time… But hey, we made it. The “Fission with Elm” demonstration app is now fully functioning, and you now have a better grip on the basics of integrating Fission into your code.

In the first part of this series, I showed you how to set up Vite to manage Elm applications. This was the foundation of the application. In the second part, I showed you how to integrate Fission into an Elm project via the webnative-elm module. This highlighted the structure of Fission integration. This third part took what was established in the previous two parts and demonstrated some of the processes of Fission.

I hope you have found this series of articles helpful as you begin to build Fission-based applications in Elm!

Feel free to email any questions you may have to info@xeticode.com and my team and I will answer as promptly as we can :)

Appendix A

Creating a Fission account

Go to https://fission.codes/
Click on the "Sign up" button (located in the top portion of the screen)
Click "Create account"
Enter an email and desired username into the fields
Click "Get started"
Follow the instructions on your screen to link your account to another device!

Using Fission with Elm - Part 2: Integrating Fission into the Elm project

Verge729 — Mon, 18 Oct 2021 22:47:24 +0000

Prelude

This is part of a three-part series. In part one, I demonstrated how to use Vite to manage an Elm application. In part two (this article), I will show you how to integrate Fission into the project from part one. Part three will walk you through how to refactor the project for Fission authentication and Fission Drive.

The Github repository associated with this article can be found here:
https://github.com/xeticode/fission-with-elm-demos/tree/Part-2

Intro

Welcome to round two! The time has come to upgrade our project from part one! The upgrade will connect the application to Fission, which I will introduce to you in a short moment. Before the introduction, I want to point out why Fission is a tool of the future. Fission uses a distributed system to store data. To one up that, Fission built a file system in the distributed system and protects it with military grade encryption. That means you can have a whole file system saved and protected across a whole network (in this case, the internet) rather than just on a remote machine or your own. And for app development, it means no need to worry about server maintenance or scaling. Anyways, I am getting ahead of myself. Without further ado, I present to you the InterPlanetary File System (IPFS) and, of course, Fission.

Enter IPFS…

In short, the “IPFS is a distributed system for storing and accessing files, websites, applications, and data” (for more information, see IPFS). No more need for centralized servers! Have you ever heard of blockchain? It uses a similar technical approach: peer-to-peer networking using content addressing. Say goodbye to centralized servers!

Enter Fission…

To add to my pre-introduction, Fission is built on top of the IPFS, and implements a layer of military grade encryption. I know I mentioned this before, but it deserves more attention. Fission created a file system called Webnative File System (Wnfs). It has a huge advantage over cloud storage in that it resides in a distributed system rather than centralized servers, meaning it is backed up on a vast network of machines and not at the data centers of some tech company.

Fission developed the Webnative SDK to interact with Fission services. Since we are working with an Elm application, we will use the Webnative-elm module for Elm (see Webnative-Elm). Using this wrapper allows us to maximize our Elm code and minimize the JavaScript for the project.

The Walkthrough

NOTE: This article assumes you have completed the project as described in part 1. If you have not completed that project, please go back and follow the steps in part 1 to complete it or download the part 1 reference project. See Fission with Elm, Part 1: Using Vite to manage Elm applications for both options.

Installing Webnative dependencies

To start things off, we will need to install Webnative to our node modules and elm.json file. To do this, run the following commands in the terminal from the root directory of the project:

npm install --save-dev webnative webnative-elm
npx elm-json install fission-suite/webnative-elm

These commands do the following:

npm install webnative webnative-elm will install both webnative and webnative-elm libraries to the project (check package.json for the new additions).
npx elm-json install fission-suite/webnative-elm will install the Elm dependency of the fission-suite/webnative-elm module (check elm.json for the new addition). This module is a wrapper, written in Elm, for Webnative.

Modifying js/index.js

This is pretty simple.

At the top of the file, add these two lines:

import * as webnative from “webnative”
import * as webnativeElm from “webnative-elm”

And after the const app = Elm.Main.init({}); line, add these two lines:

webnative.setup.debug({enabled:true});
webnativeElm.setup({app, webnative});

Here is a quick breakdown of the new lines:

webnative.setup.debug({enabled:true}); toggles on the debug mode. If enabled, the debug mode will output Webnative-related messages to the Console tab in the Developer Tools window. Toggle debug mode with this window open and you will easily see the difference.
webnativeElm.setup({app, webnative}); initiates the webnative-elm wrapper, taking the initialized Elm application and the Webnative SDK connection as parameters.

Modifying src/Main.elm

Ports

Elm ports are how an Elm application can communicate with JavaScript, or the “outside world” as I like to call it (for an in-depth explanation of Elm ports, see Elm Ports). The current state of the Main.elm file does not permit the use of ports. To change this, we need to change the file from a standard module to a port module. On line 1 of Main.elm, add port before module. We can now use ports in this Elm file! Let’s add some!
Normally, Elm ports require two ends: one Elm, and one in JavaScript. What makes this situation “abby”-normal (if you know, you know) is that this application is only concerned with interacting with Fission. The webnative-elm wrapper handles the JavaScript end of the Webnative-related ports. The wrapper has also consolidated all of the ports we may need into two ports: one for all Webnative requests, and one for all Webnative responses.
The Webnative SDK requires two ports: one for requests, and one for responses. Add these two lines just after the import block at the top of the file in Main.elm to satisfy the requirement:

port webnativeRequest : Webnative.Request -> Cmd msg
port webnativeResponse : (Webnative.Response -> msg) -> Sub msg

Once you have them added, you will notice the red squiggles under Webnative.Request and Webnative.Response. This is because we have yet to import Webnative to the file. Add:

import Webnative

to the import block at the top of the file.

Adding Permissions

Every Fission-based application requires a set of defined permissions to initialize the application.
There are three functions we will add to our project to define these permissions: appPermissions, fsPermissions, and permissions.

appPermissions will return a record with fields indicating the name of the application and the creator of the application. Add the following just after the Webnative ports in Main.elm:

appPermissions : Webnative.AppPermissions
appPermissions =
    { creator = "Trillian"
    , name = "fission-with-elm"
    }

This is what Fission will use to create a file path within the Wnfs to the files produced by this application (i.e. Apps/Trillian/fission-with-elm/). Feel free to change the creator field to your own username if you so desire.

fsPermissions will return a record with fields indicating what public and private parts of the Wnfs for which the application will request access (“fs” stands for File System here). Add the following a couple of lines after appPermissions, but before type alias Flags:

fsPermissions : Webnative.FileSystemPermissions
fsPermissions = 
    { public =
            { directories = []
        , files = []
            }
    , private = 
            { directories = []
            , files = []
            }
    }

This application is not asking to access any parts of the Wnfs external to this application, so the lists will remain empty.

permissions the icing on the cake. This will return a record with two fields: app and fs. These correspond to the two previous code blocks we talked about. Add the following a couple of lines after fsPermissions, but before type alias Flags:

permissions : Webnative.Permissions
permissions =
    { app = Just appPermissions
    , fs = Just fsPermissions
    }

We will pass this, our newly defined permissions, through the webnativeRequest port in the next step.

The `init` and `subscriptions` functions

`init`

The only difference here is changing the Cmd msg from Cmd.none to a command that will initialize the application as a Webnative application. The new init function should look like this:

init : Flags -> Url.Url -> Navigation.Key -> (Model, Cmd Msg)
init {} url key =
    ( Model
    , permissions
        |> Webnative.init
        |> webnativeRequest
    )

Here is a quick explanation of the new command:

permissions was previously defined in the walkthrough. It indicates both the name and creator of the application and contains a list of Wnfs access requests.
Webnative.init is a function of webnative-elm that will load a user's Wenative File System, if said user is authenticated.
webnativeRequest is our port for our Webnative related requests. subscriptions We now need to subscribe to webnativeResponse so the response will be properly handled and not left by the wayside. In the subscriptions function, change Sub.none to:

webnativeResponse GotWebnativeResponse

This will set the application to watch our webnativeResponse port for any changes. GotWebnativeResponse is a Msg variant we will add in a few moments and will be where we handle the response.

Adding a variant to the `Msg` and updating the `update` function

`Msg`

At this point, we have only two Msg variants: UrlChanged Url.Url and LinkClicked Browser.UrlRequest. To handle the webnativeResponse, we need to add the GotWebnativeResponse variant. Add the new variant to the Msg so that it looks like this:

type Msg 
    = UrlChanged Url.Url
    | LinkClicked Browser.UrlRequest
    | GotWebnativeResponse Webnative.Response

This new variant will allow us to dictate how to handle each response the application receives from webnativeResponse. Our friendly red squiggles should now be present on our update function. This is because our new Msg variant is a new branch the case statement in our update function needs to handle. The only problem? We have yet to add the branch to the case statement. This exemplifies one of the beauties of Elm, it forces us to handle each defined potential outcome or branch of whatever it is that is the subject of a case statement. Super helpful if you are, at times, forgetful 😉 Let us now add the new branch to update.

`update`

That being said, as much as we may enjoy the red squiggles, they need to go. Add the following branch to the update function's case statement:

GotWebnativeResponse response ->
    (model, Cmd.none)

This will satisfy the Elm compiler, but it needs to be noted that this state of the GotWebnativeResponse branch does not handle anything. It is currently a dead end for the Webnative response, and for the time being, it will stay that way. The reason for this decision is that adding the proper logic to this branch fits beautifully with what is covered in part three of this series: authentication and interacting with the Wnfs. So be sure to check out part three!

The Ending

Before its over: See that it works

So far we have done all this work, but have yet to visually see any of that work in our app. If you have not done so already, get your dev server running. Once you have the app running, open the Developer Tools window in your browser, and go to the Console tab. You should see the following message in the list of messages:

[vite-plugin-elm] ports. webnativeRequest.subscribe called

This indicates that our application is listening to the webnativeRequest port! Visually, it is not much, but internally this is very important.

Adieu

And there you have it! The application has been upgraded with Fission integration. In this article, I showed you how to build upon what we made in the first article. In the third article, we will see the culmination as functionality is added to the project. If you wish to learn more about Fission or the Webntive-Elm module, check out these links:

Fission
Webnative-elm
- https://package.elm-lang.org/packages/fission-suite/webnative-elm/6.0.0/

Using Fission with Elm - Part 1: Using Vite to manage Elm applications

Verge729 — Tue, 12 Oct 2021 22:34:16 +0000

Prelude

This is a three-part series. In part one (this article), I will show you how to use Vite to manage an Elm application. The second article will show you how to integrate the basics of Fission via the Webnative SDK into the project and the third will walk you through how to refactor the project for Fission authentication and using a Fission Drive.

The Github repository associated with this article can be found here: https://github.com/xeticode/fission-with-elm-demos/tree/Part-1 .

Intro

Hello, hello! In this article, I will walkthrough how to initialize a Vite project and then set up an Elm application within that project. Before I do that, I will quickly introduce you to both Vite and Elm because a lack of character development is almost always an insufficient foundation for any good story. So, without further ado…

Enter Elm…

Elm is not only a typed, pure functional language that transpiles to JavaScript, it is also an architecture for web applications (known as The Elm Architecture or TEA, for short). As a language, Elm offers excellent error messages and is able to avoid runtime errors at compile time because of its strong typing and pure functions. This combination can make refactoring a project a breeze as Elm directs the developer to the exact spot or a specified area where the error is occurring. As an architecture, Elm employs a reactive Model-View-Controller design, or more common within the code: a Model, a view, and an update function. As the user interacts with the UI, messages are sent to the update function which then can alter the data within the Model, which will then update the UI, and the cycle continues on.

To learn more about Elm, check out https://elm-lang.org/ .

Enter Vite…

Vite is a bundling tool that uses browser-native ES modules and tools such as Rollup to build a project. Vite makes it easy to build JS modules along side your Elm code for seamless project deployment. This will not be apparent in this article because we will not be using JS modules. That being said, we will use them in subsequent articles, so setting up Elm with Vite is necessary moving forward. For now, we will have the benefit of using the dev server, build, and build preview functionality offered by this tool.

To learn more about Vite, check out https://vitejs.dev/ .

The Walkthrough

Alright, now that introductions have been made, we can proceed!

Initialize the Vite project

First things first: open an IDE of your choice and open the directory in which you want to store the fission-with-elm application. Once that is done, run the following commands in the terminal from the directory holding the project:

npm init vite

This command will initialize a Vite project.

We will be prompted to enter a name for the Vite project. Normally, this would be your chance to come up with something creative, but since this is a walkthrough, that will have to wait. Name the project fission-with-elm. Anyway, next you will then be prompted to select a web framework. Vite initializes a project differently based on the chosen web framework. As Elm is not one of the core frameworks we will select vanilla for the framework and vanilla as the variant.

Once the Vite project has successfully been initialized, these will be the next commands to run, some of which are displayed at the end of the output from the npm init vite command:

cd fission-with-elm
npm install --save-dev vite-plugin-elm
npm run dev

These commands do the following:

cd fission-with-elm : will move the terminal's working directory into the project directory.
npm install --save-dev vite-plugin-elm : will install a Vite plugin that bridges the gap between Vite and Elm. Vite supports a handful of web frameworks from the get-go and Elm is not one of them. Thus we install a plugin to make up for that. The --save-dev tag will make this a development dependency, which is a dependency kept for development and building of the project, but is not kept for deployment.
npm run dev : will begin the dev server. dev is a script defined in the package.json file.

Before running these commands in the terminal, take a look at the file explorer and browse the files added by npm init vite. You should see:

.gitignore
favicon.svg
index.html
main.js
package.json
style.css

As we change some of the project structure, some of these files will become redundant and can be removed. I will indicate which files those are at the appropriate times. Now run the three commands indicated by the terminal.

After running npm run dev you will see the dev server is running at http://localhost:3000. If you go there you should see this:

The only thing that remains to finish initializing this Vite project is making it so the project can properly use the Elm plugin. To do this, we will create a file named vite.config.js. This file will be placed within the current directory (which is named after the name you chose for the Vite project). The file needs to contain the following:

import elmPlugin from "vite-plugin-elm"

export default {
  // identify what plugins we want to use
  plugins: [elmPlugin()],
  // configure our build
  build: {
    // file path for the build output directory
    outDir: "build",
    // esbuild target
    target: "es2020"
  }
}

Set up the Elm Application: Installation

elm-tooling

Life and setting up an Elm application have at least one thing in common: there are many ways to do it. As this is a dev article, I will not indicate which way of life you should live, but I will tell you which method to use to set up an Elm application. For this project, we use elm-tooling. It is a command line program for managing Elm tools, namely: elm, elm-format, elm-json, and elm-test-rs (see elm-tooling-cli for more information). First step for setting up an Elm application is to install elm-tooling. Run the following commands in the terminal (double check to make sure you are still in the fission-with-elm directory):

npm install --save-dev elm-tooling
npx elm-tooling init
npx elm-tooling install

These commands do the following:

npm install --save-dev elm-tooling : installs the elm-tooling tool to the project.
npm elm-tooling init : will initialize elm-tooling within the project. You will notice a new file named elm-tooling.json : appear in the file explorer.
npx elm-tooling install : will install the selected tools to ~/.elm/elm-tooling/ and create soft links to these tools in ./node_modules/.bin/ .

You can see what tools elm-tooling has to offer by running the

npx elm-tooling tools

command. This will also let you select the tools you want for the project. Running the command will present you with output like this one:

As you can see, elm, elm-format, and elm-json are selected by default. We will not be using the last tool, elm-test-rs, which is a tool used for testing the application, as writing tests is beyound the scope of these articles.

elm-json

Next, run:

npx elm-json new

This will create a file named elm.json. This file holds information concerning the Elm application such as: dependencies, location of source directories, and which version of Elm is being used for the project. There will be a question about what type of Elm project you want, select “application”.

At this point we have four JSON files: elm.json, elm-tooling.json, package-lock.json, package.json. Here is what is significant about each file:

elm.json : this contains Elm specific information such as Elm module dependencies, the version of Elm being used, and the file path(s) to any source directories within the project.
elm-tooling.json : this contains a limited selection of Elm tools
package-lock.json : the npm package version lock.
package.json : this contains information of the project such as the name of the project, command line scripts (i.e., the dev command previously executed in this walkthrough).

Set up the Elm Application: Modifying to the file structure

Ok, now that installation has been complete, let’s add some structure to the project! We will be adding a few directories and files with those directories. As a reminder, everything that will be added will be with the fission-with-elm directory (now referred to as root directory for the remainder of this article).

Add a directory named src. This will be for your Elm source files. Within that directory, add a file named Main.elm. Leave the file empty for now.
Add another directory in the root directory called js. In this new directory, create a file called index.js. Leave the file empty for now.
Create another directory in the root directory called public
1. Within public, create a directory called assets
2. Within assets, create a directory called images
3. The end product here should look like: ./public/assets/images/. For this project, we will be using the Fission logo. You can download this image from the repo associated with this article. To do so, Run the following command in the terminal from the images directory:
```
  curl -o fission.svg https://raw.githubusercontent.com/xeticode/fission-with-elm-demos/Part-1/public/assets/images/fission.svg
```

Set up the Elm Application: Adding content to the files

We are near the end! We have a few files to change: ./js/index.js, ./src/Main.elm, and ./index.html. First, we will take a look at ./index.html.

index.html

We need to connect the index.js file to the index.html file via a script tag that will be placed within the head tag.

This is the new content of the index.html file:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="favicon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite App</title>
    <!-- Here is the new script tag -->
    <script type="module" src="./js/index.js"></script>
  </head>
  <body>
    <!-- This is the old content -->
    <!-- <div id="app"></div> -->
    <!-- <script type="module" src="/main.js"></script> -->
  </body>
</html>

These changes make the main.js and styles.css files redundant as we no longer reference them. Both files are used to present the Hello Vite! webpage from the beginning of the walkthrough. Delete these files now.

index.js

Here is all that is needed in the ./js/index.js file:

import { Elm } from "/src/Main.elm"

const app = Elm.Main.init({});

This is the connection point between index.html and our Elm application. Line 1 indicates where to find the application, and line 3 initializes the application.

Main.elm

This article does not focus on the components of Main.elm. Because of this, and the length of the file, we will download the file directly from the Github repository. We will dive into the file in Part 2, but for now, use this command to download the Main.elm file from the repository asociated with this article. We will dive into this file in part 2:

curl -o Main.elm https://raw.githubusercontent.com/xeticode/fission-with-elm-demos/Part-1/src/Main.elm

Set up the Elm Application: Importing Elm modules

Alrighty! Go ahead and run

npm run dev

The compilation should fail. Reason being? There are dependencies we refer to from within Main.elm that have not been installed. Run the following command in the root directory to install the missing dependencies:

npx elm-json install elm/browser elm/url mdgriffith/elm-ui

Here is some information on the packages being installed (for more info on each package, see https://package.elm-lang.org/ and enter the package name in the search bar):

elm/browser enables the Elm application to run in the browser.
elm/url handles creation and parsing of Urls (required when using Browser.application).
mdgriffith/elm-ui handles layout and styling (there are a few options for for layout and styling, and I chose elm-ui for its simplicity, capability, and ease of use).

After running the command, a confirmation prompt will appear regarding the addition of these modules to the elm.json file. There will be some dependencies to be installed to the indirect dependcies because the direct dependencies depend on them. The word "dependency" was used too much in that last sentence... I recommend having the elm.json file open so the changes can be visibly seen.

You can also run the npx elm-json install command once per dependency if desired. Once those dependencies have been installed, the error messages should disappear and you should see this:

The Ending

Before its over: Witness the live reload of Vite

For this part, make sure you have the dev server running and a browser open to the localhost domain. Vite has live reload functionality. In other words, if you change something in the Main.elm file, it will take note of the changes made and automatically serve the new files. To demonstrate this, go to line 68 in Main.elm. You should see this:

, EBA.color <| E.rgb255 176 192 222

This line dictates the background color of the application. Change any number of the intgers following E.rgb255 to a value between 0 and 255 inclusive and see the background automatically change!

Before its over: Build and Serve the project

Before we can officially wrap this up, I will show you how to build the project and serve the build directory. Run these commands:

npm run build
npm run serve

Both build and serve are scripts defined in package.json. These commands do the following:

npm run build will use Vite to build the project. As it builds, a new directory named build will appear in the file structure. The first children of this directory will be the static files from the location indicated by the publicDir tag from the vite.config.js file. The other children will take a moment to appear and will be the files generated from the build process.
npm run serve will start a localhost server and serve the files from the build directory. This will be running at http://localhost:5000 .

The result should be the same as what is produced by the npm run dev command.

Adieu

And there you have it! A simple Elm project that is managed by Vite. As a reminder, this only covers the basics of setting up Vite and Elm, if you wish to learn more about what they both have to offer, follow these links:

Elm
- https://package.elm-lang.org/
- https://elm-lang.org/
Vite
- https://vitejs.dev/

In the next article, we will alter this project to integrate Webnative, an SDK built and provided by Fission.

FaunaDB, GraphQL, and Elm, A Tutorial for JAMstack, Part 2

Dirk Johnson — Mon, 27 Jul 2020 15:45:52 +0000

Introduction

[Note: this tutorial was written by commission for Fauna, Inc]

In part 1 of this article, you were introduced to a simple Elm JAMstack site called Shall We Play?, an application for scheduling game nights with friends. Shall We Play? lacked secure login and database support, making it a minimally useful site for scheduling game nights but a perfect site for introducing FaunaDB, a multi-region, zero-operation database with native support for GraphQL.

Part 1 focused on creating a GraphQL schema for supporting secure login and pulling restricted data from the database. Additionally, it introduced the sophisticated attribute-based access control features of FaunaDB which was used to back the GraphQL schema and provide identity services.

Part 2, the final part of this article, will continue building upon the work done in part 1 by updating Shall We Play? to take advantage of this new GraphQL service using an Elm package called elm-graphql by Dillon Kearns.

This part of the article assumes you are comfortable with using a command-line, git source control, and package managers like npm. Additionally, you should have a rudimentary understanding of Elm. If you are new to Elm, take some time to review the official Elm guide up through the Installation chapter. Don't worry if you don't have any practical experience with Elm, I'll walk you through everything.

Ready to go? Great! Let's dive in.

Connecting Shall We Play? to FaunaDB through elm-graphql

If you completed all the steps outlined in part 1 of this article to set up our GraphQL service, then we are now ready to add login services to Shall We Play?. The ideal way for this to happen is for you to join me in the coding process, just like you joined me when setting up our GraphQL schema and database in part 1.

Setting Up Shall We Play? for Local Development

The Shall We Play? starter application is an open source project on GitHub. Before you get started with this section, you will need to create a fork of the application so you can run and edit it locally.

First, create a free GitHub account if you need to, then log into GitHub and go to the Shall We Play? project. Click on "Fork" in the upper right.

Once the project has completed forking, clone the project to your local system.

The master branch is the starting point for part 2. I would recommend creating a branch off of master before continuing with the tutorial in case you need to back and up and try again or want to go a different direction later.

For managing the project during development, we use some Node.js tools, so you will need to install Node.js. As of the time of this writing, I am using Node.js v13.12.0 and npm v6.14.4. Go ahead and make sure you have Node.js properly installed; refer to the installation instructions for your particular system, if necessary.

Next, you will need an editor. If your preferred editor does not have good language support for Elm, please give VSCode a try with the Elm tooling extension. However, there are actually a lot of good editors out there with Elm support, including Vim.

Now we will need to install some npm packages to get things going. Bring up a terminal in the root directory of the project and run npm install. Once npm is finished installing, test the current version of the application by running npm start.

$ npm start

> shallweplay@0.0.1 start /Users/dbj/Documents/Family/Dirk/XetiCode/projects.nosync/internal/shallweplay
> npx elm-live ./src/Main.elm --dir=./static -o -- --output=./static/assets/js/shallweplay.js --debug

elm-live:
  Server has been started! Server details below:
    - Website URL: http://localhost:8000
    - Serving files from: ./static

elm-live:
  The build has succeeded. 

elm-live:
  Watching the following files:
    - src/**/*.elm

npm start runs the elm-live tool which will install any elm packages that are needed, compile the code, and bring up the application in your default browser. While running, elm-live will continue to watch the Elm files in your source directory and, when they change, recompile them and reload the browser view.

Have a look around to re-familiarize yourself with the application; it should behave identically to the deployed version.

A Bit About Elm

Elm is both a functional language and an architecture for web applications. The architecture imposes a simple data-flow pattern that is easy to reason about, as illustrated by the following diagram taken from the official Elm guide:

Elm renders the initial HTML for the site. Then, as users interact with the site, they generate messages, which are sent to Elm. Elm processes the messages, updates the model (data) and generates new HTML based upon the updated model. Simple. Elegant.

Where things might get challenging is in learning to read and think functionally if your experience is not with functional languages. Pure, functional languages are as orthogonal to the traditional object-oriented paradigm as you can get; it really is a different way of thinking. But the payoffs are worth it.

As noted before, as we go through the exercise of modifying our application, I will explain things with the assumption that you have gone through the official Elm guide, at least through the Installation section. The good news is, Elm is expressive, and if you are familiar with JavaScript or other languages, and you read my explanations, you should be able to understand most of what is happening even if the details of the code are not clear.

A Tour of the Project

Let's take a look at the project structure. If you look inside the "src" directory, you should see 3 files:

Colors.elm
DataModel.elm
Main.elm

The Colors.elm file specifies the colors used on the website. The coloring of the site was in honor of my wife's favorite color. No comments, here, OK?

The DataModel.elm file has our model, most of our types, and the functions that support them.

The Main.elm file is the entry point into our application; it manages our message handling, and renders our view.

Let's dig deeper into our data model; go ahead and open the DataModel.elm file in your editor. First you will notice our Model record, which is our persistent state between messages. We store, among other things, the current logged in Player, if any, a full list of Players, and a full list of Events.

type alias Model =
    { input_user_name : UserName
    , input_password : Password
    , m_player : Maybe Player
    , players : Players
    , events : Events
    , m_possible_event : Maybe PossibleEvent
    , m_poss_event_elem_info : Maybe Dom.Element
    , login_offset : Float
    , login_field_with_tab_index : LoginField
    , dragged_player_position : PlayerPosition
    , drag : D.State UserName
    }

After the model, the core types are declared, such as Player, Event, and Invite.

type alias Player =
    { user_name : UserName
    , member_since : Int
    }

type alias Event =
    { id : EventId
    , organizer_user_name : UserName
    , millis : Int
    , title : String
    , description : String
    , venue : String
    , status : EventStatus
    , invites : Invites
    }

type alias Invite =
    { for_user_name : UserName
    , status : InviteStatus
    }

The Player record tracks everything we need to know about a player. The Event record tracks the details about organized events including which player organized the event and what players were invited. The Invite record simply tracks which player the invite is for, and what their invite status is.

The type we will be most concerned about in this article will be the Player type.

Now let's look at the Main.elm file. The code is delineated informally by commented section headers:

Main and Init
Subscriptions and Commands
Msg and Update
Views
Helpers

Take a look at the "Msg and Update" section. Here you will see our Msg type which defines all of the messages that could be received through various interactions by users and other side effects (like system events or XHR requests). The update function must deal with every one of these messages; Elm ensures this through the use of the case statement.

Now scroll on down to the "Views" section. Notice that the model is available to these views through the entry point view function. This allows our views to respond to changes in the model.

For the HTML/CSS generation, I have chosen to use an excellent package called elm-ui. It is a low level abstraction of HTML and CSS (i.e., it does not define components). Elm also provides formal HTML and CSS packages so you can operate at that level if desired, and indeed, the HTML package is a complement to using elm-ui.

Showing The Password Field

While we are in the "Views" section of the code, I'd like you to bring up the application if it is not running (run npm start from the root directory) and then look at the loginLogoutRowView function:

loginLogoutRowView : Model -> E.Element Msg
loginLogoutRowView model =
    E.row
        [ E.width E.fill
        , E.spacing 20
        , E.moveLeft model.login_offset
        ]
        [ loginView model.input_user_name model.login_field_with_tab_index
        , passwordView model.input_password model.login_field_with_tab_index
        , logoutView model.m_player
        ]

The last list in this function is a list of child views which are aligned in a single row. However, only one of these views will be visible at a time, and that is based on a single offset value set on the model called login_offset. The current value of this offset now shows the loginView.

Go ahead and log in with any user name. Once you do, the logoutView is shown. Note that the passwordView was skipped because the offset was set to go past it.

For our very first change in the app, we will update the login flow so it shows the passwordView after the loginView. We will do this by updating the function that controls the offset after providing a user name.

I like to run the application while I am editing the files so I can receive immediate feedback on my changes. elm-live will compile and reload the site when it notices changes to the code, or, if there is a compiler error, it will display the compiler error right in the window. Make sure elm-live is running while we make these next changes.

The first place we need to update the offset is in the updateModelFromEnteredUserName model handler in the Main.elm file. Right now this function jumps from the loginView right to the logoutView at offset 804. Let's change this to jump to the passwordView which is at offset 402. Additionally, we need to control where tabbing can go in the DOM, so change NoField to PasswordField to keep the passwordView in the DOM's tabbing order:

{ model | login_offset = 402.0
        , login_field_with_tab_index = PasswordField
}

As a matter of interest, the updateModelFromEnteredPassword function, which deals with the submitted password, already sets the correct offset to move from the password field to the logout field.

Let's test our small change by logging in; you should now see the password field instead of the logout button. Small victories, right?

Notice that even though we have not yet provided a password or completed the login process, the main view still changes to look like the user is logged in, showing the events summary to the right and the details of the events below. Let's work on fixing that next.

Showing The Logged In Main View At The Right Time

Right now the application simply looks to see if there is a valid Player record in the model to determine whether a player is "logged in". Now that we will be requiring a password and a valid login token from FaunaDB before we will consider the player logged in, let's change this logic from looking for a valid player to looking for a login token.

We need to have a place to store the authentication/authorization token, so let's do that right in the Player record.

Open the DataModel module in your editor. First, to keep the code easier to understand, let's create a type alias for the token, which, under the hood, is a String. Put this after the Password type alias:

type alias Token =
    String

Now lets update the Player record to take a Maybe Token called m_token ("m" for "Maybe"):

type alias Player =
    { user_name : UserName
    , member_since : Int
    , m_token : Maybe Token
    }

We use a Maybe Token because we will not always have a token, and, as you know, there is no such thing as null in Elm (which is a very good thing).

We also have a player constructor function called newPlayer which we need to update to set a default value for m_token:

newPlayer user_name =
    Player user_name 0 Nothing

Nothing is one of the type variants for the Maybe type, and it represents the absence of a value.

Remember, in our reactive Elm architecture, the view is always driven by changes in the model. So now that we want our view to only show us the logged in main view once we are truly logged in, we need to update the view logic to look for the presence of a player token. This logic is in the mainView function in the Main module; open the Main.elm file in your editor.

The mainView function looks at whether there is a player record, and if there is, it considers the player logged in. Now we need to update this function to look a little deeper in the player record for a token, and if present, we consider the player logged in. Here is what the code should look like:

mainView model =
    case model.m_player of
        Nothing ->
            plainMainView

        Just player ->
            case player.m_token of
                Nothing ->
                    plainMainView

                Just _ ->
                    eventsMainView model player

We also need to update the youHaveView because it displays the event summary if the player is logged in:

youHaveView events m_player =
    Maybe.andThen
        (\player ->
            player.m_token
                |> Maybe.map
                    (\_ ->
                        E.column
                            [ E.width E.fill
                            , E.spacing 8
                            ]
                            [ youHaveEventsView events player
                            , youHaveInvitesView events player
                            ]
                    )
        )
        m_player

Here again, we just drilled down to see if there was a token, and if so, display the summary.

In Elm, compiler errors are not actually dreaded (unlike some other languages ;). Elm's error messages are quite informative and often guide you right through the fix. When you get a compiler error, don't read the error quickly - read it and stop and think about it a second. I find if I jump to conclusions too quickly, I sometimes miss what the error is saying. In Elm, the compiler is your BFF.

Go ahead and test out your app. When you enter a user name, you are brought to the password field, but now you should not see the logged in main view. The journey of a 1000 lines of code begins with the first change (or something like that).

Adding A Little Polish

When the app showed the password field, did you notice how you had to tab or click to get the focus to try to enter your password? Let's fix this annoyance, shall we? When you first launch Shall We Play?, the user name field immediately has the focus. We can use the same mechanism for giving focus to the password field after the user enters a user name.

Go to the update function type signature. Notice that the update function returns a tuple with a Model and a Command (Cmd).

update : Msg -> Model -> ( Model, Cmd Msg )

Commands are one way to send asynchronous messages out from the type-protected, pure space of Elm to a part of the runtime that does not have the same guarantees. (These are called side effects.) Using the Browser.Dom module, we can actually send a command to the DOM to set focus on a specific field.

Go to the focusFieldWithId function; this function takes the id of the DOM element you want to focus on and calls the Dom.focus task as a command.

focusFieldWithId id =
    Task.attempt (\_ -> NoOp <| "focus field with id " ++ id) (Dom.focus id)

This function is used by the focusUserNameField function which passes in the id for the user name field. Let's create a similar function for the password field, leveraging the focusFieldWithId function; don't forget to add the function's type signature:

focusPasswordField : Cmd Msg
focusPasswordField =
    focusFieldWithId (fieldIdForLoginField PasswordField)

You will notice from the focusFieldWithId function that the message that we get back from the focus command is called NoOp. This is a message that basically means we do not want to do anything specific in response to the command completing. This makes sense as we won't know what to do next until the user enters a user name or password.

Now that we have a new focusPasswordField command, we need to make sure it is called once a user enters a user name. The message that is sent when a user enters a user name is called EnteredUserName and it is handled by the update function. Let's take a quick look at the EnteredUserName message handler:

EnteredUserName ->
    ( updateModelFromEnteredUserName model
    , commandFromEnteredUserName model.input_user_name
    )

The EnteredUserName message handler calls the commandFromEnteredUserName command handler. Let's take a look at what it does:

commandFromEnteredUserName user_name =
    let
        cleaned_user_name =
            cleanedLoginString user_name
    in
    if isUserNameValid cleaned_user_name then
        blurUserNameField

    else
        Cmd.none

If the user name coming in from the EnteredUserName message is valid, a command called blurUserNameField is sent. Blurring is the opposite of focusing, meaning an element that is blurred no longer has focus. Let's replace this command with our new focusPasswordField command.

...
  if isUserNameValid cleaned_user_name then
      focusPasswordField

  else
      Cmd.none

Test our change. How did it go?

The blurUserNameField command that we replaced is no longer being used, so we could delete this function. However, you may have guessed that we will need a similar function soon for the password field, so we will leave this function alone for now and repurpose it shortly.

Wiring Up The Password Field

Now we need to update the password field so it completes the login process once the password is submitted.

But before we do that, let's stop and take a look at what is happening to our model when our user name and password is being entered. We can do this by looking at the built-in debug panel.

Make sure your application is running and visit the site. In the bottom right, you have probably noticed the white tangram in a blue box:

You may have even been tempted to click on it. If you did, a debug pane should have come up. Bring up the debug pane now.

Remember that the Elm Architecture is about reactive message passing. The Elm debugger displays all the messages it receives and records the model at each message. Since the model drives the view, we essentially have a time-traveling debugger which can scrub back and forth through time so we can see the state of the app and the view at any point we want. This is a great way to zero in on bugs that are driven by data and logic errors, but it is also a great way to simply see what is happening with our app, like an x-ray.

Notice that there is already one message waiting for us - the NoOp message, which has the payload of "focus field with id user_name". This is the message that gets sent when the app first starts up so that the user name field is focused and waiting for the user to type. Look at the model. Notice that both input_password and input_user_name have empty strings as their values.

Now, go ahead and type a user name and hit return. Notice that your focus command was received and that input_user_name contains the user name you entered.

Go ahead and scrub back through time using the slider at the top-left, and watch the input_user_name field change. You will also see the view change. (OK, confession. Sometimes I just play with the scrubber when I need a quick break from coding… it's just too cool. ;)

I have noticed that, on macOS, if I run my browser in full screen mode and then I try to interact with the Elm debugger, it can be painfully slow responding to clicks. If you notice the same, simply bring the browser out of full screen mode and all should work just fine.

And now go ahead and enter a password and make sure that the input_password field in the model is being updated properly while you type. If the UI isn't responsive, it's because you used the scrubber which paused Elm; hit the blue and white "play" button in the upper-left of the debugger and you should be good to go.

Now that we know the password is being saved, let's update the app to complete the login process after the password is submitted. Let's take a look at the updateModelFromEnteredPassword function:

updateModelFromEnteredPassword model =
    let
        cleaned_password =
            cleanedLoginString model.input_password
    in
    if isPasswordValid cleaned_password then
        { model
            | login_offset = 804.0
            , login_field_with_tab_index = NoField
        }

    else
        model

This function looks at the stored password in the model, and if the password is valid, we update the login_offset field to show the logout field as well as taking the password field out of the tab order in the DOM. What we need to do in addition is to:

Call the createAndOrLoginPlayer GraphQL mutation
Clear the password from the model (don't want that sitting around)
Blur the password field so it no longer has focus (to avoid keystrokes in the password field while it is not visible)

As we update the code to complete the login process, we are going to fudge step 1 above, and just make the model think we have made a GraphQL call and have received back a token. Wiring up elm-graphql will be quite an undertaking, and I would rather be sure we have everything else working before we start down that road.

Sending off a request through GraphQL will involve sending a command that should return a message with our login token. Let's wire that up now. First, let's go to our Msg type and add a message called LoggedInPlayer that has a payload of type Token. Let's place it below the EnteredPassword variant.

| LoggedInPlayer Token

Now update the update function to handle this new Msg. Create a message handler that uses a model handler to update the model. This message handler will not need to send any commands, so we don't need a command handler. Place the new message handler next to the EnteredPassword message handler, just like with the Msg variants list.

LoggedInPlayer token ->
      ( updateModelFromLoggedInPlayer model token
         , Cmd.none
      )

Create the updateModelFromLoggedInPlayer model handler in its proper place next to the other model handlers. At this point, it should just set the token on the current player in the model:

updateModelFromLoggedInPlayer : Model -> Token -> Model
updateModelFromLoggedInPlayer model token =
    case model.m_player of
        Just player ->
            let
                updated_player =
                    { player | m_token = Just token }
            in
            { model | m_player = Just updated_player }

        Nothing ->
            model

Let's go to the update function and look at the EnteredPassword message handler. We know that this is called when the player has submitted the password, so in response to this, we want to try to create and/or log them in. Update the message handler to send a command called createAndOrLoginPlayer, passing in the input_user_name and input_password from the model:

EnteredPassword ->
   ( updateModelFromEnteredPassword model
   , createAndOrLoginPlayer model.input_user_name model.input_password
   )

Create the createAndOrLoginPlayer command function below the focusPasswordField command. This function will create a placeholder task that will return immediately with the LoggedInPlayer message carrying a pseudo token string, as though it had come from FaunaDB.

createAndOrLoginPlayer : UserName -> Password -> Cmd Msg
createAndOrLoginPlayer user_name password =
    Task.perform LoggedInPlayer (Task.succeed "abcdefgHIJKLMNOP1234560987")

With this command in place, we can now test the handling of our login flow without needing to wire up elm-graphql at this moment.

Using our debugger, let's test our command to see if it actually sets a token value for the current player. Take a look. That should put a smile on your face. :)

Let's complete our last two easy tasks of clearing the password and removing focus from the password field when the password has been entered. First, update the updateModelFromEnteredPassword model handler to clear the input_password field in the model:

...
  if isPasswordValid cleaned_password then
      { model
          | login_offset = 804.0
          , login_field_with_tab_index = NoField
          , input_password = ""
      }

  else
      model

Next, we will return to the blurUserNameField and rename it to blurPasswordField. Be sure to change the message that gets passed into NoOp (as it is visible in the debugger, and we don't want that message to be misleading) and be sure to use PasswordField to generate the field id:

blurPasswordField : Cmd Msg
blurPasswordField =
    Task.attempt (\_ -> NoOp "blurPasswordField") (Dom.blur (fieldIdForLoginField PasswordField))

Now we can send this command out as part of the EnteredPassword message handler.

But wait! We are already sending out the createAndOrLoginPlayer command in this message handler; can we possibly send two at once? The answer is, of course, Yes! Simply combine them using the Cmd.batch function, which batches a list of commands:

EnteredPassword ->
   ( updateModelFromEnteredPassword model
   , Cmd.batch [ createAndOrLoginPlayer model.input_user_name model.input_password, blurPasswordField ]
   )

Let's test everything out and make sure it all works. Use the debugger to see if we are still setting the token properly, that the input_password field is reset, and if typing on the keyboard once logged in updates the input_password field, which it shouldn't, because we blur the password field:

Assuming your testing went well, (and I'm sure it did,) we are now ready to implement "la pièce de résistance": we get to integrate elm-graphql with our application so we can log in using our GraphQL service. Woot!

Integrating elm-graphql into our application

Now that we are ready to integrate elm-graphql into our application, lets step back a moment and talk about elm-graphql and how to set it up within our project.

elm-graphql was created by Dillon Kearns. It is an elm package that fully supports all GraphQL features in a type-safe way. elm-graphql is also an npm command-line utility that will get your project ready to work directly with your schema by auto-generating decoders, query functions, and other necessary functionality. All we need to do is provide elm-graphql our GraphQL endpoint and a key with permissions to access it.

FaunaDB provides the same GraphQL endpoint to all customers: https://graphql.fauna.com/graphql. The way FaunaDB knows which schema and database need to handle specific requests, then, is by the key that is provided along with each request. We will need to generate a server key that we can provide elm-graphql to access our schema. Don't worry, this is the only use for this key; it will never be used by the client directly:

Log into your FaunaDB account; you should be brought to your FaunaDB Console Home
Go to the DB Overview for your "swp" database by clicking on the name of the database
Go to the Keys page by clicking on the "SECURITY" tab to the left
Create a new Key by clicking on the "NEW KEY" link
Set the Role to Server and give the key a name (the key is arbitrary, but should be descriptive)
Save the key and then record the server key that is displayed for later use (this will be the only time you will see the key)

We will now use this key to execute a script that uses elm-graphql to generate our project's GraphQL files under the namespace "SWP":

Make sure the application is not running
Open a terminal and navigate to the root of your Shall We Play? project directory
Generate our "SWP" elm-graphql files for our project by executing the following command:

FAUNA_KEY=<fuana-server-key> npm run build-gql

Where <fauna-server-key\> is replaced with the server key generated before in step 6

Note for the curious, the "build-gql" script makes the following call: npx elm-graphql https://graphql.fauna.com/graphql --base SWP --output src --header \"authorization: Bearer ${FAUNA_KEY}\"

When this script has completed running, you should see a brand new folder in your "src" directory called "SWP". This directory houses all the files that were auto-generated by elm-graphql. Because we will not be updating these files directly, it is safe to auto-generate our files again, should our schema ever change.

Let's take a look at some of the files that were generated. Browse the Mutation.elm and Query.elm files at the root level of the "SWP" folder.

createAndOrLoginPlayer :
    CreateAndOrLoginPlayerRequiredArguments
    -> SelectionSet String RootMutation
createAndOrLoginPlayer requiredArgs =
    Object.selectionForField "String" "createAndOrLoginPlayer" [ Argument.required "user_name" requiredArgs.user_name Encode.string, Argument.required "password" requiredArgs.password Encode.string ] Decode.string

allUserNames : SelectionSet (List String) RootQuery
allUserNames =
    Object.selectionForField "(List String)" "allUserNames" [] (Decode.string |> Decode.list)

You should see functions whose names match the query and mutation we defined in our schema as well as those added by FaunaDB.

There are also some sub-folders, the most interesting of which is the Object folder, which has a Player.elm file in it. Go ahead and look at this file, and notice that it has functions for each field of our GraphQL Player type.

user_name : SelectionSet String SWP.Object.Player
user_name =
    Object.selectionForField "String" "user_name" [] Decode.string


member_since : SelectionSet Int SWP.Object.Player
member_since =
    Object.selectionForField "Int" "member_since" [] Decode.int

Each of these functions returns what is called a SelectionSet; more on that soon.

Now that we have generated elm-graphql files specific to our project, Let's establish a basic nomenclature and context for GraphQL so we can apply that to how elm-graphql sees the GraphQL world.

Relating GraphQL to elm-graphql

GraphQL has fundamentally just 2 types: Object types and Scalar types. (Enums, Union types, and Interfaces, for example, are just special derivations on these two types.) An Object type has fields. Each field has a type, which can either be Object or Scalar. Ultimately, as you follow the fields down the object hierarchy to the "leaves" of the type structure, they will all be scalar types.

In GraphQL, there are 3 parts to defining a query:

The operation type (and sometimes an operation name and variables)
The entry point or root field of the query
The shape and domain of the data you want back.

The operation type will be one of "query", "mutation", or "subscription". The entry point of the operation is known as a root field. Root fields are defined in the schema in one of 3 special Object types: Query, Mutation, and Subscription (as you might have guessed). Depending on what type is returned from a root field, you will define selection sets to specify the shape (what fields) and domain (using arguments, custom resolvers, etc) of the data you want back. Selection sets are delineated by paired curly braces ({}).

As an example, imagine you have the following types defined in your schema:

type Player {
  user_name: String!
  member_since: Int!
}

type Event {
  organizer: Player!
  title: String!
  description: String
}

type Query {
    allEvents : [Event!]
}

Using this schema we could craft a query operation like the following:

query {
    allEvents {
        title
        organizer {
            user_name
        }
    }
}

In this example, everything between the first set of curly braces is called the root selection set, then allEvents has its own selection set, title has no selection set (because it is a scalar) and organizer has its selection set.

Now let's context switch to elm-graphql. elm-graphql is centered around the SelectionSet type. Any query must have a root SelectionSet, which represents the root field in a GraphQL query. SelectionSets can be nested, just like in a GraphQL query. SelectionSets play a dual role, however, in that they also define what types your data will be decoded to when the data conforming to your root SelectionSet is returned. Because of this dual nature, every field in your GraphQL types, scalar or no, will have its own SelectionSet to facilitate its decoding.

As an example, take a look at the SWP.Object.Player module. This module defines a SelectionSet for each field of the Player GraphQL type. Notice that user_name, for example, is a String scalar type, but it still has a SelectionSet so it can be decoded:

user_name : SelectionSet String SWP.Object.Player
user_name =
    Object.selectionForField "String" "user_name" [] Decode.string

SelectionSets are also used to represent GraphQL fragments as any SelectionSet can be combined with another related SelectionSet.

The SelectionSet type definition is defined with two placeholder type variables:

type SelectionSet decodesTo typeLock

The first type variable is labeled decodesTo and represents the Elm type that this particular SelectionSet should decode to. For example, for the user_name field above, the first type variable is specified as "String", meaning this field should be decoded to a String. The second type variable is labeled typeLock and it represents the context for this specific SelectionSet. Again, looking at user_name above, the context of this specific field is the Player GraphQL Object type. The typeLock ensures that fields from different GraphQL Object types cannot be decoded into the same context.

Assembling our allEvents GraphQL query above with SelectionSets might look something like the following:

type alias Player : {
    user_name: String
}

type alias Event : {
    title : String
    , organizer : Player
}

playerSelectionSet : SelectionSet Player SWP.Object.Player
playerSelectionSet =
    SelectionSet.succeed Player
        |> SelectionSet.with SWP.Object.Player.user_name

eventSelectionSet : SelectionSet Event SWP.Object.Event
eventSelectionSet =
    SelectionSet.succeed Event
        |> SelectionSet.with SWP.Object.Event.title
        |> SelectionSet.with (SWP.Object.Event.organizer playerSelectionSet)

rootQuery : SelectionSet (Maybe (List Event)) Operation.RootQuery
rootQuery = Query.allEvents eventSelectionSet

The two type aliased records are used to capture the data from decoding players and events. Notice that these records do not need to have all of the possible fields for the GraphQL types we defined. The playerSelectionSet function builds upon the field-level SelectionSet for user_name to create a SelectionSet that can decode to a Player. The eventSelectionSet function builds upon both a scalar field SelectionSet and the custom playerSelectionSet to properly decode to the Event type. And the allEvents root field builds upon the eventSelectionSet to build a root query that we can call.

The purpose of the illustration above is to demonstrate how to map a GraphQL schema to elm-graphql. Understanding how to build out SelectionSets in elm-graphql is the most critical part of leveraging this package.

Enough of the theoretical examples… let's dig in and we'll learn the rest of what we need to know about elm-graphql while we implement our GraphQL call to FaunaDB.

Connecting elm-graph To Our GraphQL Service

We will divide up the task of building and executing our createAndOrLoginPlayer mutation into 5 easy steps (seriously, they are not too hard ;):

Assemble our SelectionSets for the mutation
Assemble our query request
Assemble our query response handling
Test it out
Do a happy dance because it works!

Step 5 is my favorite.

Let's create a new module that will act as a bridge between our main application code and the "SWP" elm-graphql framework. Call it "Bridge.elm" and save it at the root level of the "src" folder.

In part 1 of this article, we called our createAndOrLoginPlayer mutation from the GraphQL Playground provided by FaunaDB. Let's review that mutation operation here again:

mutation CreateAndOrLoginPlayer {
  createAndOrLoginPlayer(user_name:"cool_user_name", password:"even_cooler_password")
}

The root field of the mutation selection set returns a simple String, which is our token for the logged in player. This means we will not need to assemble any custom SelectionSets. That is good news for our first effort, nice and simple.

In our Bridge module, then, let's move on to step 2 and create our query request. We will start by importing the modules we are going to need – here is how to start the file:

module Bridge exposing (..)

import DataModel exposing (Password, Token, UserName)
import Graphql.Http as Http
import Graphql.Operation exposing (RootMutation)
import Graphql.SelectionSet exposing (SelectionSet)
import SWP.Mutation as Mutation

elm-graphql provides an Http module to create and send GraphQL requests and handle errors. Using this module, we will need to send our request to our FaunaDB endpoint along with our "bootstrap" custom key as a Bearer token. In this light, lets create a few constants in our Bridge module for these two data points; be sure to use your own custom key:

endpointURL : String
endpointURL =
    "https://graphql.fauna.com/graphql"

customKeyBearerToken : String
customKeyBearerToken =
    "Bearer zzA20468euAbCdEMOlvgSa8xRvJLRBQH7BfXh4iu"

Remember, due to the way we set up our access control in FaunaDB, it is safe to include this custom key in our client-side code, but do be sure it is the "bootstrap" key, and not the server key that we used earlier.

Next, let's put together our root field mutation SelectionSet. elm-graphql created the building blocks for us in the "SWP/Mutation.elm" file; take a look again at the createAndOrLoginPlayer function.

createAndOrLoginPlayer :
    CreateAndOrLoginPlayerRequiredArguments
    -> SelectionSet String RootMutation
createAndOrLoginPlayer requiredArgs =
    Object.selectionForField "String" "createAndOrLoginPlayer" [ Argument.required "user_name" requiredArgs.user_name Encode.string, Argument.required "password" requiredArgs.password Encode.string ] Decode.string

Notice its first parameter is a record with the required data to make our createAndOrLoginPlayer GraphQL mutation call. This ensures that there is no way we can call our mutation without providing the necessary parameters.

Let's add a function to our Bridge module that creates our root field mutation SelectionSet with the required user name and password data:

mutationCreateAndOrLoginPlayer : UserName -> Password -> SelectionSet Token RootMutation
mutationCreateAndOrLoginPlayer user_name password =
    let
        required_arguments =
            Mutation.CreateAndOrLoginPlayerRequiredArguments user_name password
    in
    Mutation.createAndOrLoginPlayer required_arguments

We are almost done with step 2. All that is left is to assemble our GraphQL.Http.Request. Our request will be a mutation operation with an endpoint and an authorization header that contains our custom key. Our root SelectionSet we created in the previous step will be our entry point into the operation:

requestCreateAndOrLoginPlayer : UserName -> Password -> Http.Request Token
requestCreateAndOrLoginPlayer user_name password =
    Http.mutationRequest endpointURL (mutationCreateAndOrLoginPlayer user_name password)
        |> Http.withHeader "authorization" customKeyBearerToken

We are now done with step 2, except, instead of exporting everything out of the Bridge module on the first line, which is not necessary, let's limit our exports to the requestCreateAndOrLoginPlayer function.

module Bridge exposing (requestCreateAndOrLoginPlayer)
…

Now we are ready to move on to step 3 which will take place completely within our Main module. Luckily, we have already put in a nice faux login sequence, so we only need to tweak a few things, and it should "just work".

Open the Main.elm file in your editor. Let's start by importing our Bridge module and the Graphql.Http module we will need to send the request:

import Bridge exposing (requestCreateAndOrLoginPlayer)
import Graphql.Http as Http

Next we need to update the handling of the LoggedInPlayer message. Let's tweak the signature of this Msg variant like so:

| LoggedInPlayer (Result (Http.Error Token) Token)

Instead of LoggedInPlayer carrying back just the Token, it will now carry back a Result. A Result, if it is an error, will carry back a Graphql.Http.Error, or, if it is successful, will carry back the Token.

Of course, since we changed the signature of the message, there will be a ripple effect; we will need to update the message handler in the update function, and the model handler for the message itself. The message handler should now look like this:

LoggedInPlayer response ->
   ( updateModelFromLoggedInPlayer model response
   , Cmd.none
   )

Pretty straight forward, we grab the response and pass it on to the model handler to deal with. The changes in the model handler are more extensive:

updateModelFromLoggedInPlayer : Model -> Result (Http.Error Token) Token -> Model
updateModelFromLoggedInPlayer model response =
    case response of
        Ok token ->
            case model.m_player of
                Just player ->
                    let
                        updated_player =
                            { player | m_token = Just token }
                    in
                    { model | m_player = Just updated_player }

                Nothing ->
                    model

        Err _ ->
            model

OK, so maybe not that much more extensive, but it could have been. Let me explain.

Rather than first looking for whether we have a player or not in the model, we now first look to see if the result was Ok or an Err. If the result was Ok, then we grab the token and proceed as we did before by storing the token in the current player, if any. However, if the request had an error, we… well… we do nothing, just return the model. This is not good! What we should do here is handle the error in a thoughtful manner. For example, if the error was a network error, perhaps we could put up a message and ask the user to try again. Or if the error was a GraphQL error, we could check the error and give the user a chance to respond to it, like when an incorrect password is entered. You see, this could have (and should have) been much more extensive of a change!

So this does beg the question why didn't I do it? And the short answer is, so you would have something fun to do after you complete this article! In either case, PLEASE do not ignore thoughtful and thorough error handling in your production code. 'Nuff said!

There is now one final change we need to make before we test our code and see if we have successfully joined our front-end to the backend – we need to update the command that makes the mutation request to use our updated message and new Graphql.Http.Request. This is what it should now look like:

createAndOrLoginPlayer user_name password =
    Http.send LoggedInPlayer (requestCreateAndOrLoginPlayer user_name password)

OK – that's it! We are now done with step 3 and are ready for step 4 - Testing! Start the app, load the front page, bring up your debugger so you can see your messages and model, and let's give it a try!

Here is what I saw when I tried logging in with a new player named "Dirk":

And here is what it looked like in the application:

I hope there were no hidden cameras recording me doing step 5! 🕺🏼🎉🕺🏼

Wait. Wait. I almost forgot. Let's look at the database and see if our new account shows up:

Just like we'd hoped!

Play around a little more. Try logging out and logging back in with the same account. Is a new record created? Log in with a few more new accounts. Enjoy the fruits of your labor for a moment. And when you are ready, we'll move on to using that token to fetch a list of all other players.

One More Time About Error Handling

In playing with logging into different accounts, were you curious enough to test logging back in with a wrong password? I was, and here was what the payload for the LoggedInPlayer message looked like:

This message is from FaunaDB letting us know that the player instance could not be found or the password was incorrect. In a useful app, we would, of course, let the user know and give them an opportunity to try again.

Getting All User Names

The purpose of saving our login token in the Player record was so that we could use it to get back the user names of all registered players so that we would know whom we could invite to our gaming events. We want to be sure not to send too much data back to the client, so we only send the user names. The user name alone is enough information for us to invite players to events, because, in addition to being the visual presentation of a Player, the user name is the Player's unique identifier in the client application.

Before we add fetching user names to the client, we actually have to clean up some things. You have noticed that even when you created your first real Player, you actually see a list of players after logging in. This is because, for the "stage0" version of the app, I was starting up with some locally created players and events, just so there'd be something to see. Before we start fetching the user names actually stored in the database, we should remove this demo data.

In the DataModel module, go to the defaultModel constant and replace the startingPlayers and startingEvents dictionaries with empty dictionaries (Dict.empty):

defaultModel =
    { input_user_name = ""
    , input_password = ""
    , m_player = Nothing
    , players = Dict.empty
    , events = Dict.empty
    , m_possible_event = Nothing
    , m_poss_event_elem_info = Nothing
    , login_offset = 0.0
    , login_field_with_tab_index = UserNameField
    , dragged_player_position = emptyPlayerPosition
    , drag = D.init
    }

Now delete the startingPlayers and startingEvents dictionaries found in the same module. Log in and take a look at how it looks now:

Ahh… nice and sparkly.

Now we are ready to apply the same 5 easy steps we used to add login functionality to fetching all user names with our newly minted login token:

Assemble our SelectionSets for the query
Assemble our query request
Assemble our query response handling
Test it out
Do a happier dance to 'Staying Alive' by the BeeGees because it works!

Step 5 is still my favorite.

When we put together our GraphQL query for createAndOrLoginPlayer, we didn't need a step 1 to assemble any custom SelectionSets because all we were getting back was a String, and this decoding was handled directly in the root field SelectionSet auto-generated by elm-graphql. However, for our query for allUserNames, we are going to do some SelectionSet wrangling to make sure the data comes back in a form that is easily consumable by our application's model.

First, remember that the user names coming back from allUserNames is a list of strings. However, in our model, we track the set of all players in an Elm Dict.

type alias Players =
    Dict UserName Player

An Elm Dict has a nice convenience function to populate it from a List called fromList:

fromList : List ( comparable, v ) -> Dict comparable v

Notice that fromList takes a list of tuples that are composed of a "comparable" key and an arbitrary value. Hmm… this is not exactly what we are getting back from our GraphQL query. Rather, we are getting back a list of comparable UserNames (Strings). For us to easily populate our Players Dict, we will have to transform our SelectionSet of UserNames to a SelectionSet of tuples of type (UserName, Player). No problem.

To accomplish this, we will use a SelectionSet function called map. map takes the decodeTo type of a SelectionSet and transforms it to another decodeTo type:

map : (a -> b) -> SelectionSet a typeLock -> SelectionSet b typeLock

Here a represents the incoming decodeTo type and b represents the outgoing decodeTo type. As noted above, the type we want to transform to is a tuple of type (UserName, Player). Let's first go to our DataModel module and create a new type alias for this type and call it PlayerAssociation:

type alias PlayerAssociation =
    ( UserName, Player )

Next, lets to go our Bridge module and update our imports so we have what we need to work with; note that some of these are updated imports and some are new:

import DataModel exposing (Password, PlayerAssociation, Token, UserName, newPlayer)
import Graphql.Operation exposing (RootMutation, RootQuery)
import Graphql.SelectionSet as SelectionSet exposing (SelectionSet)
import SWP.Query as Query

Now we will create a root field query that will perform the SelectionSet transformation we described above using SelectionSet.map. Let's call this query queryAllUserNames:

queryAllUserNames : SelectionSet (List PlayerAssociation) RootQuery
queryAllUserNames =
    Query.allUserNames
        |> SelectionSet.map
            (\user_names ->
                List.map
                    (\user_name ->
                        ( user_name, newPlayer user_name )
                    )
                    user_names
            )

Notice that we used a constructor called newPlayer to help us generate new players easily. We are now done with step 1.

In step 2, as per normal, we will assemble our query request. The mutation request we created earlier relied on the custom key that all instances of Shall We Play? use to create and log in new players. However, this custom key, thankfully, does not have permission to grab the user name list. To grab the user name list, we need an authorized login token. Let's create a request called requestAllUserNames that takes this token:

requestAllUserNames : Token -> Http.Request (List PlayerAssociation)
requestAllUserNames token =
    Http.queryRequest endpointURL queryAllUserNames
        |> Http.withHeader "authorization" ("Bearer " ++ token)

In order to call this new request from the Main module, we'll need to expose this function:

module Bridge exposing (requestAllUserNames, requestCreateAndOrLoginPlayer)

We are now done with Step 2.

Step 3 will require the biggest changes to the application, all within the Main module. As with all commands, we are going to need a Msg variant so we know when the command has completed. This particular message, shall we call it ReceivedUserNames, will return with the result of the query, which will hopefully be a list of UserNames... wait, I mean, a list of PlayerAssociations… nice, right? Let's add this message, which takes a Result, to our Msg variants list:

| ReceivedUserNames (Result (Http.Error (List PlayerAssociation)) (List PlayerAssociation))

And, of course, Elm will not let us get away with not handling this message in our update function; be sure to specify a model handler:

ReceivedUserNames response ->
   ( updateModelFromReceivedUserNames model response
   , Cmd.none
   )

In our model handler for ReceivedUserNames, we will need to create a new Dict of players. Luckily, thanks to our SelectionSet wrangling, our data is coming back to us in the exactly the form we need to easily create our Players Dict:

updateModelFromReceivedUserNames : Model -> Result (Http.Error (List PlayerAssociation)) (List PlayerAssociation) -> Model
updateModelFromReceivedUserNames model response =
    case response of
        Ok player_associations ->
            { model | players = Dict.fromList player_associations }

        Err _ ->
            model

A red light should have gone off when you noticed I had no error handling here, right? OK. Move along, move along.

We are almost done assembling our puzzle pieces. They are fitting together very nicely, by the way. We now need to create the command that sends the query request. But before we can do that, we need to update the Bridge import to include our new request:

import Bridge exposing (requestAllUserNames, requestCreateAndOrLoginPlayer)

In the tradition of naming our command after the GraphQL query, let's call our command allUserNames and pass in the token we need from the currently logged in player:

allUserNames : Token -> Cmd Msg
allUserNames token =
    Http.send ReceivedUserNames (requestAllUserNames token)

We have our command ready, now all we need to do is discuss when we will call it. Thinking back to the login flow, a player provides their user name, then their password. Then we send off the createAndOrLoginPlayer mutation and receive back the LoggedInPlayer response, where we parse the result and store the login token. I think it makes sense to request all user names right when the token comes back with the LoggedInPlayer message.

Let's look at the current implementation of the LoggedInPlayer message handler in the update function:

LoggedInPlayer response ->
   ( updateModelFromLoggedInPlayer model response
   , Cmd.none
   )

We receive the message response, which is of type Result (Http.Error Token) Token. We don't know at this point if we actually have a valid token so we can't call our allUserNames command here. Looks like we need a command handler to deconstruct the response and retrieve the token, just like the updateModelFromLoggedInPlayer model handler does. Update the LoggedInPlayer message handler with a new command handler called commandFromLoggedInPlayer:

LoggedInPlayer response ->
   ( updateModelFromLoggedInPlayer model response
   , commandFromLoggedInPlayer response
   )

And the details of the commandFromLoggedInPlayer command handler:

commandFromLoggedInPlayer : Result (Http.Error Token) Token -> Cmd Msg
commandFromLoggedInPlayer response =
    case response of
        Ok token ->
            allUserNames token

        Err _ ->
            Cmd.none

If the token is part of the response, we call the allUserNames command with the token and await the juicy details. Note that we wouldn't necessarily need to do any error handling here, because the model handler is also looking at the response and could deal with the error there. Just sayin'.

That's it. Step 3 is done. Time for step 4. I don't know about you, but my stomach is telling me I'm anxious to see the results. Let's give it shot, shall we?

If you haven't been developing with the application running (which I do recommend, as you know), go ahead and launch the app now. Log in and see if you have a user list!

Here is what I see:

And on my screen:

Woot!! Step 5 here I come! Go ahead, click on the link. You know you want to! 'Staying Alive' by the BeeGees. 🕺🎊🕺 🎉🕺.

Congratulations for completing this tutorial!

Retrospective and Conclusion

Let's review what we have accomplished over the course of this article. In part 1 you were introduced to a starter JAMstack site for scheduling game nights with friends called Shall We Play?. Shall We Play?, an Elm application, had rudimentary features, but was not backed by any identity management or data storage, making it shiny but of no real value.

You then learned about FaunaDB, a database built from the ground up for the serverless, JAMstack architecture. We leveraged FaunaDB's native support for GraphQL and built-in identity management to construct a secure GraphQL schema to back Shall We Play?. We developed these services independent of Shall We Play?, knowing that if we designed a good schema, Shall We Play? would be able to easily interface with this service.

In part 2 we turned our sites to the Shall We Play? application and interfaced it with our GraphQL service using an Elm package called elm-graphql. This integration required us to introduce passwords to the login flow, and otherwise only required a few new messages to account for the client-server interactions via GraphQL. Thanks to the intuitive design of elm-graphql, we used the same concepts we knew from GraphQL to easily build out our interface.

Shall We Play? now has secure login and can fetch a list of all registered players. While this is not enough of an improvement to make it good at scheduling gaming events, it is certainly a great example of the power and flexibility of the triumvirate of Elm, GraphQL, and FaunaDB.

While what we have covered is not a complete solution by any means, you should see a clear path to leveraging these technologies to get you the rest of the way simply and securely.

Thanks for joining me!

FaunaDB, GraphQL, and Elm, A Tutorial for JAMstack, Part 1

Dirk Johnson — Tue, 21 Jul 2020 13:51:43 +0000

Introduction

[Note: this tutorial was written by commission for Fauna, Inc]

If you are reading this tutorial, something about it caught your eye. Perhaps it was the reference to Elm, a delightful language for reliable web apps. Perhaps it was GraphQL, which is an abstract query language and service for your backend APIs. Or perhaps it was FaunaDB, a full-featured, cloud-based datastore built for serverless computing. Hopefully it was all three!

This tutorial will cover how to bring all three of these capable technologies together as a cohesive solution for writing JAMstack applications.

Oops, I just dropped another term on you: “JAMstack”. Let's provide further explanation for all these terms, starting with JAMstack.

JAMstack

JAMstack is an approach to architecting your web applications. It is not opinionated about what technologies you use to do this, other than requiring Javascript (J), APIs (A), and Markup (M).

The core JAMstack architecture builds upon static content enhanced by client-side Javascript and serviced by microservice APIs. Notice that there is no mention of a tightly-coupled web application behind your site! This means your entire application (with the exception of your microservice functions,) can be cached and delivered by a Content Delivery Network (CDN). This simplified application architecture leads to better performance, higher security, and straightforward scaling.

Serverless Computing

While browsers are getting more and more capable, to provide security and persistent, global data storage for your client, you still need to back your JAMstack applications with server-side services. However, rather than backing your client with a monolithic backend application server requiring development, deployment, and support cycles, in the JAMstack architecture, we use "serverless" microservices which are accessed directly or through stateless functions. These functions and microservices run in the cloud, and require little to no support on your part.

I realize all of this sounds wonderful at a high level, and that discerning developers are going to need to go deeper to be confident of the advantages of the JAMstack architecture, but for the moment, accept the coolness, and join me in discovering how to leverage some technologies custom fitted for JAMstack; please welcome FaunaDB, GraphQL, and Elm.

FaunaDB

Behind every data query is a data store. Choosing the right data store for your application architecture is, in my opinion, one of the most important architectural decisions you will make for an enterprise-level application. There are many considerations to choosing the right data-store, such as the ability to impose data integrity assurances and constraints, data security, reliable backup-and-restore, ease of scaling, performance, and the list goes on.

And in today's JAMstack architectures, there are new considerations like schema flexibility, minimal operational investment, data consistency, global low latency, and, of course, ease of backing a microservice architecture. Whew!

FaunaDB is a database built from the ground-up to address all of these checkbox items and more. One that I am particularly excited about is FaunaDB’s native GraphQL service which makes implementing a GraphQL interface as simple as defining your schema, importing it, and fleshing out the resolvers. Zap!

GraphQL

Applications and services need to communicate with each other. As with all effective communication, each side of the conversation needs to listen to and speak the same language. GraphQL is both a language and a service that facilitates querying for data, mutating data, and even subscribing to messages about data. Those familiar with JSON, an extremely popular exchange format for structured data, should feel right at home with GraphQL, as its type structures are expressed in a similar format.

One of GraphQL's benefits is the ability to not only provide a schema for the shape of your data, but also the types of your data (which is very nice for Elm). It also allows you to dynamically limit the data members returned from your structured data, thus reducing the total size of the data passed over the wire, especially when compared to other data-exchange interfaces such as REST.

Elm

Elm is a strongly typed, functional language that transpiles to Javascript. Because of its type guarantees and pure, functional approach, it boasts an amazing compiler with very friendly error reporting, and a near perfect absence of runtime errors (by real-world measurements).

Elm is also an architecture for web applications (lovingly referred to as The Elm Architecture, or TEA). The key concepts of this architecture are a centralized Model for your data, a View (HTML) purely driven by updates to the Model, and an update function that responds to specific messages from the DOM (or a worker, or an XHR request, etc.), which then updates the Model, which then triggers an update to the View, and so on. This clean, reactive design pattern is found in some form in other frameworks such as Redux and Vuex; however, coupling it with a pure, functional language makes this pattern much more natural so architecting your own application is intuitive, allowing you to focus on what makes your project special.

A Triumvirate for JAMstack

Each of these technologies, FaunaDB, GraphQL, and Elm, are great technologies on their own, but bringing them together creates an even more powerful combination. FaunaDB boasts powerful features with an amazing ease of setup and management in the serverless space. On the client side, you have Elm, with its strong runtime guarantees built upon a simple, reactive architecture. And, bringing these two together in a well designed, typed, data exchange is GraphQL. Together, each layer of the JAMstack is both fun and profitable. And isn’t that why we do this job – so we can have fun?

So… let’s go play!

Shall We Play?

In this 2 part article, you are going to learn how to bring these technologies together in a unified, secure, JAMstack architecture. In part 1, we will focus on FaunaDB and it’s native GraphQL support by building out our schema and identity management architecture. In part 2, we will focus on Elm, and, more specifically, on a package called elm-graphql, that will allow us to easily interface an Elm application with the backend services we implemented using FaunaDB.

However, before we even get started, we will first need an Elm JAMstack application ready and waiting to be integrated with a backend service. As luck would have it, there is one waiting and ready for us called "Shall We Play?". Shall We Play? is a not-so-full-featured site for scheduling game nights with friends.

For this introduction to Shall We Play?, you can visit the basic, deployed version of the application.

Logging Into Shall We Play?

Since Shall We Play? does not currently have a secure login, all that is necessary to sign in right now is a user name. If that user name exists, you will be logged in as that user; if it does not, it will be created.

Go ahead and enter any user name you'd like and hit return or click on the login button.

The likelihood is that you chose a user name that did not exist. If that is the case, then you should see a view similar to the following:

As should be expected when logging in with a new account, Shall We Play? tells you that you have organized 0 events and that you are invited to 0 events.

If you did choose a user name that existed (against all odds), just log out and log back in with a new user name.

Below the logout panel you will see a list of "All Other Players". This is a list of all registered players (except for yourself, of course).

The "Events" section below the players list is also empty. This should always correspond to the event summary reported at the top.

Creating Your First Event

So, you want to play Star Fleet Battles with your friends Solo and Charlie – how do you start a new event? To the right, under the summary header is text that says "Drag a player to start an event". Cool, let's do that. Go ahead and start dragging "Charlie".

As you drag "Charlie", you will see a dialog pop up. Drop "Charlie" on this dialog. Go ahead and drag "Solo" over as well. Add a creative title, description, and venue. Set a date for the event, then click "Save".

You should now see your first event under "Events". The number of events you have organized should also be reported as 1. Notice how "Charlie" and "Solo" have yellow backgrounds; this is because they have not yet accepted their invitation from you.

Log out of your account by clicking on the logout button and log back in as Charlie and accept the invitation by clicking on "Update to I Am Going".

You should now see Charlie's "Going?" status set to "Yes" with a green background.

Log out of Charlie's account and log back in as yourself. You should now see "Charlie" with a green background.

Peeking Under The Hood

There are a few more features to discover about Shall We Play?, but not much more. And for the curious, feel free to peek under the hood at the Elm code. We will go into far more detail later on regarding how Shall We Play? is architected, but at this point, it could be fun to take an unguided tour.

As you explore the code for Shall We Play? you will notice that there is no pre-render step for this simple application, which is sometimes considered a hallmark feature of a JAMstack site. Please note that there are two solid static site generators for Elm that I am aware of (and have used). The first is inspired by Jekyll, called Elmstatic by Alex Korban (who has also authored a great Elm book). The second is inspired by Gatsby, called Elm Pages by Dillon Kearns. In either case, I did not want to add to the complexity of a very simple application, so I chose to keep Shall We Play? minimal, while still keeping to the tenets of JAMstack, that is, deploying completely from a CDN and being backed by a multi-region, zero-operation database.

Securing Our Login with FaunaDB

Shall We Play? is nice, but it has a few issues. First, it is not very useful. Other people logging into a different application instance will not see any of the events that you invited them to. And if you reload the page, all of your scheduled events go away. Oops! By moving to FaunaDB as your backend data store, you will be able to persist your data so that everyone using the site will see the same data and feel comfortable that their data is going to be there when they visit again.

The second issue is that Shall We Play? is not secure; if anyone knows your user name, they can log in as you. And, if they log in with any name, they can see yours and everyone else's user names, so there is not even the comfort of "security through obscurity" (which, as the saying goes, "is no security at all").

The most important issue to solve is the insecure login and so, will be the primary issue we address in this tutorial. Once we have added secure login, you will have all the tools in your tool belt that you need to add saving events to the database.

The Registration And Login Use Case

FaunaDB's native integration with GraphQL as well as its identity management and attribute-based access control (ABAC) will allow us to provide an elegant solution to securely logging into our application. But first, we are going to put on our thinking caps and think through what we need to do to allow a user to register and login, and then access player user name data. If we don't get this right, we risk exposing data to unauthorized clients and peers. So let's get it right.

First, we need to acknowledge that our client is untrusted. Anything our client has or says cannot be trusted. Yes, it's true. The reason is, and it's a simple reason, that in the web application world, everything our client application knows and sees is accessible by the user, including uninvited users. This goes for images, JavaScript code (as obfuscated as it may be), data in memory; everything is available to the uninvited user.

Now let's think about the data store. We could approach data security by being miserly and not let anyone have it. But then that wouldn't be a very useful data store. Data is meant to be consumed, responsibly, of course. So what we need to do is define which data and data operations are safe to share with potentially uninvited users, and which data and data operations can be shared with authenticated and authorized users, which we will call "players".

Finally, let's create a use case for how Shall We Play? will behave when registering and logging in a new player. We'll start by reviewing how Shall We Play? currently does it:

A new player goes to the Shall We Play? website and sees the login prompt. The new player enters a new user name and clicks on the login button. A new account is created and the player is logged in, where they can see the user names of all other registered players.

This is a nice, simple approach, but to secure the login process, we need to require a password. Let’s update this use case by adding a password to the login flow:

A new player goes to the Shall We Play? website and sees the login prompt. (At this point, they are, by default, untrusted and therefore considered uninvited.) The new player enters a new user name and clicks on the login button. The password field is then presented and the new player enters a password and clicks on the login button again. A new account is created and the player is logged in where they can see the user names of all other registered players. (At this point, the new player is a trusted player.)

This new use case tells us what we need to know to build our permissions structure for logging in and sharing player data:

We need to allow untrusted players to create and/or login to an account
We need to hide player data from untrusted players, but make user names accessible to trusted players once they log in

Perfect!

Creating Our Initial GraphQL Schema

Now that we know what data, operations, and permissions we need to support for registration and login, we can start to define our GraphQL schema. Go ahead and create a schema file with a proper name, ending with the suffix .gql.

While this tutorial does not require you to be an expert in GraphQL, having a cursory understanding of GraphQL schemas, queries, and mutations will help tremendously.

If you took time earlier to look at the underlying Elm code, you would have noticed that the Player type has two fields: user_name of type UserName (which, under the hood, is a String) and member_since of type Int.

So on the GraphQL side we will follow suit and, in our new schema file, define a Player type with a user_name field of type String! and a member_since field of type Int!:

type Player {
  user_name : String!
  member_since : Int!
}

The ! means the field value is non-nullable (i.e., required to have a non-null value).

The next thing we need is a GraphQL mutation we can use to register a new player and/or log a player into the application. This mutation will need to support the new player use case we outlined above as well as support a returning player logging in (or rejecting them if the password is wrong). This means we will only need to define one mutation for both registration and login:

type Mutation {
  createAndOrLoginPlayer(user_name: String!, password: String!): String!
}

Both the user_name and password parameters to the createAndOrLoginPlayer call are required and the return type is a String that cannot be null. This string will be a very important token which represents both the identity of the now logged in player as well as what data they have permission to access.

Finally, to meet our requirements outlined above, we will define a GraphQL query that can only be called by a logged in (trusted) player, and that can only return player user names and nothing else about a player:

type Query {
  allUserNames: [String!]!
}

If you are confused by this notation with the ! both outside and inside the array, you would read this as "the array is non-nullable, but can be empty, and if the array does have values, they must be Strings, no nulls allowed."

It is idiomatic to provide a query of the form allType: [Type!] that returns all records of a certain type, for each of the types in the schema. However, an allPlayers query would not be useful to us for this tutorial, because we do not want a query that allows the return of any/all properties of a player. Rather, we just need to get back a list of user names.

Adding FaunaDB GraphQL Directives To Our Schema

Our GraphQL schema is now complete in that it represents all we need in order to register and log in a new player, however, due to FaunaDB's tight integration with GraphQL, there is more that we can add to the schema that will help. FaunaDB’s GraphQL Directives automate the creation of database resources such as collections, indexes, and functions. These directives save us a lot of time by creating what we would otherwise have to create manually. All GraphQL Directives start with an @. FaunaDB provides several custom directives but we will only concern ourselves with two: @unique and @resolver.

One of the things we will need to ensure is that no two players have the same user name. FaunaDB defines unique constraints like this through Indexes. In order to tell FaunaDB to create an index to ensure that the user_name field remains unique, we will add the @unique directive to the user_name field:

type Player {
  user_name: String! @unique
  member_since: Int!
}

Next, we need to make a tweak to the mutation and query we have defined in our schema. FaunaDB will evaluate our schema when it is imported and create some default queries and mutations, but our specific query and mutation will require us to define a User Defined Function (UDF) for each. These UDFs will be used to perform the business logic surrounding registration and login as well as specifically returning just the player data that the logged in player is authorized to see.

At this point you might ask why FaunaDB doesn’t just provide the registration and login logic for us as this is such a common feature? Good question! The reason is that the business policies surrounding registration and login can be complicated and are highly variable between different use cases. FaunaDB, rather, provides you with the building blocks necessary to create whatever policies you need. More on that later.

When UDFs are attached to a query or mutation, they are called resolvers:

type Mutation {
  createAndOrLoginPlayer(user_name: String!, password: String!): String! @resolver(name: "create_andor_login_player")
}

type Query {
  allUserNames: [String!]! @resolver(name: "all_user_names")
}

Notice how the @resolver takes a name parameter; this is the name of the UDF that FaunaDB will create for us when this schema is imported. The UDFs that are auto-created will, by default, throw an error when called. This is to remind us that we actually have to update these functions with our own business logic, which we will do shortly.

We are now ready to import our new schema into our brand new database... wait... what database?

Signing Up For Your FaunaDB Account

In order to proceed, we are going to need a database for Shall We Play?. Fauna has a free tier that allows you to take full advantage of FaunaDB’s features, with a generous daily usage quota. If you would like to follow along, and you haven’t already signed up for your free account, you can go directly to the registration page, log in with your GitHub or Netlify account, or use your email to create a new Fauna account.

Creating The FaunaDB Database

Now that you have a Fauna account, let’s create the database for Shall We Play?:

Log into your FaunaDB account; you should be brought to your FaunaDB Console Home
Create a new database by clicking “New Database” in the upper-left
Let’s name the database "swp", nice and simple. Save the new database.

You will be brought to the DB Overview for your new database.

Notice the tabs to the left for collections, indexes, and functions. We will visit these in a bit. Also notice there are tabs for an interactive FQL shell, GraphQL management, and security management. We will be visiting all of these tabs before we are done.

Documents, Collections, Indexes, and Functions

As noted before, the core of any communication is speaking the same language. In the tech world, that means understanding acronyms and terms in their respective contexts. In that light, let’s review a few terms in the context of FaunaDB: Documents, Collections, Indexes, and Functions.

First, if your background is SQL, there is a nice section in the documentation drawing comparisons between FaunaDB and SQL. If this is for you, take a look.

A Document is an editable record that stores related data surrounding a single concept, like a Player or a Book or an Author. It references these data by keys or field names, similar to how a JSON Object works. It is similar in concept to a row in a SQL table. It will always have an identifier or reference.

A Collection is a grouping of documents. It serves to categorize the documents it holds, though there is no constraint on what the structure of its constituent documents must look like. Indeed, the documents within a single collection need not have any fields in common (though ensuring they do, at least in part, makes having different collections much more useful).

An Index facilitates flexible data searches and sorts on a single collection. Documents in a collection are always accessible by the document’s reference; however, retrieving documents by their data fields requires an index. Indexes also serve to enforce constraints, like unique values within a common field or fields, and they are inherently sorted.

FaunaDB Functions are bits of code written in FQL (the Fauna Query Language). Functions can be used to enforce secure and authorized access to data, to automate maintenance, and to enforce business logic. When functions are used as resolvers for GraphQL queries and mutations, they are called User Defined Functions (UDFs).

For further review of these terms and many others, please see the FaunaDB Glossary.

Importing our GraphQL Schema

Now that we have learned these new terms, let’s do something with them; let’s import our GraphQL schema into our freshly created database. As a review, our GraphQL schema looks like the following:

type Player {
  user_name: String! @unique
  member_since: Int!
}

type Mutation {
  createAndOrLoginPlayer(user_name: String!, password: String!): String! @resolver(name: "create_andor_login_player")
}

type Query {
  allUserNames: [String!]! @resolver(name: "all_user_names")
}

Make sure the schema you have ready to import looks like this (and only this) and that its file name ends in .gql. Now lets import:

Go to the Console Home of your "swp" database and click on the “GRAPHQL” tab
Import your GraphQL schema by clicking on “IMPORT SCHEMA” and selecting your schema file from the file selection dialog

If your schema imports correctly, you should now see a GraphQL Playground which will allow you to test your GraphQL service.

If you received an error importing your schema, review your schema’s contents, make sure it is identical to the one listed above, and try again.

With the GraphQL Playground up, click on the “SCHEMA” tab in grey to the right. This is what your schema looks like after FaunaDB imported your schema and messaged it for you.

Notice you still see your Player type with user_name and member_since fields, but it also has a few more fields called _id and _ts, which are leveraged by FaunaDB internally to track your record over time.

Also notice that you actually have four mutations you can call, one of which is your custom mutation called createAndOrLoginPlayer. And your allUserName query is there along with another automatically provided for you by FaunaDB, because, in this case, Fauna knows best.

Now visit the “COLLECTIONS” tab on the left. Notice that based on the schema you imported, FaunaDB automatically created a Player collection for you.

Now visit the “INDEXES” tab. Again, based on the schema you imported, and more specifically, based on the @unique directive you placed on the user_name field of Player, FaunaDB automatically created an index for you that will let you search by user_name and also ensure that any inserted user names will be unique.

Finally, visit the “FUNCTIONS” tab. Here you will see two functions created for our two resolvers. The names should correspond to the ones you specified in your schema.

Take a look at their FQL code – though you may not understand FQL per se, by just reading them you should get a good idea as to what they do – they abort execution with a message that we need to actually add real behavior to these UDFs.

Don’t worry, that part is coming up real soon.

But first, we need to discuss exactly how we are going to make sure our data is safe from uninvited users.

Creating The Permissions Structure In FaunaDB

We will be leveraging FaunaDB’s flexible attribute-based access control (ABAC) to secure our application. This access control model is quite deep and nuanced, but also extremely powerful and flexible. I will not attempt to provide you a complete explanation of all its features and interactions, but will rather use specific examples relevant to our project to explain how the ABAC model will work for us.

First Question: What Do I Know?

The doorway into FaunaDB’s attribute-based access control system is always through a “secret”. If FaunaDB can’t verify what you know, then it won’t let you in. There are 2 types of secrets: Tokens and Keys. Tokens are identities that are tied to a specific document in a specific collection. They are usually tied to a collection that conceptualizes a real individual like “user” or “customer”. Tokens are generated by “logging in” with the proper credentials (password).

Keys, on the other hand, are global secrets independent of any collection in your database. They are not generated through logging in, but are created by the database administrator, and their distribution should be carefully controlled. Both types of secrets are important and have different use cases as you will see next.

The astute reader will have already realized where in our use case we will need a key and where we will need a token. Lets review the requirements of our use case:

We need to allow untrusted players to create and/or login to an account
We need to hide player data from untrusted players, but make user names accessible to trusted players once they log in

So, for the first requirement, we will need a custom key for untrusted players. We will need to make sure this key can only create an account and/or log in to the application. And for the second requirement, we will need a token, gained when logging in, to provide access to player user names.

Second Question: What Can I Do?

All Keys are tied to Roles, and Roles dictate what actions we can take on which resources. Looking at the first requirement of our use case, we need our key to be able to call the create_andor_login_player function, so we will need to tie our key to a role that can do this. Let’s call that role bootstrap:

Third Question: What Can My Functions Do?

Remember we said that roles dictate what actions we can take on which resources? Our functions themselves need access to resources as well. So, in this case, we need a role for our create_andor_login_player function. To determine which actions our function will need to take on which resources, lets diagram the flow of logic for this function and see what resources it uses:

The client calls create_andor_login_player with a user name and password
The function searches for a Player record with the user name provided using an index
If there is no Player record with that user name, then we create a Player with that user name and password
We attempt to login with the player (either a newly created Player or an existing one) using the password
If the login is successful, we return the login token to the client

In summary, it looks like we will need to (1) read (use) an index (called unique_Player_user_name) to search for a player by user_name. It also looks like we will need to (2) read the Player the index may find, and finally, we will need to (3) create a new Player if the index finds none. So lets create a role called register that has permission to do these three things:

Setting Up Your Permissions With FQL

We’ve outlined secure permissions for logging in. I know we still need to set up the permissions for calling our all_user_names UDF, but I’m anxious to get what we have just designed set up and tested in our GraphQL Playground. So let’s do that, shall we?

But first, a little more about FQL. FQL is a concise, functional, query language native to FaunaDB. Anything you can do with the database can be done in FQL. I’m not going to be teaching you FQL in this tutorial, but we will be using it. The language is descriptive enough that you should get the idea of what we are doing from reading the code and my explanations. However, if you’d like to learn more about FQL before (or after) proceeding, I recommend you start with their tutorials.

We will be entering our FQL in the web-based shell for our "swp" database, so let’s get into the shell first:

Log into your FaunaDB account; you should be brought to your FaunaDB Console Home
Go to the DB Overview for your "swp" database by clicking on the name of the database
Go to the shell console by clicking on the SHELL tab to the left

Dominating most of the page is the log and the editor areas; the log is on top and the code goes in the editor at the bottom. If this is the first time you have used the shell, you will see 3 lines of code entered for you:

Paginate(Collections());
Paginate(Indexes());
Paginate(Databases());

Go ahead and run this code by clicking on “RUN QUERY” (you can also run the code when focused in the editor using Cmd+return). You should see output in the log similar to the following:

Paginate(Collections());
Paginate(Indexes());
Paginate(Databases());

[
  {
    "data": [
      Collection("Player")
    ]
  },
  {
    "data": [
      Index("unique_Player_user_name")
    ]
  },
  {
    "data": []
  }
]

>> Time elapsed: 109ms

The return data is contained within an array which begins and ends with square brackets. As there were three calls, there were three JSON-like objects returned inside this array, each having a field named “data”. The first call asked for a list of all collections; notice that the first data point has a list (array) with your Player collection. The second call asked for a list of all indexes; notice that the second data point has a list with your unique_Player_user_name index. Finally, the third call asked for a list of the child databases in our "swp" database, of which we have none. (We will not be covering child databases in this tutorial.)

As I introduce new code, I will first show you the code, then provide an explanation, and then instruct you to enter the code into the editor and run the query. Be sure to read the explanation first before executing the code. Understanding what you are doing before actually doing it is an important pattern to remembering what you learn.

Let’s start fleshing out our permissions by first creating our bootstrap role. Let’s take a look at the FQL code:

CreateRole({
  name: "bootstrap",
  privileges: [
    {
      resource: Function('create_andor_login_player'),
      actions: {
        call: true
      }
    }
  ]
});

The description of the role is contained in an object. It has name and privileges properties. The name we have chosen is “bootstrap”, and the privileges indicate that this role has permission to call the create_andor_login_player function.

Go ahead and enter the code and execute the query; be sure to replace any code that might be in the editor already.

The core of the output should look something like this:

{
  "ref": Role("bootstrap"),
  "ts": 1590968733065000,
  "name": "bootstrap",
  "privileges": [
    {
      "resource": Ref(Ref("functions"), "create_andor_login_player"),
      "actions": {
        "call": true
      }
    }
  ]
}

This is what the role record looks like. It has a unique reference (“ref”), a timestamp (“ts”), a name, and our privileges. We won’t always review the log output of our FQL commands, but always look them over and make sure you understand the gist of it.

Tip: You can clear out the log by clicking on the “CLEAR” button at the top of the page.

Now let’s create our custom key that is tied to this new role:

CreateKey({
  name: "Bootstrap Key",
  role: Role("bootstrap")
})

Creating keys is pretty straight forward: choose a role and give it a name.

Go ahead and enter the code and execute the query.

The core of the output should look something like this:

{
  "ref": Key("267083179018420748"),
  "ts": 1590969218195000,
  "name": "Bootstrap Key",
  "role": Role("bootstrap"),
  "secret": "zzA20468euAbCdEMOlvgSa8xQvJLRBQH7BfXh4iu",
  "hashed_secret": "$2a$05$/OmiXQiSTDpuqr1KLpv/S.5VOfu6tYwB6FdPGnCrtZEWUnz8QcGhW"
}

The output from this command is very important to save, at least one part of it – the secret. The secret is the actual key that our Elm client will use to create and log in players. This is the only time the key will ever be displayed by FaunaDB. If you lose this secret, you will have to create a new one – there is no way to recover it.

Save this secret somewhere safe; we will need it later.

The secret listed above in this tutorial is not a real key – it has been changed to protect the innocent.

We have now set up the first half of the permissions structure we outlined above. Let’s continue with the second half by creating the role our UDF will use to access our index and read and create players:

CreateRole({
  name: "register",
  privileges: [
  {
    resource: Collection("Player"),
    actions: {
      create: true,
      read: true
    }
  },
  {
    resource: Index("unique_Player_user_name"),
    actions: {
      read: true
    }
  }
  ]
})

This register role is a little more complex than the last role we created. Instead of specifying privileges for a function, we are specifying privileges for our Player collection (create and read permissions), and for our unique_Player_user_name index (read permissions).

Go ahead and enter the code and execute the query.

Now we need to update our placeholder UDF created for us by the import of our GraphQL schema:

Update(Function("create_andor_login_player"), {
  name: "create_andor_login_player",
  body: Query(Lambda(["user_name", "password"],
              Let({
                    match: Match(Index("unique_Player_user_name"), Var("user_name")),
                    player: If(
                        Exists(Var("match")),
                        Get(Var("match")),
                        Create(Collection("Player"), {
                          credentials: { password: Var("password") },
                          data: {
                            user_name: Var("user_name"),
                            member_since: ToMillis(Now())
                          }
                        })
                      ),
                    login: Login(Select("ref", Var("player")), { password: Var("password") })
                  },
                  Select("secret", Var("login"))
              )
            )
        ),
  role: Role("register")
})

Woah! There is a lot going on here. Don’t panic. Let’s break it down.

First you will notice that we are actually updating our function as opposed to creating it (as we created the new roles and key). That is because this function already exists, so we need to modify it.

The core of the function is in the body field. When we create a function, the function wraps what is called a Lambda function. A Lambda function is basically an unnamed function. In this case, FQL uses Lambda functions to specify function behavior. When we designed our permissions structure, we actually went over the flow of this function – let’s review what we wrote in the context of what we see above:

The client calls create_andor_login_player with a user name and password; those parameters are passed into the Lambda function.
The function searches for a Player record with the user name provided using an index. This is done with the Match built-in function, which is using the unique_Player_user_name index.
If there is no Player record with that user name, then we create a Player with that user name and password. The Exists built-in function tests whether the Match call returns anything. If it doesn’t, it creates the player with the built-in Create call. Notice how in the Create call, the password is passed in as credentials for this specific player.
We attempt to login with the player (either a newly created Player or an existing one) using the password. This is done with the Login built-in function.
If the login is successful, we return the login token to the client. The Select built-in function returns the secret, which is the token from the result of the Login call.

Finally, notice that the role for this function is set to register.

Go ahead and enter the code and execute the query.

Looking at our two diagrams above, I think we have covered everything. Now we are ready to test our createAndOrLoginPlayer GraphQL mutation.

Testing Our Permissions with GraphQL Playground

We are now going to test our createAndOrLoginPlayer GraphQL mutation. We will do this from the GraphQL Playground found under the “GRAPHQL” tab; go there now.

The GraphQL Playground is a neat tool that lets you query your GraphQL service, and push against your GraphQL schema. On the left, you have a GraphQL query editor, on the right you have the output. And further to the right you have the “DOCS” and “SCHEMA” tabs. When you first imported your schema, we took a look at the “SCHEMA” tab. Go ahead and look at the “DOCS” tab now.

The “DOCS” tab shows you a different view of your schema than the “SCHEMA” tab. It presents your queries and mutations in the form of documentation that is useful for assisting you building complex queries. With more complex schemas than ours, this is a life-saver. Notice there is a search bar at the top so you can even search for that one query you can’t seem to get right. Go ahead and close the “DOCS” tab.

We are now going to create a mutation operation to test our schema and permissions. This operation will come from the GraphQL Playground “client”. As mentioned before, our Elm client will have to make this mutation call using our custom key. So, to test our permissions, we will need the GraphQL Playground client to use this key as well. At the bottom of the query editor is a footer called “QUERY VARIABLES”. Expose the “QUERY VARIABLES” section by clicking on the footer.

You will see an HTTP “authorization” header with a default key using basic encoding. We will replace this key with our custom key in “Bearer” format (non-encoded format). Insert your custom key into this template and replace the headers object with this new one:

{
  "authorization": "Bearer your-custom-key-here"
}

Now enter the following mutation in the query editor, but don’t execute it just yet:

mutation CreateAndOrLoginPlayer {
  createAndOrLoginPlayer(user_name:"example_user_name", password:"example_password")
}

This mutation operation calls the createAndOrLoginPlayer query with a user name of “example_user_name” and a password of “example_password”. When this query is executed, it will trigger the resolver that backs this query, passing in the user name and password. If all goes well, the UDF will create a new record in the Player collection with this user name and return a player token.

In the center between the query editor and the log is a “play” button. Go ahead and execute this mutation by clicking on the “play” button.

Assuming all went well, your output should look something like this:

{
  "data": {
    "createAndOrLoginPlayer": "fnEDtOiSt-CCAb00k_rewAIHaEzzJe5lKGBcrBpEdChNiYPEcXk"
  }
}

The return value of the createAndOrLoginPlayer call is found within a data object. The return value is the player token generated from the Login call. We did it! Congratulations! That should feel very good.

Let’s feel even better - let’s go take a look at the Player collection under the “COLLECTIONS” tab. You should see your newly created player.

Notice that the credentials that were used to create the user are not shown here. Credentials are a special, encrypted field in FaunaDB that will never be returned.

OK, one more test. Run the query one more time. This should log in your player again, returning a different token, but not create a new record. Do you still see only one record? Nice.

Completing The Permissions Setup

Now that we have the first part of our permissions working, we need to design and implement the second part, which is having the logged in player fetch a list of all user names. Now that we are practiced, this shouldn’t take us too long, but I do need to share one more aspect about Roles that will help us.

As you saw previously, Roles are used by Keys and Functions to give them access to resources, and, more specifically, to specify what actions these Keys and Functions can perform on these resources. Keys and Functions actually have a role field, which ties them to a Role. Tokens, on the other hand, require a different method for associating themselves with Roles; Tokens rely on Role Memberships.

When a role is created, along with the permissions, a list of memberships can be provided. Each membership is associated with a single collection. In the simplest configuration of a membership, any member of this collection, as long as they have a valid login token, is associated with this role, and has the permissions ascribed to it.

With this new found feature of roles, let’s design the final portion of our player permissions:

This diagram looks much like the first diagram except instead of a key, there is a player token combined with a membership for the player collection. These tie into the logged-in role which has permissions to call the all_user_names resolver. As the resolver needs its own permissions, it ties into a role called all_user_names. (Why not use the same name as the function?) This role grants read permissions on the Player collection as well as uses a new index called all_user_names which only has access to the user_name field values of the Player collection.

For those already familiar with GraphQL and FaunaDB, you may have addressed the issue of limiting access to field data on a document in a different way. Once such way would be breaking out restricted data into a separate type and creating an allType:[Type!] query which FaunaDB supports with no UDF required. This is also a valid approach. The value of creating a custom index and UDF, as I have done, is that our custom index only requires 1 read to resolve and is therefore faster and more efficient than using the allType query which internally maps over all documents to generate its result.

We could create all_user_names index through FQL as we did the one before, but let’s create it this time through the Web Console:

Log into your FaunaDB account; you should be brought to your FaunaDB Console Home
Go to the DB Overview for your "swp" database by clicking on the name of the database
Go to the Indexes page by clicking on the “INDEXES” tab to the left
Start a new Index by clicking on the “New Index” link at the top

Look at the image below and make sure your index definition looks the same:

Of course, the collection we will be searching is the Player collection. For the name of the index, we can use the same name as the function that will be using the index. This index does not have any search terms like the unique_Player_user_name does because rather than isolate a specific subset of the collection, we want all the user names in the collection. And finally, because we want to be sure the all_user_names function can only get at the user_namedata, we will list this single field in the “Values” section. Note how the editor puts data before the user_name field name; this is because the actual data that is returned from this search will be inside a data object.

Once you have confirmed your index settings look like those above, save the index.

We now need to create the all_user_names role. We can also use the Web Console to create Roles:

Go to the “SECURITY” tab and take a moment to notice our “Bootstrap Key” we created above.
Click on the “MANAGE ROLES” link and take a moment to notice our “bootstrap” and “register” roles
Start a new Role by clicking on the “NEW ROLE” link

Look at the image below and make sure your role definition looks the same:

Referring back to our permissions diagram should help make sense of this screen. We give our role the same name as the function it services. We then only need read access to the Player collection and the all_user_names index.

When you are sure your settings look the same, save the Role.

We will now return to the FQL shell to update the all_user_names function:

Update(Function("all_user_names"), { name: "all_user_names",
  body: Query(Lambda([],Select("data", Paginate(Match(Index("all_user_names"), []))))),
  role: Role("all_user_names")
})

The all_user_names function uses the built-in Match function to grab all the user names using the all_user_names index. Whenever we request a list of items, we are required to use pagination so we don’t shoot ourselves in the foot. Paginate returns a data structure that lets us page through results in small chunks, 64 documents by default. (In this tutorial, 64 user names at a time will be plenty so we will not take time to explore the full power of pagination.) As mentioned when we set up the index, the data will be returned in a data field, so we use the built-in Select function to extract the array of user names from this field. Of course, we tie this function to the all_user_names roll.

Go ahead and enter the code and execute the query.

We now only have one more resource to create: the logged-in role that our player token will access through its membership in the Player collection:

CreateRole({
  name: "logged-in",
  privileges: [
  {
    resource: Function('all_user_names'),
    actions: {
      call: true
    }
  }
  ],
  membership: [{
    resource: Collection("Player")
  }]
})

What is new here is the membership field. This field takes an array of Membership definitions. Memberships are very flexible, and a lambda function can be provided to qualify further the terms of membership. For our example today, we will use the simplest form of membership by simply defining that membership in the Player collection is all that is needed to be attached to this role (when presenting a valid token, of course).

Food for thought: why is the privileges field name plural, but the membership field name singular when they are both arrays? Perhaps we will never know.

Go ahead and enter the code and execute the query.

The Final Permissions Test

We are now ready to perform the second part of our permissions test – whether a player token has access to all the user names in the Player collection. Can you taste the anticipation? I can.

To perform this test, let’s start from the very beginning and create a new player and get back a new player token. Return to the GraphQL Playground.

Sometimes when I return to the GraphQL Playground, there is a new tab there, but my previous tab(s) are there, too. Just delete any blank tabs that may be there if they are confusing to you.

If your setup from our previous test is gone, go back through the instructions above and make sure you are using our custom key for the bearer token in the headers. Go ahead and create a new player with the createAndOrLoginPlayer mutation, passing in different values from before. Here is an example.

mutation CreateAndOrLoginPlayer {
  createAndOrLoginPlayer(user_name:"cool_user_name", password:"even_cooler_password")
}

You should get back a response similar to this:

{
  "data": {
    "createAndOrLoginPlayer": "qqEDtPCdvjABCDF0k_rewAINr729XiQJBmm-sqvuTAv9hJTWYB0"
  }
}

Be sure to save the return string from this call – it is the player token we will need in the next step.

Now that we have a new player and a new player token, we can now test our allUserNames query. Open a new tab and change the “authorization” header for the new tab to use the new player token in the form of a “Bearer” token as with the custom key.

Now enter the following query in the query editor:

query AllUserNames {
  allUserNames
}

This query is much simpler than the mutation before as it simply calls a parameterless query and waits for the return values.

Now go ahead and execute the query; if all goes well, you should see two user names returned!

{
  "data": {
    "allUserNames": [
      "cool_user_name",
      "example_user_name"
    ]
  }
}

Two user names, just like we expected! (Insert 🎆 fireworks 🎇 here.)

But… not to celebrate too early, shall we run an experiment? In our testing we have tested that the custom key and player token do most certainly have permission to perform their intended behaviors. But what if we were to switch the token for the key? Can the custom key fetch user names? Can a player token be used to create a new player?

Let’s give it a go, shall we?

Return to the GraphQL Playground tab where you executed the allUserNames query and replace the player token in the “authorization” header with the custom key and rerun the query. What do you see? This is what I see:

{
  "errors": [
    {
      "message": "Insufficient privileges to perform the action.",
      "extensions": {
        "code": "permission denied"
      }
    }
  ]
}

So far so good. Now go to the first tab where you ran the createAndOrLoginPlayer mutation, and replace the custom key in the “authorization” header for the player token and rerun the mutation. What do you see? This is what I see:

{
  "errors": [
    {
      "message": "Insufficient privileges to perform the action.",
      "extensions": {
        "code": "permission denied"
      }
    }
  ]
}

We have now verified we have a secure setup for creating and logging in players, and limiting access to user names to only trusted players.

Security is a good feeling, isn’t it?

The solution we have just implemented for identity management is secure but limited. FaunaDB's identity management feature set is capable of providing much more robust identity management for both service-to-service and stateless client architectures. Rather than forcing the developer into an opinionated solution, FaunaDB provides the building blocks for you to either roll your own, as we have done (in part), or to easily tie into 3rd party identity management providers.

In part 2 of our tutorial, we are going to focus on the Shall We Play? Elm application, and, more specifically, the elm-graphql package. Using elm-graphql, we will update the application to use our new GraphQL service which provides secure login and authorized access to player data.

I can hardly wait! See you then.

DEV Community: XetiCode LLC

The 10 Commandments of AI

The 10 Commandments of AI

The AI Commandments of Performance

The AI Commandments of Informance

The General Commandments of AI

Using Fission with Elm - Part 3: Adding authentication and using the Fission Drive

Make sure the npm and elm-module packages for webnative-elm are at 6.1.0 and 7.0.0, respectively. To update them, run the following from the root of the project:

Prelude

Intro

Things to review

Walkthrough

Msg variants

Model

Before we dive in

Authentication

Prep work

Signing in

The UI

Signing out

Data Storage

type Tag

Helper functions

update Function

The Finished Project

The End of a Trilogy

Appendix A

Creating a Fission account

Using Fission with Elm - Part 2: Integrating Fission into the Elm project

Prelude

Intro

Enter IPFS…

Enter Fission…

The Walkthrough

Installing Webnative dependencies

Modifying js/index.js

Modifying src/Main.elm

Ports

Adding Permissions

The init and subscriptions functions

init

Adding a variant to the Msg and updating the update function

Msg

update

The Ending

Before its over: See that it works

Adieu

Using Fission with Elm - Part 1: Using Vite to manage Elm applications

Prelude

Intro

Enter Elm…

Enter Vite…

The Walkthrough

Initialize the Vite project

Set up the Elm Application: Installation

elm-tooling

elm-json

Set up the Elm Application: Modifying to the file structure

Set up the Elm Application: Adding content to the files

index.html

index.js

Main.elm

Set up the Elm Application: Importing Elm modules

The Ending

Before its over: Witness the live reload of Vite

Before its over: Build and Serve the project

Adieu

FaunaDB, GraphQL, and Elm, A Tutorial for JAMstack, Part 2

Introduction

Connecting Shall We Play? to FaunaDB through elm-graphql

Setting Up Shall We Play? for Local Development

A Bit About Elm

A Tour of the Project

Showing The Password Field

Showing The Logged In Main View At The Right Time

Adding A Little Polish

Wiring Up The Password Field

Integrating elm-graphql into our application

Relating GraphQL to elm-graphql

Connecting elm-graph To Our GraphQL Service

Make sure the npm and elm-module packages for `webnative-elm` are at 6.1.0 and 7.0.0, respectively. To update them, run the following from the root of the project:

`Msg` variants

`Model`

The `init` and `subscriptions` functions

`init`

Adding a variant to the `Msg` and updating the `update` function

`Msg`

`update`