Forem: Catherine Mohan

Using Power Automate to Configure Graph API Site.Selected Permission

Catherine Mohan — Mon, 08 Aug 2022 17:10:00 +0000

Microsoft Graph is a powerful tool. It can give you access to user information, SharePoint files, and Office tenant settings. Because of this, admins need to be careful when granting permission to the the many Graph endpoints. The permission options for Graph are usually all-or-nothing. The SharePoint permission options, for example, are either Site.Read.All or Site.ReadWrite.All. When it says “All”, it means all. Granting this permission gives an app or a user access to every SharePoint site in the tenant. This is not ideal from a security perspective and requires admins to closely monitor any use of the SharePoint endpoints.

Fortunately, Microsoft has added a third permission option called Site.Selected. This allows admins to restrict Graph access to specified sites and control read/write access per site. However, you can only configure these settings through the Graph API itself. The lack of a GUI for this setting means you have to send a minimum of three API requests to get all the information needed to setup the permissions. Doing this manually can get annoying after a while so I setup a flow to do it for me.

This flow takes in the name and id of the app, the name of the SharePoint site and whether the app should have write access to the site.

It follows my standard format of initializing the variables first followed by scope blocks in a Try-Catch-Finally configuration. The four variables that this flow uses are the following:

IsError: Used for error catching
SiteId : The Id for the site specified in the trigger. This will be gathered as part of the flow.
Roles: This JSON array tells Graph what kind of permissions the app should be given. I’ve set the default value to just be “Read”.
AccessToken: This is the access token needed for the Graph API requests. Since Graph uses Bearer tokens, I’ve already set that portion of the token and the rest will be acquired by a call to the authorization endpoint.

The first thing this flow does is check if the app needs Write access and updates the Roles variable if needed.

It then gets and saves the access token to use to get the SharePoint site's Id.

Once all that information is saved, it builds the request body and sends the POST request to the SharePoint site to configure the permissions.

If any of the blocks encounter an error, the flow goes to the Catch scope, updates the IsError variable to true. At the very end of the flow, it checks to see if an error was caught. If it was, it forces the flow to Terminate with a Failed status. If not, the flow completes successfully and now your app should be able to access only the SharePoint site you specified.

The Site.Selected Graph permission opens up new opportunities for your employees to create applications that use Graph to interact with SharePoint sites without compromising the security of your entire tenant. This permission was critical to my work of encouraging employees to build their own automation solutions.

Introducing the Journal Prompt Randomizer

Catherine Mohan — Thu, 24 Mar 2022 14:03:21 +0000

I like journaling.

Journaling helps me process my thoughts and feelings by getting them out of my head and onto a page. Getting them out of my head means that I am less likely to obsess about them and spiral down a rabbit hole. It’s easy to journal when I have lots of thoughts and feelings, on the busy days where big things are happening. But on the quiet days, when I don’t have any big thoughts, I stare at the blank page. A blank page that contains infinite options. And I have to pick one.

Ah, the paradox of choice: Having options is good, but having too many options can be paralyzing.

I look up writing prompts in an attempt to kickstart my brain out of paralysis, but I encounter more choices! Lists and lists of prompts for memories, business planning, self-reflection, or empowerment. I just have to pick one.

You see the issue?

I found plenty of physical notebooks that had prompts pre-printed on the pages, but only a few digital generators, most of which had very cluttered UIs that made them confusing to use. So I gathered prompts from a number of journal prompt lists and built this minimalist site:

It just gives you a prompt. Only one. However, it also has a button that will give you a different one if you want. But that's it. One prompt and one button. No more paradox of choice.

I’ve been using a hacked together version of this idea for a while now. It has really helped me stay consistent in my journaling. If I can stay consistent during the quiet times, then I am more likely to remember to be consistent during the busy times when I need to journal the most. I’ve been going through some rough things these past few months and now I’m coming out the other side. I decided to make a proper site for this in the hopes that it can help others get though those busy times as well, the good ones and the bad ones.

If you like it, please consider donating towards the cost of the domain & hosting.

Tech Specs

This site is a Blazor WebAssembly PWA written in C# for .NET Core 6. It is hosted in a Azure Static Web App instance. This setup has served me well for the small sites I specialize in and is very reasonably priced. Highly recommend 👍

Get all items from a Large SharePoint List using a Custom Power Automate Http Endpoint

Catherine Mohan — Mon, 16 Aug 2021 17:00:12 +0000

Microsoft Graph is the backbone of Power Automate these days, but sometimes the connectors do not show us the full scope of the API. When that happens, you don't necessarily need to abandon Power Automate, just use the HTTPS connector instead! You'll have full access to the Graph API while keeping the benefits of the low-code and Microsoft-connected environment.

