Forem: Tejas Kumthekar

New RudderStack Integration: Create Actionable Insights

Tejas Kumthekar — Wed, 08 Mar 2023 17:00:32 +0000

Are you looking for a way to gain a clearer picture of your users and use that insight to improve your communication strategies? We've got some great news for you! Today, we're thrilled to announce an integration between Courier and Rudderstack, a customer data platform (CDP) that allows businesses to collect, process, and route customer event data across product, marketing, and analytics tools for better decision-making.

This integration builds on our recently improved integration with Segment and will further improve your ability to track your users' actions and take advantage of customer data stored in RudderStack to improve the notification experience for your users.

"Courier makes it easy to trigger notifications based on RudderStack events. We're really excited about this integration because it removes a lot of complexity for engineers and data teams looking to build a notification system."

Eric Dodds, Head of Product Marketing, RudderStack

For those who may not be familiar with RudderStack, it’s a customer data platform (CDP) that allows businesses to collect, process, and route customer event data across product, marketing and analytics tools for better decision-making. As for Courier, it’s an all-in-one notifications solution that enables development teams to manage communications with their users, from product notifications to marketing messages, through a number of channels, such as email, chat, in-app messages, SMS, and push, all in one place.

So, by integrating Courier with RudderStack, you get the combined benefits of both systems: you can now collect, process, and route your users' interaction data between Courier and different marketing and analytics tools, via RudderStack. This integration can help you gain a clearer picture of your users and use that insight to improve your communication strategies.

You can also track notification engagement data, such as the percentage of communications that were successfully delivered, opened and read, and on what notification channels. The detailed notification analytics data gives you the potential to create more personalized app experiences for users based on their activity within your product. For example, you could adjust the way a user receives notifications based on their interactions with your product, as well as data from Salesforce, Google Ads, Mailchimp, and other RudderStack sources.

More about Courier

Courier is an API and web studio that centralizes all product-triggered communications, such as email, chat, in-app messages, SMS, and push notifications. With Courier, businesses can deliver messages to their users using their preferred communication channels, with real-time visibility and tracking for each message. This tracked data within Courier can now be passed to RudderStack!

One of the best things about Courier is that it provides a single, unified interface for developers to manage all communications. This reduces complexity and eliminates the need for developers to manage multiple APIs and libraries to send notifications to various channels. Courier's simple and elegant APIs make it easy for developers to create new notifications and manage messages in a way that doesn’t require additional work for each new notification channel.

More about RudderStack

RudderStack, as we already mentioned, is an easy-to-use CDP, with a straightforward installation process and intuitive user interface. It doesn’t require any in-depth technical knowledge, making it a popular choice for businesses that want to collect and process customer data without the need for a dedicated development team.

Unlike most other CDPs, RudderStack is open-source, which means that developers can access the source code, modify it to suit their needs, and contribute to the development of the platform. Additionally, RudderStack offers a range of pricing plans, including a free plan, making it accessible to businesses of all sizes. Another great feature of RudderStack is that you can host it in your private cloud infrastructure, giving you even more control over your data.

RudderStack’s control plane

The RudderStack platform consists of two main components: the user-facing control plane and the data plane that operates under the hood. In this section, we'll take a closer look at the control plane.

The control plane is the web-based interface that allows you to manage data integrations, monitor data flows, and control user access. It's the place where you can configure and manage your RudderStack accounts, add and remove integrations, and control who can access data.

RudderStack’s control plane also lets you manage your data integrations easily. For instance, you can set up and choose your data destinations and sources, control who can access the data, and monitor the flow of data between the sources and destinations.

In RudderStack, sources are platforms or applications from which RudderStack tracks and collects data. A destination, on the other hand, is a cloud tool or a platform where you want to send this collected data.

From the control plane, you can also create custom transformations and enrichments to modify the data before it gets sent to the destination. These features provide you with granular control over your data integrations and allow you to create custom data pipelines that fit your specific needs.

Events — the data sent by Courier

There are two types of user data Courier can now send to RudderStack: message events and audience events.

Message events are all about notification deliverability and user engagement. These events track whether a message was sent, delivered, clicked, and opened. Message events help businesses track notification usage data, including successful deliveries, opens, clicks, and the channels through which messages are sent. This data can help businesses create custom user journeys that are tailored to users' communication preferences, improving the overall user experience.

