[{"meta":{"title":"Serverless Swift","description":"Controlling Philips Hue bulbs by running Swift on AWS Lambda.","date":"2025-02-24T00:00:00.000Z","imagePath":"/blog-images/serverless-swift/serverless-swift.png","imageAlt":"Serverless Swift","tags":["serverless","swift","aws"]},"path":"/blog/serverless-swift","postContent":{"html":"

It's Swift on Server, minus the server. Deployed on AWS via Swift Cloud.

I've long been interested in running Swift on the back end, but it wasn't until a combination of a fun project idea and a spark from Swift Cloud that I was inspired to dig in and try it out. But why do it this way? How does it work? And how well does it run in terms of cost and performance? We'll break all of that down.

TL;DR

I built an event-driven serverless back end entirely in Swift that remotely flashes the Philips Hue bulbs in my house whenever my favorite sports teams score or win. It runs on AWS services including Lambda, DynamoDB, SQS, and EventBridge, and costs less than $0.20/month.

You can view the full source code for this project on GitHub.

Background

They say the only constant in life is change, and that has certainly been the case for my career in software development. I got started in front-end web development, grew to pick up traditional back-end development, fell in love with serverless back-end development, and then turned my favorite pastime into my full-time job building native Swift apps for iOS.

For the last several years, I've locked in on the two areas I'm most passionate about and enjoy the most: serverless back-end development and native iOS development with Swift.

I've written independently about both serverless and Swift before, but this is the first time I've gotten to combine the two. It's been a ton of fun working on the project and writing this post.

Why Serverless?

The first thing that comes to mind when you think Swift on Server is probably Vapor, or maybe Hummingbird. I am interested in both, and have used Vapor in the past, but I leaned on serverless for this project for reasons that I could talk about for days.

To keep it brief, I simply enjoy building serverless systems. Once you understand the primitives, serverless offers the best combination of speed, cost, fun, and scale that I know of. It's not a cure-all, but it's great for projects like this.

Additionally:

It's in the name - you never have to deal with servers
It's cheap, especially for small projects like this one. More on cost later
It automatically scales up and down. Ideally to zero
It's simple to configure basic services
You can write the services in any language
Infrastructure as Code platforms make hooking up the primitives seamless

Why Swift?

Honestly, the main reason is because I thought it would be fun. And it was! I had a blast building this.

There are other, more pragmatic, reasons as well:

It's the language I know best - I use it to write all of my iOS apps
It promises excellent performance and a low memory footprint
It does not incorporate a Just-In-Time (JIT) compiler, which conserves CPU and memory resources and results in quicker Lambda startup times
It uses Automatic Reference Counting, which allows for deterministic performance
It's strongly typed, null-safe, and a joy to write
It has a robust and modern package ecosystem

The Project

As mentioned above, it's a serverless system written in Swift that controls Philips Hue bulbs in my house whenever my favorite sports teams (Tulsa football & basketball, Eagles football) score or win. It runs on AWS Lambda, DynamoDB, SQS, and EventBridge.

Tools

I used Xcode to build it, but any editor that supports the SourceKit-LSP will work - including VS Code, Neovim, Emacs, Nova, and others.

The deployment engine that makes this project go is Swift Cloud. It's the infrastructure as code tool I use to deploy my Swift package to AWS with the configuration I define. Specifically, Swift Cloud vends Swift components like AWS.Function() that get compiled into Pulumi YAML files. The Pulumi CLI deploys that configuration to the cloud when you run Swift Cloud's swift run Infra deploy command. Notably, you don't need to know anything about Pulumi to use Swift Cloud. It's just used internally.

I've used other IaC tools like the Serverless Framework and SST. They are great, but they either don't support custom runtimes like the swift-aws-lambda-runtime at all, or require the use of Lambda Layers to use them. Swift Cloud supports it out of the box with no hassle. It's been great to work with.

Infrastructure

The project currently consists of six primary pieces of infrastructure, all of which are defined within Sources/Infra/Project.swift:

A cron job managed by EventBridge that triggers my scheduler function
A scheduler Lambda function that fires off SQS events every 10 seconds
An SQS queue to hold those events
A poller Lambda function triggered by SQS that polls the ncaa-api for Tulsa football, men's basketball, and women's basketball scores, and the public-espn-api for Eagles scores. It writes those results to DynamoDB
A DynamoDB table that keeps track of the games found in the previous step
A processor Lambda function triggered by DynamoDB Streams that checks the scores for those teams I care about, and if they scored (football only) or won, make my Philips Hue lights go nuts in that team's colors

The basic data flow looks like this:

It also consists of two other pieces of infrastructure used to refresh my Hue API tokens every three days:

A cron job managed by EventBridge that triggers my token refresher function
A token refresher Lambda function that refreshes my Hue API tokens

Project Configuration

I won't go through the code in too much depth. You can look through all of it yourself on GitHub. But I will cover the key elements.

Package.swift

First, you have to create a new Swift package. Since I used Xcode as my editor, I did this from Xcode by navigating to File -> New -> Package, chose macOS as the platform, and chose Executable as the package type. Alternatively, you can do it via the CLI by running swift package init --name MySwiftPackage --type executable.

Once your package is created, you need at minimum a single .executableTarget which will point to the file containing your infrastructure definitions, plus the Swift Cloud dependency.

At its most basic, that looks like this:

import PackageDescription\n\nlet package = Package(\n\tname: "MySwiftPackage",\n\tdependencies: [\n\t\t.package(url: "https://github.com/swift-cloud/swift-cloud.git", branch: "main"),\n\t],\n\ttargets: [\n\t\t.executableTarget(\n\t\t\tname: "Infra",\n\t\t\tdependencies: [\n\t\t\t\t.product(name: "Cloud", package: "swift-cloud")\n\t\t\t]\n\t\t)\n\t]\n)\n

I called my target Infra, as that was the default name Swift Cloud suggested, but you can call it whatever you'd like.

Once you have that set up, you need to create a folder called Sources, a folder inside Sources named whatever you named your .executableTarget above, and then a Swift file named whatever you want - I used Project.swift.

Project.swift

Project.swift is where you define your infrastructure. I housed all six of the pieces of infrastructure I needed within this one file, but nothing is stopping you from breaking this up into multiple files and configuring it however you'd like.

This file is where you configure the resource primitives you want to use, like functions, databases, queues, and more.

Swift Cloud provides these components for you across a variety of cloud providers. AWS is my cloud of choice, though they also offer providers for Cloudflare, Digital Ocean, Fastly, and Vercel.

I mentioned I use EventBridge for cron jobs, Lambda for processing, SQS as a queue system, and DynamoDB for data storage. In Swift Cloud, configuring those is as simple as this:

let pollerCron = AWS.Cron(\n\t"sports-api-cron-job",\n\tschedule: .rate(.minutes(1))\n)\n\nlet sportsApiScheduler = AWS.Function(\n\t"sports-api-scheduler",\n\ttargetName: "Scheduler"\n)\n\nlet sportsApiPollerQueue = AWS.Queue("sports-api-poller-queue")\n\nlet scoresTable = AWS.DynamoDB(\n\t"Scores",\n\tprimaryIndex: .init(\n\t\tpartitionKey: ("gameId", .string)\n\t),\n\tstreaming: .enabled(viewType: .newAndOldImages)\n)\n

Permissions are automatically created and managed for you when you link two resources together via methods on the resources themselves, like this:

 pollerCron.invoke(sportsApiScheduler)\n sportsApiScheduler.link(sportsApiPollerQueue)\n sportsApiPollerQueue.subscribe(sportsApiPoller)\n scoresTable.subscribe(scoreProcessor)\n

You can also create custom permissions yourself via the Link struct provided by Swift Cloud, which takes in a standard array of IAM permissions and resources to give extra access where needed.

More details on all of those in Project.swift in the GitHub repo.

Targets

Each Lambda function I have gets its own .executableTarget in Package.swift, an associated folder inside Sources, and an executable Swift file within that folder called main.swift. You provide the dependencies those functions need inside Package.swift, then import them inside the Swift file itself.

Note: the executable Swift file must be called main.swift so it can execute top-level calls like try await runtime.run().

For example, my ScoreProcessor Lambda function is provided as an executable target that depends on some of my code and four third-party dependencies. The executable target for it looks like this:

.executableTarget(\n\tname: "ScoreProcessor",\n\tdependencies: [\n\t\t"Models",\n\t\t"SSMUtils",\n\t\t.product(name: "AWSLambdaRuntime", package: "swift-aws-lambda-runtime"),\n\t\t.product(name: "AWSLambdaEvents", package: "swift-aws-lambda-events"),\n\t\t.product(name: "AWSSSM", package: "aws-sdk-swift"),\n\t\t.product(name: "AsyncHTTPClient", package: "async-http-client")\n\t]\n)\n

The "Models" and "SSMUtils" dependencies are each code I wrote. The four others that begin with .product(name:) are third-party dependencies that must be defined in your top-level dependencies array within Package.swift.

Swift on Lambda

Enough configuration talk. Let's look at some actual Swift code that runs on Lambda.

Each of the main.swift files have server-side Swift code we could discuss, but ScoreProcessor.swift is an especially useful file to look at as it touches a lot of key Swift on Lambda concepts including event parsing, API requests, interacting with other AWS services, and more.

At a high level, this function is triggered when new data is written to my Scores table in DynamoDB. It parses the DynamoDB event into my own GameInfo Swift struct, which I can then act on in a type-safe way.

The top level code for ScoreProcessor.swift looks like this:

let runtime = LambdaRuntime { (event: DynamoDBEvent, context: LambdaContext) async throws -> Bool in\n\tcontext.logger.info("Received DynamoDB event: \\(event)")\n\n\tfor event in event.records {\n\t\tguard let gameInfo: GameInfo = parseDynamoEventIntoGameItem(event: event, context: context) else { continue }\n\n\t\tif isFootballGame(game: gameInfo.currentGame) {\n\t\t\tif myTeamScored(gameInfo) {\n\t\t\t\ttry await flashLightsAppropriateColors(gameInfo: gameInfo, context: context)\n\t\t\t}\n\t\t}\n\n\t\tif myTeamWon(gameInfo) {\n\t\t\ttry await flashLightsAppropriateColors(gameInfo: gameInfo, context: context)\n\t\t}\n\t}\n\n\treturn true\n}\n\ntry await runtime.run()\n

Let's talk about the five key interactions that happen within that abstracted code:

Using the Swift AWS Lambda runtime
Event parsing
API PUT requests
Swift Concurrency
Interacting with other AWS services

\n
\n\n

First, using the Swift AWS Lambda Runtime.

The Swift AWS Lambda Runtime is defined as "an implementation of the AWS Lambda Runtime API and uses an embedded asynchronous HTTP Client based on SwiftNIO that is fine-tuned for performance in the AWS Runtime context." More on that asynchronous HTTP Client in a bit.

The runtime runs a Lambda function's handler method when the function is invoked. It starts with let runtime = LambdaRuntime { }, and all of your code is included in those brackets. This is how you configure reacting to certain Lambda events and access information from Lambda's context object like the function ARN, the log group it will write logs to, the function's memory limit, and more.

Lambda executes your code inside its run loop when you call try await runtime.run(). Reminder: you can see all of this with more context in the code block above.

\n
\n\n

Now that we have code Lambda can execute, let's discuss event parsing.

This happens within the parseDynamoEventIntoGameItem() function.

We can use Swift's guard case pattern matching to safely extract values from the DynamoDB records (newImage and oldImage) like this:

guard case .string(let gameId) = newImage["gameId"],\n\t  case .string(let sport) = newImage["sport"],\n\t  case .string(let myTeam) = newImage["myTeam"],\n\t  case .number(let myTeamScore) = newImage["myTeamScore"],\n\t  case .number(let previousMyTeamScore) = oldImage["myTeamScore"],\n\t  case .string(let opposingTeam) = newImage["opposingTeam"],\n\t  case .number(let opposingTeamScore) = newImage["opposingTeamScore"],\n\t  case .string(let previousGamePeriod) = oldImage["gamePeriod"],\n\t  case .string(let gamePeriod) = newImage["gamePeriod"] else {\n\tcontext.logger.error("Missing or invalid attributes in DynamoDB record")\n\treturn nil\n}\n

Swift's pattern matching here makes event parsing pretty straightforward.

Numbers are sent across the network to/from DynamoDB as strings, so we still have to convert the number values to Int via Int(myTeamScore), but once you have those it's easy to take the values and store them in your own Swift struct or similar - which is what I do with my GameItem and GameInfo structs.

\n
\n\n

Next, API PUT requests.

Once I have my GameItem and GameInfo structs, I know whether my team scored, if the game is over, and whether my team won. Given that information, I need to make my Philips Hue light bulbs flash different colors. To do that from a cloud environment, you need to use Philips Hue's Remote API, which is a somewhat involved process that is not well documented. I found this guide very helpful. I left a comment on it fixing one bit which was outdated.

For iOS apps, we'd reach for URLSession to make our API requests. But because URLSession relies on Apple platforms, and Lambda runs a variant of Linux, we have to use something else to make our API requests. The preferred mechanism is async-http-client from swift-server. It's built on top of SwiftNIO, Apple's asynchronous network application framework.

To make a PUT request with async-http-client, you need to create the request with the HTTPClientRequest struct, define the HTTP method, add any necessary headers, add the request body, and execute the request with await HTTPClient.shared.execute(request).

In my project, that looks like this:

let hueBody = buildHueBody(for: color)\nlet url = "https://api.meethue.com/bridge/\\(hueUsername)/lights/\\(lightNumber)/state"\n\nvar request = HTTPClientRequest(url: url)\nrequest.method = .PUT\nrequest.headers.add(name: "Content-Type", value: "application/json; charset=utf-8")\nrequest.headers.add(name: "Authorization", value: "Bearer \\(hueAccessToken)")\n\ndo {\n\tlet jsonData = try JSONSerialization.data(withJSONObject: hueBody)\n\tvar buffer = ByteBuffer()\n\tbuffer.writeBytes(jsonData)\n\trequest.body = .bytes(buffer)\n\n\tlet response = try await HTTPClient.shared.execute(request, timeout: .seconds(30))\n} catch {\n\tcontext.logger.error("Error updating light \\(lightNumber): \\(error)")\n}\n

When adding the request body, you'll notice that I created something called a ByteBuffer. That's a struct from SwiftNIO defined as something that "stores contiguously allocated raw bytes. It is a random and sequential accessible sequence of zero or more bytes (octets)". Whew. Let's break that down briefly.

The jsonData we serialize our hueBody into is of type Data, which is raw binary data. We need to write that binary data to a buffer before we can attach it to our request body. That's what ByteBuffer does for us here. It takes our binary data and writes it to a buffer which we can then use as the request body and send over the network.

\n
\n\n

Hue's API unfortunately only allows for controlling one light at a time, and this is where Swift Concurrency comes in. Using TaskGroup or async let, we can easily and safely fire off multiple API requests in parallel (one for each light we need to control) and wait for them all to complete before returning from our Lambda.

While the async let syntax is simpler for sure, I used TaskGroup for this. I find TaskGroup's behavior more predictable. That's just personal preference.

\n
\n\n

Finally, the eagle-eyed among you may have noticed there was a hueUsername and a hueAccessToken used in the API request code above. Those are parameters stored securely within AWS's Parameter Store. What does it look like to get those out of the Parameter Store at runtime? This is a good example of interacting with other AWS services.

To get my Hue API access token out of the param store, I wrote a utility function called getSSMParameterValue.

That function depends on the AWSSSM library from aws-sdk-swift and gets the parameter specified like this:

func getSSMParameterValue(parameterName: String, context: LambdaContext) async throws -> String? {\n\tlet config = try await SSMClient.SSMClientConfiguration(region: "us-east-1")\n\tlet ssmClient = SSMClient(config: config)\n\tlet input = GetParameterInput(name: parameterName)\n\n\tdo {\n\t\tlet response = try await ssmClient.getParameter(input: input)\n\t\tguard let parameterValue = response.parameter?.value else {\n\t\t\tcontext.logger.error("Parameter value for \\(input.name ?? "nil") is nil")\n\t\t\treturn nil\n\t\t}\n\n\t\tcontext.logger.info("Retrieved parameter value: \\(parameterValue)")\n\t\treturn parameterValue\n\t} catch {\n\t\tcontext.logger.error("Error fetching parameter \\(parameterName): \\(error)")\n\t\treturn nil\n\t}\n}\n

I can then call that function for the parameter I need as follows: let hueAccessToken = try await getSSMParameterValue(parameterName: "hue-access-token", context: context)

Once I have my Hue access token and Hue Remote API username, I can interact with the Hue Remote API however I'd like and have it control my lights here at home.

Code Wrap-up

At this point, we've covered most of the core concepts you need to wrap your head around how this project works and why it's set up the way it is. It works well, the code is pretty straightforward, it deploys to and can be removed from AWS with a single command, and it's easy to maintain. Let's move on from the nitty-gritty and into some different areas. Specifically cost and performance.

Cost

I've had this system running 24/7 since the end of January. Every ten seconds, it polls two different APIs to check score updates for my favorite teams. If it finds scores for my teams, it writes those scores to DynamoDB, which triggers my ScoreProcessor function to flash my lights accordingly.

The core system requires an EventBridge cron job that schedules SQS messages, an SQS queue that triggers my poller function every 10 seconds, a DynamoDB table to hold the scores the poller function retrieves, and a processor function that runs if scores change.

All of that code and the infrastructure running it costs less than 20 cents per month to run on AWS. Essentially all of the cost is from DynamoDB, which I could be smarter about to save money if I cared about 20 cents per month.

Further, because this is fully serverless, it will scale to zero for a large chunk of the year. The first step of my job scheduler function is to check whether it's currently football or basketball season, and, if it's not, return immediately and don't trigger the rest of the flow. At that point, the system will automatically scale down to $0/month without me doing anything whatsoever.

The beauty of serverless!

Performance

To evaluate performance, let's look at both my API poller function which runs every 10 seconds, and my score processor which is triggered much less often - it only runs if there is a change to one of my favorite teams' scores. Both of these functions call other APIs, so their total run time is dependent on the response times of those APIs as well.

I don't have any broader monitoring set up for this project, but CloudWatch does provide cold start times via the "Report" section of each invocation. We'll default to looking at the three most recent log streams for each function and average out both the total durations and cold start times of each.

Each log stream contains one cold start (its first invocation), and then each subsequent invocation inside the stream is from an already-warm container - so there are no cold starts after the first invocation in every log stream. Therefore, we'll look at the duration and cold starts of just the first invocation of each log stream, which theoretically should have the worst performance of any of the invocations in the stream.

API poller function:

Duration 649.85 ms, cold start 194.40 ms
Duration 713.07 ms, cold start 197.26 ms
Duration 766.10 ms, cold start 204.21 ms

Average run duration: 709.67 ms

Average cold start time: 198.62 ms

Most of the run duration here is waiting to hear back from the ncaa-api and the public-espn-api. The processing time once we get that data is negligible.

And look at the sub-200 ms cold start time! This is in a Lambda function that imports five large third-party dependencies, Apple's Foundation library, and two of my own dependencies. The unzipped executable it produces is 143.7 MB. Hitting under 200 ms to warm up a code package that large is noteworthy.

Score processor function:

Duration 14496.34 ms (lights were triggered), cold start 192.10 ms
Duration 28.98 ms (no light trigger), cold start 204.72 ms
Duration 36.15 ms (no light trigger), cold start 208.71 ms

Average run duration: 4853.82 ms

Average cold start time: 201.84 ms

The average run duration here is massively skewed by the first invocation, which triggered the flow that makes my lights go crazy. When that happens, my lights change colors 13 times with half-second delays after each change. Because Hue only supports changing one light per API request I have to make 4 API requests in parallel for each of those 13 color change requests so it can change all four of the lamps in the room I care about. Waiting for all of that to complete is what causes the long run time.

There's a similar story on the cold start times here. Just above 200 ms on average for an unzipped executable that comes in at 154.5 MB due to five more large third-party dependencies, Apple's Foundation library, and some more of my code.

Let me reiterate that those cold starts hardly ever come into play. Most invocations don't have any cold start period, as Lambda reuses already-warmed containers very often. The speeds reported here are the worst-case speeds when a fresh Lambda container needs to be spun up, the code loaded into memory, etc.

Given that I haven't done any work at all to try and slim things down, I'm quite happy with 200 ms cold starts in these cases. This is just from the raw code I'm deploying to Lambda from Swift Cloud with no real consideration for optimization or efficiency. Not bad.

Source Code

And that about covers it! The full repository, including everything discussed in this post and much more, is on GitHub.

Here's the raw URL: https://github.com/r-token/sports-home-automation-swift

If you've gotten something out of this post, please give the repo a star!

Shout-Out to Andrew from Swift Cloud

I want to take a moment and give a huge shout-out to Andrew Barba. He created and maintains Swift Cloud, and provided a ton of help in the Swift Cloud Slack while I was working on this project.

It's a fantastic tool, and Andrew was quick to respond to feedback and gave help when I needed it. If you're interested in running Swift on AWS, I'd start with Swift Cloud.

Thank You

If you made it this far, thank you for reading! I know it was a long one.

I had such a blast creating this project and writing this post. It combines two of my favorite things: serverless back-end systems and the Swift programming language.

I love talking about this stuff. If you want to chat, feel free to reach out over email, Bluesky, Mastodon, X, or LinkedIn.

And if you particularly enjoyed this post, you can buy me a coffee!

\n \n\t $\"Buy$ \n \n

"}},{"meta":{"title":"CatchUp v3","description":"Revisiting my first iOS app with new features and a fresh UI.","date":"2024-04-03T00:00:00.000Z","imagePath":"/blog-images/catchup-v3/catchup-icon.png","imageAlt":"CatchUp v3","tags":["iOS","swiftui","swiftdata"]},"path":"/blog/catchup-v3","postContent":{"html":"

I first launched CatchUp - Keep in Touch for iOS in May 2018. It was the first app I'd ever released and it was, from a code perspective, objectively pretty bad.

It's now April of 2024 and somehow, despite years of neglect while building three other apps, CatchUp still does relatively well on the App Store.

CatchUp is like a first child for me. It marked the beginning of a journey that has shaped my life and career. I still love and use the app weekly. It still helps me stay in touch with those that matter most.

However, due to the aforementioned neglect, it has had obvious bugs and missing features for quite a while. That all changes with CatchUp v3, out today.

CatchUp v3

CatchUp v3 is a significant improvement across every corner of the app. The core functionality remains - you can still add your contacts and set recurring reminders to CatchUp with people - but everything around it has changed.

First, there's a new auto-updating grid of your next CatchUps. I've found this helpful as I plan my week and get a feel for who I should remember to get in touch with. It looks like this:

I've also revamped the contact detail screen's design and removed the “Notification Preference” pop-up sheet entirely. Setting your notification preference for a contact now lives fully within the contact detail screen. There's no "Save" step anymore either. The app auto-saves your notification preference every time you change it.

That new contact detail screen looks like this:

All controls for this contact now live inside this single screen. Additionally, there's a nice new "Next CatchUp" row, which shows the next time you'll get a notification to CatchUp with this person.

Longstanding Feature Requests

Those are the primary UI improvements, though there are several more UI tweaks here and there that you might notice.

The rest of v3's changes address longstanding feature requests. For example:

There are now orange unread indicators on the contact rows if it's time to CatchUp with them
Pulling down on the home screen fetches the latest contact picture and information for all of your selected contacts
- Previously you had to delete and re-add the contact to update their information
\n
There is now automatic cloud syncing, so your contacts and notification preferences stay up-to-date across iPhone, iPad, and Mac
- This involved a fun migration to SwiftData, which dramatically simplified my local storage code
\n

Still Free with No Ads

CatchUp is, and always will be, completely free with no ads. The tiny bits of money I make from this app come from the in-app Tip Jar. This is a passion project that I genuinely find helpful in my day-to-day life. I do not, nor do I have any incentive to, store your data on my servers or use your data in any way.

I hope that you use the app and find it valuable. If you do, please consider supporting development by leaving a tip in the app. I really do find that motivating. Alternatively, you can buy me a coffee!

\n\t\n\t\t $\"Buy$ \n\t\n

\n\n

Download

Thank you for reading, and thank you for your interest in CatchUp - Keep in Touch. Feel free to reach out via email with any questions or comments.

CatchUp v3 is available on iOS, iPadOS, and macOS. It requires iOS 17. You can download it on the App Store today:\n $\"Download$

\n"}},{"meta":{"title":"Hot Local Food for iOS","description":"It's like Tinder, but for food, and it already likes you back.","date":"2023-01-26T00:00:00.000Z","imagePath":"/blog-images/hot-local-food/hlf-icon-square.png","imageAlt":"Hot Local Food App Icon for iOS","tags":["iOS","swift","swiftui"]},"path":"/blog/hot-local-food","postContent":{"html":"

Think Tinder, but for food, and it already likes you back. Say hello to Hot Local Food. Free, hot, and available on iOS 15 and newer.

Find love, then eat it

Want something to eat or drink but don't know where to go? Want to explore the local scene nearby or far away? Just want to look at some good pictures of good food? Hot Local Food is there for you.

With a photo-heavy, Tinder-style swipe interface, an extensive library of restaurants powered by Yelp, and slick features built on top, Hot Local Food will help you find exactly what you need.

Features:

High-quality photos of each location (powered by Yelp)
Filter places by category, price, and location
Save places for later by adding them to a custom list
Quick shortcuts to make reservations (OpenTable), order delivery or pickup (DoorDash and Uber Eats), and find directions (Apple Maps)
Easy access to information about the place, including its phone number, address, hours, and whether or not it's currently open

Personally, I've gotten the most use out of the location filter.

It's a simple map for v1.0 of the app, and will likely be expanded upon, but the ability to pan around the map to see what's available in places I'm interested in has been invaluable.

My wife and I recently moved to Denver. Before moving we used the app to check out fun bars and restaurants close to where we would be living and in the surrounding areas. It was a fun exercise and we've repeated it when getting ready to travel for weddings, vacations, and other trips. We also often use it on an average weekday when we want to go out somewhere.

Building this app has been a labor of love by me and a good friend – Carter Krafft. Carter has been the driver behind the idea and the overall concept, while I've done the implementation work and taken some creative liberties with the design. It has been a blast to build, and we hope you get as much out of it as we have.

Technical notes and privacy:

100% of Hot Local Food is written in Swift and SwiftUI
I do not store any of your data on my servers
I do use iCloud to sync your saved Lists and swipes data between iOS devices
The free version of the app uses Google AdMob, which collects some very basic data - you can pay to remove the ads

$\"Download$

Personal Notes

If you're still here, hello there! This is just a bit more background on how the app came to be.

As is tradition, after launching Outrank for iOS in October of 2021, I moved away from iOS development for a while. This is not new behavior for me. I try to stay active in three areas of software development: iOS, front-end web, and back-end web; but I can only focus on two at a time. I'm always active in back-end web because that's what I focus on for work, but then I have to choose which one to spend my free time on: front-end web or iOS. So, naturally, once Outrank for iOS was out and stable, it was time to re-up my front-end skills. That led to rewriting my website in SvelteKit (and also Nuxt 3?).

But iOS came calling again, as it always does. This time in the form of one of my very good friends. Carter and I went to college together and still frequently bounce ideas off one another. One of those ideas was a "Tinder for food" app. The initial idea came at a bar over three years ago when Carter and I, as well as another one of our friends (Matt Rechtien), were talking about app ideas.

Three years, two app icons, one pandemic, and multiple starts and stops later - we have our app. It's all SwiftUI, it's clean and straightforward, it's not (currently) expensive to run, and it's ready for the world. I'm so excited about it.

We'd love it if you tried it out. If you do, and you have feedback - positive or negative - we'd be honored to hear from you. Please email us.

$\"Download$

\n"}},{"meta":{"title":"Nuxt 3 vs SvelteKit","description":"Choosing between Nuxt 3 and SvelteKit for ryantoken.com v3.","date":"2022-10-24T00:00:00.000Z","imagePath":"/blog-images/nuxt-3-vs-sveltekit/cover.png","imageAlt":"Nuxt 3 logo vs the SvelteKit logo","tags":["web","jamstack","rewrite"]},"path":"/blog/nuxt-3-vs-sveltekit","postContent":{"html":"

Rebuilding ryantoken.com

I've been thinking for several months about rebuilding my website (again). There were several reasons. First, to dig back into front-end work and re-familiarize myself with that world. Next, to get up to speed with the latest JavaScript framework options and how they worked. And finally, my previous website was no longer cutting it for me in several different ways.

For reference, here's what my website looked like before:

I built that version of the site with Swift and Publish - a static site generator for Swift. While a great tool, I needed something more flexible that better aligned with how I feel about web development today. Thus, the rewrite project began.

The Debate

The primary debate was about which framework I was going to use. After some thought, I landed on two options. Option one was Nuxt 3: a Vue framework we use at Storyboard. Option two was SvelteKit: a new framework I originally heard about due to Scott Tolinski frequently singing its praises on the Syntax podcast. I come from a React background, so regardless of my choice it was going to be quite new conceptually and syntactically.

Additionally, Nuxt 3 and SvelteKit are both meta-frameworks. Nuxt is a meta-framework for Vue, and SvelteKit is a meta-framework for Svelte. This means that they're frameworks that provide abstractions on top of other frameworks - primarily to handle the boring/routine stuff for you. Think wiring up page routes, sharing common layouts between pages, handling smooth page transitions, etc. They also generally come with best practices built in like build optimizations, link prefetching, and more. I did have some experience with meta-frameworks like Gatsby, but not much. And while most of this post will compare the meta-frameworks of Nuxt 3 and SvelteKit, we'll also get into some of the differences between the core Vue and Svelte frameworks.

Let me preface the rest of this post by emphasizing that I am not a front-end expert. My full-time job is primarily in serverless back-end development with node.js. On top of that, most of the front-end framework experience I do have is in React. I've played around with Vue before but was completely new to Nuxt, Svelte, and SvelteKit. Because of this, I'm certain I will get some front-end terminology or facts wrong. Please email me with corrections or clarifications if you have them.

Ok, on to the main event.

Both Nuxt 3 and SvelteKit offer some similar features out of the box, including:

Filesystem-based routing
Route prerendering
Link prefetching
Fully static and server-side rendering options
Single-file components
Easy integration with Tailwind, which I knew I wanted to try for this rewrite

I first decided to do the rewrite with Nuxt 3. As mentioned, we use Vue and Nuxt at my place of work and I wanted to get my hands dirty with how it actually works. Again, I currently spend most of my time doing back-end development.

However, Nuxt 3 has now been in Release Candidate mode since April of 2022 (about 6 months at time of writing). It still isn't done and is missing some key features for me to be fully satisfied with it. After waiting long enough for Nuxt 3 to be fully released, I decided I would also rewrite my website with Svelte and SvelteKit.

Both of these rewrites have been more-or-less completed and live at different URLs.

Before spoiling which one I chose, let's get into my experience with each:

Nuxt 3

Nuxt 3 is a brand-new framework. It doesn't have a 1.0 release yet and I'm still waiting on several key features to be released. Primarily Nuxt Image support for static sites or sites hosted on Netlify or Vercel, and Nuxt Content support for static sites.

Neither of those issues are complete dealbreakers though. I can 1) not use Nuxt Image, and 2) go with server-side rendering for now instead of a fully static site. That works around both of those issues for the time being.

Developer Experience

Despite those hurdles, I've sincerely enjoyed the developer experience of building with Nuxt 3 and Vue 3.

Things like this from Nuxt 2:

\n

Turn into this with Nuxt 3:

\n

So much nicer. Additionally, one of the primary reasons I wanted to use Nuxt 3 was to take advantage of the Nuxt Content rewrite - which is their content engine and what I use to generate the blog.

My website is not a complicated one. It's primarily just a bunch of static pages that include text and images. The only relatively complex parts are the responsive sidebar and the blog. The sidebar could be solved once and considered "done" - it's not something I should need to revisit often.

The blog, though, needs to be as simple as possible to maintain and update over time. If blog posts are hard to write, or, once written, hard to connect to the rest of the site, that puts up a large mental roadblock for me to continue writing.

The Blog - Nuxt and Nuxt Content

Nuxt 3 and Nuxt Content solve the blog problem. All you need to do is create a /content directory at the root of the project, a /blog directory within that, and a new folder for each blog post. You can then write blog posts in standard markdown and include Vue components within that markdown via MDC syntax. Nuxt will automatically configure the routing for you. For example, an index.md markdown file within /content/blog/fancy-blog-post will be accessible at https://your-website.com/blog/fancy-blog-post. Pretty sweet!

MDC Syntax

I did find the MDC syntax a bit annoying, though. Again, this is the syntax used to include Vue components in the markdown itself. For instance, I have a custom Vue component for showing a responsive/resizable image. To include that in a blog post with Nuxt Content and MDC, it looks like this:

::ResizableBlogImage{src="/path/to-image.png" altText="Some alt text"}\n::\n

The double-colon syntax felt weird to me. Maybe that's common in parts of Vue that I'm not familiar with, but it's much different from how you use components in standard Vue files.

The previous example was for a "block" component, something that isn't inlined with the rest of the markdown. You can also use Vue components inline via MDC, but I ran into another oddity there. If I wanted punctuation immediately after the inline component, it broke! The MDC syntax itself would render in the blog post instead of the actual component.

The only way I found to get around this was to include the punctuation within the component's props, like so:

:ExternalBlogLink{url="https://url-to-go-to.com" text="The text to style with a period at the end."}\n

This component in particular styled the URL a certain way though, so it would also style the ending period that way. Not ideal. That's how it works in the Nuxt version of the site today. If this issue has since been fixed, please let me know!

Edit: @manutopik informed me on Twitter that "standard" component syntax works as well! So this is also appropriate MDC syntax:

\n

Look at that! So straightforward. You use it just like every other Svelte component in any other Svelte file.

And it's the same for inline components. No weird asterisks around how to handle punctuation or special symbols immediately after you use the component. It just works.

Other - SvelteKit

I've already discussed most of the primary benefits I found when using Svelte and SvelteKit, as well as discussed how I implemented the blog in this version of the site. But several other SvelteKit niceties deserve a callout before moving on:

Like Nuxt 3, the developer experience was great and the development feedback loop was extremely fast. SvelteKit also uses Vite but comes bundled with a Svelte plugin for Vite and Hot Module Replacement (HMR) to reflect changes to your code in the browser immediately.
\n
Svelte itself was surprisingly easy to learn. I mentioned the tutorial already, but it really is very simple to get a hang of while you work through that. It's a clean and simple framework.
\n
Due to its smaller size, no virtual DOM, optimizing at build-time rather than run-time, and no need for extra state management code, Svelte is arguably the fastest JavaScript framework on the market today
\n

Comparing Nuxt 3 and SvelteKit

Ok, enough on my experience with each. Let's get into some hands-on comparisons between how they performed when actually building this website. I'll start with a couple of component comparisons before getting into total page sizes, load speeds, and total lines of code.

Component Comparisons

Topbar Component

A good first component to look at for comparison's sake is the Topbar component. The Topbar only appears on small screens/mobile phones, but it interacts with the Sidebar in an interesting way.

When you tap the sidebar icon, it needs to send some kind of notification to the Sidebar component to let it know that it should open/close itself.

Here's what the Topbar looks like:

Here's a simplified implementation of the Topbar component in Vue 3:

Topbar.vue

\n\n\n    </button>\n\n    \n  </button>\n\n  <a href="/" on:click={updateSelectedPage}>Ryan Token</a>\n</div>\n

The Topbar component and the Sidebar component are rendered at the same level in the component hierarchy - one is not a child of the other. However, the Sidebar needs to react to changes in the Topbar's state. As mentioned, when a user taps the "toggle sidebar" icon in the Topbar, it should open/close the Sidebar.

For reference, here's a simplified version of the parent component that renders both the Sidebar and the Topbar:

\n\n<div>\n  \n  <div>\n    \n    <main>\n      <slot />\n    </main>\n  </div>\n</div>\n

A change in the Topbar's sidebarOpen state needs to be bubbled up to its parent component, then forwarded on to the Sidebar component so the Sidebar knows whether it should open itself, close itself, or do nothing.

Props are typically sent from a parent component to a child component. Sending prop data changes back up the hierarchy from a child to a parent is always more complicated. Vue and Svelte both have ways of handling this, but they do it very differently.

Vue uses the concept of emits to send messages from a child to its parent.

Svelte uses two-way data bindings instead. In the parent component, I can pass the value of the Topbar's open prop to the Sidebar with the bind keyword like so: ``

Personally, I found Svelte's approach to be more straightforward than needing to emit an event and then set up an event listener that reacts to that. Neither approach was overly complex, but Svelte's felt more natural to me.

BlogPreview Component

Let's look at one more component comparison before moving on.

The BlogPreview component is the responsive card that shows each blog post's primary image, title, description, publish date, and tags. Here's how it looks:

Here's a simplified implementation of it in Vue 3:

\n\n<template>\n  <div>\n    <div @click="navigate(slug)">\n      <div>\n        <div>\n          <img :src="image" :alt="imageAlt" />\n        </div>\n\n        <div>\n          <p>{{ title }}</p>\n          <p>{{ description }}</p>\n          <p>{{ formattedDate }}</p>\n          <div>\n            <div v-for="tag in tags" :key="tag">\n              \n      </div>\n\n      <div>\n        <p>{ title }</p>\n        <p>{ description }</p>\n        <p>{ formattedDate() }</p>\n        <div>\n          {#each tags as tag (tag)}\n            <div>\n              <a href="/blog/tags/{tag}">\n                { tag }\n              </a>\n            </div>\n          {/each}\n        </div>\n      </div>\n    </div>\n  </div>\n</div>\n

The main difference to outline here is how each framework handles a for-each loop within the HTML. For this component, we want to loop through an array of tags. For each tag in the array, we need to render out the name of the tag and a link to it.

Vue 3 (what Nuxt uses) does this with the v-for directive.

Svelte uses an #each block around the div that should be repeated.

Both are relatively nice and concise. I don't have a strong preference between the two here. However, the Svelte component is 13 lines shorter than its Vue counterpart.

MDC vs mdsvex

I mentioned my preference for Svelte's mdsvex to Nuxt's MDC syntax earlier, but I want to give a side-by-side comparison here so it's easier to understand why. Again, these are the libraries that allow you to use Vue or Svelte components within Markdown.

Here's how you use a block component, like a resizable image, with Vue and MDC:

::ResizableBlogImage{src="/path/to-image.png" altText="Some alt text"}\n::\n

And here's how you do the same thing with Svelte and mdsvex:

\n

Again, neither are bad, but one of them makes more sense and is more concise. And that, to me, is the Svelte solution.

Page Size Comparisons

So we've talked now for a while about conceptual differences, syntactic differences, and developer experience differences between the frameworks, but what about real-world speed and size comparisons?

Let's start with size.

To gauge a page's size, I'm using Chrome's standard Developer Tools and the Network tab. Doing a hard refresh of the home page of my site, I see the following:

Nuxt 3 site:

45 requests
942 kB transferred
2.0 MB resources

SvelteKit site:

37 requests
627 kB transferred
1.6 MB resources

The SvelteKit site is smaller in every way despite being a nearly identical website. Plus one for SvelteKit.

Additionally, Svelte, as its name implies, is simply a small framework. This is primarily because there's no virtual DOM or extra state management libraries that Svelte needs to deal with. This results in a framework that's smaller in overall size and has less JavaScript bloat.

The size difference between the two pages also lends itself to our next point of comparison: speed.

Page Speed Comparisons

Speed is harder to measure reliably. While the Network tab was consistent and reliable for calculating page size, it showed a significant variance in page load speed on every refresh for both versions of the site.

To try to put some more concrete numbers around this, we'll defer to Google's PageSpeed Insights.

Note: I have not yet put serious time into optimizing either site for increased performance metrics aside from compressing images.

Nuxt 3 site - mobile

Nuxt 3 site - desktop

SvelteKit site - mobile

SvelteKit site - desktop

Some interesting takeaways there. First, they both scored perfect 100s on desktop. Again, I have put almost no time into deeper page optimizations. All I've actively done is compressed the image files throughout the site so they're smaller and quicker to load. To get perfect 100s on desktop effectively out of the box with both of these frameworks is impressive.

There's a bigger difference in how they scored for mobile. The Nuxt site performed moderately worse in every metric on mobile than the SvelteKit site. The primary performance drag for both sites was the Apple Podcasts embedded player I include on the home page. PageSpeed Insights complained about that player being slow to load every time. Given that it's 1) lazily loaded, and 2) at the bottom of the page so you typically need to scroll to see it, I'm not too worried about it.