One of my biggest pet peeves is that the SharePoint List connectors have built in limiters and will not return large responses. I understand that Power Automate does this because currently it is not built to handle them, however business requirements and budget limits require some ingenuity. There have been a handful of times recently, when I've had to create and interact with large SharePoint lists. The standard SharePoint List connector has a limit of 200 items and my lists were 500 - 1,000 items, sometimes more. I had to come up with a way to get all the items using PowerAutomate.

Trigger

This flow that I designed uses a HTTP Request trigger, but you can use whatever trigger you want. I chose that trigger so I can access this flow from other Power Automate flows as well as other external programs. I used a sample payload to generate the schema for this endpoint. It takes in a Site ID of the SharePoint site containing the list and the ID of the list itself. This information can be obtained from the relevant Graph API endpoints and won't change during the lifetime of the site or list.

Getting Graph OAuth Token

Although you are in the Power Automate environment, you'll still need to get an authentication token if you want to send calls via the HTTPS connector. I prefer to do this right at the beginning of your flow at the same time I'm setting up all my variables. It starts with an HTTPS block that will make the call for the authentication token.

The information in the block is all straight out of the Microsoft Graph documentation for this endpoint.



URL: https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token

Headers:
    Host: login.microsoftonline.com
    Content-Type: application/x-www-form-urlencoded

Body:
    client_id=<client_it>
    &scope=https://graph.microsoft.com/.default
    &client_secret=<client_secret>
    &grant_type=client_credentials

Originally, I placed a Parse Json block after this call to get the token. Once parsed, the token would appear as an option in the Dynamic menu. After working with Power Automate more, I've become more familiar with how to access information that exists, but doesn't appear in that menu. Now I can simply have an Initialize Variable block to save the token.

Here's the code that gets the token from the response:



body('Get_Auth_Token')?['access_token']

I include the keyword "Bearer" in the variable so I don't have to remember to add it to each call. Also, makes the blocks look a bit cleaner with only a variable name in the field.

Initializing Loop Variables

When you send a request to a Graph API endpoint and the results are larger than it can include in its response, it will include a URL called the "nextLink" that has a skip token embedded. If you send a request using that URL, the endpoint will see the token, skip the results you have already received, and send a new batch. Depending on how many total results there are, you may have to repeat this process numerous times to get everything. In Power Automate, sending the request is the easiest part. Figuring out how to save the results all to the same variable is a bit trickier. This is probably my 3rd or 4th version of the loop, slimmed down to almost the fewest blocks possible.

First, you'll need the Array variable that will hold the results of all your requests. Second, you need a String variable that will hold the request URLs and also control the loop. The initialization value is the first request URL you'll send.

We don't know how many times the loop will need to run, but we do know that the last response will not include a nexLink URL. Power Automate and Strings can be a bit strange so I tested out some different options for the right hand side of the loop control equation. Surprisingly, leaving it completely blank is the easiest and most reliable solution.

Now for the Loop!

The first step in the loop is the HTTPS block that sends the request to the Graph API. Since this example is only used GET requests, the setup is fairly straightforward. Remember to click "Advanced Options" so you can enter the Authentication information!



Method: GET
URL: <url variable>
Authentication: Raw
Value: <authToken variable>

Next, we use a Parse Json block to read the response. This step is not strictly needed as you can still access the response information the same way I did with the OAuth token, but it makes configuring the next blocks easier. Make sure you choose the Body of the previous block, not the Value, because we want to parse the entire response. Responses from the Graph API wrap the results within a Value property to separate them from other metadata in the response, like the nextLink URL, like this:



{
  "@odata.nextLink": "https://...",
  "value":
    [
    {"name": "myfile.jpg", "size": 2048, "file": {} },
    {"name": "Documents", "folder": { "childCount": 4} },
    {"name": "Photos", "folder": { "childCount": 203} },
    {"name": "my sheet(1).xlsx", "size": 197 }
  ]
}

(Usually, you will only need the results of the call so you would use Value instead of the Body. This is one of the few exceptions since we need that Next Link value.)

When first building a flow, I use the Generate from Sample button to create a starting schema, and then modify it to fit my needs, especially when I have large responses with many properties. This is what the Parse JSON schema looks like after I've edited it and removed the fields I don't need.



{
    "type": "object",
    "properties": {
        "@@odata.nextLink": {
            "type": "string"
        },
        "value": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "fields": {
                        "type": "object"
                    }
                },
                "required": [
                    "fields"
                ]
            }
        }
    }
}

For this flow specifically, I removed most of the schema, leaving only the fields and the @@odata.nextLink properties. Those are the only items I'll be using in my flow so there's not much reason to parse the other data. Since this is a generic flow to be used with any list, we also don't want to specify the names of the sub-properties within the fields property. The @@odata.nextLink property is not required so the automation doesn't throw an error when it reaches the end of the list and there is no Next Link to follow.

This is what the unedited generated schema would look like:



{
    "type": "object",
    "properties": {
        "@@odata.context": {
            "type": "string"
        },
        "@@odata.nextLink": {
            "type": "string"
        },
        "value": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "@@odata.etag": {
                        "type": "string"
                    },
                    "createdDateTime": {
                        "type": "string"
                    },
                    "eTag": {
                        "type": "string"
                    },
                    "id": {
                        "type": "string"
                    },
                    "lastModifiedDateTime": {
                        "type": "string"
                    },
                    "webUrl": {
                        "type": "string"
                    },
                    "createdBy": {
                        "type": "object",
                        "properties": {
                            "user": {
                                "type": "object",
                                "properties": {
                                    "email": {
                                        "type": "string"
                                    },
                                    "id": {
                                        "type": "string"
                                    },
                                    "displayName": {
                                        "type": "string"
                                    }
                                }
                            }
                        }
                    },
                    "lastModifiedBy": {
                        "type": "object",
                        "properties": {
                            "user": {
                                "type": "object",
                                "properties": {
                                    "email": {
                                        "type": "string"
                                    },
                                    "id": {
                                        "type": "string"
                                    },
                                    "displayName": {
                                        "type": "string"
                                    }
                                }
                            }
                        }
                    },
                    "parentReference": {
                        "type": "object",
                        "properties": {
                            "siteId": {
                                "type": "string"
                            }
                        }
                    },
                    "contentType": {
                        "type": "object",
                        "properties": {
                            "id": {
                                "type": "string"
                            },
                            "name": {
                                "type": "string"
                            }
                        }
                    },
                    "fields@odata.context": {
                        "type": "string"
                    },
                    "fields": {
                        "type": "object",
                        "properties": {
                            "@@odata.etag": {
                                "type": "string"
                            },
                            "Title": {
                                "type": "string"
                            },
                            "LinkTitleNoMenu": {
                                "type": "string"
                            },
                            "LinkTitle": {
                                "type": "string"
                            },
                            "id": {
                                "type": "string"
                            },
                            "ContentType": {
                                "type": "string"
                            },
                            "Modified": {
                                "type": "string"
                            },
                            "Created": {
                                "type": "string"
                            },
                            "AuthorLookupId": {
                                "type": "string"
                            },
                            "EditorLookupId": {
                                "type": "string"
                            },
                            "_UIVersionString": {
                                "type": "string"
                            },
                            "Attachments": {
                                "type": "boolean"
                            },
                            "Edit": {
                                "type": "string"
                            },
                            "ItemChildCount": {
                                "type": "string"
                            },
                            "FolderChildCount": {
                                "type": "string"
                            },
                            "_ComplianceFlags": {
                                "type": "string"
                            },
                            "_ComplianceTag": {
                                "type": "string"
                            },
                            "_ComplianceTagWrittenTime": {
                                "type": "string"
                            },
                            "_ComplianceTagUserId": {
                                "type": "string"
                            }
                        }
                    }
                },
                "required": [
                    "@@odata.etag",
                    "createdDateTime",
                    "eTag",
                    "id",
                    "lastModifiedDateTime",
                    "webUrl",
                    "createdBy",
                    "lastModifiedBy",
                    "parentReference",
                    "contentType",
                    "fields@odata.context",
                    "fields"
                ]
            }
        }
    }
}

Saving the Results

After that, the loop is almost completed, with only three short actions to complete.

The first one is a Compose block with the following expression in it:



union(variables('listItems'), body('Parse_response')?['value'])

This expressions combines the two lists and outputs them as a new combined array, which we then save to the listItems variable with a Set Variable block.

Last but not least, we extract the Next Link URL, if one came with the response, and save it to the url variable that is controlling the loop. If no Next Link came with the response, url just becomes null and will therefore end the loop.

Once the loop has completed, the full list of items is returned as a response to the original request that triggered this flow.

Limitation

This automation works very well for short lists with less than 1k - 2k items total. It is able to compile the list within the standard timeout limit for most API calls. Once you get above 2k items or so, this flow will still return all the items, but it will take longer and could exceed the timeout limit. You can change that limit manually in some cases, but there is another way to accommodate larger lists that I will post and article on in the future.

Conclusion

Power Automate is a great tool for all sorts of automations, but sometimes we need to get a bit creative when business requirements exceed the built-in limits of this tool. When I approach a new automation project, I usually start with PowerAutomate and then move up to more flexible tools if needed.

Here is the whole flow from start to finish. I hope you this demo will help you with your automation projects and inspire you to discover more interesting ways Power Automate can be used.

Use Power Automate to copy a Template Folder

Catherine Mohan — Fri, 08 Jan 2021 17:09:06 +0000

When I start a project, there are usually three files that I know I'm going to need. Originally, I had template files that I would copy manually from a default folder into a new folder specifically for the project. Not a complicated process, but I only have three files. Some teams can have many files they need to copy for each new client or project! If you store your project files in SharePoint, you can take advantage of this Power Automate Instant Flow to automate your project kick-off.