Audience events, on the other hand, make use of Courier's dynamically defined user groups, known as audiences. Audiences give you more flexibility than static lists. For instance, you can define an audience as a set of users with the title “Software Engineer.” You can even take this one step further and define more niche audiences by specifying that the user also has listed, for example, TypeScript as one of their favorite programming languages.

Audience events allow you to track when people join or leave these pre-defined groups based on changes in user characteristics, allowing for better data collection and therefore improved end user experience. For example, an audience event would be triggered if someone changed their job title to “Software Engineer” or if they changed it from “Software Engineer” to something else. This gives you control over the type and amount of notifications specific users receive, improving their overall experience.

Using this new data

When your events have been loaded in RudderStack, you can use different aggregate views to study them, or you can forward them to an analytics destination like Looker or Tableau. This integration enables you to perform analytics on your notification data, giving you powerful insights about how your users interact with your product, and create even more enjoyable notification experiences.

You can also automatically update information in Courier from your product or from other software tools via RudderStack. For example, if a user changes their email address in your web app, you can propagate that information into the user’s profile in Courier without the need to add a separate Courier API request.

What are you waiting for?

Whether you're new to RudderStack or an existing user, integrating Courier is a straightforward process. To enable the integration, add Courier as a source and/or destination. Adding Courier as a destination is as simple as specifying Courier as a "destination" in your RudderStack dashboard. Just navigate to ‘directory’, go to the destinations tab and search for Courier.

For more detailed information on how to implement courier as a source or destination, and help getting started with the RudderStack and Courier integration, visit our documentation and follow the steps outlined there. This will start the flow of data and can start giving insights straight away, helping you to improve your user experience and helping you make better product decisions.

How to Internationalize Your App’s Product Notifications

Tejas Kumthekar — Thu, 10 Feb 2022 21:12:20 +0000

Internationalization in software development, known as “i18n” for its number of letters, is as vital as ever for modern companies. Web-based products and services are no longer tied to geographical and cultural boundaries and not every potential customer speaks English. You might have designed your app with your native region in mind, but you’ll eventually need to expand your supported languages and regions to cater to a global audience.

In this article, you’ll learn about the scope of internationalization and the tools that are available to build software with internationalization logic. You’ll also see how Courier’s own internationalization workflow is designed and our suggestions for how to do it yourself.

What is internationalization?

The purpose of internationalization is to prepare your product for expansion into other markets and countries. With i18n-ready software, you can competitively grow your customer base. Increasing supported languages can also provide sustained future growth. Effective internationalization involves abstracting much of the software by removing all culture- and locale-specific elements. These elements include languages, regions, dates, units, currency, and even cultural symbols and colors. An i18n-ready software should be free of all hard-coded region-specific elements.

Localization, or “L10N,” would then be the process of creating these specific elements for every different locale. This is a recurring process that needs to be completed for every additional locale, while internationalization is done only once to prepare the software to be localized. Localization is more than just translation as it involves updating all cultural markers, such as icons, symbols, colors, etc. Effective localization is dependent upon carefully crafted i18n logic in the software.

At Courier, we serve clients who increasingly look to reach customers across the world. Read on below to learn how we’ve crafted an internationalization workflow.

How does Courier work with i18n flow?

Courier recently introduced a checks system that is similar to GitHub’s checks. We implemented the notifications flow around these checks to allow for maximum flexibility and automation. The diagram below illustrates how the checks system establishes a flow between Courier and you.

First, you create the notification in the Courier workspace and then submit it for review. The HTTP webhook listens for this submission event and notification content is received via the API call. You can then initiate translations in your own space.

The i18n process is emphasized at the bottom of this diagram. As you submit your own content for translation/localization, you can work piecemeal with your translators until the notification template is translated and localized for each desired locale. You can update as you go along, instead of waiting until all language translations have been completed for each notification block.

As the localization process is completed for each locale, you can notify Courier by updating the check-status via API and Courier will know the notification is ready for publishing. For example, if all German translations are complete but the French ones are not, you can still upload all the German translations and push those through with the checks system while waiting for the French translations. This process allows for a smoother workflow as you can prepare notifications and translations and Courier will take care of the rest.

Who handles the translation?

All translation and localization work is done outside of Courier. It’s up to you to find the right localization service for your product. There are many machine translation services available these days but they are not suitable for most cases as localization is much more than translation. Many developers don’t realize how many locale assumptions their system is making. For example, China perceives good or lucky colors differently than many western nations. There, red is actually lucky and associated with positivity while green is unlucky and is even used to denote financial losses.

