DEV Community: Ryan Overton

Set up a Neon PR branch for a React Native Expo application using GitHub actions

Ryan Overton — Mon, 18 Nov 2024 17:11:49 +0000

It is essential to test any changes before merging them into a main or feature branch to catch bugs before they make it to production and ensure existing functionality continues to work as expected. Testing against a copy of production data is recommended to better find data-related issues.

Previously, this process was problematic and time-consuming, often involving multiple teams. Luckily, Neon has a built-in branching mechanism, which allows you to create a copy of your data quickly.

In this tutorial, you will learn how to create a preview build for each pull request for a React Native Expo application. You will also learn how to set up a corresponding Neon database branch to be used with the preview build—and all this will be done within a single GitHub Action. Then, once the pull request is closed, you’ll learn how to clean up your resources with another GitHub Action.

Prerequisites

Before we begin, you will need to have a few things already set up.

An Expo account for deploying and testing preview branches
A Neon account with a database project for branching
A GitHub repository containing your Expo application

Setting up GitHub

The first thing we need to do is add the following secrets and variables to our GitHub repository. These secrets and variables will be used throughout our GitHub Actions.

On your GitHub repository page, navigate to Settings → Secrets and variables → Actions and add the following secrets and variables.

Neon API Key: Obtain a Neon API key from the API Keys by clicking on your avatar in the upper right corner of the Neon dashboard, then Account Settings → API Keys. Once you have created your API key, add it to your GitHub projects Repository Secrets with the name NEON_API_KEY.
Neon Project ID: The Neon Project ID can be obtained from your Neon project’s Settings → General page. Add the Neon Project ID to your GitHub projects Repository Variables under the name NEON_PROJECT_ID.
Neon Database Username: Add the DB Role to be used for branch creation to your GitHub projects Repository Variables under the name NEON_USERNAME.
Expo Token: Obtain an Expo access token by going to Account Settings → Access tokens from the Expo dashboard. Then add a Robot user by clicking on Add robot and giving it the name GITHUB_ACTIONS. Next, click Create token and give it a descriptive, meaningful name, something like GitHub actions token for PR builds. Finally, copy the token and add it to your GitHub projects Repository Secrets with the name EXPO_TOKEN.

Creating a custom preview build for pull requests

With the GitHub project secrets and variables set, it’s time to configure GitHub Actions to handle pull requests made to the repository.

Create a new GitHub Actions file from your Expo project's root directory in the GitHub workflows directory.

MacOS / Linux

touch ./.github/workflows/deploy-preview.yml

Windows

mkdir "./.github/workflows" && call > ./.github/workflows/deploy-preview.yml

The following code defines the steps the GitHub Action will perform. Copy and paste this code into the file you created above.

name: Deploy Preview
run-name: Create a preview build 🚀

on: [pull_request]

env:
  NEON_API_KEY: ${{ secrets.NEON_API_KEY }}
  NEON_PROJECT_ID: ${{ vars.NEON_PROJECT_ID }}
  NEON_USERNAME: ${{ vars.NEON_USERNAME}}

jobs:
  deploy-preview:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
      - name: 🏗 Setup repo
        uses: actions/checkout@v4

      - name: 🚀 Create Neon Branch
        id: create-branch
        uses: neondatabase/create-branch-action@v5
        with:
          project_id: ${{ env.NEON_PROJECT_ID }}
          # parent: dev # optional (defaults to your primary branch)
          branch_name: preview/pr-${{ github.event.number }}-${{ github.event.pull_request.head.ref }}
          username: ${{ env.NEON_USERNAME }}
          database: dg_db # database to branch
          api_key: ${{ env.NEON_API_KEY }}

      - run: echo "EXPO_PUBLIC_NEON_URL=${{ steps.create-branch.outputs.db_url }}?sslmode=require" >> $GITHUB_ENV

      - name: 🏗 Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: 18.x
          cache: npm

      - name: 🏗 Setup Expo CLI
        uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: 📦 Install dependencies
        run: npm install

      - name: 🚀 Create Expo preview
        uses: expo/expo-github-action/preview@v8
        with:
          command: eas update --auto --branch ${{ github.event.pull_request.head.ref }}

The first section defines the GitHub Actions name, the events it responds to (in this case, when a pull request is created), and the environment variables that will be used throughout the various GitHub Action steps.

name: Deploy Preview
run-name: Create a preview build 🚀

on: [pull_request]

env:
  NEON_API_KEY: ${{ secrets.NEON_API_KEY }}
  NEON_PROJECT_ID: ${{ vars.NEON_PROJECT_ID }}
  NEON_USERNAME: ${{ vars.NEON_USERNAME}}

jobs:
  deploy-preview:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
      - run: echo project_id ${{ env.NEON_PROJECT_ID}}

      - name: 🏗 Setup repo
        uses: actions/checkout@v4

The next section uses the Create Branch Action step provided by Neon to create a branch from our primary branch, using a specific pattern to create a unique branch name for the Neon database. Using this unique and reproducible pattern ensures it can be automatically deleted once the pull request is closed.

Once the branch is created, a new environment variable is created, EXPO_PUBLIC_NEON_URL, with the newly created database URL. The environment variable should be the same one used within your Expo application to connect to your Neon database. If it is not, update the variable name used in the GitHub Action to match what is used in your application.

- name: 🚀 Create Neon Branch
  id: create-branch
  uses: neondatabase/create-branch-action@v5
  with:
    project_id: ${{ env.NEON_PROJECT_ID }}
    # parent: dev # optional (defaults to your primary branch)
    branch_name: preview/pr-${{ github.event.number }}-${{ github.event.pull_request.head.ref }}
    username: ${{ env.NEON_USERNAME }}
    database: dg_db # database to branch
    api_key: ${{ env.NEON_API_KEY }}

- run: echo "EXPO_PUBLIC_NEON_URL=${{ steps.create-branch.outputs.db_url }}?sslmode=require" >> $GITHUB_ENV