The first step in creating this automation is to create a template folder in SharePoint containing all the default files you need to kick-off your project. You can store it in the same place as you want to store the project files or you can store it somewhere else. Here's mine as an example:

Once you have this folder setup, you can begin creating the Power Automate Instant Flow. The trigger is the "For a selected file" SharePoint block. This will add this flow to the SharePoint document library menu so you can trigger it from the SharePoint site itself. In the trigger block, you can also add a field so you can enter the name of the client or the project to be added the new folder.

Once the trigger is setup, you can begin adding the following blocks to build the automation flow:

Create new folder - This block creates a new folder using the client/project name in the document library for project files.
List folder - This block lists all the files and sub-folders in a folder. It doesn't go into the sub-folders though. If you have sub-folders, you'll need to repeat this block for each of those to get all the files.
Copy File - For each file in the folder create a new copy of the file in the new client/project folder. You can choose to keep the same name as the original file or you can give it a new name that includes the client or project name.

Here's what the automation looks like in the Flow Designer:

This is a small automation that you can get up and running quickly. It's also a great way to get started with Power Automate and see what other automation options it has for you.

Customizing your Powershell Profile

Catherine Mohan — Thu, 03 Dec 2020 17:43:23 +0000

The Powershell console has a settings script that you can use to customize your experience. You can use it to load the same modules everytime you run the console, create custom commands, or customize the console itself.

If you've never worked with the different Powershell profiles, this article explains the six different types and when each profile is used. Personally, I only use the CurrentUserAllHosts profile. I haven't found a use case where I would need the other types yet.

View the template profile here

Profile Sections

I split my profile into different sections to keep it organized:

Modules
Accelerators
Custom Functions
Custom Console Settings

Modules

# region Modules - must be first

using module CatMods
using module ImportExcel

#endregion

This Modules has to be the first as the modules won't load if other commands are run before the using statements. This section can be used to automatically load in locally installed modules including custom modules you've written.

Accelerators

#region Accelerators

$type = [PowerShell].Assembly.GetType('System.Management.Automation.TypeAccelerators')
$type::Add('ArrayList', [System.Collections.ArrayList])
$type::Add('DateTimeConverter', [Management.ManagementDateTimeConverter])

#endregion

Powershell becomes even more versatile and powerful when you start incorporating .NET data types. The downside is, that to use those data types, you have to specify the exact location of the data type and those can get a bit convoluted. Accelerators allow you to create a shortcut keyword that you can use instead. I frequently use the ArrayList data type instead of the native Powershell arrays and ArrayList is easier to remember than System.Collections.ArrayList.

Custom Functions

# region Custom Functions

function Start-PSAdmin ()
{
    Start-Process pwsh.exe -Credential "AD\cmohan.admin"
}

function Start-PSElevate ()
{
    Start-Process pwsh.exe -Verb RunAs
}

function Open-GitBash ()
{
    wt -p "Git Bash" -d $(pwd)
}

#endregion

If you run the same commands frequently, it could be in your interest to save them in a custom function. I only have a few one-liners in my profile as I created a custom module to hold the more complicated fucntions that I need.

Here are the three I use the most often:

The Start-PSAdmin function starts a new Powershell console with a different account. I have it set to run using my work admin account so I can easily switch to work with something my normal work account can't access.
The Start-PSElevate function starts a new elevated Powershell console. This is the same as starting Powershell with the "Run As Administrator" option from the right click menu. Frequently there are Powershell commands that require administrator-level access and this function lets me create a new console quickly.
The Open-GitBash is a new function I created only a few months ago. It opens a new Windows Terminal console set to the Git Bash profile I configured and opens it to the same working directory as the Powershell console was using. Recently, I was working on a Powershell application that was stored on a server and getting to that folder in the Git Bash console was a bit of a slog. Every tab complete took 10 to 15 seconds to load. Since I usually already had a Powershell console open to that working directory, this function let me access the Git Bash significantly faster.

Custom Console Settings

# region Custom Console Settings

$env:PSModulePath += ";C:\Users\catherine.mohan\Documents\Git\WindowsPowershell\Modules"


# Check for Elevated Prompt

$wid = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$prp = new-object System.Security.Principal.WindowsPrincipal($wid)
$admin = [System.Security.Principal.WindowsBuiltInRole]::Administrator
$IsAdmin = $prp.IsInRole($admin)

if ($isAdmin)
{
    $Host.UI.RawUI.WindowTitle = "$($env:USERNAME) - Elevated - Powershell $($PSVersionTable.PSVersion.ToString())"
}
else
{
    $Host.UI.RawUI.WindowTitle = "$($env:USERNAME) - Standard - Powershell $($PSVersionTable.PSVersion.ToString())"
}

#endregion