Another cultural marker that might easily be missed by a developer is the direction of reading, such as between English which reads from left to right, and Arabic or Hebrew which reads from right to left. A proper localization service would consider gender, word order, abbreviations, and many more such cultural marks for each specific locale.

So, while it’s up to you to translate and localize your notification content, we set up Courier to handle the communication pathways, the storage of locale-specific translations, and user profiles, and the data logging for your notifications. Basically, Courier has designed a workflow that abstracts all the logic so that you only have to provide your own translations and at your own pace.

What would your i18n flow look like without Courier?

If your current software is not already designed with internationalization logic, retrofitting it is usually costly due to the labor and time involved. Every hard-coded locale-specific element will have to be re-coded as a variable that grabs the correct locale for each stored user profile from a library.

If you want to implement your own i18n flow, here are some recommendations. First, you’ll want to decide on your process and document it. You will need to set up a project management system and ensure a way for the development team to communicate with the localization team. One possibility might be to hire a project manager into the flow. It will be up to the development team to hand off notifications for translation and localization, and upon receipt of the translations from the localization team, add them into the system. For each new notification, this process will need to be cycled through, where a translation is requested and run through the process and then uploaded into the system.

Depending on the content and complexity of the notification, there might be some other difficulties. Courier uses various drag-and-drop content blocks as the basic components of a notification. If you’re building your system in a similar fashion, you’ll need to ascertain how you will abstract each block so that they are not hard-coded with locale-specific elements. Simple blocks, like text, can be replaced with custom variables. That seems intuitive. However, when you scale your company, this will become more difficult to implement as the different invocations will have to be written per locale. In addition, if your notification composition is complex and includes a variety of content blocks, each block would need to be handled as a custom variable as well. This can quickly become unmanageable if not accounted for from the outset.

Are there available resources for implementing i18n yourself?

There are several open-source libraries and frameworks available to develop i18n-ready software.

i18next, a comprehensive open-source framework that has been around since 2011 with a dedicated community of developers. It provides you with plugins that can detect language and load translations, with support for multiple files.
FormatJS and GlobalizeJS, which are collections of javascript libraries for i18n formatting and other tools. However, unlike i18next, developers using FormatJS will need to write their own code to detect language.
Ruby on Rails has its own i18n library to abstract locale-specific information, replace it with another locale, and store these dictionaries.
Polyglot.js, which is an interpolation and pluralization helper created by Airbnb.

Despite the number of tools available, you will still need to ascertain which ones are right for you. As you measure your options, keep in mind how long it might take to develop your i18n flow. Your team will need to write the code that will tie these libraries together. You will also need to configure how to store and manage locales in profiles. And of course, unless you provide the translators access to your codebase, you will still need to devise a method for continuous bi-directional communication between the developers and translators for the duration of the process.

Build your i18n workflow with Courier

Courier has introduced an i18n workflow so that you can tap into new markets and locales when you’re ready to expand. We store your customer’s profiles with locales, we’ve built automated communication pathways for developers and translators, and we engineered content blocks for smoother localization, however you design your notifications.

You can always build your own notification system with i18n flow, but you’ll also spend valuable time and resources in the process. There is massive upside in focusing on your product and expanding your customer base as smoothly and efficiently as possible. Ultimately, the decision rests on available resources: do you have time to write i18n logic and re-design your product, or are expediency and user engagement your priorities for the moment in time? For more of our content, subscribe below or follow us at @trycourier!

Hacking PostgreSQL Internals to Deliver Push Notifications

Tejas Kumthekar — Thu, 20 Jan 2022 23:30:36 +0000

PostgreSQL announced their latest version (PostgreSQL 14) on September 30th, which includes a bunch of features like pipeline API, gathering statistics on replication slots, query parallelism improvements and so on. While the origin of PostgreSQL can be traced back to 1986, it has been in active development for the past 30 years. Tons of companies, agnostic of the the type and size, have trusted Postgres over the years and their tagline “The world's most advanced open source relational database” is hardly an overstatement.

In a typical, non-trivial system, there is more than one database server, and the data is often copied across multiple servers. A fairly common notion in a distributed system, this copying of data across multiple server nodes is known as replication. Replication processes are often abstracted from the consumers of the database, so most of the application layers are transparent to which node serves the data and if you’re an app developer like me, we expect things to “just work”. However, what goes behind the scenes of some of the most sophisticated databases of the world is often a fascinating reading and learning experience.