There were minor differences every time I ran the PageSpeed Insights process on each site. They were relatively consistent each time though, so I think it's a fair comparison.

Total Lines of Code

Before we wrap up, I wanted to share a quick note on total lines of code for each project.

Total lines of code (counted with cloc):

Nuxt 3 site: 27,939 total lines of code

-------------------------------------------------------------------------------\nLanguage                     files          blank        comment           code\n-------------------------------------------------------------------------------\nJSON                             8              0              0          26092\nVuejs Component                 26            222             59            842\nMarkdown                        11            500              0            767\nJavaScript                       3             17              0             75\nYAML                             1              9              0             69\nTypeScript                       3              9              3             61\nCSS                              1              3              0             21\nTOML                             1              2              0             10\nText                             1              0              0              2\n-------------------------------------------------------------------------------\nSUM:                            55            762             62          27939\n-------------------------------------------------------------------------------\n

SvelteKit site: 8,439 total lines of code

-------------------------------------------------------------------------------\nLanguage                     files          blank        comment           code\n-------------------------------------------------------------------------------\nJSON                             4              0              0           6463\nSvelte                          21            265              3           1001\nMarkdown                        10            452              0            656\nJavaScript                      14             29              3            188\nCSS                              2             21              8            119\nHTML                             1              0              0             12\n-------------------------------------------------------------------------------\nSUM:                            52            767             14           8439\n-------------------------------------------------------------------------------\n