Lastly, it configures the build environment for the Expo application, creates a preview build, publishes it to the Expo cloud for testing, and adds a comment to the pull request.

- name: 🏗 Setup Node
  uses: actions/setup-node@v3
  with:
    node-version: 18.x
    cache: npm

- name: 🏗 Setup Expo CLI
  uses: expo/expo-github-action@v8
  with:
    eas-version: latest
    token: ${{ secrets.EXPO_TOKEN }}

- name: 📦 Install dependencies
  run: npm install

- name: 🚀 Create Expo preview
  uses: expo/expo-github-action/preview@v8
  with:
    command: eas update --auto --branch ${{ github.event.pull_request.head.ref }}

The pull request comment added to the pull request is done as part of the Create Expo preview step. It contains information about the published app, such as the project name and platforms it was published to, as well as a QR code to open the preview build within the Expo Go app on your corresponding mobile device.

You’re now free to perform any actions on your preview app that would add, update, or modify data without fear of impacting or polluting data or resources in your production environment with test data.

Cleaning up the preview environment

Once the pull request has been merged, or closed, it is recommended to clean up the resources no longer needed, like the Neon database branch created when the pull request was made.

From the root directory of your Expo project, create a new GitHub Actions file in the GitHub workflows directory.

touch .github/workflows/cleanup-preview.yml

The following code defines the steps the GitHub Action will perform. Copy and paste this code into the file you created above.

name: Clean up Preview Deployment
on:
  pull_request:
    types: [closed]
env:
  NEON_API_KEY: ${{ secrets.NEON_API_KEY }}
  NEON_PROJECT_ID: ${{ vars.NEON_PROJECT_ID }}

jobs:
  delete-preview:
    runs-on: ubuntu-latest
    steps:
      - name: Delete Neon Branch
        uses: neondatabase/delete-branch-action@v3.1.5
        with:
          project_id: ${{ vars.NEON_PROJECT_ID }}
          branch: preview/pr-${{ github.event.number }}-${{ github.event.pull_request.head.ref }}
          api_key: ${{ secrets.NEON_API_KEY }}

The first section again defines the GitHub Actions name, the events it responds to (in this case, when a pull request is closed), and the environment variables that will be used throughout the various GitHub Action steps.

name: Clean up Preview Deployment
on:
  pull_request:
    types: [closed]

env:
  NEON_API_KEY: ${{ secrets.NEON_API_KEY }}
  NEON_PROJECT_ID: ${{ vars.NEON_PROJECT_ID }}

The last section deletes the Neon database branch created when the pull request was made using the same branch naming pattern when the pull request was made.

jobs:
  delete-preview:
    runs-on: ubuntu-latest
    steps:
      - name: Delete Neon Branch
        uses: neondatabase/delete-branch-action@v3.1.5
        with:
          project_id: ${{ env.NEON_PROJECT_ID }}
          branch: preview/pr-${{ github.event.number }}-${{ github.event.pull_request.head.ref }}
          api_key: ${{ env.NEON_API_KEY }}

And that’s all there is to it! When a pull request is merged or closed, its corresponding Neon database branch is deleted.

Conclusion

In this tutorial, you learned how to create a preview build of a React Native Expo application for each pull request made. You also learned how to create a corresponding Neon database branch for each preview build, passing its connection string along to the Expo application build process.

If you want to test this yourself, use the sample code and instructions on GitHub.

Using Custom Fonts on your Website

Ryan Overton — Mon, 14 Feb 2022 22:07:25 +0000

The team at Google has provided an amazing library of fonts which you can use for free on your website. These fonts have allowed developers to show their creativity, as well as uniqueness. In addition, Google has also provided a service allowing you to load any of these fonts into your site without having to host them yourself. Which quite a few of us are probably using at this very moment.

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Robot">

But what about when you’ve got a custom font that’s been created just for you, or you can't use the service provided by Google for business or other reasons? How can you use that font on your site?

In this article, I’ll show you how you can use those custom fonts, or still use the fonts provided by Google without using the Google Fonts APIs.

Font types

There are several different font types and not all browser versions support every font type. So, check the table below to understand what browsers support what types and the versions at which they started supporting them.

Font format	IE	Chrome	Firefox	Safari	Opera
TTF/OTF	9.0*	4.0	3.5	3.1	10.0
WOFF	9.0	5.0	3.6	5.1	11.1
WOFF2	14.0	36.0	39.0	10.0	26.0
SVG	Not supported	Not supported	Not supported	3.2	Not supported
EOT	6.0	Not supported	Not supported	Not supported	Not supported

* table data provided by w3schools

It's worth noting, the World Wide Web Consortium (W3C) recommends using the Web Open Font Format (WOFF). WOFF is a TrueType font (TTF) or OpenType font (OTF) with compression. WOFF 2.0 is a newer version of WOFF, just with better compression.

Download font

To get your font from Google, navigate to https://fonts.google.com, select your desired font, and click Download family.

This downloads a ZIP file containing all the variations (medium, bold, italic, etc.) of the font. Once you unzip the file, you will notice it downloads a TTF format. You can either use this as is, or convert it to WOFF2. Converting is recommended for production.

Convert font

To convert the font to WOFF2, you can use a service like cloudconvert.

Upload your TTF file, click Convert, then click Download.

Use font in your website

With your font converted to WOFF2, you’re ready to add it to your website.

Move the converted font into your website folder.

Next, you’ll add a @font-face rule. The @font-face rule allows you to define new font types which can be used throughout your CSS.

The @font-face rule requires you to give the font a name and the url where the font file is located. When the rule is loaded into the client's browser, it will download and load the font file from the specified location.

Place the @font-face rule at the top of your <style> tag or CSS.

@font-face {
  font-family: mySuperFont;
  src: url(assets/SupermercadoOne-Regular.woff2);
}

Now, the font can be referenced by the other styles in CSS,

p {
  font-family: mySuperFont;
}