The last section in my Powershell profile is the custom console settings. In this section you can modify environment variables, change the look of your console window, or initialize custom variables. Before I reorganized my code files, I had my custom modules stored in a different folder than the standard Powershell module folder. In order to access it, I had to modify my PSModulePath variable to add that folder to the list.

The only console customization I have in my profile is a function to set the title of the console window. It shows what account the console is running under, whether the console is elevated to administrator permissions, and which version of Powershell the console window is. At one point I had three different versions of Powershell installed and not all of the scripts I was running worked in all versions. Listing the version of Powershell in the console title was an easy way to differentiate between console windows.

I don't have an example here, but in a past job I had a credential securely stored in an encrypted file that my profile script decrypted into a Credential variable that I could use easier in the Powershell console. This way I didn't have to type in the very complicated password multiple times in a row. You could also use it to save some constant values that you use frequently.

Conclusion

Powershell profiles are an easy way to up your productivity in the console. Using a scripting format you're already familiar with, you can create shortcuts and customizations for your most common commands and functions.

Build a Basic Gatsby Blog with Markdown Posts

Catherine Mohan — Tue, 15 Sep 2020 16:05:00 +0000

If you aren't familiar with it (I hadn't heard of it before 2020), Gatsby is a static site generator that allows for the use of React components, plugins, and an internal GraphQL API to create sites that are interactive, run fast, and are quick to build.

NOTE: This tutorial requires NodeJS and npm. I'm using Powershell 7 as my command prompt but use whatever you feel comfortable with.

Getting Started

If you haven't worked with Gatsby before, you'll need to install the Gatsby CLI first.

npm install -g gatsby-cli

I've found that the fastest way to get going is to use one of the project templates that Gatsby offers. You can find them all or submit your own at gatsby.dev/starters. However, the default Gatsby template that is used when you don't specify a particular template is actually quite complete and that can be a bit overwhelming if you haven't used Gatsby before. I'll be using their Hello World template for this tutorial since it creates less files and folders than the default template.

To make a new Gatsby site, navigate to the directory you want to store you project in and run the new command:

gatsby new gatsby-md-blog https://github.com/gatsbyjs/gatsby-starter-hello-world

The command goes gatsby new <projectName> <projectTemplateURL>. If you omit the template URL, it'll use the default Gatsby template.

It may take a bit to run so be patient. Once it's done you'll have a project folder containing a basic scaffolding of folders and files. Now would be a good time to run a git init to start the repository for this project, if you want to do that.

Open src/pages/index.js and you'll see the code for basic page with a "Hello World" header. To view the page, run gastby develop from the root folder of the project to start up the development server.

Once it's loaded, you'll see the localhost URL the development server is using. By default it's http://localhost:8000/ but you can run the develop command with the -p flag to specify a particular port.

You'll also see another URL that ends with "graphql". This URL is a GraphQL API explorer where you can see all the accessible data in your site. We'll use this more later.

The development server auto-refreshes whenever you save changes to any of the pages so you don't need to stop and start it that often. For now, stop the development server with CTRL + C.

Creating Posts

With our basic site created, we're going to setup the folder for our posts and create some sample posts. From the root folder of the project, create three post folders and the Markdown document for each post. Here is the Powershell code I used to do that.

@("2020-09-01-first-post", "2020-09-05-second-post", "2020-09-10-third-post") | ForEach-Object {
    mkdir src/posts/2020/$_
}

cd src/posts/2020

Get-ChildItem -Directory | ForEach-Object {
    cd $_.FullName
    New-Item index.mdx
}

Here's what the resulting file structure should look like:

Open each index.mdx and put the following Markdown in the corresponding file:

First Post

---
title: "First Post!"
date: 2020-09-01
published: true
---

# h1 Heading

First MDX Post for Gatsby Blog! Hello World!

## h2 Heading

### h3 Heading

Second Post

---
title: Second Post!
date: 2020-09-05
published: true
---

This is my second post!

#### h4 Heading

##### h5 Heading

###### h6 Heading

Third Post

---
title: Third Post!
date: 2020-09-10
published: true
---

This is my third post!

> How my achievements mock me! -William Shakespeare

At the top of each post, between the dashes, is metatdata called frontmatter that we can access with the GraphQL API. Right now we just have the title, date, and a published value, but you can put other data in there that you need.

Installing & Configuring Plugins

Now that we have posts, we need a way to display them!

We will be using two plugins to pull these posts and display them.

The gatsby-source-filesystem plugin pulls the filesystem into the GraphQL API so you can access that information with calls to that API
The gatsby-plugin-mdx plugin will allow Gatsby to read the MDX posts we just created and display them as pages.

To install the plugins and their dependencies, run the following command from the root folder of the project:

npm install gatsby-plugin-mdx @mdx-js/mdx @mdx-js/react gatsby-source-filesystem