A monstrous difference. 27,939 lines of code for the Nuxt 3 project, and only 8,439 for the SvelteKit project.

The major difference here is the amount of JSON. I'm not writing much JSON myself for this website - nearly all of that is coming from the package-lock.json file that manages dependency versions. This means that the Nuxt 3 version has a lot more internal dependencies than the SvelteKit version.

Doing an npm install from the root of each project reveals that the Nuxt 3 site is using 961 individual packages, while the SvelteKit site is using just 302. That is significant.

The amount of actual code you write as a developer is relatively similar for each, but SvelteKit having 1/3 of the overhead when compared to Nuxt 3 is very attractive.

The Winner (for now)

\n \n

\n\n

You've probably already guessed which framework I ended up choosing for the production version of the site.

I chose SvelteKit, and these were the primary reasons:

It's no-nonsense. The syntax is clean, concise, and consistent while using primarily traditional HTML, CSS, and JavaScript. There is some "magic" with SvelteKit, like the filesystem-based routing, but Svelte itself is very self-explanatory
No virtual DOM diffing or complex state management code
It's reactive by default. Vue requires you to explicitly initialize reactive variables, Svelte does not
It's extremely fast and performs well on both desktop and mobile out of the box
I prefer Svelte's mdsvex to Nuxt's MDC for components in Markdown. How the blog works is arguably the most important part of the site for me, so this matters a lot
I prefer Svelte's two-way binding feature to Vue's emit feature for bubbling props from child components up to their parents