or by inline styling

<div style='font-family:mySuperFont'></div>

Sample app

I've created a working sample application demonstrating how this concept and placed the code for it on GitHub.

OnyxPrime / custom_fonts_sample

Using custom fonts in your website

If you've got any questions, comments, or other ways you get custom fonts in your websites let me know in the comments below.

4 Ways to Optimize 3rd Party Libraries

Ryan Overton — Thu, 07 Oct 2021 18:11:50 +0000

Web performance is an often overlooked metric of a company's website. It’s pushed to the back of the queue in preference of a site's look, layout and theme. While these areas of a site are important aspects of your visitors' experience, a poor loading and performing website will cause them to leave your site before it’s loaded. This means all the time and effort spent on crafting a great and compelling user experience was for naught.

According to a study conducted by Google in 2017, as page load time goes from 1 second to 3 seconds the probability of a user navigating away increases 32%. The performance of your site ensures visitors get to go through the finely crafted experience teams have spent many hours creating.

If you’re a 3rd party SaaS provider, performance is more important. Businesses want to use your service, but if it’s the cause of performance issues on their site, they will be looking to replace your service as soon as they can.

At Ketch, one of our top priorities is to ensure our libraries are as optimized as they can be for performance.

Here are 4 ways we use, and so can you, to optimize our libraries to ensure they don’t hinder the loading and performance of our customers' websites and applications.

Use async/defer

If at all possible you should design your library to be loaded asynchronously, rather than synchronously. This is to allow page rendering to occur while the library is being downloaded, unlike synchronous scripts which stop page rendering until the script is downloaded, parsed, and executed.

You can utilize the async or defer attributes to instruct the browser to continue parsing the HTML while the scripts are downloaded.

While both the async and defer attributes tell the browser to download while the page is being rendered, the point at which the downloaded script is executed is where they differ.

The async attribute tells the browser to execute the script the first chance it gets after it has been downloaded, but before the load event is fired.

The ‘defer’ attribute tells the browser to execute the script after the HTML has finished parsing, but before the DOMContentLoaded event is fired.

Remove unused code

Photo by v2osk on Unsplash

To optimize the loading of your library you will probably run it through a bundling process to reduce the number of round trips to the server. Bundling combines your code files and their dependencies into a single file.

What we tend to forget is that we rarely use all of the functions available within our dependencies, which come along for the ride during the bundling process. This can lead to an unnecessarily large file to download.

To reduce this file size, implement a tree shaking process to remove all the code not being used.

Tree shaking looks at the bundled file and attempts to determine which code paths are not called and remove them from the final output.

Note: Tree shaking can have unintended side effects if it is too aggressive in removing what it thinks is unused code. This can cause unintended side-effects or broken logic on your page. You need to thoroughly test your page with the tree shaken file.

Break larger JavaScript files into multiple, smaller logical files

Photo by Daniel Cheung on Unsplash

Above we talked about the bundling process, which combines your code and its dependencies into a single file to reduce the need for multiples to the server. Sometimes we don’t need all the functionality immediately upon page load.

For instance, there may be function calls that require a user to press a button before it’s activated. This code can be separated into another file to be downloaded, or deferred, after the page’s HTML has been parsed.

Use a Content Delivery Network

People illustrations by Storyset

With all the previous optimizations implemented, you may think you’ve done all you can to increase your page’s performance, but visitors to your customers site are not created equal, at least in the case of location.

The further the visitor is away from your web server's physical location, and the speed of the network they’re connected to, affect how long it will take for their device to download your library.

While the previous optimizations will help tremendously with how long a library takes to download, this will move the files closer to the visitor. This can be accomplished by utilizing a content delivery network (CDN), like Fastly, Akamai, or Cloudflare.

The CDN does not replace the need for a web server, but allows caching of a site’s content at strategic locations around the world. This caching closes the distance between your library and the visitor viewing your customers page, decreasing the download time.

Conclusion

As a library creator, your responsibility doesn’t stop at getting the code working as expected. How it loads and affects the page on which it's executed is just as important.

At Ketch we are continually monitoring and improving the performance of our libraries utilizing the tips above, ensuring we are never a hindrance to a customer’s site.

Optimizing your library will show customers you care just as much about their site’s performance as they do.

Weekly Win (47/2020)

Ryan Overton — Tue, 17 Nov 2020 18:31:20 +0000

When implementing a third-party library, we set expectations on how we believe it will be implemented, and when these expectations aren't met, we can get very frustrated and start taking it out on the team, or developer, who created the library. We also set these same expectations on other tasks we perform, and can be met with the same level of frustration and disappointment when things don't go as planned.

A few weeks ago, I had the task of changing the water filter in our rent house refrigerator. It's used to filter water used in automatic icemakers and water dispensers built inside of refrigerators.

I set my expectations on how the water filter should be changed based on my past experience changing water filters over the past twelve plus years of home ownership.

Here were the steps I followed:

Buy new filter
Remove old filter
Insert new filter
Enjoy clean water and ice

This process had worked well, without issue, until a few weeks ago. We recently moved in to a rent home and it was time to change the water filter. I followed my normal steps, but when I got to step two, something different happened. As I began removing the water filter, water started spraying all over the inside of the refrigerator. 😲 I tried just putting the old filter back on, but it didn't stop the spraying. At this point, I realized I needed to shutoff the water going to the refrigerator, conveniently located behind it.

With the water shut off, inside of the refrigerator thoroughly soaked and water draining out on to the kitchen floor, I had two ways to handle the situation: let my frustration and anger at the implementation ruin the rest of my day, or flip my perspective and look at it in all it's hilarity, like my family was doing 😂.

I took the second option and joined in on the laughing. I also looked as it as an opportunity to do something I probably wouldn't have done, clean out the refrigerator 😁 and add a new step to my process: turn off the water.

