The New Notification Stack for Developers - Mike Miller

Sr. Software Engineer, Courier

Noah:

Howdy, listeners. Today we are kicking off a new series of interviews entitled The New Notification Stack for Developers, brought to you by our longtime friends and sponsors of the Code Story podcast Courier. As a reminder, Courier is developer infrastructure for product notifications, making it easier to deliver the notification experience that your customers expect. Check out their product to learn more at Courier.com.

Noah:

Well, today I have a special guest on the Code Story podcast, Mike Miller, the lead mobile SDK engineer at Courier. He has many years of experience in product management, UI, UX design and mobile engineering. Mike, thank you for being on the show today.

Mike:

Hey, thank you for having me. Excited to be here.

Noah:

Before we go too far into our topic for today, tell me and my audience a little bit more about you.

Mike:

Yeah. Been doing a lot of startup things for about ten years and worked at a bunch of different startup companies, built a bunch of different products from scratch on not only the design side but the mobile engineering side. So along the way, I got a bunch of experience building notification systems out from scratch, experienced a lot of issues there.

Mike:

And now I lead the mobile engineering team at Courier, building the ideal way to make push notifications happen in your app.

Noah:

I would imagine, given your track record of the things you've worked on, a lot of the mobile space you've had to rebuild and rebuild and rebuild this a ton of times and now you're setting it up the right way. Am I understanding you correctly?

Mike:

That a good way to put it. I've definitely learned the wrong way many times. Now I get to definitely stay on the right side of things.

Noah:

And that's awesome. Well, cool. Let's dive into that then. So the happy path for building push notifications as a mobile engineer, as someone who's setting up mobile mobile apps, what is that happy path? What is the happy path for building push notifications in an app?

Mike:

So typically you're going to get some sort of design piece that you need to solve for your users. So that's like, hey, we're going to send a message out and we need users to come back into the app. That's like the user experience. You know, we've all seen pushes before. You like somebody post on Instagram, they get a push notification saying, Hey, somebody liked your post, your DoorDash delivery is on the way.

Mike:

Maybe there's a sale in some sort of store type app that you need to hear about. So they're trying to reengage you. As a developer then, what you have to do is you have to figure out, okay, how are we going to send these messages? When the user receives this message on the device, what are we going to do?

Mike:

How do we make them go into the app and navigate to the right page? So this usually starts with Googling how do push notifications work and you figure out that, okay, I need this thing called a push notification device token. Then you figure out you have to store these device tokens in your database. Then you have to figure out how to get those tokens out of your database and send a message to the token.

Mike:

Then if everything goes well there, which usually it doesn't. If you're lucky enough, you get to now make the notification actionable in your app, which requires a whole other set of things to understand. And then you can finally start to make your app do something when someone receives the notification.

Noah:

So you're using notifications to reengage users or to hook people into the application again. And throughout the way, there are different things you have to do to register a device and to receive that information and do something with it. Right. What are some of the most common problems that mobile engineers face when building push notifications? Because, you know, being a mobile engineer myself, I could guess where you're going to go with some of these things.

Noah:

But I'm curious what you have to say there and in how you're describing that path. There's lots of different pitfalls, I would say, and probably complexities that are hidden in your descriptions. So tell me about that.

Mike:

The first thing is developers, you know, go through and they start Googling a bunch of different things about push notifications. Push notifications have changed a lot over the years. The original ones that came out on iOS are not the same exact way they are now, and same for Android. So there's a lot of questions and answers on your Googling path that are old.

Mike:

So one of the common pitfalls is that people will put the request push notification permission prompts in a weird part of their app. I think we've all installed an app before and had it say before you've even used it, you just open it up and it says, Do you agree to push notifications? And you're like, Wait, what? Like, I've never even used this app.

Mike:

What are you going to send me? And I think that the root of that is from old answers on the Internet and people just kind of quickly adding the code snippets into their app in places that aren't ideal for the user experience. Another common problem is when you go to send a message to a push notification token, the data that you send to that token has to be perfectly structured.

Mike:

And if it's not structured perfectly, it's either very difficult to debug or it's not possible to debug. You can send the message and have the message go through successfully, but you won't receive it. So it must be structured in a really particular way in order to receive that message on the device. Another thing is as you build these out, you typically have to bring in more engineers or just different parts of your stack into understanding what it takes to receive these messages and send these messages.

Mike:

So it's very common to be like, okay, I'm going to add pushes without realizing, Oh, I need to work with the backend team to store these tokens and send these messages out at the right time. And that can create just more collaboration that you maybe didn't plan for early on.

Noah:

Okay, So. Then let's let's jump into Courier then. So how does Courier’s mobile SDK solve these types of problems?

Mike:

Courier is building a super awesome notification infrastructure as a service, so a lot of the rails that you would normally have to build into your app Courier is building and they're already in place. You don't have to rebuild a lot of these systems from scratch like you used to have to. And what the Courier mobile SDK has done to integrate with Courier is we automatically do much of the heavy lifting.