Let me be clear, though. Nuxt 3 is an excellent framework. It's performant, provides a wonderful developer experience, and has a great team behind it and a bright future ahead of it.

I loved building the website with Nuxt. I was consistently impressed with how intuitive its features were to implement and how quickly I was able to get off the ground. I began this project with Nuxt for a reason.

The current plan is to maintain both the Nuxt 3 site and the SvelteKit site over time. I may even change which one ryantoken.com points to at various times. Doing this will keep me up-to-date with how each framework is progressing and keep my skillset up on both simultaneously.

Nuxt 3 site: https://ryantoken-v3.vercel.app

SvelteKit site: https://ryantoken.com (you're on it)

This was a wonderful exercise to go through, and I've never been happier with my personal website. Thanks for reading, and feel free to get in touch if you have feedback on this blog post or the site in general. I'd love to hear from you!

And if you particularly enjoyed this post, you can buy me a coffee!

\n \n $\"Buy$ \n \n

"}},{"meta":{"title":"Dynamic Lambda Storage","description":"Serverless compute with dynamic ephemeral storage.","date":"2022-06-10T00:00:00.000Z","imagePath":"/blog-images/dynamic-ephemeral-storage/cover.png","imageAlt":"A custom diagram showcasing dynamic ephemeral storage with lambda","tags":["web","cloud","serverless"]},"path":"/blog/dynamic-ephemeral-storage-lambda","postContent":{"html":"

I published an article on Storyboard's Dev Blog about how to configure dynamic amounts of ephemeral storage for a Lambda function on a per-invocation basis.

AWS does not let you do this natively. You manually set the amount of storage on the function itself, and then you’re done. You can edit it after the fact, but you can’t change the amount of storage allocated with each invocation.

In the post, I detail (what I think is) a clever solution to this limitation which can save you a significant amount of money in the long run. Hint: it's built with the Serverless Framework.

Check out the full post in the link below, and let me know what you think!

Link to the post: https://medium.com/storyboard-podcasts/storyboard-dev-blog-serverless-compute-with-dynamic-ephemeral-storage-8fd38c0df93d

\n"}},{"meta":{"title":"One Year at Storyboard","description":"Reflections on my first year and a look at what's to come.","date":"2022-04-29T00:00:00.000Z","imagePath":"/blog-images/one-year-at-storyboard/cover.png","imageAlt":"Storyboard's logo","tags":["career","reflections"]},"path":"/blog/one-year-at-storyboard","postContent":{"html":"

This week marks one year since I joined Storyboard.

From a high level, it looked like a bit of a leap of faith. I left a larger, more "stable" company for an early-stage startup in the middle of a pandemic. From my perspective, though, it was more a necessity than it was a risk. Yes, I was happy at my previous company, but it wasn't enough. I wanted to be challenged, I wanted to be involved in areas outside of just software, and, most importantly, I wanted out of my comfort zone.

Storyboard has provided all of this and so much more.

I'm learning technologies I hadn't heard of previously; I'm working with the design team, the product team, and even the sales team on features both internal and external; I'm working with developers who know so much more than I do about various aspects of software. It's a feeling that I lost for a while after several years in my previous role, and I love it.

Writing this now, I can't believe it's already been a full year since I joined the team.

The company has grown substantially, both in terms of revenue and team size, but we're careful and sustainable with that growth. See Fast's recent collapse for some insight into why that's important.

My own skillset has seen significant growth over this year as well. With the possible exception of my first year out of college, this is the most I've learned in a single year in my career. From creating our serverless architecture, to going deep on WebRTC and Hypercore, to helping with difficult authentication problems, to learning a new front-end framework, it has been a massive year for me.

These are all areas I'm deeply interested in, but some of them are also areas I did not have much (or any) experience with when I joined the company. I'm convinced that there's something about joining a scrappy, tenacious startup that rubs off on you. Part of me has always been that way, but it was taken to eleven when I joined Storyboard.

Remote At Its Core

Storyboard is fully remote. We have no office, we have no central location. I don't even think we have more than three people living in any given city. We're remote at our core.

I knew that coming in, and I had done plenty of remote work the year prior due to Covid-19, but it was still an open question in my mind as to whether I'd enjoy the fully remote life after a full year of it - knowing that there was no office I would eventually be going back to.

I absolutely love it.

Also at its core, Storyboard is a communication company. We provide asynchronous communication channels. We facilitate idea sharing even, and especially, when the environment makes that difficult. It's clear to everyone who works here that this is Storyboard's heart. We host podcasts with employees, we have regular lunch & learns that we also distribute as podcast episodes, we actively engage in cross-function discourse instead of hoping it happens passively. And the fact that everyone is remote instead of just some of us sets a level playing field.

It's a wonderful environment. And while I do occasionally miss seeing my coworkers in person, the benefits gained from being remote-first are clear and obvious to me. I understand not everyone works the same way, but this role and company atmosphere feels like it was made for me.

What's Next

An important question I'm asking myself now is how will I keep the momentum going for year two?

I have a few ideas that are outside the traditional "keep learning" norms:

1. Produce more internal content

Storyboard is all about podcasting. I run my own podcast outside of work. While I've done my share of episodes internally for Storyboard, there's plenty of room for me to do more. And I have more to say! I've yet to decide whether that be a quick audio journal on what I worked on/learned that day or week, or something else. But more internal content is certainly a priority for me this year.

2. Engage in more open-source software development

I made my first couple of open-source contributions this past year, but none that I would consider significant. I've identified several projects that I love, that impact the work we're doing at Storyboard, and that have maintainers I've either gotten to know or simply respect. The opportunity is there for me to make a meaningful impact in these projects.

3. Reach the "final form" of a full-stack engineer

I'll close with this one, as I have some more to say here.

I've long struggled with keeping up with all of the different "stacks" that a full-stack developer works with simultaneously.

The three stacks I'm discussing here are front-end web development, back-end web development, and, for me, mobile development.

I have no problem staying fresh on two of these areas at a time. I'll always be fresh with whichever piece is my primary responsibility at work, and I'll always be fresh with whichever piece I choose to work on in my spare time. But fitting that third piece in somewhere is where I've struggled in the past.

For the last couple of years I've been most confident in my back-end and mobile skills, but I've lost some of the front-end skills I used to have. Before that, front-end and mobile were my stronger suits, but back-end dropped off. And the pattern continues.

I have all three going right now. I hope to keep that up and take them all to new heights this year. I'm taking on some smaller front-end projects at work while spending most of my time on back-end development. I'm keeping up with mobile in my spare time. I released a native iOS app in October of 2021 called Outrank and am coming down to the wire on another as I write this.

I think this is the combination that works best for me. Doing mobile development primarily outside of work keeps it fresh and offers a break from the web technologies I typically work with during the day. This change of pace in the tech I work with, I hope, will keep the momentum going as I become a significant contributor in all facets of application development.

So now I'm off to year two at Storyboard. A year that will be full of personal changes and (hopefully) professional fulfillment. I couldn't be more excited to continue working with this team, at this company, at this time. Full speed ahead ⚡️

\n"}},{"meta":{"title":"Introducing Outrank","description":"Discussing the new app and my experience building it.","date":"2021-10-26T00:00:00.000Z","imagePath":"/blog-images/introducing-outrank/outrank-icon.png","imageAlt":"Outrank's app icon","tags":["iOS","swift","swiftui"]},"path":"/blog/introducing-outrank","postContent":{"html":"

Today I'm excited to debut my first new iOS app in three years:

Outrank

icon courtesy of my amazing wife, Emma

If you're a fan of American college football, this app is for you. Available for iOS, iPadOS, and macOS (on M1 Macs), Outrank is the easiest way to check how your favorite teams stack up against the rest. It shows you where your team ranks in forty-seven different tracked statistics compared to the other 129 FBS teams.

\n\n\t\n\n\t\n\n\t\n\n\t\n

\n\n

screenshots courtesy of Federico Viticci and his wonderful Apple Frames shortcut

Ever wonder where your team ranks in total offense, team sacks, turnover margin, and red zone defense? All of this is simply glanceable information for each team instead of needing to hunt for each stat individually.

Want to preview the most intriguing matchups of the week? There's a feature for that, too. From the Compare tab, you can select any two teams and see how they compare with a convenient side-by-side view.