So, the next time your faced with a failed set of expectations, instead of denigrating the team, or person, who missed those expectations, flip it around and look a it as an opportunity to change something for the better, even if it might be a little more work than we had thought, or hoped. After all, as developers, we should always be looking at ways to better improve our solutions, and practices, at least that's how I look at it.

When's the last time you had your expectations not met and how'd you deal with it?

I look forward to reading your responses below!🙂

ASP.NET: The Next Generation

Ryan Overton — Mon, 16 Nov 2020 20:58:38 +0000

Unless you've been locked away in a dark room for the past six years, you've likely already heard about ASP.NET Core. It is the reimagination of ASP.NET, the web framework we've grown to love, and at times hate 😜, over the past 18 years. With the former framework still being supported and actively worked on, it can be hard to make a case for switching off a framework with such a rich history, like ASP.NET, to a relatively new framework, even if it shares the same name.

In this article, we're going to look at the reasons why the team building the next generation digital experience platform, Kentico Xperience, decided to transition to ASP.NET Core.

Future Friendly

Let me start by saying, ASP.NET and the .NET Framework are not going anywhere anytime soon. Much of Windows still relies on the .NET Framework and until such time that it doesn't, there will still be support and bug fixes for the .NET Framework. But, and it is a big one, there will be no major updates to the .NET Framework beyond version 4.8.

The future of .NET, and by virtue ASP.NET, is .NET Core. This is where investments are being placed. Which means you'll be able to take advantage of all the improvements being made to the platform and the languages used for development.

As an example, many of the C# 8.0 features have platform dependencies which are implemented in .NET Standard 2.1, which .NET Core 3.0 and newer will support, but .NET Framework 4.8 never will.

So, in order to stay innovative, competitive, and continue to attract top talent, the team looked for a platform that was familiar and would be supported for the foreseeable future.

Cross-platform Support

Long gone are the days where clients will meet you where you are. As software creators, we NEED to be meeting our clients where they are and it's no longer exclusively on a dedicated platform, like Windows.

Unlike its predecessor, ASP.NET Core does not require IIS or Windows to develop or run. This means you can use other operating systems, like macOS and Linux, to develop applications and as hosting environments.

This may not seem like a huge deal to some, but if you're looking at the cost to run a Windows environment versus a Linux environment, you'll likely start to see a growing difference in cost. This could end up greatly reducing the operating costs of your applications allowing you to adapt quickly to changes happening within your market.

For development teams, this means we're able to reuse a majority of our code as we expand the reach of our application to other platforms.

Performance

Eight seconds.

No, we're not talking about the movie chronicling the life of PRCA Bull Riding World Champion, Lane Frost, but the average attention span of a website visitor. And if your site takes longer than three seconds to load, there's a 40% chance they'll abandon their visit to your website. So, it's no wonder most clients, partners and users will tell you your site needs to be faster.

This is one of the biggest benefits you'll gain when you switch to using ASP.NET Core and in my opinion, one of the most compelling reasons to make the move to ASP.NET Core.

Benchmark data shows ASP.NET core can do approximately 285,000 requests per second, whereas, ASP.NET averages approximately 1500 requests per second.

Benchmark data shows ASP.NET core can do approximately 285,000 requests per second, where as, ASP.NET averages approximately 1500 requests per second.

After moving to ASP.NET Core, the Kentico Xperience team ran some preliminary tests on startup times. They found the Dancing Goat starter site was starting up 4 times faster using ASP.NET Core.

Summary

Although migrating to a new platform is never fun and almost never easy, the .NET Core teams continue to add APIs and features to help ease migration efforts from the .NET Framework. The Kentico Xperience team also understands this and is currently looking at options to aid clients and partners in their migration efforts.

The Kentico Xperience team found being future friendly, cross-compatible and highly performant compelling reasons to move from ASP.NET to ASP.NET Core.

What do you think? Are you ready to take the plunge? Something holding you back?

Need a little more convincing? Download Xperience 13 and see the impact of our transition to ASP.NET Core.

🤦‍♂️ Weekly fail (41/2020)

Ryan Overton — Tue, 06 Oct 2020 13:20:15 +0000

Last week, I spent the better part of my Friday livestream working on solving a single problem. With a little more attention to detail, this wouldn't have been a problem at all.

I had just gotten done implementing a custom 404 handler for a static site I have been developing for a friend. I went to test the handler, but it wasn't working. I was still getting the generic 404 exception, cannot GET \page, when a page does not exist. I spent the next 1.5 - 2 hours trying to solve why the redirect wasn't working and just before I ended my stream, I figured it out.

I had been working on this site many times over the course of several weeks and I typically leave my working pages open in a browser window, including the site running on localhost, specifically localhost:8080. I also leave my command windows open because that's where the static site generator CLI is running and watches for changes in order to rebuild and reload the site.

At some point, the command window, or CLI, crashed and when it did it left a Node.js process running in the background. This process was still running and using localhost:8080 to serve up my site. On Friday, when I reran the CLI in a command window, it started up another Node.js process, this time serving it up on localhost:8081. 🤦‍♂️ And did I mention, the CLI tells you specifically where it is serving your site.

Lesson learned: Pay attention to what the CLI is outputting and when in doubt, restart everything, including your computer.

I love the opportunity to post my fails in hopes of saving someone from the same fate, but also to show no matter how many years of experience you have, we all still struggle, and fail, from time to time. So don't get all down on yourself when it happens to you 😉.

What was one of your fails last week?

Also, if you ever want to chat about it, or anything for that matter, drop in to my stream where you'll find an amazing, supportive group ready to welcome you and share their wins and fails!

🤦‍♂️ Weekly fail (36/2020)

Ryan Overton — Tue, 01 Sep 2020 13:54:18 +0000

If there's one thing I've learned in my 13 years of being a software developer, it's that nothing is easy! Even the tasks that seem the most trivial.

A little over a year ago, I was given the amazing opportunity to become a developer evangelist for one of the leading content management providers out there, Kentico. One of the things I love most about being a developer evangelist, and the primary reason I changed roles, is I get to create content about my passion, software development.