Mike:

So if you use the mobile SDK, you don't have to manually sync push notification tokens, they're automatically synced to Courier. All you do is just use the SDK, how it's documented, integrate it into your user experience you're building and you never have to deal with a push notification token ever again. So you don't have to worry about it being valid or invalid or anything like that.

Mike:

We've also automatically structured the data you send via a push notification in a way that gives you good insight if there are errors, but most errors are completely gone. So you can get up and running, sending messages to the device very quickly. We have quite a few convenient functions in there, so you can request push notification permissions when makes sense for you and not have to deal with Googling how to ask for that.

Mike:

It simplifies quite a bit down there in terms of managing, getting the pushes up and running or getting the pushes to where you can receive them nicely. And then we have a nice function that allows you to send a test message out to yourself so you don't even need to set up like a back end or work with a back end engineer or do raw HTTP calls like all of it can be done from right inside the SDK and one engineer can get up and running with all of it.

Noah:

Nice. Okay. So that leads me to my next question. Really, really well. So how does this affect the collaboration process for a mobile engineering team? Right. Because it simplifies the process. It simplifies how a back end engineer has to, you know, sort of create the innards for a messaging system. But for the mobile engineering team themselves, how does that affect the collaboration process?

Mike:

A lot of this is designed in a way, a lot of how we design the implementation of the code is designed in a way where one engineer can get up and running. So I can create a Courier account, I can grab my key out of there, I can implement the SDK, I can use that key to our simple authentication function flow and start sending messages to myself.

Mike:

Once, once that's all good to go, you can then start to integrate the more complicated parts into your backend and expect the same exact result. So I could get up and running and getting pushes onto my device as one engineer, then I can pass over to the backend engineer, use this specific sender quest to Courier, and then I expect to receive those pushes in the same exact way that I had been testing with.

Mike:

So no longer having to build the infrastructure to manage things from scratch. Just work with your backend to send the right messages.

Noah:

Okay. So I'm sold, right. I want to get up and running. How do I set this up? How do I get the mobile SDK integrated into my app?

Mike:

So first you can go to Docs.Courier.com underneath the client library section. There are four stickers. We have an iOS, Android, React Native and Flutter SDK. They all support APNS. Apple Push Notification Service and Firebase Cloud Messaging. You can follow each repo if you just go to GitHub, you can see the repo and you can follow a nice step by step guide to get up and running.

Mike:

We really try to minimize the amount of code that somebody has to write, so it's definitely consolidated down to as few lines of code as we can try to get to at this point. And maybe we can remove some more steps as time goes on. But yeah, it keeps it really, really simple that way. So you can just follow the docs.

Noah:

Spoken like a true developer. Follow the docs. Right. Okay, Mike, this all make sense to me. And you being a mobile engineer, I'm connecting with what you're telling me, but let's quantify it a little bit. So in building my mobile application, my mobile experience, how many lines of code am I saving by going and using Courier or, you know, how much time am I saving by going and using Courier?

Noah:

Tell me a little bit there.

Mike:

So the mobile SDK’s save a considerable amount of code, not only on your mobile app but on your back end. And most of this is what's crazy is most of the mobile SDK’s are kind of just integration more so than actually like code. So once you sign a user in and you request push notification tokens, there's basically one other function that is what you want to do when the notification arrives on the device or when a user clicks it.

Mike:

And that's about it. Like normally that would be many, many days of hunting through potentially outdated documentation from Apple and Google working with your back end engineer. So we really consolidate probably things down into less than 50 lines of code or around there and saving many, many days you can get up and running with the mobile SDK is within a couple of hours.

Noah:

Okay, I got to ask Mike as an engineer myself and as someone who's built stuff, how does it feel to be building something that truly helps developers save time? It simplifies a process, and this is something that, you know, in the past would have made your job easier. How does it feel to be building that for other devs?

Mike:

It's awesome. When I joined Courier I had been very familiar with this problem for many years and my mentality is as we continue to build this, it's if we're building this once and for all, for like a million developers, like how would we structure this? How can we remove as much complexity out as possible and just make it to where developers get to focus on creating a great user experience rather than building notification infrastructure?

Noah:

Well, Mike, thank you for being on the show today. I think this has been an excellent overview on the mobile SDK. The problems for mobile engineers and why Courier's mobile SDK and approach to integrating notification infrastructure into mobile app is is super simple and easy to use. I really appreciate you be on the show today.

Mike:

Yeah. Thank you so much.

Noah:

This was an awesome conversation and a bit nostalgic for me to recall some of the mobile engineering pain that accompanies setting up push notifications within an app. Mike did a fantastic job illustrating how Courier is simplifying this process not only for mobile engineers but for the entire engineering team involved. As a reminder, Courier makes it easier for you to deliver a world class notification experience that your customers expect to learn more about their product and get started today, Check out Courier Dotcom and thanks again for listening.