In this post, we will start diving into the internals of Postgres to understand how replication works and data integrity is ensured using WAL (Write-Ahead Logging). We will then steer towards interesting concepts like logical decoding and output plugins. Finally, we will start hacking some code to write our own plugin that can send push notifications! I know this sounds a bit contrarian to the common approach of sending notifications from application servers, but hey what's the fun in doing common boring things! Let's dive right in :)

Replication at a high level is a process of transferring data from a primary server to a replica server. In Postgres lingo, servers can either be primary or stand-by. Primary servers are the ones that send data, while standbys are the receivers of replicated data. In certain settings, standbys can also act as senders. Replica or standby servers can take over if the primary fails which is the crux of how database systems manage fault tolerance.

https://www.enterprisedb.com/postgres-tutorials/postgresql-replication-and-automatic-failover-tutorial#replication

WAL (Write-Ahead Logging) is the standard method to ensure data integrity in Postgres. Systems are bound to fail and database servers are not excused from that. At the application layer, it's comparatively easier to retry and manage failures without typically resulting in data loss, however, when we go deep in the stack, especially at the data layer, persistence is doubtlessly super critical. When consumers make a write operation to the database, before the database is acted-upon, the changes are written to the server’s file system. This by design ensures data persistence and recovery in the cases of operating system crashes or hardware failures. Consumers are (obviously) abstracted from these internal mechanisms and applications connected to the Database expect things to work out of the box.

The log entry we talked about above is known as the Write-Ahead Log record while the process is called Write-Ahead Logging. Each record has a Sequence number which is used for checkpointing periodically after logs are synchronized to the database. In cases of system crashes, this checkpoint is used to re-read and synchronize. WAL, being a reliable method for synchronizing or recreating the ordered state of the database, is used for replication across multiple servers. WAL can replicate the data using either a File based approach or a Streaming approach where both approaches have their own pros and cons. Streaming replication, although is typically in an asynchronous mode, can be tuned to be synchronous.

https://hevodata.com/learn/postgres-wal-replication/

WAL records being representative of the internal state of the Database system, are not easy to be fed into or understood by an external system/consumer. Logical Decoding to the rescue! “Logical decoding is the process of extracting all persistent changes to a database's tables into a coherent, easy to understand format which can be interpreted without detailed knowledge of the database's internal state.” Using logical decoding, replication solutions and auditing can be achieved much easily.

The following diagram depicts the logical decoding process.

Source: https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/change-data-capture-in-postgres-how-to-use-logical-decoding-and/ba-p/1396421

In order to enable the logical decoding, you need to make some configuration changes to the Postgres instance -

wal_level = logical # default value is `replica`
max_replication_slots = 1 # good enough for a sample project
max_wal_senders = 1 # default is 10

Ref: https://www.postgresql.org/docs/current/runtime-config-replication.html and https://www.postgresql.org/docs/current/runtime-config-wal.html for details on tuning the configuration

Once we have the configuration up and running, record changes are passed to the Output Plugin which does the key step of transformation from the WAL format to the format specified in the plugin (eg. JSON). These changes are made available on the replication slot(s) and consumer applications can receive the stream of updates as and when those occur.

Some output plugins and consumer apps out there -

wal2json Output Plugin that converts WAL output to JSON objects [Open Source]
pg_recvlogical Postgres app that can consume update stream [Out-of-the-box with Postgres]
decoderbufs Output Plugin that delivers data as protobuf [Open Source, Used in Debezium]

We can write a consumer from scratch or use battle-tested tools built to achieve this at scale. Debezium is one of the most widely used solutions out there. Netflix open sourced their in-house tool for CDC called DBLog - https://netflixtechblog.com/dblog-a-generic-change-data-capture-framework-69351fb9099b is a fantastic read on it.

What are we building? Lets keep this simple - whenever a new user entry is made to Postgres table, we will consume replication logs and send a welcome email to the user.

Let’s hack some code! We will be using a Go package https://github.com/jackc/pglogrepl which is a Postgres logical replication library.

Step 1: Follow Logical replication instructions

https://github.com/jackc/pglogrepl README has step by step instructions to configure logical replication in your local Postgres Instance.

Step 2: Try out the demo in the repo

Give https://github.com/jackc/pglogrepl/tree/master/example/pglogrepl_demo a try - it demos how the library works under the hood

Step 3: Update the demo code to log new email inserts

To keep it simple for this blog post, let's add some code that prints out specific email which was inserted on the new row.