One of the mediums for my content is video uploaded to my YouTube channel. You would think sitting down in front of a camera, recording yourself talking would be a no brainer. Well remember in the beginning I said "nothing is easy"... yeah, that includes sitting down in front of camera and recording yourself talking.

In my latest video, I recorded a 20 minute portion without audio 🤦‍♂️. At some point I muted the microphone because it was providing background noise as I was trying to edit a video. To make matters worse, I didn't actually find this out until I started to editing this video. Needless to say I had to go back and re-record that section.

Lesson learned: No matter how many times you've done it, ALWAYS perform a video and audio test before you begin your production recording! That's right, testing isn't just for software development anymore. 😜

Bonus: Own your fails and be proud of them! Your failures and how you handle them, say so much more about you, than your successes.

What's been one of your latest fails?

My Twilio Hackathon Successful Failure

Ryan Overton — Sun, 03 May 2020 19:56:30 +0000

This past April, I had the opportunity to participate in the Twilio x DEV community hackathon. Participants had the entire month of April to develop and submit your project.

It's only the 3rd hackathon in which I've participated and my first, hopefully of many, virtual hackathons. Unfortunately, due to some unforeseen, non-project related, circumstances, I was unable to submit my project on time. 😢 This is the failure I'm speaking of in the title.

Wait, but you called it a "successful" failure. How can a failure be a success? Some of you may already understand what I mean by this, but for those who don't, please bear with me. Everything will become clear by the end.

The Project

I struggled a little with what should the project be, but with the help of a friend, Ondrej Polesny, the ifBored project was born.

Throughout a person's life, there are times where one has nothing to do. Let's be honest though, there's always something to do. We just need a little help deciding what we should do 😉. That's where my project comes in.

When you are not sure what you should do next, text a number, visit a site on your phone, tablet, or computer, answer a few questions, and get a suggestion about what you should do next. Sounds simple, right!?

The Technology

I've spent most of my 13 professional years in software development working within the Microsoft stack, specifically using C# and Azure.

I took the hackathon as an opportunity to step outside my comfort zone and work with some technologies and platforms I had very little experience with and had not worked with previously. This, by far, was the most challenging piece of the project.

Oh, and I also did the majority of it LIVE on my Twitch channel Developers Garage!

I chose JavaScript because it's one of the top programming languages and one which I'm not as familiar with as I'd like to be. To me, JavaScript is like the wild west 🤠. The rules, if any, aren't clear and you don't find out about them, until after you've tried it.

I also chose to use a serverless infrastructure, so I didn't have to setup, configure and manage a server environment. Plus, there are some great free options for serverless environments, which plays well with proof of concepts and hackathons. That's where Netlify comes in. Netlify is an all-in-one platform to build, test and deploy your modern web applications.

For user interaction, I went with Twilio because it was part of the requirement and they're an amazing communications platform across the board. They also provide great documentation and software development kits (SDKs) for use with whatever framework you're working with.

To store the questions and suggestions, I could have used text files with JSON in them, but I wanted to use a service which abstracted away the management and distribution of this data, as well as, provide a great experience. That is why I chose Kentico Kontent, a content as a service platform providing all the benefits of a headless service platform.

Full disclosure: I currently work as a developer evangelist for Kentico Kontent 😊

When questions are asked and answers provided, we need to store this conversation. For conversation storage, I chose to use Fauna, a serverless, No SQL database featuring native GraphQL. The structureless nature of a No SQL database is very appealing to me because it allows the data structure to naturally evolve with the application.

In case you haven't realized it yet, there is a general theme in my choices of platforms and services, I'm using for the project. They all have a FREE tier meaning anyone can try, improve and contribute to this project without fear of having to spend any money.

For phase 1 of the project, a user texts our Twilio number, which calls the associated endpoint, a serverless function hosted on Netlify, which retrieves the conversation from Fauna, gets the first question and returns it to Twilio, which responds back to the user with the question. This same process continues, except stores the answers to the questions in the conversation in Fauna, until all questions have been answered. Once all questions have been answered, the system will suggest something to learn, or do, and provide a resource.

Phase 1 works functionally, but is missing the decision making logic. So, it currently asks a few questions and returns the only suggestion it know.

For future phases, we will implement other platforms (web, voice, WhatsApp, etc.) to allow different users to interact with the service, as well as, implement the decision making logic 😜 and add the ability to submit new suggestions through a web interface.

Conclusion

So, back to why I called this project a "successful failure". I learned SO much while working on this project and feel so good about the work accomplished. While I would have liked to have submitted my project into the hackathon, the ultimate goal was to learn something new and that is exactly what I did. This is why I called this project a "success".

I am much better, and more comfortable, with JavaScript and am more familiar with Netlify and how to host various services and applications on it. I am more comfortable using a NoSql database and how they're constructed. I also realize there is SO much more to learn and am excited to continue this project.

That's right, this project is far from done! It will continue to be done in the open and LIVE on my Twitch channel Developers Garage. The latest schedule for my streams are found on the channel, but be sure to like the channel by clicking the ♥ and turning on notifications to be notified the next time I go live. Also, follow me on Twitter where I also post when I go live.

I can't do this alone, nor do I want to. This project wouldn't be where it is, if it wasn't for others in the development community. Thank you to those who joined the previous streams!

You too can help make this project a reality and resource for those who have down time and need something to do. To help, fork the repo, join the live stream sessions or comment and create issues.

If you're looking to learn more about the technology used, join me on the Developers Garage live stream where it's always an ask me anything stream.

See you in the chat!

Increase Your Discoverability With Keywords in Kontent

Ryan Overton — Tue, 24 Mar 2020 05:10:53 +0000

You come up with an amazing idea for a piece of content. You spend the next few days, week or longer creating, editing, fine-tuning your content. Once complete, you publish it to your medium of choice and wait for the reviews or read counts to go up, but they never do.