Other features include:

Widgets to show a team's top four and bottom four stats
The ability to set your favorite teams and watch them sync seamlessly between Apple devices
A UI that's flexible enough to extend to iPadOS and macOS apps (for M1 MacBooks)
Tip jar and subscription options

I built Outrank because I needed it. I host a college football podcast and wanted a quick way to find where my favorite teams stacked up, but couldn't find a service that provided it without a lot of pain in the process.

The app is free with no ads. It makes me no money by default. If you enjoy Outrank, I'd love it if you left a tip or subscribed in the app, or supported my work on Patreon or Buy Me a Coffee.

Thank you for your interest in Outrank. If you have a feature request or feedback, please get in touch on Twitter or send me an email.

I'll end the main post here, but there are extra details on the app and my experience building it further down for anyone interested.

$\"Download$

\n
\n\n

Extra Points

Hello! If you're still reading this, thank you! I had a blast building Outrank. I thought I'd go a bit deeper and share my experience building the app, things I learned, the technologies involved, and more.

SwiftUI

First, a comment on SwiftUI. 100% of Outrank is written with it - there is no bridging into UIKit for anything, and there's no Objective-C code either. It's all Swift and SwiftUI, just as the good lord intended.

When I rewrote my first app CatchUp with SwiftUI last year, there were a lot of issues. I detailed some of them in this post. Long story short, nearly all of the big SwiftUI bugs I ran into with CatchUp have been resolved! This is not to say that SwiftUI is now flawless. It absolutely has problems, and debugging those problems can sometimes be baffling, but the entire SwiftUI development experience has improved so much since last year. I was astounded.

Development Efficiency

This brings me to my second point: development speed and efficiency.

File > New > Project for this app happened on October 2nd, 2021. Three weeks later, the app was done and released to the world. And I should note that I have a full-time job doing full-stack web development. All development time for this was either in the mornings before work, the evenings after work, or on weekends.

There are a few different reasons I was able to ship this so quickly.

First, on June 29th, 2021, I began Paul Hudson's 100 Days of SwiftUI course. On October 7th, exactly 100 days later, I finished it. I began working on Outrank on Day 95.

I simply cannot express how much working through this course helped me. I had started it twice before over the years but burnt out around Day 40 both times. This time, due to a combination of support from my partner and posting daily in the Hacking with Swift Slack Channel as Paul recommends, I was able to stay locked in and complete the course.

This was undoubtedly the most significant contributor to the development speed I mentioned. Working with Swift effectively every day for 100 straight days and taking all of that knowledge and practice directly into a new app paid off immensely. Being familiar with the latest SwiftUI techniques and having it all fresh in my head made all the difference in the world. And when I needed to go somewhere for advice, both Hacking with Swift and Swift by Sundell provided vast repositories of sample code, guidance, and articles to help me figure it out. And, of course, the indomitable Stack Overflow.

The second most important contributor to development speed was simply SwiftUI's power and convenience. This wound up being the perfect app for SwiftUI. Outrank uses a lot of Lists, the UI doesn't try and get too "custom", and there was no need to bridge into UIKit for anything. That last part made things particularly clean. I've written a UIKit app before, and I'm comfortable bridging into it from SwiftUI when necessary (see CatchUp and its contact picker), but not needing to build those bridges makes things much smoother.

SwiftUI gives you so many features for free. Dark mode support, solid accessibility features out of the box, simple animations, the ability to jettison storyboards into the ether, flexible layouts between iOS, iPadOS, and macOS - all of this comes built-in with no changes required. Of course, to take full advantage of these features, you can (and should) go deeper than what SwiftUI provides by default, but it's impressive how much you get just by opting into the SwiftUI lifestyle.

Other Technologies

To close things out, a bit on some of the other core technologies involved with the app:

Syncing favorite teams between Apple devices happens exclusively with Core Data and CloudKit, which was surprisingly simple to set up.

The back-end infrastructure is all AWS-based. I have a node.js server that handles a lot of the rankings data collection. That server throws its data into a couple of different DynamoDB tables, and the app calls various API Gateway endpoints that trigger Lambda functions to query those DB tables. The results of those API calls return JSON that I decode into Swift structs which finally winds up inside a SwiftUI List in the UI. All of the AWS infrastructure is generated via IAC with the Serverless Framework and Terraform.

There is no web front-end for this yet, but that is one of my goals for the app. I'm big into Jamstack web development and have recently been experimenting with the Nuxt 3 beta. My background with front-end web development is in React, but the plan is to build the web front-end for Outrank with Nuxt 3 once it's out in production.

A Quick Note on Privacy

I collect/store none of your data. Literally 0. I have no interest in any of it, so let's put that to bed right now. You can read my Privacy Policy and Terms of Use for more information.

Signing Off

That covers all of the big pieces I wanted to get to about this app. I have legitimately had a wonderful time building this, and (95% of the time) SwiftUI continues to be a true joy to work with.

Thank you for reading. If you have questions, comments, feedback, feature requests, or anything else about the app, please email me.

$\"Download$

\n"}},{"meta":{"title":"I'm Joining Storyboard!","description":"Starting a new, remote, cloud-heavy journey.","date":"2021-04-25T00:00:00.000Z","imagePath":"/blog-images/joining-storyboard/cover.png","imageAlt":"Storyboard's original logo","tags":["career","aws","serverless"]},"path":"/blog/joining-storyboard","postContent":{"html":"

A New Chapter

Hello out there! Relatively quick life update here – I'm joining a new company!

After nearly four years with ConocoPhillips, I'm joining Storyboard as a Full Stack Software Engineer.

I did truly enjoy my time working at ConocoPhillips. I worked on projects I'm proud of and teams I loved, I grew significantly as an employee and as a human being, and I made some very good friends along the way. It was my first job out of college, and I loved it – it was tough to step away.

What brought me to Storyboard was five-fold:

1. The product

Storyboard is the app for private podcasts.

Imagine a company wants to start a private, internal podcast for its employees. They want to interview the leadership team, send out weekly company updates, and roll out various forms of training in podcast form. There could be several hurdles to overcome. Secure distribution likely being the biggest one.

Many companies will do a great job recording an episode, but then post the .mp3 file on an internal SharePoint site and include the link in some big company newsletter along with fifty other things. Not ideal. You need to open the email, you need to be on the company network, you need to find the SharePoint URL every time you want to listen to an episode, the list goes on. I've seen this scenario first hand.

Storyboard solves this problem. If the company uses Storyboard to record/distribute its podcasts, the company's podcast episodes are pushed to you like any other podcast player. These episodes are secured via Single Sign On (SSO) and only accessible by active employees.

2. My personal interests

Podcasts are just cool. I'd argue that I've gotten more value out of listening to podcasts than any other form of media. Some of my favorites include Accidental Tech Podcast, Big Technology Podcast, How I Built This, Syntax, and Startups For the Rest of Us.

As you might know, I also run my own podcast about athletics at The University of Tulsa. I love listening to and creating podcasts. The idea that I could actively help bring this medium to the enterprise is extremely exciting.

3. My professional interests

My previous two blog posts have been about 1) the Jamstack, and 2) WebRTC. This role combines both of those interests and so many more.

I spend the vast majority of my time both in my professional work and my side projects in the world of AWS - specifically on the serverless side of things. Recently, I've been deep into the AWS CDK for efficient management and development of AWS infrastructure. The CDK is incredibly powerful and I plan to use it as much as possible in my role with Storyboard.

4. It's fully remote

The ethos of Storyboard is that employees should be able to collaborate and work together from anywhere. As such, everyone at Storyboard is remote. At the time of publishing I haven't met everyone quite yet, but of those I'm aware - there are employees in Los Angeles, Denver, New York, and Nashville.

I'll be working remotely out of Tulsa. It's wonderful to be able to stay in the town where my wife and I graduated from college just four years ago, where my wife still works downtown, and where I still have so many close friends. The technology scene in Tulsa is also booming right now. Coworking spaces like 36°N and others, along with the Tulsa Remote program, have accelerated the city's technology ecosystem rapidly.

5. It's a startup

I've long been interested in the startup world, and this one checks all the boxes.

✅ A product I believe in

✅ A founder I believe in

✅ My ideal technology stack

✅ Remote work

✅ A combination of my interests

I'm psyched to give everything I've got to a product and a team like this.

Start Date

My first day with Storyboard is April 26th, 2021. I can't wait.

While I did sincerely enjoy my time with ConocoPhillips, I couldn't be more excited to begin this new adventure.

And if your company wants to get started with a private podcast, get in touch!

\n"}},{"meta":{"title":"Learning WebRTC","description":"Explaining WebRTC to myself and others.","date":"2021-03-07T00:00:00.000Z","imagePath":"/blog-images/learning-webrtc/cover.png","imageAlt":"The WebRTC logo","tags":["web","webrtc"]},"path":"/blog/learning-webrtc","postContent":{"html":"

WebRTC can be tricky to wrap your mind around – there's a lot involved and it's easy to get overwhelmed. Once you understand the basics though, it's much easier to reason about the rest.

I've been working heavily with the standard over the past several weeks and wanted to document the knowledge I've gained while also providing some sample code, evaluating the technology's pros and cons, and supplying resources for continued learning.

First, What is WebRTC?

\n\tWebRTC stands for Web Real-Time Communication and, as you'd expect from the name, enables real-time communication for the web. Think video calls, web-based chat, etc.\n

\n\n

The technology has grown significantly since its initial implementation in 2011 as an open-source project by Google. Today, it's implemented as an open, standardized API that enables rich peer-to-peer communications, including the transmission of audio, video, and generic data between browsers, mobile devices, IoT devices, and more.

The most important thing WebRTC takes off your plate is the challenge of finding the best peer-to-peer path to exchange data in an efficient and low-latency manner.

WebRTC Pathfinding - diagram from WebRTC Crash Course

A Typical WebRTC Lifecycle

Client A wants to connect to Client B
\n
A first needs to determine all possible ways that the public can connect to it (A)
\n
B then also needs to determine how the public can connect to it (B)
\n
A and B signal this session information (SDP) (more on this later) to each other somehow. This can be via text message, with a QR code, via HTTP, via WebSockets, or something else. How you send this information doesn't matter.
\n
A then connects to B via the most optimal path (determined by ICE) (more on this later as well)
\n
A & B also exchange their supported media types and security information
\n
An agreement is made, and the connection is opened
\n

\n
\n\n

Necessary Concepts & Terminology

There are several terms you'll need to be familiar with before we discuss WebRTC further. I'll briefly introduce them below.

NAT: Network Address Translation

To understand WebRTC, you have to understand the fundamentals of NAT. I'll try my best at a simple explanation of NAT and why it's necessary here.

The problem: Devices don't have their own public IP addresses.

The only way to connect to another device is via its public IP address. If our device doesn't have its own public IP, how will we be able to communicate that information out for someone else to use?

The answer: NAT

NAT bridges this gap. NAT operates on the router and translates our devices' private IPs into a public IP that others can reach us at.

When others try to reach you, they ultimately reach your router's public IP and your router translates that back to your device's private IP.

There are four different NAT types: Full Cone NAT (normal NAT), Address-Restricted NAT, Port-Restricted NAT, and Symmetric NAT. All of these work well with WebRTC except Symmetric NAT. More info on the four NAT types here.

\n
Edit: According to the Internet Engineering Task Force, the "Cone" and "Symmetric" NAT terminology has done a poor job explaining NAT behavior. While you may still see these terms when reading about NAT, it is recommended to use the following terminology instead: Endpoint-Independent mapping and filtering, Address-Dependent mapping and filtering, and Address and Port-Dependent mapping and filtering.
\n

\n
Address and Port-Dependent mapping and filtering is the equivalent of Symmetric NAT, which is the only type that does not work with WebRTC. You can read more about the new NAT terminology here.
\n

In the context of WebRTC, our devices pass through our routers to a STUN server. The STUN server sends us back a public IP address we can use to connect peer-to-peer with another client.

STUN: Session Traversal Utilities for NAT

A STUN Server Example - diagram from WebRTC Crash Course

A STUN server's main job is to tell a client what its public IP address/port is through NAT.

Talking to a STUN server is table stakes for any WebRTC application. We first need to find our public presence so we can communicate that information to someone else. Once someone else has that information, we can try to open a connection with them.

STUN servers are cheap to maintain, and many are publicly available for free usage.

TURN: Traversal Using Relays around NAT

A TURN Server Example - diagram from WebRTC Crash Course

As I mentioned previously, WebRTC does not work well with Symmetric NAT. This is caused by Symmetric NAT blocking communications with the STUN server.

If a router is using Symmetric NAT, STUN won't work, and we'll have to fall back to a TURN server. This gets rid of the peer-to-peer benefit of WebRTC and requires all communication to pass through this single TURN server instead, which creates a bottleneck and could buckle under heavy usage.

If a TURN server is required, I've heard people argue for just using a standard web server with a reverse proxy instead. Theoretically this would give you similar functionality while allowing you to have more control over the server. I haven't formed my own opinion on this topic yet.

ICE: Interactive Connectivity Establishment

