Swift on Lambda while creating feature flags on CloudKit

Some nice articles that might get you to think out of the box this week. Backpressure is a concept I pretty much have not thought about for years. And Sarun has a nice tip on dealing with inconsistent APIs.

• Result builders in Swift - The.Swift.Dev
• Using CloudKit for content hosting and feature flags | Rambo Codes
• Create your first HTTP endpoint with Swift on AWS Lambda
• Backpressure in Combine | iOS Development
• How to decode enums ignoring case in Swift Codable | Sarunw
• What role do Tasks play within Swift’s concurrency system? | Swift by Sundell

Runway
Put your mobile releases on autopilot and keep the whole team in sync throughout. More info on runway.team

Lead Software Developer 
Learn best practices for being a great lead software developer.

Transcript

Jeroen Leenarts: 0:46

Welcome to the fifth episode of my podcast app Force One. My name is Shinola knots. And I've been developing software for over nine years developing iOS app for over nine years, and I'm running the Dutch cocoa hats for over eight years. If you're an iOS app developer, you should listen to my podcast because it will keep you updated on interesting articles, conferences and events you might not have heard about. In this episode, I'm going to talk about result builders in Swift. Using cloud kit for content hosting and feature flags, create your first HTTP endpoint, which 50 on AWS lambda back pressure in combined how to decode enums ignoring case in Swift codable, what role to task play with in Swift concurrency system. And on December 15, I'll be presenting at a Dutch cocoa heads. So let's get started. And now a month in my new role at stream, really enjoying myself there. And hopefully, by the time that this is published, I will have my first piece of true content available online on their website. It's been, it's been in the making for a couple of weeks now. It's been a lot of fun. And what's really great is that there are so many people in the company helping me with cutting this piece out. Yeah, it's just great to see that even in remote environments can be such team spirit when working together on something can't tell too much about it. But there's many great things in store for 2022. On the other nodes. With keyboards, I now created a keycaps SS PlayPad it's it's a small keyboard for macro usage. So it's it's a four by four grid, and I created one with two encoders on it. Really enjoyed this. And my daughter is six years old. She wants to do soldering as well now, so still thinking about ways how can actually do this? Because yeah, one of the soldiering item Irons is, is pretty hot, and can be one of those things to six years old. I'm not sure yet if that's a good idea. But on the other hand, getting her interested in STEM topics is is always good, I guess. So yeah, that let's just dive in and, and see where we'll end up with the content. So the first article is result builders in Swift. If you want to make a result builder in Swift This article will help you deal with the most common cases when creating your own DSL. The result builder proposal originally, it was called function builders was implemented in Swift 5.4. The feature allows you to build a result value using sequence of components at first sight, you might think, Hey, this looks like an array with a series of elements, except the comma in between the items. But nope, this is completely different. But why is it good for you? Result builds can be used to create entirely new domain specific languages inside swift creating a DSL has many advantages. Since DSLs, are usually tied to a specific problem. The syntax that you use to describe the language is fairly lightweight, yet powerful and capable. Since with DSL or typesafe, it's much safer to use one instead of a manually concatenated object. Swift DSLs allow you to use basic control flow inside these embedded macro languages. The article uses HTML as an example to define a DSL, obviously, we know HTML, if you just concatenate a bunch of strings together, it's not very typesafe. But by using a DSL structure can actually create a tree structure of this HTML structure. And this allows you to do much more in depth reasoning about the content that you're dealing with. So you can make sure that everything is type safe, and that there's no mistakes in there, and it's all valid. And in the article, it's clearly explained why swift result builders are helpful when you're defining your own DSL. It's a bit of a technical article. But I must say that there's a lot of code samples in there. And if you just follow along carefully, it's a very interesting read on how a DSL could actually work out in practice, in the Swift language, result, builders is not a very easy topic to get into. But once you get over the initial hurdle, I think it will be very much worth your while to see how you can use result builders in your code. Maybe even define your own DSL glue. Marimba has an article on using Cloud kit, content hosting and feature flex. And the most common application of cloud kit by far is to store private user data with the goal of keeping their device in sync. This is mostly what Rambo's cloud get one on one post is focused on. It also explains the basic concepts of how clouds could works and the best practice around that type of data synchronization. After refreshing what cloudkit is and how it is set up. Rambo actually makes the case for using cloudkit as a way to store content and feature flags for your app. It also goes into the details on what the implication of this would be if your app is the next next grade tick tock or maybe even if it's an app that you want to build an Android version of, according to Rambo, this will just all just work out. Because of the graceful usage theory that Apple provides on the on the cloudkit platform, it's a bit of a different usage of cloudkit. So normally just sync private data, but with this sample that that Rambo explains, you can clearly do a lot more with cloudkit than the initial standard usage of the platform would actually allow. So I found it an interesting read to just think a little bit out of the box for cloudkit. And, of course, all the articles parama always explain everything really nicely. So fabyan wrote an article on creating your first HTTP endpoint with Swift on AWS lambda. It's an it's a tutorial type article that helps you create and deploy your first lambda HTTP endpoints using Swift Of course, it assumes that you have completed another article that Fabiana wrote on the AWS lambda runtime. Since it starts where the previous article ended, I do advise you to have a look at this previous article. So AWS search integrates with lambda by sending specific JSON payloads to lambda. So that's the Swift AWS lambda runtime. It offers a number of ways to execute service out of the box. And as Fabio creates a nice tutorial type article on creating your first HTTP endpoint which 50 on AWS lambda. It's it's part of a series of articles, that explains how you can run Swift code on AWS lambda. AWS lambda is a runtime service that allows you to create Functions as a Service. So it's, you could say it's a fast platform. And it just are allowed to deploy bits of code that could execute it on demand. And if you can deal with the delay of AWS lambda, especially at starting up, then it's actually a very worthwhile way to get some logic cloud hosted. Yeah, if you just want to get started with this, have a look at this article and and see how lambda can actually work. And then based on that you can assess whether or not lambda is something that you could use in your application. Back pressuring combine, and Natasha for diva writes an article on the concept of back pressure in combine. When working with scribes in combined you mostly use sync received value and assigned to one to receive an unlimited amount of files from publisher. There are some cases though where processing those received values takes longer while new values arrive. In this case, we may need to avoid the amount of values that arrive to avoid some kind of blocking or outflow. The concept of limiting the elements of subscriber received is called backpressure. An example of back pressure in practice is processing fails takes time, like reading or writing data. And there's more messages coming in then that you can actually handle in the amount of time that you have available. So there are several strategies that you can deal with back pressure, for instance, just buffering everything or dropping items that are coming in. And both of these strategies can be implemented in different ways either by creating a custom subscriber or by using combines buffering and time operations. The article by Natasha goes into some detail on how you can actually create a back pressure mechanism in your implementation using combine. And it's a nice step by step article that shows how you can implement this and how we can make sure that back pressure is concept that your implementation can properly deal with. Saloon wrote an article on how to decode enums that ignore casing in the Swift codable structure. Swift makes it effortless to decode enums from its raw value, all you need to do is make sure your enum is row representable, and that your inner conforms to codable, of course. So it turns out that someone recently had the situation that he had to deal with the legacy ecosystems API where enums can represent in both uppercase and lowercase. In his article, he shows how you can create a case insensitive enum decoding strategy to deal with this inconsistency in the API that he was working with. So it's a fun challenge. And yeah, here's a nice solution for it. It's quite simple, but it's it's something that you should be aware of, if you ever run into the same situation. And it also is a nice showcase of some of the details related to codable and and and how you get a single failure container and how it can decode failures out of that. The next article is by John sandal. Now what role do tasks play within swift concurrency systems? Around writing asynchronous code using Swift new built in concurrency system creating a task gives you the access to a new asynchronous context in which you're free to call async marked API's and perform work in the background. But besides enabling you to encapsulate a piece of asynchronous code, the Task Type also lets you control the way that such called Run managed and potentially canceled. Perhaps the most common way to use task within a UI based application is to have it acts as a bridge between your synchronous main thread bound UI codes, and any background operations that are used to fetch or process the data that your UI is rendering. So it's basically an article that details how tasks can play a role in gluing code together that is on the main thread and call to this executed off the main thread. Of course, you want to do this correctly, and make sure that it did all works in a way that it doesn't crash your app, and that you don't have any race conditions. And by using tasks in a new Swift concurrency system, it is clear that there's like a really clean way to deal with asynchronously, and your application calls. And John goes into a lot of details on how you can actually do this. So the STS New Task Type enables you to encapsulate observe, and control a unions have asynchronous work, which is something that in turn allows you to call async marks API's and perform additional background work, even within code that otherwise completely synchronous, that way, you can gradually introduce async functions and rest of switch new concurrency system. Even within applications weren't designed with those new features in mind, in a way, John advocates that you start implementing the new asynchronous API's in Swift gradually, and that you take a step by step approach to actually do this. So as already mentioned, I'm presenting at the Dutch cocoa hats on December 15. So if you want to join them, just have a look at cokehead Staaten URL and make sure that you end up at a meetup page. And obviously, if you're listening to this after December 15, there's always ways to enjoy the next presentation by CO grads, but also gone to their meetup page. And that's it again for this week. I must say that lately, I've have been in a bit of a time crunch show recording my regular episodes, but it's it's all I think part of getting into the groove at my new role. I'm really enjoying myself as of late, but I must say that okay, occasionally I do have the feeling that a day has too few hours to do everything that I want to do in a day. But talk to you again next week. And just keep sending me feedback on what you like and didn't like about my episodes, feedback you can send to at app force one on Twitter, and yeah, just DM me or send me a message and we'll make sure to respond to it.