Once the plugins are installed, we need to modify our gatsby-config.js file to configure them. Open the file and replace the module.exports section with the following code. This will tell Gatsby which file extensions the posts will be in and where they are in the file structure.

module.exports = {
    siteMetadata: {
        title: `The Localhost Blog`,
        description: `This is my coding blog where I write about my coding journey.`,
    },
    plugins: [
        {
            resolve: `gatsby-plugin-mdx`,
            options: {
                extensions: [`.mdx`, `.md`],
            },
        },
        {
            resolve: `gatsby-source-filesystem`,
            options: {
                name: `posts`,
                path: `${__dirname}/src/posts`,
            },
        },
    ],
}

Internal GraphQL API

The plugins we installed added information to the API that we can now pull with queries to the API. Remember that http://localhost:8000/___graphql URL we saw when we started up the development server? The development server provides an explorer tool to view the available information in the API and build queries.

Start up the development server with gatsby develop and go to that URL. You'll see a GraphQL API explorer for all the data available in your site.

Enter the following query in the editor to see all of the posts we created and the metadata we included in them.

{
    allMdx {
        nodes {
            frontmatter {
                title
                date
            }
        }
    }
}

There are other places you can put metadata. For metadata you want to use throughout your site, you can put that in the gatsby-config.js file. We included some when we updated that file earlier.

module.exports = {
    siteMetadata: {
        title: `Gatsby Markdown Blog`,
        description: `Learn how to make a blog with Gatsby and Markdown posts.`,
    },
        ...
}

You can see that data in the GraphQL explorer too with this query

{
    site {
        siteMetadata {
            title
            description
        }
    }
}

Now that we have that info in the site, how do we use it in our pages? There are a few ways to use this data in Gatsby pages.

The first way we'll cover is to have a query within the page code that pulls the data. This is for mostly one-off queries that are only used on that one page.

The second way we'll cover is to have use a React Hook called useStaticQuery to pull the data into a file that can then be used multiple times throughout the site.

There is a third way that uses the StaticQuery tag to pull data into reusable page components. We won't be covering that method in this tutorial, but you can read more in the Gatsby documentation about it here: https://www.gatsbyjs.com/docs/static-query/.

Query In Page

Lets look at the first method, queries within the page file. Open src/pages/index.js and replace all the code with this and save the file.

import * as React from 'react'
import { graphql } from 'gatsby'

export const query = graphql
`
    query HomePageQuery {
        site {
            siteMetadata {
                title
                description
            }
        }
    }
`

const HomePage = ({ data }) => {
    return (
        <div>
            <h1>{data.site.siteMetadata.title}</h1>
            <p>{data.site.siteMetadata.description}</p>
        </div>
    )
}

export default HomePage

In the import statements, we've added import { graphql } from 'gatsby' so we can access the GraphQL API within this code.

The next block is the GraphQL query that pulls the title and description metadata stored in gatsby-config.js.

After that we start defining the page. We now have {data} as a parameter of the HomePage to store the data pulled by the query. We can put that data in page by enclosing the variable in curly braces.

Now when we look at http://localhost:8000, we'll see this:

useStaticQuery Hook

Onto the second method, the useStaticQuery hook that can be reused throughout the site. We'll start by making two new files, src/pages/about.js & src/hooks/use-site-metadata.js.

Open use-site-metadata.js and paste in the following code:

import { graphql, useStaticQuery } from "gatsby"

export const useSiteMetadata = () => {
    const { site } = useStaticQuery( graphql
        `
            query SiteMetaData {
                site {
                    siteMetadata {
                        title
                        description
                    }
                }
            }
        `
    )

    return site.siteMetadata
}

This will be the hook that calls GraphQL and pulls the data we want. It looks similar to the block of code in our HomePage that called the API, but it wraps it up to be exported instead of automatically going to the page code block.

With the hook completed, we can use that data in our About page. Open the about.js we made previously and paste in the following code:

import React from "react"
import { useSiteMetadata } from "../hooks/use-site-metadata"

const About = () => {
    const { title, description } = useSiteMetadata()
    return (
        <div>
            <h1>Welcome to {title}</h1>
            <p>About: {description}</p>
        </div>
    )
}

export default About

http://localhost:8000/about now shows the site metadata we added.

Per the Gatsby documentation on this method, you can only use one useStaticQuery hook per page currently due to how Gatsby handles the queries, but each hook can be used multiple times throughout the site.

Displaying Posts List

Using these methods to get data from our site and pages, we can programatically pull all the posts and display links to them in a list on our homepage.

Open src/pages/index.js and update the code to this:

import * as React from 'react'
import { graphql } from 'gatsby'

export const query = graphql
`
    query SITE_INDEX_QUERY {
        site {
            siteMetadata {
                title
                description
            }
        }
        allMdx(
            sort: { fields: [frontmatter___date], order: DESC }
            filter: { frontmatter: { published: { eq: true } } }
        ) {
            nodes {
                id
                excerpt(pruneLength: 250)
                frontmatter {
                    title
                    date
                }
            }
        }
    }
`