So we've discussed private IP addresses, public IP addresses, STUN servers, TURN servers, and more. How do we know which options are the best to connect with?

This is the primary job of ICE. It finds the optimal path from one peer to another by conducting connectivity checks.

ICE collects all available ICE candidates (information for each available path) and sends them to the remote peer via SDP. ICE will then collect all available candidates on the remote peer as well.

With both peers' session information now understood, ICE can determine the best path for a connection between the two clients.

This process can take some time, sometimes in the 10s of seconds. To get off the ground a little quicker, you can use a relatively new WebRTC feature called Trickle ICE. Trickle ICE takes the ICE process and runs it in parallel, so you won't need to wait for every candidate to be found before sending the information via SDP. This can dramatically improve the time it takes to make the initial connection with the remote peer.

SDP: Session Description Protocol

"sdp":"v=0\\r\\n\\\no=- 20518 0 IN IP4 203.0.113.1\\r\\n\\\ns= \\r\\n\\\nt=0 0\\r\\n\\\nc=IN IP4 203.0.113.1\\r\\n\\\na=ice-ufrag:F7gI\\r\\n\\\na=ice-pwd:x9cml/YzichV2+XlhiMu8g\\r\\n\\\na=fingerprint:sha-1 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7\\r\\n\\\nm=audio 54400 RTP/SAVPF 0 96\\r\\n\\\na=rtpmap:0 PCMU/8000\\r\\n\\\na=rtpmap:96 opus/48000\\r\\n\\\na=ptime:20\\r\\n\\\na=sendrecv\\r\\n\\\na=candidate:0 1 UDP 2113667327 203.0.113.1 54400 typ host\\r\\n\\\na=candidate:1 2 UDP 2113667326 203.0.113.1 54401 typ host\\r\\n\\\nm=video 55400 RTP/SAVPF 97 98\\r\\n\\\na=rtpmap:97 H264/90000\\r\\n\\\na=fmtp:97 profile-level-id=4d0028;packetization-mode=1\\r\\n\\\na=rtpmap:98 VP8/90000\\r\\n\\\na=sendrecv\\r\\n\\\na=candidate:0 1 UDP 2113667327 203.0.113.1 55400 typ host\\r\\n\\\na=candidate:1 2 UDP 2113667326 203.0.113.1 55401 typ host\\r\\n\\\n"\n

An SDP Example - basically a giant string of session information

SDP is arguably the most important concept in WebRTC. SDP is the information that ICE sends back and forth to try and establish the best possible connection.

Despite its name, SDP is less of a protocol and more of a format. It describes all ICE candidates, networking options, media options (audio/video), security options, etc., and combines it all into one massive string.

Once another client has this information, a connection between the two clients can be attempted.

For another person to connect with us though, we need some way to communicate our SDP information out to them. This is called signaling.

Once you have your SDP string, you'll need to signal it out yourself. WebRTC does not care how this is done, but it also doesn't provide a built-in way to do this. You can send out your SDP information through a QR code, a messaging app like WhatsApp or iMessage, via WebSockets, HTTP, or anything else. We just need to get that large SDP string to the other party.

DTLS, SRTP, & SCTP – Securing and Customizing WebRTC Data Flow

\n
DTLS: Datagram Transport Layer Security
\n

\n
SRTP: Secure Real-time Transport Protocol
\n

\n
SCTP: Stream Control Transmission Protocol
\n

WebRTC Data Flow - diagram concept from BlogGeek.me

Note that WebRTC did not introduce these protocols. They were around long before WebRTC was established in 2011. DTLS was invented in 2006, SRTP in 2004, SCTP in 2000.

The purpose of DTLS and SRTP is to secure the connection previously established by ICE.

First, WebRTC does a DTLS handshake over the connection that ICE established. Once that handshake has been completed, we have a secure connection, and this new DTLS connection is used for messages over our data channel.

We then use SRTP for secure audio and video transmission. The SRTP session is encrypted by extracting the keys from the negotiated DTLS session.

Once both of these steps have been completed, we have a bi-directional and secure communication channel.

The final term to understand here is SCTP. SCTP provides different options for delivering messages. You can choose to have unreliable, out-of-order delivery so you can get the latency needed for real-time systems; or you can opt for reliable, in-sequence transmission of messages with congestion control.

Revisiting the WebRTC Lifecycle

Now that we understand the fundamental WebRTC concepts, let's revisit a standard WebRTC communication lifecycle with some more detail.

Some additional information first: Every client maintains two SDP descriptions, a local SDP description and the SDP description of the remote client it's trying to connect to.

Client A wants to connect to Client B
\n
A creates an offer. The offer is just the SDP string that consists of all ICE candidates, security options, audio/video options, etc
\n
A then sets its local SDP description to the offer it just created.
\n
A signals that offer to B via SDP. Again, it doesn't matter how this signaling happens (iMessage, HTTP request, etc)
\n
B receives A's offer, and sets A's offer as its remote SDP description
\n
B creates an answer to send back to A, and sets that answer as its own local SDP description
\n
B signals its answer to A via SDP
\n
A receives B's answer, and sets B's answer as A's remote SDP description
\n
With all SDP information now understood by both parties, an agreement can be made. The connection is created and data can flow between the two clients
\n

A Vanilla Implementation

Let's walk through how to create a basic WebRTC connection between two peers using just the vanilla WebRTC API. We won't use any libraries or anything extra on top of it – just the basics so you really understand what's happening here. You could run this code directly in two browser windows via the browser's dev tools and it would work.

Note that we will not need to connect to any STUN or TURN servers in this example, as both browsers will be on the same local area network. STUN and TURN are only required when connecting to a remote peer on a different network. If we did need to connect to a STUN/TURN server, we'd pass that information into the new RTCPeerConnection we create in step one.

Browser One

Create the local peer connection.

const localConnection = new RTCPeerConnection()\n

Create a data channel from that connection.

const dataChannel = localConnection.createDataChannel("channel")\n

Set up listeners on this channel for when a message is received (onmessage) and when a connection is opened (onopen).

dataChannel.onmessage = e => console.log("Just got a message " + e.data)\ndataChannel.onopen = e => console.log("Connection opened!")\n

Set up a listener on the local connection for new ICE candidates. Print the SDP string every time we get a new ICE candidate. This will provide examples of what SDP strings look like.

localConnection.onicecandidate = e => console.log("New ICE candidate! Reprinting SDP " + JSON.stringify(localConnection.localDescription))\n

Create the offer locally, and set that offer as our local SDP description.

localConnection.createOffer()\n\t.then(offer => localConnection.setLocalDescription(offer))\n\t.then(a => console.log("Set local SDP description successfully"))\n

Browser Two

Now open a new browser window, and we'll work on connecting the two browsers.

After running the previous commands in browser one, you should have an SDP offer string printed out in your browser's dev tools. Copy and paste that from browser one, and set it to a new variable in browser two. It should look something like this:

const offer = {"type":"offer","sdp":"v=0\\r\\no=- 6161885883039613335 2 IN IP4 127.0.0.1\\r\\ns=-\\r\\nt=0 0\\r\\na=group:BUNDLE 0\\r\\na=extmap-allow-mixed\\r\\na=msid-semantic: WMS\\r\\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\\r\\nc=IN IP4 0.0.0.0\\r\\na=candidate:613963537 1 udp 2122262783 8feb3e9a-4ba2-48b6-a5b9-b7e6164dad0d.local 50380 typ host generation 0 network-id 2 network-cost 50\\r\\na=ice-ufrag:m9IL\\r\\na=ice-pwd:HSi4w0HG5HCDGlhkTaJVACHM\\r\\na=ice-options:trickle\\r\\na=fingerprint:sha-256 B5:BF:A6:FA:45:FE:83:B7:AF:D2:03:5F:FC:EF:06:ED:2E:C2:51:A3:53:7E:7E:7A:B0:6D:AE:08:9C:3A:A4:D7\\r\\na=setup:actpass\\r\\na=mid:0\\r\\na=sctp-port:5000\\r\\na=max-message-size:262144\\r\\n"}\n

Create the remote peer connection.

const remoteConnection = new RTCPeerConnection()\n

Print the SDP string every time we get a new ICE candidate on the remote side this time.

remoteConnection.onicecandidate = e => console.log("New ICE candidate! Reprinting SDP " + JSON.stringify(remoteConnection.localDescription))\n

Set up a listener on the remote connection that will receive the data channel from the other connection.