A. Look for inserts and print the WAL data

if logicalMsg.Type() == 'I' {
   // `I` stands for Insert
   log.Println(string(xld.WALData))
   // this logs the complete entry
   // however it would require a little more cleanup
}

For example, a new entry with ID 5 and email tejas@courier.com shows up as I@Nt5ttejas@courier.com

B. Clean up the internal WAL representation and derive email

// find the second column
  walData := xld.WALData[5:]
  pos := bytes.Index(walData, []byte("t"))

  email := walData[pos+1:]
  pos = bytes.Index(email, []byte("t"))

  email = email[pos+1:]
  emailStr := string(email)

C. Send a welcome email to the user

We will be creating a new template by configuring an email integration supported by Courier.

messageID, err := client.Send(context.Background(), "VDPE8SWN1K4BWMP8RJ101YRZTF3J", "user-id", 
courier.SendBody{
    Profile: profile{
       Email: emailStr,
    },
    Data: data{
       Foo: "bar",
    },
})

if err != nil {
  log.Fatalln(err) 
}

log.Println(messageID)

Find the modified code at https://github.com/tk26/pglogrepl Here’s a quick loom video of how things work.

Now that we have configured Postgres to send emails by listening to replication logs, changing it to send a push notification would be as simple as changing a configuration in the Courier Studio.

Thanks for reading! Reach out to us @trycourier if you have any questions or comments or you know, just say Hi!

Nodemailer: Send through multiple service providers

Tejas Kumthekar — Sat, 14 Aug 2021 01:47:50 +0000

Early stage companies are constantly evolving their product to fit the market they operate in. They reach customers to keep them engaged using a high magnitude vector that contributes to their success. Architecting the communications strategy for your product thus becomes an important problem to tackle, which in turn can cause second-order effects like having to trade off the speed of product development iterations. The decisions you would have to make along the path can be hard, confusing and prone to change, and the last thing you want to invest precious time and energy in is these non-core features of your product.

In this blog post, we start by diving into Nodemailer, a module that helps send emails from your Node.js backend, and then we steer our way into writing a transport layer plugin that can help you switch downstream email service providers purely by configuration instead of tedious and sometimes massive code changes.

Projects that have stood the test of time

In the fast growing tech industry, there’s a special place in the hall of fame for projects that have stood the test of time. Nodemailer is one such project that deserves the well-earned spot. Launched in 2010, not long after Node.js’ inception, Nodemailer has been a go-to dependency for sending email messages for Node.js users. With 14k+ stars and 438k+ usages on GitHub and ~1.48M weekly downloads on NPM as of this writing, Node.js developer community has benefited immensely from the project.

Apart from a wide variety of features provided by Nodemailer, it comes with zero dependencies and has been evolving with a security-first mindset. While some of us might think how hard it can be to have zero dependencies, let's remember we’re in a Node.js world where there is a package for every little thing you could possibly imagine. Don’t believe it? Brace yourself while looking at https://www.npmjs.com/package/is-odd and https://www.npmjs.com/package/is-even. Yep that’s right - there’s a dependency that can help determine if a number is odd or even. No more complex arithmetic, right?

On another note, Nodemailer’s security-first development also deserves a round of applause. Those of you who have had to frequently run audits and rack your brains figuring out how to resolve vulnerabilities would agree. Moreover, considering the scale at which projects like Nodemailer have been adopted, even a single vulnerability can have huge negative impacts on the software of the world. One recent example is a vulnerability in the netmask npm package that could potentially play a hand in malware delivery.

Extensibility and elegant abstractions are the cruxes

Nodemailer is highly extensible via plugins that can operate on the mail object (pre-processing step), the mail stream (processing step) or the transports (sending step). For the scope of this blog post, we’re mostly concerned about the sending step. SMTP is the main transport in Nodemailer for delivering messages - but can be extended using the transport plugin to a different transport mechanism. For example, if you already use Amazon SES, you can use the SES transport plugin instead of SMTP, which is built-in. Like SES, there are several email service providers out there like SendGrid, Mailgun, Postmark and SparkPost to name a few. In order to cater to the Node.js (and Nodemailer) audience, most of these providers do have a transport plugin of its own should you need to integrate with your tech stack. You can explore through all such plugins with a simple “Nodemailer transport” search query on the NPM registry.