const HomePage = ({ data }) => {
    return (
        <div>
            <div>
                <h1>{data.site.siteMetadata.title}</h1>
                <p>{data.site.siteMetadata.description}</p>
            </div>

            <div>
                {data.allMdx.nodes.map(({ excerpt, frontmatter }) => (
                    <>
                        <h1>{frontmatter.title}</h1>
                        <p>{frontmatter.date}</p>
                        <p>{excerpt}</p>
                    </>
                ))}
            </div>
        </div>
    )
}

export default HomePage

What have we changed?

We updated the query to also pull all of the Markdown posts we have, sort them based on the date metadata in each post, and filter out the posts that aren't "published" yet. If we don't sort them, they'll come back in no particular order. Besides the post metadata, we're also pulling the ID for each post and an excerpt that is limited to the first 250 characters.

We also updated the page's html code to display the list of posts. If you aren't familiar with the map function, it's a type of for-each loop that will execute the defined function for each node or post in our site. Each post will get a listing with the title of the post, the date, and a plain text excerpt of the post.

https://localhost:8000 should look like this now.

Creating Links to Posts

Gatsby has a handy tool called Node API that can help make the URLs for the post pages if we don't want to specify them in the metadata of the posts. These URLs are called slugs and once they're created, we can pull them with an API query to create links on the homepage. This tool will be run through a file called gatsby-node.js. It's not included in the Hello World template so you'll need to create it in the root folder of the project, like our gatsby-config.js file

Open the file and past in the following code:

const { createFilePath } = require(`gatsby-source-filesystem`);

exports.onCreateNode = ({ node, actions, getNode }) => {
    const { createNodeField } = actions

    if (node.internal.type === `Mdx`) {
        const value = createFilePath({ node, getNode })

        createNodeField({
            name: `slug`,
            node,
            value: `/posts${value}`,
        })
    }
}

The .onCreateNode() function is called for each file or node in our Gatsby site. We have an If statement in the function to only act on the MDX files in our site. It uses the createFilePath() function from the gatsby-souce-filesystem plugin to create the URL and then we save it with the node.

Back on our homepage, src/pages/index.js, we can now update our GraphQL query to get that slug. It's located in the nodes section under fields.slug.

export const query = graphql
`
    query SITE_INDEX_QUERY {
        site {
            siteMetadata {
               title
               description
            }
        }
        allMdx(
            sort: {fields: [frontmatter___date], order: DESC},
            filter: {frontmatter: {published: {eq: true}}}
        ){
            nodes {
                id
                excerpt(pruneLength: 250)
                frontmatter {
                    title
                    date
                }
                fields {
                    slug
                }
            }
        }
    }
`

You can see the slugs in if you put that query in the GraphQL explorer

To make links out of these slugs, we'll need to first update one of the import statements in src/pages/index.js.

// Old Gatsby import statement
import { graphql } from 'gatsby'

//New Gatsby import statement
import { graphql, Link } from 'gatsby'

This allows us to use the <Link> object in our page HTML like this:

const HomePage = ({ data }) => {
    return (
        <div>
            <div>
                <h1>{data.site.siteMetadata.title}</h1>
                <p>{data.site.siteMetadata.description}</p>
            </div>

            <div>
                {data.allMdx.nodes.map(({ excerpt, frontmatter, fields }) => (
                    <Link to={fields.slug}>
                        <h1>{frontmatter.title}</h1>
                        <p>{frontmatter.date}</p>
                        <p>{excerpt}</p>
                    </Link>
                ))}
            </div>
        </div>
    )
}

This will make the whole section a link:

If you only wrap the title of the post in the Link then just the title will be linked:

const HomePage = ({ data }) => {
    return (
        <div>
            <div>
                <h1>{data.site.siteMetadata.title}</h1>
                <p>{data.site.siteMetadata.description}</p>
            </div>

            <div>
                {data.allMdx.nodes.map(({ excerpt, frontmatter, fields }) => (
                    <div>
                        <Link to={fields.slug}>
                            <h1>{frontmatter.title}</h1>
                        </Link>
                        <p>{frontmatter.date}</p>
                        <p>{excerpt}</p>
                    </div>
                ))}
            </div>
        </div>
    )
}

Creating Post Pages

Great, you say, we have links but they don't actually go anywhere other than a 404 error page. How do I make those pages out of the Markdown files? Again, the Node API can help us by making pages to go with those URLs using the .createPages() function.

Open your gatsby-node.js file and add this to the bottom, after the .onCreateNode() function.

const path = require("path")