remoteConnection.ondatachannel = e => {\n\tremoteConnection.dataChannel = e.channel // e.channel is the data channel we received from the other party\n\tremoteConnection.dataChannel.onmessage = e => console.log("New message from client! " + e.data)\n\tremoteConnection.dataChannel.onopen = e => console.log("Connection successfully opened!")\n}\n

Set our remote and local SDP descriptions based on the offer we received (remote SDP description) and the answer we create (local SDP description).

// set remote description for the offer we received\nremoteConnection.setRemoteDescription(offer)\n\t.then(a => console.log("Offer set!"))\n\n// set local description with our answer\nremoteConnection.createAnswer()\n\t.then(answer => remoteConnection.setLocalDescription(answer))\n\t.then(a => console.log("Answer created"))\n

Back to Browser One

Set the answer SDP we just generated in the previous step to an answer variable.

const answer = {"type":"answer","sdp":"v=0\\r\\no=- 1817317559757912498 2 IN IP4 127.0.0.1\\r\\ns=-\\r\\nt=0 0\\r\\na=group:BUNDLE 0\\r\\na=extmap-allow-mixed\\r\\na=msid-semantic: WMS\\r\\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\\r\\nc=IN IP4 0.0.0.0\\r\\na=candidate:613963537 1 udp 2122262783 264b84bf-cd92-41f3-9b5c-6d08060977f8.local 58006 typ host generation 0 network-id 2 network-cost 50\\r\\na=ice-ufrag:O629\\r\\na=ice-pwd:8TOlrnjf31jsOOIHZZGnT1Xh\\r\\na=ice-options:trickle\\r\\na=fingerprint:sha-256 DC:CE:94:53:BC:E1:BF:1F:67:44:08:5F:8E:A5:B7:AD:01:D3:84:C8:FC:D5:BA:D7:76:28:E3:3F:FC:15:3E:9B\\r\\na=setup:active\\r\\na=mid:0\\r\\na=sctp-port:5000\\r\\na=max-message-size:262144\\r\\n"}\n

We're coming full circle now. In the first section (Browser One), we set the local connection's local description. In the second section (Browser Two), we set the remote connection's local & remote descriptions. And now, we close the loop by setting the local connection's remote description to the answer we just set in the previous step. This opens the connection between the two peers.

localConnection.setRemoteDescription(answer)\n

The connection is now open, and we can send data back and forth between the two browsers with the send() function.

Browser One (the local connection)

dataChannel.send("Hello Peer B, what's up?")\n

Browser Two (the remote connection)

remoteConnection.dataChannel.send("Not much Peer A, what about you?")\n

You should see each of those messages in the other browser's dev tools now. 👍

WebRTC Pros and Cons

Pros:

Having a peer-to-peer connection is fantastic. It allows for low latency and high-bandwidth content to be shared seamlessly
\n
WebRTC provides a standardized way for developers to implement this functionality with an API that we don't have to build ourselves
\n
It's a popular open-source technology supported by Google, Mozilla, Opera, and others. You can browse the source code here
\n

Cons:

Maintaining STUN and TURN servers\n * STUN isn't too bad since there are free STUN servers publicly available for you to use.\n * TURN is expensive and more difficult, and no one offers them for free usage like STUN servers\n * Kind of a Pro, but you can create your own STUN and TURN servers with the COTURN open-source project\n
\n
Peer-to-Peer can fall apart in cases of many participants\n * If you have 100 people in one environment, maintaining peer-to-peer connections between all 100 people isn't viable. This would be 99x100 individual connections\n * A centralized server makes more sense here. Everyone connects to the centralized server, and you maintain the connection and traffic rules on that server\n * More latency in this scenario, but much more viable\n * Large online games don't use WebRTC, for example. They use a centralized server people connect to
\n

Powering Up with Amazon Kinesis Video Streams

As mentioned, one of the cons of WebRTC is the need to maintain and manage various STUN and TURN servers.

\n\tAmazon Kinesis Video Streams with WebRTC offers a potential solution to this problem, as well as handling the signaling implementation for you.\n

\n\n

AWS offers SDKs to work with this service from the web, iOS, Android, and embedded devices.

In AWS's words, Amazon Kinesis Video Streams (KVS) "provides a standards-compliant WebRTC implementation as a fully managed capability. You can use Amazon Kinesis Video Streams with WebRTC to securely live stream media or perform two-way audio or video interaction between any camera IoT device and WebRTC-compliant mobile or web players. As a fully managed capability, you don't have to build, operate, or scale any WebRTC-related cloud infrastructure, such as signaling or media relay servers to securely stream media across applications and devices."

Using this service abstracts away the need to manage your own STUN and TURN servers while optimizing for even lower latency and higher bandwidth streaming.

There's a fantastic walkthrough of how to get up and running with this service here. Familiarity with AWS isn't necessarily required to follow that blog post but is certainly helpful.

AWS Kinesis Video Streams with WebRTC Architecture Diagram

I was able to build a very performant peer-to-peer video streaming application by building on top of the aforementioned walkthrough. I recommend giving it a try and seeing how it goes for you. There's also some fantastic sample code on GitHub.

Resources I Used While Learning

Getting Started with WebRTC on WebRTC.org
\n
WebRTC API on the Mozilla Developer Network
\n
WebRTC For The Curious
\n
WebRTC Crash Course on YouTube\n * This was particularly helpful. I highly recommend you take the time to watch the full thing\n * Many of the concepts in this post were inspired directly by this video\n
\n
Introduction to WebRTC on YouTube
\n
What is Kinesis Video Streams with WebRTC from AWS
\n
Kinesis Video Streams with WebRTC: How it Works from AWS
\n
Enabling Video Chats Using Amazon Kinesis Video Streams with WebRTC from AWS
\n
Amazon Kinesis Video Streams implementation on GitHub
\n

A Final Note

There are a lot of YouTube videos that claim to teach you WebRTC by "building a Zoom clone" or something similar. I worked through a couple of these and found them to be less than valuable. Most layer on a bunch of third-party libraries like socket.io, simple-peer, peer.js, and others to handle the dirty work.

In my opinion, it's far better to fully understand the fundamentals before adding on these libraries.

Thank you for reading!

\n"}},{"meta":{"title":"Rocking the Jamstack","description":"Diving into the Jamstack, and loving every minute of it.","date":"2021-02-21T00:00:00.000Z","imagePath":"/blog-images/rocking-with-the-jamstack/cover.png","imageAlt":"The Jamstack logo","tags":["web","jamstack","serverless"]},"path":"/blog/rocking-with-the-jamstack","postContent":{"html":"

What Is the Jamstack?

There comes a time in every young developer's life when they stumble upon a technology, or a philosophy around technologies, that just works for them. At least, that's what I envision an older and more experienced developer telling me.

That's been the Jamstack for me.

The Jamstack, originally styled as JAMstack, can sound a bit nebulous at first. The J-A-M there stands for JavaScript, APIs, and Markup. Those are the only required ingredients for any Jamstack application. There is no specific framework involved, no cloud provider or back end language you need to use, no required toolchain or build process. There are very few hard-and-fast requirements at all. It is a vague term intentionally, and that's one of its positives, but there are two requirements.

First: a static front end

A Jamstack front end is pre-rendered. That is to say, the content that a user sees on the client-side is generated before it's required, not once it's required. This gives Jamstack applications a massive speed advantage.

This markup generation happens during a build step rather than on-demand on the server-side. Because of this, your app doesn't need to repeatedly make network round-trips to serve up the pages the user requests; they've already been generated and are there instantly for the user to interact with. This takes the load off of the web host and dramatically improves scalability.

Second: decoupling

A college professor of mine continually stressed the idea of applications that were "loosely coupled and highly cohesive".

Half of the idea he was pushing here was the concept of decoupling. A decoupled application has clean separation points between its various parts. Decoupling allows each component of the application to be more easily understandable and simpler to swap out or upgrade.

The key takeaway in the context of the Jamstack is to enforce a clean separation between your front end and your back end services.

This means a static site on the front end with serverless functions on the back end. Your front end should not care what you're using on the back end, and vice-versa. Each can be iterated on independently without ever impacting the other.

The loosely coupled glue between the front end and back end in a Jamstack application is the API layer. I use AWS's API Gateway to host my APIs, but there are plenty of options.

Ok, great, but seriously what IS the Jamstack?

All of this is to say that the Jamstack is NOT a specific set of languages or tools you need to learn - it's a mindset of how to build applications (with some recommendations 🙂).

Why Should You Care?

Modern web development can be exhausting and overwhelming. Jamstack applications aim to simplify your architecture while significantly enhancing the speed, scalability, and overall performance of your application.

Speed: The fact that all of your pages are static and pre-rendered means your page load times will decrease dramatically compared to a standard server-side rendered app.
\n
Scalability: Server-side rendered applications inherently slow down when under heavy load. The web servers get buried under a mountain of requests and suffer when they can't fulfill all the requests for each page in time. This problem simply does not exist for Jamstack applications. The pages are already rendered on the front end – all your app needs to do is show users the page they want. No network round-trip necessary.
\n
Future Proofing: The decoupled nature of Jamstack applications means you can easily swap out your Angular front end with a React front end, or vice-versa. Want to migrate your back end services from Azure to AWS? Or write them all in Python instead of Node.js? Your front end won't care, and it will be a much simpler process.
\n
Developer Experience: Developing with the Jamstack is just fun. There are cutting-edge technologies in use across the board. Having Netlify automatically see a change on my main branch in GitHub and then seamlessly deploy a new build out to production still makes me smile every time. The Jamstack supports all of the latest JavaScript frameworks too. React, Gatsby, Next.js, Hugo, and more are all widely supported.
\n

How to Get Started

It's easier than you think! Outside of a basic understanding of JavaScript and APIs, there are hardly any specific technologies you need to know in order to start building Jamstack applications. There are some concepts you should be familiar with, though:

Static Site Generators: Frameworks that take in one source, like JavaScript or Markdown, and create static HTML files from them. Examples include Gatsby, Hugo, Next.js, and I'd even include the indomitable Create React App.
\n
Hosting Sites: Where you host the static content generated by your static site generator. My go-to has been Netlify, a consistent champion of the Jamstack. Others include Vercel, AWS S3 Static Hosting, and Azure Storage.
\n
Back End Services: The "A" in Jamstack stands for APIs. Those API calls typically route to some serverless functions that you create but don't maintain physical infrastructure for. These can be AWS Lambda functions, Netlify Functions, Azure Functions, or a host of others. With Netlify Functions specifically, you can create a file for each function, add a configuration file that tells Netlify where those files are, and Netlify will handle the rest. Netlify automatically hosts them as Lambda functions for you and takes care of everything from there.
\n
Data Storage: Your serverless database. Where your data will persist. The top options among Jamstack developers include DynamoDB, Fauna, MongoDB, and AirTable.
\n

There are also plenty of learning resources out there. One of the best is Jamstack Conf - a semiannual developer conference solely focused on the Jamstack. The past few events have been free to attend, and I've gotten a lot of value out of them.

My Experience So Far

I've built several Jamstack applications now and have thoroughly enjoyed every bit of it. Of all its benefits, the one that resonates most with me is just how fun it is to write apps this way. Creating a React front end that calls an array of serverless functions, all while hosted on the powerful Netlify CDN, was incredibly quick to set up and simple to reason about.

Another point that I haven't touched on yet: if you are a hobby developer who doesn't want to spend much (or any) money, this way of building applications can be mind-bogglingly powerful.

Some quick price points for you:

Basic CDN and Hosting with Netlify: Free
\n
Serverless Functions with AWS Lambda: Free (up to one million function calls per month)
\n
API Setup with AWS API Gateway: Free (up to one million API calls per month)
\n
Data Storage with AWS DynamoDB: Free (up to 25 GB of data)
\n

Yes, you read that right. You can build and run a fairly sizable project completely for free. I've had two Jamstack applications running live in production with hundreds of users for months, and have yet to be charged a dime. It's so good it almost feels like cheating.

Next Steps

I am all-in on the Jamstack. As always, there are plenty of areas still for me to expand on and improve.

My front ends are all currently either using Gatsby or Create React App. I am very interested in Next.js, and will be diving into this heavily in the near future. Netlify was very quick to support Next.js, and I'm psyched about this integration.

I'm also (in my opinion) a bit too much of an AWS purist right now. Don't get me wrong, AWS is fantastic, but I need to diversify a bit. Some of the other options I mentioned above, specifically in the data storage realm, sound quite exciting. Using Fauna as a data store over AWS's DynamoDB is likely in my future.

Further, I want to try out Netlify's own serverless Netlify Functions feature instead of manually building my own Lambda functions within AWS.

That's where I'm at for now. I'm extremely excited about the future of web development with the Jamstack. There are so many cool things happening around developer experience and workflow right now. The future looks incredibly bright, and the Jamstack is leading the charge.

\n"}},{"meta":{"title":"Catching Up","description":"Modernizing CatchUp with SwiftUI and cleaner code.","date":"2020-05-08T00:00:00.000Z","imagePath":"/blog-images/catching-up/catchup-icon.png","imageAlt":"CatchUp's app icon","tags":["iOS","swift","swiftui","rewrite"]},"path":"/blog/catching-up","postContent":{"html":"

CatchUp - Keep in Touch was first released on May 6, 2018. It was the first iOS app I'd ever published to the App Store. Almost exactly two years later, I'm publishing this blog post and releasing an all-new, completely rewritten version of CatchUp.

This post talks about the origins of CatchUp, my decision to start over from scratch, implementing SwiftUI and Core Data, and writing cleaner code. At the end of this post, I do a bit of comparison between the new version and the previous version.

Getting Started with iOS

When I graduated from college in 2017 I was primarily only familiar with web development. I had never taken a mobile development course in school and knew nothing about Objective-C or Swift. For whatever reason, iOS/mobile development hadn't truly crossed my mind until after graduation. But once I started down that path in late 2017 I never turned back.

I spent the next several months learning the basics of Swift, UIKit, and everything else that comes along with iOS development. Most of that learning came via courses on Udemy, tutorials from Hacking with Swift and Swift by Sundell, finding answers on Stack Overflow, and stumbling around in the dark by myself until I happened upon a solution.

When all was said and done, I had my first app. And it worked! Much like version one of my website, it wasn't the greatest app in the world. But it was my app, and I was proud to have built it.

I put it out on the App Store on May 6, 2018, and, to my surprise, it did reasonably well. It even caught some publicity in the form of a feature in Brett Terpstra's Systematic podcast around the 46:00 minute mark of episode 218.

However, over the following months/years, CatchUp began to suffer from some poor original choices made in the app.

A Lull in Development

During the first few months after release in 2018, I updated CatchUp semi-regularly with new features and some minor design tweaks. However, as I began evaluating some larger-scope features I wanted to implement, I continued to run into the same problem.

Above all else, my existing code was just plain bad.

As I mentioned, I put this out pretty much immediately after I had learned the basics of Swift and iOS development. Knowing the basics != knowing how to make a good application. My naming was poor, many functions were massive and had far too many interspersed responsibilities, there was no consistency in where components were located, I was practically trial-and-erroring my Storyboards, etc. The list could go on and truly envelop this entire post. I'll spare you that pain.

The app was simple and straightforward enough that nearly all of this went unnoticed by users. There was only one noticeable performance issue and it didn't bother me enough at the time. As I said, the app was doing well! It was receiving nearly all 5-star reviews and was featured on a podcast. What more could I ask for?

Lesson learned. Good reviews do not mean a high-quality application. As my plans for the app grew more ambitious, and as I learned more about proper development from my full-time job, the code atrocities I was committing became ever more glaring. I consistently ran into walls caused by poor code quality as I continued to explore implementing more robust features.

I simply lost motivation for the app about a year after release. I didn't want to put forth the necessary effort to fix the underlying problems with the code that were holding it back. And so... In May of 2019, CatchUp was essentially left to die. Then came the email from Apple.

Starting Over

In March 2020, Apple sent an email to all developers with a reminder that all apps for iPhone or iPad must be built with the iOS 13 SDK or later by June 30. If they weren't, they would no longer be available on the App Store.

CatchUp was my first iOS app; it holds a special place in my heart. But it was poorly written and had become increasingly difficult to maintain because of that.

This brought me to a crossroads of sorts. I saw three options in front of me.

Option 1: Let it die.

I honestly did consider this. My initial attempts at building the app with the iOS 13 SDK severely broke a significant amount of functionality. Figuring this out would mean an even bigger maintenance hole to dig myself out of.

Option 2: Bite the bullet and fix the app, but stick with the core technologies I began with.

This probably would have taken less time than the option I ended up choosing, but would have been far less fun, and I would have learned so much less.

Option 3: Start from scratch and rewrite everything.

Why not just blow away the whole project and start over?

A headlining announcement from WWDC 2019 was the debut of SwiftUI. SwiftUI is a brand new framework from Apple that allows you to build user interfaces declaratively. Previously, all of iOS development was done imperatively using UIKit. I watched the announcement happen live, and was instantly excited and drawn to it. I had initially considered rewriting parts of CatchUp with SwiftUI, but not the entire app.

Clearly I picked Option 3. SwiftUI marked the dawn of a new era in iOS development, and this was the perfect excuse for me to start a new project and learn how SwiftUI works.

Option 3 also provided the perfect opportunity to address what ended up being one of the worst decisions I made while building the original app: using UserDefaults as my entire persistence/storage system instead of Core Data.

Everything in version 1.x of CatchUp uses UserDefaults. I didn't choose UserDefaults because I thought that was the right way to do it, I chose UserDefaults simply because that's what I had learned from the Udemy course I took when first learning iOS development. I knew nothing about Core Data or how it worked at the time, and storing everything in UserDefaults has plagued CatchUp from the beginning. Until today.

So there was my path forward. A complete rebuild using SwiftUI over UIKit, and Core Data over UserDefaults. I was ecstatic about the idea, and CatchUp would get to live to see another day.

Implementing SwiftUI

On the same day that SwiftUI was first announced back in 2019, I started working through Apple's (legitimately wonderful) "Learn to Make Apps with SwiftUI" tutorials. I also participated in Hacking with Swift's (also wonderful) 100 Days of SwiftUI course and read SwiftUI By Example All of these things together gave me enough knowledge to feel somewhat comfortable with SwiftUI, even though documentation around it was/is not quite there.

In the case of implementing Core Data, it's been around since 2005. There are plenty of resources out there to help you learn and understand how it works. SwiftUI was built to play nicely with Core Data as well, so after a few articles and WWDC videos from previous years, I felt good enough on that side of things.

The rewrite started off moving at lightspeed. SwiftUI was amazing. Legitimately. I had a full mockup of all the major aspects of the user interface done in just a few hours, and they all looked better than before.

Of course, as expected and as I've heard from others who have used SwiftUI, once you get past the basics and move into an area where not much has been done yet, you find yourself in a strange and unknown world of mystery. Here are a couple of the strangest SwiftUI holes I found myself in.

SwiftUI Issue #1:

In CatchUp's 'Preference' screen, there are a few different pickers you might work with. I wanted to run some code every time one of those pickers was interacted with. Sounds simple enough, right? Using SwiftUI's onReceive modifier does work, but actually getting the value out the picker when onReceive is triggered is much weirder than you'd think.

You have to attach:

[self.*someSelection*].publisher.first()\n

to the onReceive call, and then pass in the value from the picker via a closure. I can only hope that this is fixed in a subsequent SwiftUI update because it was maddeningly difficult to figure that out.

Here's the workaround I found on Stack Overflow - the fix is highlighted at the bottom of the picture:

SwiftUI Issue #2:

At the time of writing, you need to manually pass Core Data's managed object context from one view to another if you want to be able to use that context in the view you're navigating to.

SwiftUI's @Environment property wrapper should theoretically allow the managed object context to be accessible from anywhere. You shouldn't need to manually pass it along.

Unfortunately, this appears to be a bug in the version of SwiftUI I built the app on. So I had to use the following workaround to pass in the managed object context.

Here's what I found:

There were several other small issues that I bumped into when building this out, but those two took me the longest to find solutions for. In general, though, this is what my browser typically looked like while in the throes of SwiftUI development:

So. Many. SwiftUI. Tabs. (shout-out to Hacking with Swift and Swift by Sundell for solving most of my problems)

There's also a third issue that still hasn't been resolved as of this post being published and the app being released. Apple's Contacts frameworks don't work with SwiftUI at all.

To be fair, this is the case with several frameworks since SwiftUI is still so new. However, for most frameworks that don't work natively with SwiftUI, you can simply create a bridge into UIKit. You'd render just those views using UIKit instead of SwiftUI, then come back to SwiftUI when you're done. The interplay between SwiftUI and UIKit was heavily advertised when SwiftUI was debuted in 2019, and, for the vast majority of frameworks, seems to work as expected.

Unfortunately, I've found the bridging between SwiftUI and UIKit for the contact picker to be especially buggy. This is not ideal. The contact picker - which shows up when you tap the 'Add Contacts' button on CatchUp's home screen - is likely the first button you'll ever tap in the app. I don't want a user's first experience with my app to feel buggy and show strange animation glitches.

I filed my first ever Technical Support Incident (TSI) with Apple, and hope to have a resolution for that bug shortly.

I want to make something especially clear, though: Despite the somewhat bumpy road, I have loved working with SwiftUI. It has been a true joy and has significantly improved how I go about creating user interfaces. CatchUp V1 used Storyboards exclusively, and I would be more than OK with never having to create a Storyboard again. I know I could have done my layout programmatically with UIKit, but it's hard to imagine a system as clean and as nice as SwiftUI is proving to be.

Wrapping Up with Clean Code

As I was putting the finishing touches on version 2.0 of CatchUp, I started reading Clean Code by "Uncle" Bob Martin.

I'll tell you what, dear reader, there could not have been a better time for me to read this book.

Since releasing the original app in 2018, I had learned a lot. I knew the SOLID principles, I understood the importance of proper naming and concise logic, etc., but all of that truly sank in on a deeper level upon reading that book on my own.

While reading it, I found that nearly every chapter gave me some new idea on how to organize or clean up my code even further. It was a fantastic experience. I went from code, to book, to code, to book, and back and forth again and again until I was satisfied with the app as a whole.

If you haven't read it, and you want to be a better programmer, I can't recommend it enough. Even being over a decade old at this point, I found it incredibly valuable.

Before reading it, CatchUp 2.0 was a massive improvement in underlying code quality simply from having gained more experience and a greater understanding of what "good" code is. After reading it, I am quite proud of the quality of code I've written. To be sure, there is more work to be done and more improvements to be made. But to have rewritten an entire app from scratch, leave all the cruft and bad ideas behind, and come out on the other end with what I have now is immensely satisfying.

Here's a single point of reference for you: the difference in the number of total lines of code from version 1.1.2 to version 2.0.0, one update (and one year) later.

Lines of code is by no means a proper metric for overall code quality, but I think it represents how much simplification I was able to do for what is, by all accounts, an app that has more functionality than the previous version.

Total lines of code in CatchUp version 1.1.2: 2,924

Total lines of code in CatchUp version 2.0.0: 1,905

Lines of code counted with cloc

Over 1,000 fewer lines of code! For an app that is more advanced and has more functionality. Talk about a significant win.

What's Next

With SwiftUI and cleaner code, CatchUp is ready for the new era of iOS development. I plan to write all of my personal apps in SwiftUI going forward unless there is something that makes it physically impossible to do so.

I'm proud of the product that's available out there now, and look forward to continuing to build on the modern foundation it has today.

CatchUp is completely free with no ads. Download the all-new CatchUp – Keep in Touch here:

$\"Download$

\n"}},{"meta":{"title":"Rebuilding My Website","description":"Why I decided to rebuild ryantoken.com with Swift.","date":"2020-03-22T00:00:00.000Z","imagePath":"/blog-images/rebuilding-my-website/cover.png","imageAlt":"Publish's icon","tags":["web","swift","rewrite"]},"path":"/blog/rebuilding-my-website","postContent":{"html":"

Website V1: Bootstrap All the Things

The summer of 2015 was the summer between my sophomore and junior years at the University of Tulsa. I had taken a few programming classes by that point, and was drawn to web development. To prove to myself that I knew my way around the basics, I wanted to build a personal website – I didn't have a plan for it, but I knew that I wanted it.

Most recently, I had learned about a tool called Bootstrap. Everyone and their mother was raving about Bootstrap. In 2015, it sounded like the end-all be-all for responsive web design. Spoiler: it wasn't. But I, a young and impressionable college student, Bootstrapped the ever-loving heck out of version one of my website.

See for yourself: (most text blurred out for my own privacy)

You don't get much more Bootstrappy than that.

There are several items there that scream Bootstrap (and inexperience) if you know what you're looking for.

What screams Bootstrap? If you're familiar with it at all, you'll probably notice them immediately. The header, the Jumbotron (or Hero Unit, as Bootstrap now calls it), the three-column layout, and the footer.

All four of those items are classic, vanilla Bootstrap with very few modifications. Remember – in 2015 I was a bona-fide noob in the world of web development. I had no idea what I was doing. Bootstrap was awesome, and in some ways still is. It solved a lot of problems for a fledgling web developer.

Also, apparently CSS gradients were the greatest things I'd ever seen, as I threw different variations of them wherever I could fit them.

But hey, this was the first website I had built completely on my own. I had no input from a boss, teachers, or fellow students. I was, and still am, proud that I built it. I learned a lot that I wouldn't have learned otherwise, it helped solidify my love of web development, and when all was said and done, there was a product out there that the world could see.

Iterations

So that was 2015. Until this complete rebuild in March of 2020, it stayed more or less the same for the next several years. It did go through a couple of design refreshes over that time, though.

Notably:

And then:

In the first of those two design refreshes, I got my feet wet with transparency, and added some dynamic functionality to the footer that let you navigate the website page-by-page from there.

The second is how the website looked the day before I published the rewrite you're reading this on now.

I finally got rid of those blue-teal gradient boxes, left the three-column layout behind, added some dimensionality and pictures, and significantly simplified the codebase.

However, after five years of the same basic layout, it was time for a complete re-think of my website. The previous site felt stale and I didn't enjoy working on it or adding to it as much anymore. More than anything, though, was the fact that I'm out of college now.

The previous site was very much focused on me, my resume, and my portfolio of projects. I no longer felt that I needed as much of a 'resume' site. My mindset has shifted dramatically since college, and so my website needed to shift dramatically along with it.

Considering My Options

I knew I wanted to completely recreate the website with modern developer tools and a system that would be easy and fun to iterate on. I did not know, however, what exactly I'd be using to kick this off. To help narrow those options down, I listed out my goals for the site:

It should have a blogging component
It should be fun for me to work on and add to, instead of feeling like a chore
It should be built with a modern language and toolset
It should not look like every other personal website out there

I've added several new skills to my personal toolbox since 2015, my favorites of which are React and Swift I use React for most of my web projects, and Swift and SwiftUI for native iOS projects.

On the side, I run a podcast and blog covering University of Tulsa athletics. As part of that, I built our website with React. That was my first React project, and you might see some similarities to the screenshots above. That's because, more for comfort than anything, I used React Bootstrap to create the front-end. It's basically Bootstrap rebuilt for use in a React environment. It was easy to pick up due to my familiarity with Bootstrap, and I liked it, but I've since been using Material-UI for React projects.

I wrote a blogging engine with React as part of that project, and my first inclination was to reuse the skills I had picked up from that. I would've gone with Material-UI instead of React Bootstrap for the front-end design, but I could have reused a lot of the rest. That would have been the easier way for me, and I strongly considered that option.

Contrarily, I've been pretty deep into iOS development since 2017. I taught myself Swift, released my first iOS app in May of 2018, and have several more that I've worked on locally but haven't released. Let me be clear, I really enjoy writing code with Swift. The type-safety, readability, community, and plenty more made it incredibly fun to learn.

I've long wanted to build a website with Swift, but was never fully satisfied with the available tools. I've toyed around with server-side Swift frameworks like Vapor and Kitura, and found both to be capable but overly-complicated solutions for what I wanted.

And then I found Publish. Publish is an open-source "static site generator for Swift developers" built by John Sundell. John is a former lead iOS developer at Spotify who now runs his own company called Swift by Sundell that is, naturally, all about Swift development. Publish was open-sourced in December of 2019, and all of Swift by Sundell is built with Publish.

A Full Redesign – Zero JavaScript

I cloned Publish from GitHub to familiarize myself with it for a few days, and was hooked. I decided that this was the best (and most fun) answer.

Publish was exactly what I was looking for. It lets you build and configure your entire website with Swift and Markdown, nearly everything is customizable, and it comes with native support for blogging built in. It also supports custom themes, plugins, and a host of other powerful options.

There is zero JavaScript throughout the entire site. This doesn't attempt to solve the Thirty Million Line Problem, but it does mitigate the bloat of JavaScript Framework Hell. Long story short, front-end JavaScript frameworks come with a LOT of bloat, most of which will never be of use to you. Getting rid of all that code speeds up load times significantly, hopefully you'll notice that while navigating my site.

The main Swift file to build a site with Publish is incredibly simple to understand. Here's what mine first looked like:

First, there's an enum called SectionID. This is where you describe what sections your website will have. Mine are the four main tabs at the top of the page: Blog, Projects, and About.

Next, there's a struct called ItemMetadata. This is site-specific metadata which we’ll be able to use in a fully type-safe manner all throughout our publishing process. I don't have anything in there at this point because, honestly, I don't know what benefit it would give a site as simple as mine.

And finally, there are five variables that finalize some information for the website. The last step is the try statement that actually calls on Publish to generate the HTML and CSS files that your browser will serve up to show you this page.

It's really an incredibly simple layout.

This blog post, and every one that will come after it, are simple Markdown files that the Swift package can reference.

Next Steps

When this post comes out, I will still be using Publish's built-in theme for the site. However, Publish uses another framework (also built by John Sundell) called Plot that allows for custom themes to be built and used by Publish.

My next goal for this site is to create my own theme and really customize a lot of it. Step one was just to get it the new site out the door.

I'm incredibly excited for the journey that this site will lead me down. I've been dying to use Swift for something outside of strictly Apple development, and have also badly wanted to create my own blog. Publish satisfies both of those needs while allowing for as little or as much customization as I'd want or need.

I plan to dive head-first into Plot (Sundell's theming engine) in the very near future to add some more color, dynamism, and customization to the site. Keep an eye out for changes in that area soon.

Stay tuned! I can't wait to see how this goes.

\n"}}]

Ryan Token

Blog posts tagged with:

Career