You wonder what went wrong. Was the topic not that great of an idea? Are people not interested in the topic or am I just not as good of a writer as I thought I was? As a content creator, I feel your pain, as it's something I've been through and will continue go through in the future. Some of it might be true, as it is most times in my case 😋, but it is most likely a discoverability issue.

As I continue to create content across different mediums, live streaming, video on-demand and written articles, I'm learning discoverability is really what keeps a lot of content from getting from getting viewed. So, what can you do to help ensure your article gets seen, or noticed?

Think about when you visit a site like Medium, or YouTube, what's the first thing you do? You enter the topic you're wanting to know or learn about in the search bar, right? At least that's what I do. Then the platform suggests content based on the search terms you entered. So, how do you get the platform to suggest your content? Well, most platforms offer some sort of tagging mechanism you can use to identify the keywords which can be used to best categorize your content.

Figuring out these keywords is the next tricks, especially if you're not the original content creator. You could spend hours going through your content to identify those keywords, but I want to offer an alternative.

Keyword Extractor

As part of our hackathon at our last DevRel reunion a few months ago, one of the teams worked on a keyword extractor to be used within Kentico Kontent.

The keyword extractor custom element gives creators and editors an automated way to generate keywords for an item based on it's content. It allows editors to remove selective keywords, refresh the list manually and use different keyword selection algorithms. One algorithm, a pure JavaScript implementation, uses the rapid automatic keyword extraction (RAKE) algorithm. The other algorithm uses the Microsoft Azure Text Analytics API.

Deploying

Before we can use the keyword extractor within Kentico Kontent, it must be deployed to a public host. If you're running through a proof of concept, or just looking to test out the keyword extractor, and not ready to go through the process of setting up a production environment to host the keyword extractor, fear not.

One of the steps the team took was to reduce the time it takes to get started using the Keyword Extractor was to automate a quick deployment using Netlify. If you're not familiar with Netlify, it's an all-in-one platform for building, testing and deploying modern web projects.

To deploy the project to Netlify, simply navigate to the deploying section in the Keyword Extractor repository, click the "Deploy to Netlify" button and follow the instructions. Within 5 minutes, you'll have a fully deployed version of the Keyword Extractor.

Using the Keyword Extractor

To use the Keyword Extractor, a custom element will need to be added to the content type containing the content to be used. Instructions for adding the custom element can be found in the Kentico Kontent documentation.

You will need 2 pieces of information to complete this step.

the URL where we deployed the code to in the above step
a set of JSON parameters used to configure the Keyword Extractor

{ "elements": [ "<codename of element to be used>" ], "azureKey": "<YOUR_AZURE_ACCESS_KEY>", "debug": true }

The "elements" are an array of the codenames for the elements containing the content to be searched for keywords. The "azureKey" is the API key for the Azure Text Analytics API and "debug" displays a debug panel on the content item used in troubleshooting.

If you want to test the pure JavaScript implementation, remove "azureKey" from the JSON. If you do not want to show the debug panel, either set the value to "false", or remove it from the JSON.

Once the custom element is added and configured, it is ready for use by the content editors.

Wrap up

We've seen how we can save quite a bit of time in trying to figure out keywords to use for our content by setting up an automatic keyword extractor in Kentico Kontent. Now it's your turn to take these keywords and see how they can improve the discoverability of your content.

Is Jamstack Suitable for Anything More Than a Microsite?

Ryan Overton — Mon, 03 Feb 2020 22:38:48 +0000

In a world where user experience reigns supreme, a lone stack stands out providing fast, secure and usable sites: the Jamstack. Jamstack sites, or static sites, are great for blogs and marketing focused sites, but what about when content needs to be dynamic? Can the Jamstack handle these scenarios?

TL;DR

Yes. Yes, it can.

Before we go into how a static site can be dynamic, let's review what the Jamstack is.

What is Jamstack?

If you're new to the Jamstack, it's not like most of the stacks you might be familiar with, like LAMP (Linux, Apache, MySQL, PHP/Perl/Python) or MEAN (MongoDB, Express.js, Angular, Node.js). It's not focused on a set of technologies, but rather a modern architectural pattern for "building websites and apps that delivers better performance, higher security, lower cost of scaling, and better developer experience."

Jamstack stands for Javascript, APIs, and Markup. The power of the Jamstack comes with its core concept that sites are composed of static, pre-rendered HTML pages which can be enhanced using Javascript and APIs.

This core concept is where Jamstack websites get their speed, they're pre-rendered. We don't have to wait for the web server to fetch data, most likely from another server, render the page and return it to the client. The pre-rendered page is returned as-is to the client.

But wait... if the pages are pre-rendered, do we need a web server? No, a web server is no longer needed. We can use a content delivery network (CDN) to deliver our static pages.

This is how the Jamstack reduces the cost of scaling a site. One less server to manage, pay for and replicate as traffic increases.

Pre-rendering a Jamstack site

Because we're deploying static HTML files, we could generate these files by hand. I would strongly discourage this method primarily because updates take more time and are error-prone due to duplication of markdown.

Take the example where a new page is added to the navigation menu. All pages containing the navigation bar will need to be found and updated.

Most of the time you'll want to use a static site generator (SSG), like Gatsby, Nuxt, or Jekyll, to pre-render the HTML pages. With an SSG we can create templates and components one time and then reference them on the pages that need them.

Taking the same example used above, when a new item is added to the navigation bar, we only have to update it in the navigation bar component and all pages referencing this component will get the update once they're rebuilt.

Dynamic static site

If the idea of a static site being dynamic sends your brain spinning 🤯, no worries, mine did the same when I first tried to understand how this could be possible. Static sites are great for blogs and microsites where content doesn't change too often, but what about when we need the content updated at a more rapid pace, or based on interactions with the user?

Once I dove a little deeper into the concept of a dynamic static site, it made a little more sense. There are 2 ways a static site can be dynamic: during site pre-rendering and through user interactions with the site.