A definite question that always springs to mind is why there are so many email service providers out there and how to choose the one that fits best with your communication strategy. Unsurprisingly, such analysis paralysis is fairly ubiquitous in today’s SaaS world. Calling it a SaaS paradox of choice would hardly be an overstatement. Unless you have theoretically infinite resources at your disposal (read: you’re at a giant like Google or Facebook), these choices can slow down the speed of development significantly and don’t bode well with the “move fast and break things” mantra if you have to go back and forth between email service providers and rewrite your backend stack to accommodate the changeset.

Source: https://xkcd.com/2224/

Classic build vs buy mindset

In one of our blog posts, we talked about the build vs buy mindset and how it makes a difference, especially if you are a startup - read about it here if you’re curious. The mindset not only makes a difference for your speed of iteration, but also keeps you potentially ahead in the game especially if and when your competitors are adopting buy over build for non-core features of their product. One of the best examples is hosting on AWS vs maintaining on-premises cloud infrastructure - outsourcing cloud hosting to AWS gives you the speed of iteration with no cost of infrastructure maintenance. Imagine all of your competitors are on AWS but you aren’t - it’d certainly make a tremendous negative difference in the long run. While this certainly does not necessarily apply to all the companies out there, it does hold truth for the most. “Disruptive economic events like COVID have caused many people to step back and think about how they want to change strategically. And many have come to the conclusion that they do not want to own and run their own data centers.”, says AWS CFO Brian Olsavsky https://www.theregister.com/2021/07/30/amazon_q2_2021/.

An effective communication strategy plays a critical role in maximizing the odds of product success. It's a no-brainer that you have to have a way to reach out to users via Email - but that’s not going to be enough. Customer engagement via text messaging, in-app messaging or direct messaging (think Slack, Whatsapp, MS Teams etc.) has become a necessity in today’s hyper-competitive market. Sooner or later (definitely sooner than you think), having these multiple channels of communication are going to make a difference to your business. As you would scale your product or company, notifications infrastructure has to scale as well in order to handle queuing, scheduling, routing, rendering, and ensuring delivery of messages across multiple channels. Companies like LinkedIn have spent millions to build this infrastructure in-house - depicted quite well in LinkedIn’s Air Traffic Controller blog post.

Continuing my mini-rant on the SaaS analysis paralysis, as you’d have probably seen it coming, the paralysis exists on text messaging too - Twilio, Sinch, Plivo and Vonage to name a few providers in the arena. Managing multiple channels and providers to suit the communication strategy you’ve embraced is not a cakewalk. Lets circle back to the never-ending list of email providers and their corresponding Nodemailer transport plugin implementations out there. An easy way to fight the paradox is with a layer of abstraction, such that you can change providers without having to rewrite the code to switch the transport plugins. That’s exactly where Courier comes into picture with its API layer of abstraction and a configurable UI to switch email providers without having to change the code on your end. Needless to say, Courier should expose its own Nodemailer transport plugin which abstracts using a specific email provider plugin. Having this abstraction would imply no vendor lock-in as far as downstream delivery is concerned.

Show me the code!

Let’s dive right into writing the plugin! Nodemailer plugin creation (specifically the transport section) and a Mailgun implementation would be our reference points. While the core documentation is exhaustive, we’ll keep it relatively simple for the first version of our plugin.

TL;DR: https://github.com/tk26/nodemailer-courier-transport is the code we’ll end up writing.

Step 1 - Create a new NPM package and adding courier-node as a dependency

Here's the Node.js module for communicating with the Courier REST API. The source code behind the package is MIT licensed at courier-node repo.

Step 2 - Configuration prerequisites

You will need to get a Courier API key to get started. You can sign up and create one for free at courier.com. Courier being a middleware, you’d have to configure an email provider of your choice that’d do the actual delivery of the email to the recipient. Stuck in the paradox of choice? We got you! Here’s an article we published earlier this year that could be helpful in figuring out. Thereafter, you’d have to create a notification template with email as the channel. Here’s how to do it using SendGrid.

Step 3 - Writing the transport core

Transports have a send() method and name and version properties. Transport object gets passed to the createTransport() method to create the transporter object.

const transport = (options) => {
  const courier = CourierClient({ authorizationToken: options.apiKey });

  const courierSend = input => courier.send({
    eventId: input.eventId,
    recipientId: input.userId,
    profile: {
    email: input.to,
    },
  });

  return {
    name: "Courier",
    version: packageData.version,
    send: send(courierSend),
  };
};