exports.createPages = async ({ graphql, actions, reporter }) => {
    const { createPage } = actions

    const result = await graphql
    (`
        query {
            allMdx {
                edges {
                    node {
                        id
                        fields {
                            slug
                        }
                    }
                }
            }
        }
    `)

    if (result.errors) {
        reporter.panicOnBuild('🚨  ERROR: Loading "createPages" query')
    }

    // Create blog post pages.
    const posts = result.data.allMdx.edges

    posts.forEach(({ node }, index) => {
        createPage({
            path: node.fields.slug,
            component: path.resolve(`./src/components/post-page-template.js`),
            context: { id: node.id },
        })
    })
}

This query finds all of our Markdown posts and gets the slug URLs we created for them. Next, for each post found, we create a page at that URL using a template page, which we will make next. The context value lets us pass information to that new page that can be used on that page. In this case, we are passing the ID of the node. This will allow us take a template and populate it with the information from a specific post.

You can also pass through the slug and use that to pull posts from the API instead by setting the context to this:

context: { slug: post.fields.slug, },

The last step to making these posts real pages is the template that will be filled with the post information. Create src/components/post-page-template.js, or whatever you set in the For-Each loop of the page creation function, and open it. Paste in this code:

import { graphql } from 'gatsby'
import { MDXRenderer } from 'gatsby-plugin-mdx'
import React from 'react'

export const query = graphql
    `
    query PostsByID($id: String!) {
        mdx(
            id: { eq: $id }
        ){
            body
            frontmatter {
                title
                date(formatString: "YYYY MMMM Do")
            }
        }
    }
`

export default ({ data }) => {
    const { frontmatter, body } = data.mdx
    return (
        <div>
            <h1>{frontmatter.title}</h1>
            <p>{frontmatter.date}</p>
            <MDXRenderer>{body}</MDXRenderer>
        </div>
    )
}

This query has something new in it: A Variable! The id we passed in the page creation can be used by the query to find a specific post as the variable $id. Our query pulls all the posts, finds one with the matching ID, and only pulls the information from that one. The new item we're pulling is body which is the contents of the post file.

Down in the HTML code for the page, we see the title and date information and then the body is wrapped in an <MXRenderer> tag. This tag will interpret the Markdown text in the body and convert it to HTML so it can be displayed on the page.

If you passed through the slug rather than the ID, modify your query to this instead:

export const query = graphql
    `
    query PostsByID($id: String!) {
        mdx(
            fields: { slug: { eq: $slug } }
        ){
            body
            frontmatter {
                title
                date(formatString: "YYYY MMMM Do")
            }
        }
    }
`

Save this file and then restart the development server. You should now be able to click the post titles and see your posts at the proper URLs!

Congratulations! You made a blog using Gatsby and Markdown posts!

Next Steps

Styling

Your blog works, but it's pretty plain-looking. Fortunately, that is fixable. Gatsby allows for CSS to be used in a page's file or in a separate file that is imported. You can find more information about that here: https://www.gatsbyjs.com/docs/styling/

Another styling tool to look into is components. Similar to what we did with the template page for our posts, you can setup reusable blocks that can be imported into pages across your site, such as a header or a footer. Here is Gatsby's documentation on layout components: https://www.gatsbyjs.com/docs/layout-components/

Hosting

Once your blog is spiffed up a bit, you might want to show it off. Gatsby has documentation on deploying your site to many different hosting options such as AWS, Azure, Heroku, and GitHub pages. You can find those articles here: https://www.gatsbyjs.com/docs/deploying-and-hosting/

Gatsby also offers their own hosting option called Gatsby Cloud, specifically for Gatsby sites. They offer integrations with other services for automatic deployment of your site, as well as specialized servers that are built specifically Gatsby sites and provide quicker builds. Here is the documentation on Gatsby Cloud: https://www.gatsbyjs.com/docs/deploying-to-gatsby-cloud/.

Add Features

Some ideas are adding Prev/Next navigation to the posts, displaying code blocks with synax highlighting, giving your posts cover photos, or creating an SEO component to attach to all your pages.

Forem: Catherine Mohan

Using Power Automate to Configure Graph API Site.Selected Permission

Introducing the Journal Prompt Randomizer

Tech Specs

Get all items from a Large SharePoint List using a Custom Power Automate Http Endpoint

Trigger

Getting Graph OAuth Token

Initializing Loop Variables

Now for the Loop!

Saving the Results

Limitation

Conclusion

Use Power Automate to copy a Template Folder

Customizing your Powershell Profile

Profile Sections

Modules

Accelerators

Custom Functions

Custom Console Settings

Conclusion

Build a Basic Gatsby Blog with Markdown Posts

Getting Started

Creating Posts

First Post

Second Post

Third Post

Installing & Configuring Plugins

Internal GraphQL API

Query In Page

useStaticQuery Hook

Displaying Posts List

Creating Links to Posts

Creating Post Pages

Congratulations! You made a blog using Gatsby and Markdown posts!

Next Steps

Styling

Hosting

Add Features

This article and the code files for it can be found in this Github repo.