During site pre-rendering, a static site generator can hit APIs to gather the necessary data from an external source and use templates to dynamically create the pages.

Consider the example where you have a list of employees and there information stored in a content management system (CMS), such as Kentico Kontent, a static site generator can pull the list of employees from the CMS and build out an index page with a list of employees and individual pages for each employees details.

The other scenario is when you need to dynamically update content based on some constantly changing piece of data, like the current temperature, the number of stars on your GitHub repo, or the cart on your favorite e-commerce site.

This is accomplished by pre-rendering the page with default data. Once the page is loaded in the client, it can use Javascript to fetch the current data and update the page.

Want to know more?

If you're interested in learning more, check out the videos from my LIVE sessions on Twitch, where we discuss the Jamstack and look at getting started using 2 different platforms, Gatsby + React and Gridsome + Vue.js. I also code LIVE on Twitch, DevelopersGarage, every week where we explore and learn about the Jamstack, as well as, other various development technologies and platforms.

Deploying Your Blazor Application to Azure

Ryan Overton — Fri, 03 Jan 2020 04:47:58 +0000

This article is part of series by Ondrej Polesny and myself. To catch-up, check out the previous articles.

You've created an amazing, interactive web application using the latest feature of ASP.NET, Blazor, but now what? How do you get it out there to show the world all your hard work? Where do you host it? How do you get it there?

In this article, we'll show you how to deploy your Blazor application to Microsoft's cloud computing service, Azure. We'll also be using Visual Studio 2019 to publish/deploy the application. Visual Studio provides the ability to deploy your application to a folder, IIS, Azure, or other destinations, within the integrated development environment (IDE) reducing the steps it takes to get your application in front of your audience.

Setting up the environment

Before we can deploy our application, we need to create and configure the environment to hold and serve the application. We'll be using services that fall under the free tier account usage within Azure. To see a list of everything available on the free tier account, go here.

Creating a web application in Azure

While in the portal, click on the "+" symbol on the menu on the left.

In the Marketplace, search for "Web App",

and click "Create".

On the "Basics" tab, ensure the subscription you wish to use is selected. We'll create a new resource group to contain our app service. A resource group is a collection of resources that share the same lifecycle, permissions and policies. Then provide an instance name for our application.

Scroll down the page, changing "Operating System" to "Windows" and "Runtime Stack"to ."NET Core 3.0 (Current)". While .NET Core 3.1 (LTS) was released on December 3, 2019, at the time of this writing, web applications running under Windows on Azure do not currently support the latest version of .NET Core out of the box. Fear not, we can still run the latest version of .NET Core with a little extra configuration. We'll configure this later on in the article.

Leave the remaining options set to their defaults.

Note: .NET Core 3.1 (LTS) is available out of the box for Linux operating systems on Azure.

Now click "Review + create"

Validate all the options are correct and click "Create". This kicks off the automation process within Azure which creates the web app environment within the selected regional datacenter. This process may take a few minutes depending on the current load within the datacenter.

Once the deployment is complete, click on "Go to resource" to navigate to the newly created resource.

Configuring .NET Core 3.1 (LTS) Support

With our web application created, we can now configure support for .NET Core 3.1 (LTS). While in the web application, navigate to the "Extensions" tab and click "Add" to open the add extension window.

Click on "Choose Extension" and select "ASP.NET Core 3.1 (x64) Runtime".

Click on "Legal Terms" and click "OK" to accept the terms.

Now click on "OK" under the "Add Extension" window.

With the extension now added to our web application, we can run applications requiring .NET Core 3.1 without having to wait for Azure to support it. This same process can also be used when wanting to test new features only available within preview versions of .NET Core, like Blazor Web Assembly.

We have 1 more step to complete before we can publish our Blazor application to Azure: update the configuration to x64. We must do this because we installed the x64 extension for .NET Core 3.1.

Navigate to "Configuration" in the left menu, select the "General" tab and update the "Platform" to "64 bit".

Deploying the Blazor application

With our Azure environment created and configure, we're now ready to deploy the Blazor application to it. The application we're deploying can be downloaded/cloned from here. We'll also grab one other file from our Azure web application service, the publish profile.

Navigate to "Overview" on the left hand menu and click "Get publish profile".

The publish profile contains all the information Visual Studio needs (FTP location, credentials) to deploy our application to Azure.

Now, open the Blazor application cloned in the previous step in Visual Studio 2019. Right-click the project "awesome-blazor-app" and click "Publish".

Click "Import Profile..." and navigate to the location where you downloaded the publish profile from Azure a couple of steps ago. Select settings file and click import.

With the publish profile imported, click on "Publish". This kicks off the Visual Studio publish process, which will build the application in release mode and upon a successful build, will FTP the files to the Azure web application service we created earlier and launch our site in your default browser.

Summary

In this article, we learned how to create a web application environment within Azure to support a Blazor application and how to publish a Blazor application from Visual Studio to our Azure web application environment. We also learned how to use extensions in Azure to extend support for .NET Core 3.1 (LTS) to our web application. This is great, but it's not very maintainable, especially in a team environment. We'll fix this in an upcoming article where we automate the entire build and release process, removing bottlenecks and deployment silos.

Other articles in the series:

#1 What is this Blazor everyone's talking about?
#2 How to Build an Interactive SPA with Blazor
#3 Extending Interactive Blazor Site with Spatial Functions
#4 Deploying your Blazor application to Azure
#5 Automating the build and deploy of your Blazor application to Azure

What is this Blazor everyone's talking about?

Ryan Overton — Thu, 12 Dec 2019 15:53:15 +0000

JavaScript has been labeled as the backbone of web application development allowing you to create beautiful, and functional, web applications. But for a .NET developer, like myself, working with JavaScript can feel like the wild, wild west. Fret no more! Blazor helps alleviate that feeling by allowing us to run C# code in the browser!

Read on to learn more about what Blazor is, as well as, the pros and cons of using Blazor.