That’s pretty much it for the basic version of the plugin. We’ve pushed the code to https://github.com/tk26/nodemailer-courier-transport. feel free to play around with it and reach out with any questions/feedback. It’s open sourced under MIT license so feel free to contribute to the open source project.

Step 4 - Using the code in your tech stack

Here’s how things would look in your Node.js backend -

const nodemailer = require("nodemailer");
const courierTransport = require("nodemailer-courier-transport");

// This is your API key that you retrieve from courier.com account (free up to 10k monthly sends)
const auth = {
  apiKey: "ABCDEFGHIJKLMN",
};

const nodemailerCourier = nodemailer.createTransport(courierTransport(auth));

nodemailerCourier.sendMail(
  {
    eventId: "courier-event-id", // Configured in Courier UI
    to: "recipient@domain.com",
    userId: "unique-user-id",
  },
  (err, info) => {
    if (err) {
    console.log(`Error: ${err}`);
    } else {
    console.log(`Response: ${info}`);
    }
  }
);

Note: We haven’t published the package yet as it is still in a nascent stage. Let us know if you are looking to contribute to the package or want us to publish it so you can use it in your backend. :)

Key takeaways

Let's summarize the key takeaways from the post. First and foremost - writing and maintaining open source projects that stand the test of time is hard, and projects like Nodemailer are great examples to learn from. Buying over building non-core product features is one of the most important trade-offs you can do to grow your company faster. The sooner you do the trade-off, the higher the returns (and in turn the competitive advantage) you gain. Last but not least, communication strategy is a key pillar in your company’s success - make sure you get it right without compromising on the speed of iteration.

If you’re looking for an easy to integrate, scalable and a reliable communication strategy - sign up for a free Courier account. You build the next big thing and let us handle the communications for you! 🚀

The Three Things to Never Build In Your App: Authentication, Notifications, and Payments

Tejas Kumthekar — Tue, 18 May 2021 00:30:07 +0000

Author: Tejas Kumthekar

Back in early 2018, I embarked on a side gig with a few partners - the idea was to make ridesharing socially engaging and fun. We made a ton of mistakes and never really got the product off the launchpad, however in retrospect, the biggest mistakes we made were wasting precious time in writing code for authentication and authorization as well as user notifications. We learned to focus on customer value the hard way.

Every startup should consider the trade-offs of buying vs building non-differentiated features like authentication, notifications, payments etc. Companies like Auth0 (authentication and authorization platform), Courier (one API to design and deliver notifications across multiple channels), and Stripe (payments infrastructure for the internet) have solved these problems so you, the entrepreneur or developer, can stay laser-focused on what your users truly want out of your product.

Whether you are working on a side gig like me or starting a company, shipping an MVP as quickly as possible helps you get feedback much earlier in the product development cycle. Outsourcing authentication, notifications, and payments tremendously helps in rolling your MVP out the door. The project I mentioned above took months to reach the MVP stage and outsourcing the non-core features could have had a great impact on shortening that time frame.

In this post, we shall focus on a pretty common use case that suits almost every product you will ever build. A user signs up for your product, you save the user details, and send them a welcome message. We will be using Auth0’s post-user registration hook and Courier’s automations feature to build this use case fairly quickly. Let’s dive right in!

With a single “send” API invocation, you can use Courier to reach your customers across one or more channels (email, text, push, or a direct message). We learned through talking to our customers that more often than not, they need something more powerful than just a single “send” action. They need workflows that do multiple actions with a single invocation, like making a single API call to send an email to their users and wait for a desired period of time (inducing a delay) and thereafter send a follow-up email. Another example of a workflow we've heard quite a lot is scheduled notifications, like sending product updates every week. The Courier Automations API gives you the ability to build such workflows and quite literally “automate” your notifications. We will see it in action soon :)

Configuring the Courier side of things

Let's start by creating a free account on Courier, which lets you send up to 10,000 free notifications every month. For the use case we are tackling in this blog post, we will be leveraging Courier’s Automations API. With a single API call, you’ll be able to create a new user profile inside Courier followed by a welcome message to send to this newly created user. The Automations Guide has a detailed walkthrough of all the cool features unlocked via Courier’s Automations API. Today, we will be invoking an automation that has two steps - update-profile and send.

Step 1: update-profile

This step essentially takes any profile JSON object with a unique ID (called recipient ID) and saves it inside Courier. It stays as a permanent record inside Courier that you can further use to send notifications, add it to a list of users/profiles, customize preferences such as opt-in/opt-out, and so on. In our use case, this would originate from Auth0. Here’s how it would look:

{
  "action": "update-profile",
  "recipient_id": "<RECIPIENT_ID>",
  "profile": {
     // User properties from Auth0
     // plus any more properties you want to attach to the user
  },
  "merge": "none"
}

Save Profile Information as JSON Object in Courier

= A unique ID that you can use to identify your user.

Step 2: send

This step sends a welcome email to the user. We will be sending users an email using Sendgrid as the downstream email provider. This Setup Email using SendGrid guide walks you through sending an email notification using Courier and SendGrid. Once you have created a notification template (with email as the channel using SendGrid), you can construct a send step that looks like this:

{
  "action": "send",
  "profile": {
    "email": "foo@bar.com"
  },
  "recipient": "<RECIPIENT_ID>",
  "template": "<TEMPLATE_ID>"
}

Construct a send Step

= User ID you are sending the notification to (same as step 1)

= ID of the notification template you just created for welcoming the new user.

Final Payload

Here’s how the payload to automations/invoke endpoint will look:

{
    "automation":{
     "steps":[
         {
             "action":"update-profile",
             "recipient_id":"unique-foo",
             "profile":{
                 "email":"foo@bar.com",
                 "first_name":"Foo",
                 "last_name":"Bar"
             },
             "merge":"none"
         },
         {
             "action":"send",
             "profile":{
                 "email":"foo@bar.com"
             },
             "template":"AAZRHC4TDAMEHKGJHDAA9199WMVH",
             "recipient":"unique-foo"
         }
     ]
    }
}

Payload to Automations

Configuring the Auth0 side of things

This post assumes you have a basic understanding of Auth0 and have set up an application in Auth0 before, but if not, follow the Auth0 Getting Started guide.

Let's take a step back and imagine how things would look if there was no integration between Auth0 and Courier. Every time you would have a new user signed up with Auth0, you would have to explicitly invoke Courier to create their profile and send them a welcome message. This would require writing more code in your application, deploying it reliably and maintaining it as your application scales. Having Auth0 and Courier integrated out of the box gives you great leverage in the form of speed and agility to move fast - without having to maintain a single line of code in your infrastructure.

We want Auth0 + Courier to work together automatically - like magic. Once a new user registers for the product, we want to trigger Courier’s Invoke Automation API - this is where Auth0 Post-User Registration comes into picture. Here’s the code that lives behind Auth0 hook and uses the Courier Node.js SDK to invoke the automation dynamically based on the user obtained via Auth0 registration.

module.exports = async function (user, context, cb) {
  const { CourierClient } = require("@trycourier/courier");
  const courier = CourierClient({ authorizationToken:               context.webtask.secrets.COURIER_AUTH_TOKEN });

  await courier.automations.invokeAdHocAutomation({
   automation: {
     steps: [
       {
         action: "update-profile",
         recipient_id: user.id,
         profile: {
           email: user.email,
           username: user.username,
           phoneNumber: user.phoneNumber
         },
         merge: "none"
       },
       {
         action: "send",
         profile:{
           email: user.email
         },
         template: "AAZRHC4TDAMEHKGJHDAA9199WMVH",
         recipient: user.id
       }
     ]
   }
 });
  cb();
};

Invoke the Automation Dynamically

This saves the user profile to Courier followed by sending the welcome email you configured in the template.

The profiles can be viewed in Courier UI under Data Recipients tab:

Next, the welcome email is sent to the user - it looks just like how you configured it to look in Courier. Just to give an example of how a notification could look:

Feel the Magic Automation?

We just saw how Auth0 + Courier can help you automagically build user onboarding flow without having to maintain any code in your own system, and as we all know, the best code is no code that allows us to focus our energies where they are most needed.

Of course, Courier Integrates with more than just Auth0. Just like we sent an email using Sendgrid in this blog post, you can use any of these channels - email, SMS, push, direct messaging, etc. with providers like Mailgun, Twilio, and Slack with just a single API to power your notification workflows. Sign up for a free Courier account. You build the next big thing and let us handle the notifications for you. 🚀

Additional References -

Courier Docs
Auth0 docs
Courier Node.js SDK

The Three Things to Never Build In Your App: Authentication, Notifications, and Payments

Tejas Kumthekar — Fri, 14 May 2021 00:54:01 +0000

https://www.courier.com/blog/the-three-things-to-never-build-in-your-app