Anwesa Chatterjee

As a product manager, have you ever had to say no to improving your app’s notifications because of how complex the project seemed?

If yes, you’re not alone. At Courier, we frequently see product teams deciding not to work on notifications. And PMs aren’t making that decision because a good notification experience is not important for their SaaS product or service — quite the opposite.

The reason is that changing notifications, in their experience, requires a lot of work between engineering and product due to how closely the notifications are tied to the rest of the application. If PMs are tasked with adding a new email campaign that all new users of the app will receive, that can usually be done outside of the core app. But sending more unique notifications, like alerting a Slack channel when someone @-mentions their colleague in a shared file, can be complex and require significant engineering work. And still more work is needed when the text or the design of such a notification needs to be updated.

We believe that changing notifications doesn’t have to be so difficult. In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex and less risky for product teams.

## Why PMs believe notification projects are hard

![image1](//images.ctfassets.net/z7iqk1q8njt4/6kGqayxYctQyy0qkn5MolS/74f523a316788e845e22186ca06c979e/image1.png)

Usually, the task of improving an app’s notification experience — like adding or changing notifications, or connecting additional notification channels — falls to the engineering team that’s responsible for the main product. Such teams have lots on their plate, which makes it necessary to prioritize some tasks over others.

Notification projects tend to be high-value for product managers, as a bad notification experience can have a negative impact on a SaaS app’s customer base, while, conversely, a [good notification experience](https://www.courier.com/blog/pm-product-notification-experience/) can drive growth metrics and delight customers.

However, notification projects also score high on complexity and risk at most companies. That’s because different notification channels, which are quite different by nature (think email versus mobile push), require a lot of individual engineering.

With so much complexity involved, product managers have to make a tough call: is it really worth taking on notification work when there are easier projects to work on with more tangible benefits? Because task backlogs frequently have other items in them that don’t carry as much complexity or risk, it’s logical for product managers to postpone rather complex notification projects. And so notification projects get moved down the priority list, again and again.

## The limits of common engineering solutions to notification problems
To try and make notification changes less difficult to implement, engineering teams use open-source tools that are well supported within their framework or programming language of choice. For example, those working with Ruby on Rails applications often use Rails’ built-in email sending module, [Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html), which includes functionality for sending plain-text and HTML emails.

While tools like Action Mailer are convenient to use and well-maintained, they can’t handle more complex tasks like expanding beyond the standard notification channels. If you want to add Slack or SMS notifications, for example, choices like Action Mailer can become a limiting factor, rather than an enabler of new product functionality.

The next logical option for a software team running into tooling limitations is to go with a fully customized notification system — but such a system brings its own challenges.

## Even a custom notification system is a bottleneck for notification improvements
It may seem that the solution to the limitations of open-source tools is to simply build your own custom notification system. But a custom notification system is still code that implements notification logic, supported channels, and templates for specific notifications, and this code lives inside the application codebase in a version control system like Git. Any changes to this part of the codebase have to follow the steps of the software development process, which becomes cumbersome when making many small changes, as is the case with notifications. (Not to mention that engineering time needs to be allocated to the maintenance of such systems in the long run.)

For example, if the task is to update the wording or the design of a notification across all channels, the engineering team tasked with the work might have to:

* Change the HTML email template.
* Change the Slack notification template.
* Change the Microsoft Teams notification template.
* Test all three changes.
* Wait for code review on the changes.
* Once the code is reviewed, deploy all three changes to production.
* Hand off to the PM for a final confirmation.

And every time a PM wants more changes implemented for notifications, the process has to start over again, even for trivial content changes. The standard development process, which is totally reasonable for code changes, is too much overhead when working on notifications, and the additional overhead takes the engineers’ time away from working on more valuable things.

## The result: notifications rarely get updated
Because of the additional delays introduced by the development process, the friction for implementing notification changes ends up being so high that PMs often choose to not implement notification changes at all. 

Instead of focusing on building the best possible notification experience, they settle for the default notifications that are built into their application already, because anything else becomes too difficult to do. They might think “If it took two weeks to change the simple design on my notifications, we're just not going to change things anymore.” And so notification experiences stall out indefinitely.

## There is a better way: enable PMs to work with notifications without involving the engineering team
Courier’s point of view is that the way notifications are handled in most SaaS apps today — templates stored in code, notification functionality changes requiring code deployments, etc. — is outdated and, as we have seen in the examples above, ineffective.

Instead of having to go through the development process for each notification change, we need to give PMs and other non-technical stakeholders the right tools to work with notifications directly. Here are the core practices that act as enablers for non-technical audiences.

**Making templates accessible to non-engineers.** Notification templates in the form of text, HTML, or programming-language-specific template files need to be located outside of the application code, and PMs as well as other non-technical teams need to have access and be able to make changes.

**Making notification logic configurable without needing to re-deploy the app.** The logic involved in deciding which notifications to send when should not be located in the application code, but rather sit next to it and be configurable without needing to deploy the application. The configuration can live in a text file, a web interface, or another config format. PMs should ideally be able to change the configuration themselves.

**Enabling self-serve analytics.** Besides notification functionality, PMs need to be able to track how their changes are doing — and be able to follow the statistics without the need to ask engineering or data teams for the numbers. Analytics can be presented as a custom dashboard, but can also be an export of a business intelligence report, or even a dump of application logs that show which messages were sent, depending on which option is easier.

## What are the results of PM enablement?
To show that PM enablement works as a way to make notification projects easier, we want to share two examples from Courier customers that have experienced this change.

Bluecrew, a marketplace for hourly jobs, [has seen its business grow](https://www.courier.com/blog/courier-bluecrew-multi-channel-notifications/) after decoupling notifications from application code. The company was able to improve the onboarding experience for new users in part by taking advantage of notification templates and making them accessible to non-technical stakeholders.

Within Bluecrew’s notification system, “anyone can add a content block and insert a custom attribute like ‘shift start time’ or ‘cancelation reason.’ We also have the flexibility to add custom code anywhere in the notification,” says Cooper Newby, the Chief Product Officer at Bluecrew. 

Another company that’s been taking advantage of the enablement approach is [Expel](https://expel.com), a provider of security services. The Expel team has enabled its UX designers to use the template designer UI directly and make changes to the product in real time.

“We can get our UX designers working directly on the templates and we can make updates and have them live in seconds,” says Yousuf Ashparie, Principal Software Engineer at Expel.

Does enabling PMs to make notification changes sound appealing at this point? We hope it does — as we believe it’s a significant improvement over the current practices at most companies. Let’s look at how you can enable PMs to work with notifications in your own team.

## So, how can you enable PMs to work with notifications?
Looking to enable PMs to do more notification work, but not sure where to start? Here are our top recommendations for companies looking to get started on the PM enablement journey.

**1. Get analytics in place.** Having analytics for notifications is a key tool for PMs to measure any notification changes. While metrics can be difficult to come by for some notification channels, it is usually possible to have at least some numbers in place. Once the PMs get the data, they can use it to avoid accidentally making the notification experience worse, and to make sure the rest of the organization can see the benefits for larger changes to notifications.

**2. Make it easier to change notification templates.** While it’s ideal to make all notification channels and notification types configurable by PMs, it’s not always realistic. Instead, at least make it so that PMs can change existing notifications without much involvement from the engineering team. Even if that’s all you allow, you will still need to add functionality to adjust notification designs to fit the updated content, and likely implement internationalization and translation workflows if you’re interested in supporting multiple languages.

**3. Build guardrails to prevent notification issues from escaping to production.** Ideally, all notification functionality should be covered with automated and, possibly, manual tests so that the organization can be confident in the product’s notification experience at all times. The areas to check include: notification text fitting within the display area; possible internationalization glitches; technical issues like app crashes resulting from changes in notification text size; handling of unexpected characters if notifications include user input.

## Courier can help
Instead of building everything yourself, use Courier — and get our recommended steps 1–3 done almost instantly after some brief initial implementation work.

Using Courier frees up your team to focus on other valuable things in their backlog. For PMs, UX designers, and other non-technical stakeholders, Courier helps by:

* providing a drag and drop designer, including a staging environment, with the ability to make changes live without deploying the app
* offering a UI that allows users to add new notification channels without needing to update code
* including an Automation UI that allows users to build out notification workflows visually (no application code)
* Implementing the guardrails in point 3 above, so that you can reduce the effort involved in changing notifications without increasing the risk.


Check out how Courier has completely removed any need for product managers to mess with the code for notification content, logic, and design!

PMs shouldn't be writing code...

pm-guide-2-header

In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex for product teams.

pm-guide-2-thumbnail

How Decoupling Notifications from Your Application’s Code Empowers Product Managers

nica-headshot

Nočnica Mellifera

Or, how we’re destroying users’ trust, and how to get it back. Check out the first post in this series as well: *[Building a Great UX Outside of Your App](https://www.courier.com/blog/building-ux-outside-of-app/)*.

There is a direct connection between all the unnecessary notifications you get on your phone and the sub-prime financial crisis of 2008. The connection is human behavior in a large and anonymous marketplace where bad behavior is rarely punished.

In a recent [Hackernews post](https://news.ycombinator.com/item?id=32692884), I posited the same connection: that apps that send notifications are facing a systemic collapse where users will be so overwhelmed with mass notifications that most of them will opt out entirely. One user responded with a great synopsis of the problem:

> Unfortunately if it drives engagement of 2 people at the expense of becoming annoying to one person the app developers will keep over-using notifications.

I’d add one further sad corollary to this observation: as long as other app developers are over-using notifications, it’s irrational for you the app developer not to. As you compete for attention on users’ devices, you will fall behind your competitors if you don’t emit a few notifications a day. So even though your individual action hurts the user experience overall, it can be irrational for you to avoid doing so.

As any fan of financial crises can tell you, the subprime bubble, where lenders created AAA-rated securities out of extremely shaky mortgage lending, was not an evil scheme dreamed up by nihilists. Rather, it was the act of rational people acting in their own best interests. As long as other banks were selling junk securities at high markups, it wasn’t rational for one bank to stop, even when they knew the system couldn’t go on forever. As former Citigroup CEO Chuck Prince infamously said, “as long as the music is playing, you have to keep dancing.”

## What the crash would look like
Any time I start a discussion on Reddit or Hackernews about what users want in notifications, most commenters say that they want out of notifications entirely. It was only three years ago that most users got ‘do not disturb’ mode on their phones, and more and more users are deciding to stay in Do Not Disturb *forever*.

Can notifications ‘crash’ the same way that the mortgage market did? Absolutely. The sequence looks like this:

* Increased awareness of unnecessary notifications
* Government regulators request that OS producers limit unnecessary notifications
* All notifications become tightly restricted
* Contacting users via push notifications becomes unreliable 
* Application developers no longer invest the time in timely notifications
* With users no longer expecting notifications, developers are forced to go back to email and SMS to contact users at all

## The Prisoner’s Dilemma
John Cassidy in his illuminating book *[How Markets Fail](https://us.macmillan.com/books/9781429990691/howmarketsfail)* explains that this pattern is in fact a version of the prisoner’s dilemma. The multiple actors in the market aren’t able to coordinate and they end up choosing options that are individually beneficial, but collectively negative.

The sub-prime crisis nearly crashed the global economy and we still live in its shadow. In the world of notifications: every OS release on our phones further limits how apps can notify us, is a similar crisis coming in the market for user attention?

## How we break free
A dire situation, surely, but we can do something about it: collaboration. The prisoner’s dilemma doesn’t work nearly as well if the prisoners can communicate and see each other’s choices. In the case of notifications, all that’s required is that we the creators of applications agree to some simple principles for trustworthy notifications.

This move is not without precedent. Multiple industries decided on voluntary pledges of quality and trustworthiness rather than deal with public ire, choosing self-regulation over government regulation. Perhaps you remember this seal from the childhood newsstand:

![crisis-1](//images.ctfassets.net/z7iqk1q8njt4/2nsPqQwBpHIueEHCVrtoQl/82d7f10962cbd1731f1ee55036cc23e0/crisis-1.png)

Next to Captain America’s adventures and even Grant Morrison’s Swamp Thing, the Comics Code Authority seal was stamped on the cover of comic books for over 40 years. And perhaps you saw another sign of voluntary self-regulation in an air-conditioned theater this weekend:

![crisis-2](//images.ctfassets.net/z7iqk1q8njt4/1W7YN13dcLNuTHnGnir9Vv/433631f477614ba9671a680587009def/crisis-2.png)

Neither of these ratings and advisory boards are without their detractors, and as Comic book fans aged and concerns about violent comics diminished, the comics code has disappeared. However, these do show that a lack of public trust can be addressed by an industry-wide standard.

## A pledge for better notifications
Folks, I don’t want to be corny, but I do want us to get better. Here we get to the crux: I want us to agree to do better. Here are the principles that can guide better notifications.

*One caveat here: this pledge is not about dark patterns or dishonesty. Tricking the user into spending money unintentionally should be covered by generalized ethics, this is about good design principles for developers who want to build trustworthy tools.*

### 1. Be timely
We often feel bombarded with notifications, so a requirement that they come faster can seem counter-intuitive. But it’s critical that you identify when and with what precision your users expect to be informed. A notification that your web service is down needs to come sooner than the first angry call from a user. And a notification about breaking news needs to come before you say something mean about Queen Elizabeth on Slack. 

![crisis-3](//images.ctfassets.net/z7iqk1q8njt4/CskUDdiZMdgRl1RvZpzhi/3bf58dc29d3f3195aebd59a53df193d6/crisis-3.png)
*When the Steam Deck inspired a purchasing frenzy, many users complained they got inaccurate notifications, like this classic epoch failure for a user in the UK*

Timeliness also means not notifying too quickly. Notifications about how many people liked a cat picture don’t need to arrive at 2:00 AM, they can wait til morning. 

The required accuracy of notifications will vary a lot depending on your use case. A scheduling tool like Calendly will need its notifications to arrive on the exact minute we need them to arrive at a meeting on time. A more fun social app probably only needs to send notifications accurately within 30 minutes.

![crisis-4](//images.ctfassets.net/z7iqk1q8njt4/3jiPBK4MyEafiuSly0RPta/7f567998e084a0a5966b1e8036873f0b/crisis-4.png)
*This failure by YouTube may reflect a shift in usage patterns: where previously new and interesting videos didn’t need up-to-the-minute notifications, now users get breaking news and important premieres on YouTube.*

### 2. Be targeted
We may not want our applications to know everything about us, but targeting is a critical part of good notifications. If I ordered Pizza Hut for lunch, I don’t want them notifying me of dinner specials. Look at this not-ideal experience for a user of Accuweather that warned him of thunderstorms…3,000 miles from his current location:

![crisis-5](//images.ctfassets.net/z7iqk1q8njt4/3EZ0BStlnMusDD464RsorU/43052cf882848ee5430b53cc13944d12/crisis-5.png)
*The cut-off text makes the situation worse: it’s easy to assume this is happening in your town!*

Some things we’d ideally target in our notifications:
* Geography
* Time Zone
* User’s access level within our service
* Where they are in the user journey

### 3. Be brief
In the example above from accuweather.com, a slightly wordy notification meant the user didn’t see the area affected by the alert. This is one example of a larger problem: a failure to be brief and to-the-point with notification messages.

Since notifications are often shortened when viewed on different devices, be sure to put the most important information first. Journalists would call this the ‘inverted pyramid’ but I prefer to think of it as a special case of little-endian transmission: the least important information should come last.

A special case of the requirement to be brief is digests: ask yourself if your notifications are more meaningful in a group or one-at-a-time. Notifications of individual ‘likes’ on a post is a great candidate for a digest, as is a long conversation thread.

Ideally since you’re following rule 2 and therefore know the user’s timezone, you can dynamically generate digests when notifications would be sent in the middle of the night for the user.

### 4. Offer (the right amount of) control
Finally there’s control. If I posted every bad example of user preferences for notifications this article would resemble 2000’s Flickr. But:

![crisis-6](//images.ctfassets.net/z7iqk1q8njt4/7k9Yb2Js0xw1tAAvczkx9T/c71c080f37ae7249d22ff251d830428e/crisis-6.jpg)
*A classic example is Starbucks’ which, for a time, would only tell you order status if you also accepted spam*

So we want to offer users real fine-grained controls. But it is possible to get too fine-grained

![crisis-7](//images.ctfassets.net/z7iqk1q8njt4/AtDdpPBn2oT7fJTbbZEZI/fe645350138a19d7e5f892d3dc098c07/crisis-7.png)
*If you zoom in, this is every notification setting for Google Maps*

The solution when you have too many settings is to offer some grouping, so that users can turn off whole categories.
What unifies these needs?
The common thread between all of these requirements is that they all require technical lift. Timeliness, targeting, brevity (with digests), and user preferences all require that we go above and beyond with our notifications service. A simple bulk send email kicked off by a cron job can’t deliver these features without some very sophisticated and un-maintainable regex. The solution then is to have a notifications service that can offer these features in a lightweight experience for our product team.

In the last article of this series, we’ll cover how you can build a great notification experience *without* using Courier.


You can use the tips in this post to apply to your own internal notification system, or you can check out Courier to handle it all for you.

Avoid a notification crisis like the 2008 crash! 

woman on red backdrop screaming in annoyance as she is inundated with too many notifications

sub-prime-crisis-header

There is a direct connection between all the unnecessary mobile notifications you get and the financial crisis of 2008: lack of accountability for bad behavior.

sub-prime-crisis-thumbnail

The Sub-prime Crisis of Notifications

shreya-headshot

Shreya Gupta

Learn about how Courier might be able to help you reduce engineering complexity and deliver a better, more engaging notification experience.

Speak with a notifications expert

A swan pulls a ready-made nest out of a Courier box while a duck has to build one from scratch across the pond.

build-vs-buy-header

This post gets into the “7 C’s” that should be considered when deciding to build vs buy. Learn about how Apartment List implemented this process.

build-vs-buy-thumbnail

Build vs Buy: The “to be or not to be” of Tech

nick-headshot

Nick Gottlieb

As modern applications have become increasingly feature-rich and performant, user expectations are at an all-time high. Failure to communicate key information or displaying out-of-date information frustrates users and causes a loss of trust. Think about the last time you ordered something online: if you didn’t receive your order confirmation within seconds, you probably began to worry that something went wrong. Users require product transparency for consistent use.

Luckily for developers, a proliferation of new APIs have been developed to help provide features such as real-time order update emails, push notifications based on in-app activity, or live chat with sales and support. Communications APIs are becoming increasingly specialized, with each type being more or less suited to certain tasks.

If you’re an engineer who’s been tasked with planning out your application’s communication strategy, this post will help you map out the landscape. You’ll come away understanding the three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience. We’ll also show you how using the right APIs in the right places will streamline your own day-to-day work.

Let’s get into it! 

## Planning Your Communications API Strategy

The best outcome any engineer can hope for is that your communications strategy is so smooth, it isn’t even noticed. For the end user, it just works exactly when it’s supposed to work, the way it’s supposed to work. For your own internal teams, everyone has the ability to craft the messaging they need and send it when they need, without unnecessary bottlenecks that can often impact your own engineering time.

In a marketplace application, for instance, users need to get an automated push notification or email every time someone comments on an item they’re selling. The marketing department also wants to send email campaigns to everyone who has purchased an item in the past six months to let them know there’s a sale coming up. When a buyer’s checkout fails, they might need to message your sales or support team to get help and complete the transaction. 

All of these are very different examples that will need to use a different type of communications API to get the job done.

## Exploring The Three Types

Communications APIs are segmented not only by the functionality they provide and how immediately they need to respond to user actions but also often by which teams at the company will need to use them to send messaging. 

App-to-user APIs are highly customizable, instant communications sent by engineering as integral parts of the application experience, such as push notifications about likes or comments. Brand-to-user APIs collect data and give the company, particularly marketing and product teams, the ability to send users targeted messages individually or en masse. User-to-user APIs facilitate live chat either among app users or with someone at your company, such as sales or support.

Let’s discuss the strengths and weaknesses of the three types of APIs, and see some commonly-used third-party providers for each.

## App-to-user APIs

App-to-user APIs are transactional messages that are embedded into the application code. These APIs are often the most mission-critical of the three, as they form a core part of the application experience. For instance: your rideshare has arrived, your order was received, you have just been added to this chat room, here is your one-time password for login. These types of communications tend to be time-sensitive and are designed to send immediately when the trigger events occur.

A robust App-to-user API will provide multi-channel communication (email, SMS, and push notification), complex routing, and easy opt-in and opt-out for users. Most can be heavily automated as well. For instance, when a new user is created via Auth0, a welcome push notification can be automatically sent.

App-to-user APIs are typically instrumented and used by engineering teams. Companies who have the resources may choose to build their own App-to-user API infrastructure, which we have [a guide on how to do here](https://www.courier.com/blog/the-developers-guide-user-requirements). Courier also provides a ready-to-use App-to-user API infrastructure. 

## Brand-to-user APIs

Brand-to-user communication happens any time your company has a message for a specific group of users. Maybe the product team noticed that a user got partway through the sign-up flow but didn’t hit the “complete” button. Maybe marketing wants to tell everyone in New York about an upcoming in-person event.

Braze and Customer.io are two examples of out-of-the-box Brand-to-user APIs. Engineering implements API calls in the application code that log information about user behavior, which then gets sent to a separate dashboard other teams at the company can access. Anyone on those teams can then use that data to craft and send messages to specific subsets of users. For instance, users who didn’t complete the sign-up flow, or who live in New York. Brand-to-user APIs save engineering time because, once the initial API calls are instrumented, any team who needs to send campaigns or needs to access that data can do so easily and independently.

While Brand-to-user APIs make it easy for anyone at the company to send messaging to users, they typically aren’t configurable enough to power core parts of the application experience. Messages can go out minutes to hours after user criteria for the message have been met. There can also be implementation delays any time you want to send messages based on a different set of criteria than you were using before—new API calls in the app mean the data needs time to populate before they can be used. 

While this trade-off is often worthwhile for marketing and product communications, App-to-user APIs (discussed above) are a much better fit when you need fine control over messaging content or timing within engineering.

## User-to-user APIs

User-to-user communication APIs facilitate active conversations among two or more individuals—either between a user and someone on your own internal staff or from one app user to another. 

Support tickets, for instance, are a type of User-to-user API, as are live chat boxes that let customers have direct conversations with your support or sales teams. Likewise, two users in a marketplace might need to message each other to offer bids or send along shipping information. While these are possible services to build out in-house, most companies opt to save time by going with a ready-to-use SaaS solution, such as Intercom, Zendesk, or Sendgrid.

## Conclusion

Most applications will use more than one type of user communications API for different parts of the user experience. Your application may very well use all three! 

App-to-user APIs provide part of the application’s core functionality. These APIs are highly customizable and provide instant user communication that is tightly coupled with your application code. Marketing and product teams will often want a Brand-to-user API implementation that makes it easier to see user data and send updates to users. User-to-user APIs give customers access to back-and-forth communication either among each other, or with company support or sales teams.

When you’re thoughtful about your communications strategy, you can create a seamless experience for users while also enabling everyone on your team to save time and do their best work. 

Read on for more information on building user communication API infrastructure:

* [The Developer's Guide to Building Notification Systems: User Requirements](https://www.courier.com/blog/the-developers-guide-user-requirements)

* [How to Set Up Multi-Channel Notifications in Your AWS Stack](https://www.courier.com/blog/multi-channel-notifications-aws)

*Illustration by [Rebekka Dunlap](https://rrebekkaa.com/)*


Courier is single platform for designing, orchestrating, and routing notifications over channel providers for email, SMS, chat, mobile push, and more.

Are you delivering a delightful UX notification experience?

Three different people using a computer, tablet, and smartphone look up as magic surrounds them indicating the ease of communication through apis.

user-communication-apis-header

This post describes three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience.

user-communication-apis-thumbnail

3 Types of User Communication APIs and When to Use Them

*We recently had the opportunity to speak to a student audience at Serverless Days and came up with some insights that we felt were worth sharing with a wider audience. Please take a look and let us know your thoughts [@trycourier](https://twitter.com/trycourier).* 

Serverless architecture is relatively new, yet many startup developers prefer building their foundation on a Serverless framework. But what's with the hype? What makes developers trust Serverless to the point that companies are willing to spend their resources to rewire their entire backend infrastructure to host their products on platforms like AWS, GCP, or Azure?

At AWS re:Invent 2016, Neil Hunt, acting CPO at Vibrant Planet and previously at Netflix, spoke about how the rapidly growing global company relied on AWS to deploy servers and storage efficiently. Big name companies such as Netflix, Coca Cola, and Nordstrom as well as smaller startups like Courier are using Serverless to cut down costs and build scalable tech.

There are major advantages to Serverless that cause companies of any size to become dependent upon it. This dependency ultimately allows developers to save time, preserve resources, and lessen performance issues.

## Why Students Should Get Comfortable with Serverless
Often, cloud computing companies will visit schools and host workshops to introduce students to their software. However, there aren't many institutions that teach students specifically about Serverless architecture. Even after using these services for hackathons or class projects, few students have an in-depth understanding of how Serverless works and what it can be used for.

Many students working at startups after graduation will likely encounter one of the big three: AWS, Azure, or GCP. Serverless is increasingly becoming a technology that startup software developers and product managers will need to be proficient in, to help grow their products quickly, cheaply, and reliably.

### Time
Using Serverless frameworks allows developers to build and deploy their applications from zero to production speed. Any time a product needs to be released or updated, developers no longer need to worry about managing their backend and uploading code to the server. They can simply upload or update pieces of code to the Serverless computing provider in a fraction of the time.

### Resources
In addition to time, teams can save expenses on people and products by running their code from the cloud. They can save money on getting and running servers by purchasing cloud space from Serverless companies at a fraction of the cost.

### Reliability
By allowing Serverless computing companies to manage the servers, startup developers can avoid a large amount of risk. These Serverless companies are able to store massive amounts of servers that allow their users to scale projects in seconds. Developers no longer need to worry about their applications crashing since their servers have to take excessive loads. If an application does require more servers than anticipated, the cloud will automatically increase the number of servers provided to them. Depending on Serverless architecture massively decreases the chances of a product running into any software, hardware or human faults related to servers.

Bit Project is a student organization that tackles the deficit of shared information in tech by building and hosting free coding bootcamps to help students build key skills required to succeed in tech. One of these is the Serverless Camp, in which students spend four weeks learning about the services that Azure provides and how they can use them to build various applications. For the next four weeks, students work with professional mentors from the tech industry to find and resolve a world issue using Serverless technology.

## Example Projects to Build
Several students around the world built projects using Azure Functions for the Serverless Days: Student Edition Conference hosted by Bit Project in 2021. Each student had worked extensively with mentors in the tech industry, software developers, project managers, and developer advocates, to learn about the services that Azure provides and how to integrate databases and APIs to build bots and applications using those services to solve real world problems.

### Creating a Smart Teaching Assistant on Github with Serverless - Ganning Xu

High School student, Ganning Xu, was the first to complete the Camp course and took his head start as an opportunity to find and resolve issues in the program. The Camp curriculum itself was hosted on a in-house GitHub bot. For his final project, Ganning decided to improve the overall experience of the bot for both students and mentors by adding more features, bug fixes, and transferring the code to host the bot as a Serverless function.

### Building a Knowledge Base for Online Classes - David Tetreau

Another student, David Tetreau, was a military veteran and had shown a special interest in improving the online learning experience for new programmers. By using the Slack Bolt framework, Node.js, JavaScript, and Serverless web app hosting, David built a solution to save time and increase productivity.

His project, a Serverless Slack Bot, helps alleviate the stress of virtual team communication, and helps boost productivity. The bot maintains and updates a single knowledge base, monitors channels for keywords, and responds to inquiries with those words in threaded conversations with users.

### Go Eat! Meal Reminders with Serverless - Beatrix Cendana

Beatrix Cendana, originally a writer, wanted to build more technical skills and become a technical writer. While balancing a hectic schedule, Beatrix discovered a need for a product that can help generate random recipes for daily cooking and timely reminders for regular meals. She decided to create an SMS feature with the Twilio API that can remind people to eat based on a proper schedule and add the feature to help them get the random recipes.

Watch the full [Serverless Days: Student Edition 2021 Conference](https://youtu.be/l_1BhV-dtMk), where five of the students from the Serverless Camp present lightning talks including the inspirations behind their application ideas, journey to building it, and demo of the working application. Students also talk about their experience working with external APIs, databases, and their mentors.

These students are an example of how quickly programmers can pick up Serverless architecture, get started building their own applications, and become experts in the field. These skills can be valuable in various roles across tech that require extensive knowledge of cloud computing and deploying applications on providers like AWS, GCP, Azure, etc.


serverless-hype-header

Companies' dependency on Serverless allows developers to save time, preserve resources, and lessen performance issues during the engineering process.

The Hype Around Serverless and Why Student Engineers Should Buy In

serverless-hype-thumbnail

Why Student Engineers Should Buy Into the Hype Around Serverless

Aydrian Avatar

Aydrian Howard

Back in April, Courier sponsored the Bitcamp Hackathon from University of Maryland. It was a 36-hour hackathon and it produced one of the most interesting projects we’ve seen out of a Hackathon. Matt Graber, a new grad, created a game called Package Person with a very interesting use of Courier. The game’s objective is to deliver as many packages as possible to the package drop locations in front of the houses while avoiding the dogs that chase the player. 

Let's dive into how Matt got the idea for Package person, how he built it with Courier as a part of his suite of tools, and his reflections on the project. 

### Planning the Project

Since the 2021 Bitcamp Hackathon would be the last of UMD senior Matt’s career as an undergrad, he was committed to finishing a project and hopefully winning something in the process. He had done hackathons several times in the past, but this was his first time doing it without a team. So finishing a project of reasonable quality by himself was the main challenge and primary goal.

Matt's game development experience began when he joined the UMD AR Club during his freshman year, which later became the XR Club after merging with the VR Club. Throughout his time with the AR/XR Club, he learned and taught other students how to use the Unity game engine to create augmented and virtual reality experiences, which often took the form of games. His initial knowledge of Unity came from that experience, and he used those skills to start making more conventional games in my spare time.

Having had the time to develop these skills, Matt was inspired to build Package Person because of his experiences during the Covid-19 pandemic. He had been making games to pass the time with his roommates and during lockdown, they started hosting mini 4-hour hackathons that they called &quot;game jams&quot; among themselves with some of their other friends as judges. Predictably, they got pretty good at quickly throwing together simple games using Unity.

### The Development Process

The game’s objective is to deliver as many packages as possible to the package drop locations in front of the houses while avoiding the dogs that chase the player. The trick is for the player's top speed to be faster than the dogs' except when the Package Person is carrying a package. Upon losing, the player is brought to a leaderboard screen with the option to enter their contact information to be notified of any changes in their position on the leaderboard.

![Initial Leaderboard](https://images.ctfassets.net/z7iqk1q8njt4/44m8PJodaltVf3agJRxZwU/066cf5d6b1493ea0eddbd7a6ff8b25ab/image1.png)

Package Person was developed in the Unity engine, which uses C# for scripting. For the notifications, Matt used Courier with Twilio and Mailjet as sending providers. He created the Package Person using Adobe Fuse (which is no longer supported) and rigged and animated it using Mixamo. The other 3D assets were free from the Unity Asset Store.

An auto-generated C# code-snippet was not provided by Courier because it does not yet have an SDK for C#, unlike other languages such as Python and Java. However, Matt says he found this to be more of a minor inconvenience than anything else. He instead used the Unity API’s built-in web request system to send a POST request with the necessary information. This produced the same result as the Courier SDK would have been able to do for other languages.

```csharp
WWWForm form = new WWWForm();
form.AddField("event", "9GRDXE7RJZ42MSM12A87H4X3JCDC");
form.AddField("recipient", players[i].recipient_id);
form.AddField("override", "{}");
form.AddField("data", "{\"playerName\":\"" + players[i].playerData.playerName + "\"," +
                        "\"score\":" + players[i].playerData.score + "," +
                        "\"currentPlace\":" + players[i].playerData.currentPlace + "," +
                        "\"previousPlace\":" + players[i].playerData.previousPlace + "," + 
                        "\"beatBy\":\"" + beatBy + "\"," +
                        "\"beatMessage\":\"" + beatMessage + "\"," +
                        "\"deviceName\":\"" + dataManager.GetDeviceName() + "\"}");
form.AddField("profile", "{\"email\":\"" + email + "\"," + 
                            "\"phone_number\":\"" + phone + "\"}");

using (UnityWebRequest www = UnityWebRequest.Post("https://api.courier.com/send", form))
{
    www.SetRequestHeader("Authorization", "Bearer " + Auth.CourierKey);
    yield return www.SendWebRequest();

    if (www.result != UnityWebRequest.Result.Success)
    {
        Debug.Log(www.error);
    }
    else
    {
        Debug.Log("Form upload complete!");
    }
}```

[Full Code](https://github.com/grabermtw/Package-Person/blob/main/Assets/CourierNotifications.cs)

The games Matt and his roommates made included leaderboards that were limited to showing scores achieved on individual machines. In many ways, these games were like the classic arcade machines, which have leaderboards that can usually only be accessed by visiting the machines themselves. He wanted to give players a reminder of their scores and an incentive to return to the games on those machines by giving them updates on their leaderboard position, taunting them (quite literally) back to defend their ranking.

![Taunting in the Leaderboard](https://images.ctfassets.net/z7iqk1q8njt4/4a9uRKHE6RusrTy13QrIn5/d735e27788a26e7246e589c8d5ef5481/image2.png)

In Package Person, there are three types of notifications a player can receive. First, when the player gets on the leaderboard, the player will receive a notification that essentially serves as a “receipt,” just reminding them of the placement on the leaderboard that they just achieved. 

The second type of notification is received by all players on the leaderboard whose scores were bested by the newcomer. This notification informs the recipient of the name of the player who beat them, any message that the triumphant player has specified to be sent to lesser players, and the new placement on the leaderboard that they now occupy. 

Finally, because the leaderboard only displays the top ten players, a notification goes out to any players who get knocked off of the leaderboard as more players score higher than them. In each case, depending on whether a player entered their email, phone number, or both, they will receive an email and/or text message with the appropriate information. All of these notifications also include the “arcade name” which serves to identify the installation of the game that the notification is notifying about and is configurable in the game’s settings.

![Package Person Email Notifications](https://images.ctfassets.net/z7iqk1q8njt4/53S7ftgo3PhLJiIwtysRwo/31d5573bf935d52c4a82d4363c915542/image3.png)

### Reflections on Courier

If Courier were not an option, Matt would have had to use Twilio and Mailjet directly through their own APIs. He also would have needed to program all the logic for creating the messages in C# rather than allowing most of the logic for the message content to reside in the conditionals within the notification templates created in Courier. While it would have been doable, it would have taken much longer and he likely would have had to settle for a much simpler game due to the time constraints of the hackathon.

### Thoughts for the Future

Given more time, Matt's ideal game notification experience for Package Person would include a Package Person mobile app. This app would keep track of all scores on all the machines that an individual has used and also would feature a global leaderboard for the greatest Package Person players across all installations of the game. Package Person players would receive push notifications through the app. He would do so by adding a mobile push channel to his Courier workspace.

When asked for his advice for future game creators, he said that if they have the patience and a willingness to read documentation and follow tutorials, anyone can easily get started developing games in engines such as Unity or others. The experience needed to build a game varies with the intended complexity of the game that is being built. Starting out creating small, simple games will help build the skills required for making more complex games down the line.

When Matt started learning Unity, he found the easiest way for him to learn was to think of a game idea and then just get right into attempting to create it, stopping to read documentation and searching for tutorials whenever he would hit a roadblock. By thinking of and pursuing simple game ideas that he wanted to make a reality, he was able to keep himself more invested in learning to use the engine than if he would have been following a basic tutorial series. 

Overall, his takeaway from the experience is that it is important to pursue making something that you can call your own and be proud of in order to maintain your interest in continuously refreshing your skillset.

Package Person Header Image

Let's dive into how Matt got the idea for the Package person game, how he built it with Unity, Courier, etc. in his toolbox, and his reflections on the project.

Engineering student builds game using Unity game engine, Courier, Twilio, etc.

Package Person Thumbnail

How to Use Notifications to Build a Game in 36 Hours

chris-profile

Chris Gradwohl

Having been at startups my entire career, I’ve encountered the dichotomy between speed and scale when building software products. The usual attitude entrepreneurs take when building the first iterations of their products is “...we aren’t anywhere close to facing problems of scale, so let’s worry about that when we get there.” This first version of the software is built and shipped fast, and it’s only a matter of time before engineers realize that they simply don’t have the foundation to iterate quickly. Inevitably, limitations within their own infrastructure cause slow development cycles, impossible deadlines, and too much stress to maintain creativity and functionality. Trust me, I have been there. 

In a startup, it is difficult, if not impossible, to find the resources necessary to solve these problems at scale. I have found that Serverless is an excellent response to this challenge. I think Jeremy Daly has summarized it nicely.

*“Serverless gives us the power to focus on delivering value to our customers without worrying about the maintenance and operations of the underlying compute resources.”**__ __*

In this post, I want to explore some of our favorite Serverless stories from Courier, review some Serverless basics, and explore how Serverless has empowered our team to accomplish more with less. Perhaps through these musings, you can gain a better understanding of the Serverless landscape and determine if it's the right approach for your next project or startup.

### __60 Days to Monetization__

When I joined Courier, I was intrigued about why founder Troy Goode decided to go with Serverless, since it was a relatively new technology, with a small community of active developers. Upon asking, he said he was looking for “the speed of Ruby on Rails or Django with the scale of Kubernetes” without having to choose one over the other. Serverless framework was a perfect fit. Troy, as a team of one, was able to build Courier’s powerful send pipeline, pitch potential customers, and actually land a paying account within 60 days of development. This was incredibly exciting for me and validated the idea that a small team can become production-ready extremely quickly. 

What’s even more impressive is that the core design of our send pipeline has remained largely unchanged in the last 18 months. This has allowed us to focus on specific customer use cases and not the underlying infrastructure. This foundation has served us well, allowing us to continue to develop at a rapid pace and respond to customer feedback.

### __S3 is Our Friend__

At Courier, we are big fans of S3. With all the new features and services that seem to explode out of reInvent each year, S3 doesn’t get the love it deserves. From its guaranteed uptime of 99.9%, its dead-simple API, and low cost, what’s not to love!

One of my favorite design patterns that I picked up at Courier is the __Web Service to S3__ pattern due to its flexibility and simplicity.

![Web Service to S3 Pattern](https://images.ctfassets.net/z7iqk1q8njt4/6VoD1Wp8EGt9F19rTDutAd/b7d0603cb8b5f99340a12402b5dbea8b/image1.png)

This pattern is an excellent fit for when you need to manage time-consuming processing but don’t want to wait for its completion. In this example, a __Web Service__ puts an HTTP request onto an S3 bucket called __RequestStore. __This will trigger a Lambda function called __Worker,__ which can then send the request to another service to be processed.

This is particularly easy to configure with Serverless framework. First, you need to define an S3 bucket using cloud formation(In a production environment you need to apply a stricter policy to your S3 bucket. I added a basic PublicRead here for brevity.):

```yaml
resources:
 Resources:
   RequestStore:
     Type: AWS::S3::Bucket
     Properties:
       AccessControl: PublicRead```

Then define the lambda function with an S3 trigger event:

```yaml
Worker:
 events:
   - s3:
       bucket:
         Ref: RequestStore
       event: s3:ObjectCreated:Put
 handler: handlers/worker.default```

I love being able to reference this manifest later and visualize the system just by looking at the code.

Another powerful use case for S3 is avoiding the 400KB item limit with DynamoDB. When you need to store large item attributes in Dynamo, you can store them as an object in Amazon S3 and then store the object reference in the Dynamo item.

This approach has proven useful on numerous occasions at Courier, but is not without its tradeoffs. This strategy does not support transactions, therefore your application should handle any failures or errors that may occur.

### __Lambda Bottlenecks From A Dynamo Stream__

An interesting aspect of Serverless development is the ability to finely tune your services based on their usage. At Courier, this was done out of necessity after we noticed a performance issue in one of our key logging services. Here is a simplified drawing of the problematic design.

![Problematic Design of Key Logging Service](https://images.ctfassets.net/z7iqk1q8njt4/34oO0JDjo5cmwKaaWWYmHG/35128f881c539b2751e7fbaf1ffc3da3/image2.png)

In this scenario, we have several services that write to a Dynamo table. This table streams batches of records to a lambda function, which writes these records to Elastic to be queried by a UI. After further investigation, we found that the lambda’s *iterator age* was continuously increasing, causing a performance issue in the UI. 

Let’s quickly define some terms before we jump to the happy ending of this story. A lambdas *batchSize* is simply the number of records to read from the event streams shard. A lambda’s *iterator age is* a CloudWatch metric that measures how long it took to process the last record in the batch. Since our lambda was processing new events and the iterator age was increasing, this meant that it was taking more time to process each new record due to backpressure. *In other words, as more records were being written to the table, it was taking these records longer to reach the UI.*

The cause was due to an increase in the product's usage, so this turned out to be both a great problem to have and one with a relatively simple solution. Depending on the Lambda’s event source, AWS allows you to define the batch size of records for the triggering lambda event. In addition to batch size, you can also define the parallelizationFactor, which provides a multiple of concurrent lambda invocations per shard. For example, if Parallelization Factor is set to 2, you can have 200 concurrent Lambda invocations to process 100 shards. Thanks to Serverless Framework, this is as simple as defining the two parameters within the event section of the lambda definition. 

```yaml
LambdaWorker:
   events:
     - stream:
         type: dynamodb
         arn:
           Fn::GetAtt:
             - DynamoTable
             - StreamArn
         batchSize: 1
         parallelizationFactor: 5
   handler: handlers/lambda.worker```

AWS and Serverless made this situation a whole lot easier to deal with thanks to the built-in CloudWatch metrics and the configurability of AWS services. After reconfiguring the lambda, we saw almost immediate back pressure relief and went about our day. 

### __Green Field: Automations__

Starting a new project from scratch is exciting. Optimism is high, there are lots of creative discussions and opportunities to innovate. When I joined Courier, I was fortunate enough to lead the effort, alongside CTO Seth Carney, on a new greenfield project called Automations, which set out to allow users more control of how and when they could send messages.

We set out to allow users to define an Automation from a discrete set of job definitions, that we later named *steps*. To process these steps we designed a simple but effective job processing system.

![Job Processing System](https://images.ctfassets.net/z7iqk1q8njt4/67fsS8rrg0iKtPZxGWfgKX/532b4141432b9df7501163a2262455f3/image4.png)

First we used the trusty __Web Service to S3 __design pattern I talked about earlier__ __to quickly validate the incoming automation definition, store it into S3, and return a response to the user. At this point no jobs have been processed, only validated. We don’t want the user to wait for the entire automation to execute before receiving a response. 

Next, the request is picked up by the __RequestWorker, __where each individual job is processed in the order in which it was defined. After experimenting with other services, we chose SQS as a job processor, due to its unlimited throughput and its ability to retry messages with a DLQ. Finally, the __JobWorker __is triggered with the job definition in the event payload. Its role is to execute the job based on its definition, then enqueue the next job. Defining an SQS Queue and a Lambda with an SQS trigger is similar to the __Web Service to S3__ pattern we defined earlier.

First let’s define the Queue with CloudFormation:

```yaml
resources:
 Resources:
   JobQueue:
     Type: AWS::SQS::Queue
     Properties:
       VisibilityTimeout: 60```

Then define the lambda function, this time with an SQS trigger event:

```yaml
JobWorker:
 events:
   - sqs:
       arn:
         Fn::GetAtt:
           - JobQueue
           - Arn
 handler: handlers/worker.default
```

Notice the funny-looking  syntax. This is called a cloud formation* intrinsic function*, which is a way to retrieve the underlying ID of the AWS resource. You will notice that this was not required for our S3 trigger example, which is kind of a quirk of CloudFormation. Since it is difficult to keep track of what services require which intrinsic functions, I found this amazing [cheatsheet from Yan Cui](https://theburningmonk.com/cloudformation-ref-and-getatt-cheatsheet/) very helpful.

We were able to design, implement, and ship this architecture within a week. Considering this was implemented with a team of one, I am very proud of that accomplishment. Since then, we have added many more services, features, and functionalities to Automations, but this first implementation not only kicked off a great working relationship with my colleagues, but it also proved to me the true value of a Serverless driven infrastructure.

Serverless does not come without its own set of challenges and frustrations. Regardless, Serverless has become my favorite way to build products and companies. When faced with the uncertainty of the market and the need to iterate quickly I think choosing Serverless allows tremendous development speed with scale built in. What are your thoughts on Serverless? I hope you enjoyed these Serverless stories and I hope you feel empowered to dive in and build your next project with Serverless.

Ready to take your notifications to the next level?

serverless-header

Learn how how we use Serverless at Courier, review some Serverless basics, and explore how Serverless has empowered our team to accomplish more with less.

Courier [Notifications Landscape]

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company