What is Blazor?

Blazor is a new single-page web application (SPA) framework built on top of the .NET framework. It allows you, the .NET developer, to build the same great user interfaces as those using JavaScript, except with C#. This also means we can reuse existing .NET libraries and logic we've created, like for field validation.

Now, there are those experienced developers out there, including yours truly, who remember the last framework to provide this feature, Microsoft Silverlight, and it's fate. There was a caveat that came with using Microsoft Silverlight, though, and that was it required the installation of a compatible plugin into your browser. This is was a deal-breaker for a lot of web users, and still is, especially with the prevalence of mobile browsers. The good news for us today is Blazor does not come with this caveat.

Blazor can run in 2 different modes, server-side and client-side. Each mode has different strengths and weaknesses making them useful for different scenarios.

Server-Side Blazor

Running Blazor in server-side mode means all execution of our C# code happens on the server. Once the code execution completes, updates to the user interface (UI) are immediately sent back to the client and merged into the document object model (DOM). Blazor uses SignalR, a real-time communication framework allowing server code to push content to "connected clients instantly as it becomes available, rather than having the server wait for a client to request new data."[1]

Client-Side Blazor

When using client-side mode, all code execution happens on the client and because everything happens on the client, all of the app's assets are deployed as static files. This means you can host the files on any service that can serve static files, like a content delivery network (CDN). To execute your C# code, Blazor uses WebAssembly (Wasm), a new technology that allows the execution of binary code inside most modern web browsers.

To learn more about Wasm, check out this article by Eric Elliot.

JavaScript's not dead

If you're a frontend developer who's reading this trying to keep up with all the new frameworks coming out these days, then you might be thinking Blazor, or Wasm for that matter, is trying to replace JavaScript. Let me put your worries at ease, as this is far from the truth. Wasm is meant to be a complement to JavaScript, not replacement.

The team behind Blazor recognizes there is already a rich ecosystem of JavaScript libraries available to developers. Likewise, many companies and enterprises have a large investment in client-side libraries built throughout the many years before This is why they provide JavaScript interoperability.

The good, the bad and the ugly

Alright, we've talked enough about what Blazor is and what it's not. Let's get to the pros and cons.

Pros

1. A framework developers already know

The team built Blazor around already used pieces of popular web development frameworks. So if you already have experience developing Razor Pages, MVC or Web APIs, the learning curve to Blazor is greatly reduced!

2. Faster page rendering

Because client-side Blazor is using WebAssembly to execute code and render the pages, we're able to run at near-native speeds, and the Blazor team is continuing to look for ways to increase these speeds.

3. Client-side mode can run in an offline mode

When running your app in client-side mode, all the resources and libraries your app needs to run are downloaded to the client. This allows your application to run detached from the internet, or in an offline mode. Something to also keep in mind, this is assuming your site doesn't need access to an external service to function, and if it does, you've accounted for the pre-loading, or persistence of the data locally, until a connection can be made to the external service.

4. Server-side communication is efficient

With Server-side Blazor, none of the code or libraries are sent to the client and only a small amount of JavaScript is sent over to bootstrap the application making it very efficient going across the wire. Server-side Blazor also uses SignalR to communicate between the server and client. SignalR uses web sockets to allow real-time back and forth communication, without having to wait for the client to make a request for new data.

5. Code reuse

Blazor implements .NET Standard 2.0, a formal specification of .NET APIs common across all .NET implementations. This means we can use the same code and libraries in the browser, on the server, or any other application implementing .NET Standard 2.0 and take advantage of the extensive, and growing set of libraries available in NuGet.

6. Client-side runs in Browsers Sandbox security

Long have users been worried about whether it's safe to run a web application or not due to concerns of malicious intent or data snooping. Blazor runs in Wasm and as such does not require any additional plugins or usage confirmations. It runs within the Browser Sandbox security context.

7. UI Component ecosystem from top component vendors

Many of the top component vendors, such as Telerik, DevExpress, ComponentOne, and SyncFusion, among others, have been following the development of Blazor and have already begun creating reusable UI components. These components further reduce the time it takes to get a working application out the door.

Cons

1. .NET Framework needs to be downloaded to the client

Client-side mode executes the C# binaries in the context of the browser, and because of this client-side execution, a copy of the .NET Framework libraries are needed. This leads to the download size being larger and a longer initial app load time. Once the libraries are loaded, they can then be cached.

2. Client-side mode is still in preview

Unlike server-side mode, which was released with the general availability of .NET Core 3.0, the client-side mode is still in preview. It is expected to be released in May 2020.

3. Only works on modern browsers

Due to the dependency on Wasm, older and non-standard browsers, like Internet Explorer and "thin clients", are unable to run client-side mode versions of Blazor.

4. Debugging can be tricky

Because execution in client-side mode happens in binary on the client, custom tools are needed for debugging. These tools are currently limited in capabilities and can be cumbersome to set up. See the instructions here.

5. Reduced performance benefits in server-side mode

Unlike client-side mode, server-side mode requires a network connection between the client and server, and as such, any slowness in the network will negatively impact the performance of the application.

Conclusion

It's never an easy decision when it comes to deciding on the technology for your team's next project and I hope I've provided you with some beneficial information when it comes time to evaluate your next web technology. While I would love to see Blazor take off like gangbusters, always use the right tool for the right job. 🙂

To learn more about Blazor, head on over to the official documentation, or if you're itching to get your hands on some code and have the latest version of Visual Studio installed, just create a new project and select Blazor app. You can also view the official getting started guide here.

Other articles in the series:

#1 What is this Blazor everyone's talking about?
#2 How to Build an Interactive SPA with Blazor
#3 Avoiding Parking Fines with Blazor and Geolocation
#4 Deploying Your Blazor Application to Azure

Update 12/18/2019: Added link to article #2 in Blazor series.
Update 1/27/2020: Added link to article #3 and #4 in Blazor series.