Forem: Oleksii Klochai

Sending Scheduled and Recurring Email Notifications with PHP

Oleksii Klochai — Thu, 27 Jul 2023 11:01:32 +0000

Sending timely targeted email notifications greatly affects how your audience engages with your product. For these notifications to be effective at notifying your users of key events, you need to schedule when they are sent so that they are delivered at the right time.

Scheduled and recurring notifications are in use everywhere — for example, online stores use scheduled notifications to inform users about sale events (like Black Friday), and doctors, dentists, and tradespeople have systems that send appointment reminders. Recurring emails are commonly used for subscription services to email monthly bills to customers.

This tutorial covers two different ways for PHP developers to send scheduled and recurring email notifications through the Courier notification platform using its PHP SDK. It also offers a low-code solution for sending scheduled emails using just the Courier UI. Courier is a multi-channel notification service with a robust API, which you can use to build a production-ready email notification system in a few minutes.

Configure an email service provider in Courier

Create a Courier account if you don’t already have one, so that you can configure an email service provider in Courier, allowing it to send emails on your behalf. \

In the Courier app, navigate to Channels and choose your email service provider. For this tutorial, we will use Gmail.

On the next screen, select Sign in with Google to give Courier permission to access your Gmail account.

Create a notification template in Courier

Courier uses email templates to make it easy to reuse your emails. In this tutorial, we will use an example of a hairdressing business that sends emails to its clients before (and sometimes after) appointments.

To create your first template, start by navigating to the Designer. Click Create Template, give it the name Hair appointment reminder, and click Create Template again.

Next, select Email as the channel for this notification (choosing Gmail as the specific provider in the drop-down box). Now, click on your new email channel on the left side to see the no-code editor for designing your notification.

Give your notification the subject “Hair appointment reminder”, and paste the following content into the message body:

Dear {name},

This email is to confirm your upcoming hair appointment tomorrow.

We look forward to seeing you at {place}. Please arrive five minutes before your appointment start time.

If you need to reschedule, please let us know at least 24 hours prior to your appointment time.

Thank you for your appointment.

The {salonName} Team

The curly braces in this template are variables that will later be passed to the template as data. Now that your template is complete, click Publish Changes. Later on, you will need your notification template ID and Courier authorization token when you want to call the Courier API. These are both available in your notification template settings. Navigate there now and copy both so that you can use them later.

Now you have three options:

Directly send scheduled or recurring emails using Courier*:* Call the sendEnhancedNotification() function from the Courier PHP SDK, and use a third party task scheduling library called Crunz to deal with the scheduling side of things. This works using cron syntax, so the same principle can be used for scheduled or recurring emails.
Use Courier’s automations to add send logic to your scheduled emails: An automation in Courier is a way of chaining together different steps such as the sending of emails (or other notification-related logic) so that the steps happen in a particular order. An automation can be run by calling the invokeAutomation()function, and as with option 1, you can use Crunz to deal with the scheduling.
Using Courier’s no-code automations designer: This is a no-code GUI tool in the Courier UI that uses a drag-and-drop canvas to build up your notification logic. It contains some more advanced logic than option 2 (such as the ability to create email digests or batching).

Option 1: directly send a scheduled or recurring email using Courier

Preparing your PHP environment

For both of the PHP examples shown below, you will need to prepare a PHP environment and create a notification template in the Courier app.

Install the latest versions of PHP and Composer.
Install the following packages using Composer:
- trycourier/courier — the Courier PHP SDK
- guzzlehttp/guzzle — required by the Courier PHP SDK
- crunzphp/crunz — for scheduling one-time and recurring tasks
- vlucas/phpdotenv — for handling environment variables

You can install these by running the following command:

composer require crunzphp/crunz vlucas/phpdotenv trycourier/courier guzzlehttp/guzzle

You can also find the code shown in this tutorial in our working example repository on GitHub. If you are cloning the repository, you will need to run the composer install command to install the dependencies.

Sending a scheduled email

To manage the scheduling side of things, we will use Crunz — a PHP package that allows you to run scheduled tasks within your PHP code without having to create a cron job for each of them. We will wrap this around Courier’s sendEnhancedNotification() function, which is used for sending emails.

For this example, we have specified that the hair appointment reminder should be sent at a specific time (13:30 2023-07-01). However, note that Crunz’s on() function accepts any date format parsed by PHP's strtotime() function, so it’s easy to pass in a time value derived from one of your variables.

As per the example in our GitHub repository, you must provide your configuration in an .env file at the project root. You can create this file by copying the provided example file into your project directory:

cp .env.example .env

Then, fill out the contents of the newly copied .env file:

COURIER_AUTHORIZATION_TOKEN	Courier API key, found in Settings
TEST_EMAIL_TO	Use your own email address as the value
TEST_DIRECT_SEND_NOTIFICATION_TEMPLATE_ID	The notification template ID for the “Hair appointment reminder” email template

Crunz requires you to add a single crontab entry that runs every minute. Whenever this job runs, any tasks scheduled using Crunz for that time will be executed. You only need to do this once for your project. Append the following line to your own user’s crontab on your PHP server (you can do this by typing crontab -e in your terminal):

* * * * * cd /path/to/project && vendor/bin/crunz schedule:run

Replace /path/to/project with the absolute path to your PHP project. For security reasons, you should not add this line to your root user's crontab but instead create a user who has execute permissions for the project directory or is a member of the group that your web server runs under (by default, www-data on most Linux systems).

Crunz requires the presence of a configuration file, which contains a configured timezone. Create this by running this command in your project directory:

vendor/bin/crunz publish:config

Note that the default configured timezone is UTC, but you can change this in the config if needed.

All Crunz tasks must be contained in a directory called tasks at the root level of your project. The file containing each task should end with Tasks.php. Create this directory, and inside it, create a file called scheduledSendTasks.phpand paste the following code into it:

<?php

use Crunz\Schedule;
use Courier\CourierClient;
use Dotenv\Dotenv;

// Configure environment variables - set the .env directory to the parent of the Tasks directory
// Environment variables are stored in a variable so that they can be passed to the scheduled task, which will not have access to the current global namespace
$dotenv = Dotenv::createArrayBacked(__DIR__ . "/..")->load();

// Configure scheduler
$schedule = new Schedule();

// Configure the Courier PHP SDK - note the first null is the API path, of which we will use the default
$courier = new CourierClient(null, $dotenv['COURIER_AUTHORIZATION_TOKEN']);

// Create a new scheduled task
$task = $schedule->run(function () use ($courier, $dotenv) {

    echo "Running " . __FILE__ . "\n";

    // Send notification using the Courier PHP SDK
    $notification = (object) [
        "to" => [
            "email" => $dotenv['TEST_EMAIL_TO']
        ],
        "template" => $dotenv['TEST_DIRECT_SEND_NOTIFICATION_TEMPLATE_ID'],
        "routing" => [
            "method" => "single",
            "channels" => ["email"]
        ],
        "data" => [
            "name" => "John Doe",
            "place" => "123 High Street",
        "salonName" => "Cutting Edge"
        ]
    ];
    $result = $courier->sendEnhancedNotification($notification);
});

// Schedule a single notification for a specific time
$task->on('13:30 2023-07-01')
    ->description('Sending scheduled email');

return $schedule;

Now that you’ve created a scheduled task, it will run as soon as the scheduled time is reached. Remember, as mentioned above, the default timezone is UTC, but you can change this.

If you want to test your scheduled task, you can force it to run immediately using this command:

vendor/bin/crunz schedule:run --force

The above command will run all scheduled or recurring tasks that you’ve created. If you want to be sure which tasks will run with this command, you can run another command to check how many scheduled tasks you have:

vendor/bin/crunz schedule:list

This will output a table containing your scheduled tasks:

+---+------------------------------+-------------+-----------------+
| # | Task                         | Expression  | Command to Run  |
+---+------------------------------+-------------+-----------------+
| 1 | Sending scheduled email      | 30 13 1 7 * | object(Closure) |
| 2 | Sending recurring email      | 30 13 * * * | object(Closure) |
| 3 | Sending scheduled automation | 30 13 1 7 * | object(Closure) |
+---+------------------------------+-------------+-----------------+

Sending a recurring email

You can also use Crunz to create recurring tasks on a schedule.

Inside your tasks directory, create a PHP file called recurringSendTasks.php and paste this code into it:

<?php

use Crunz\Schedule;
use Courier\CourierClient;
use Dotenv\Dotenv;

// Configure environment variables - set the .env directory to the parent of the Tasks directory
// Environment variables are stored in a variable so that they can be passed to the scheduled task, which will not have access to the current global namespace
$dotenv = Dotenv::createArrayBacked(__DIR__ . "/..")->load();

// Configure scheduler
$schedule = new Schedule();

// Configure the Courier PHP SDK - note the first null is the API path, of which we will use the default
$courier = new CourierClient(null, $dotenv['COURIER_AUTHORIZATION_TOKEN']);

// Create a new scheduled task
$task = $schedule->run(function () use ($courier, $dotenv) {

    echo "Running " . __FILE__ . "\n";

    // Send notification using the Courier PHP SDK
    $notification = (object) [
        "to" => [
            "email" => $dotenv['TEST_EMAIL_TO']
        ],
        "template" => $dotenv['TEST_DIRECT_SEND_NOTIFICATION_TEMPLATE_ID'],
        "routing" => [
            "method" => "single",
            "channels" => ["email"]
        ],
        "data" => [
            "name" => "John Doe",
            "place" => "123 High Street",
            "salonName" => "Cutting Edge"
        ]
    ];
    $result = $courier->sendEnhancedNotification($notification);
});

// Set up a recurring task
$task
    ->daily()
    ->at('13:30')
    ->description('Sending recurring email');

return $schedule;

To test this, again run vendor/bin/crunz schedule:run --force. However, you’ll only receive one email, as you are using the –-force option, which forces a single run of each task. When your recurring task is being invoked by Crunz as a scheduled task, it will be called at the specified interval, and if you use the above code example, you will receive one email per day at 13:30.

Using Laravel? It’s already got scheduling baked in

If you’re using Laravel, you don’t need to worry about setting up your own scheduling solution, as it already has its own(https://laravel.com/docs/10.x/scheduling) (and queueing!) built in — one of the many advantages of using a PHP framework.

Option 2: use Courier’s automations to add send logic to your scheduled emails

Sometimes you need to add some logic around the sending of your scheduled or recurring emails, and this is where Courier’s automations can be useful. Automations allow you to chain together a series of different steps, including the sending of emails based on different notification templates.

Examples of when to use automations

Imagine a gym that sends its customers workout tips — it may want to sometimes send out different workout plans based on customers’ age or other groupings. Using automation in Courier, it could implement some basic branching logic such as “if the customer’s age is greater than 50, send an email using the over 50s email template; otherwise, send using the under 50s email template.”

Another feature that Courier automations offer is the ability to add a delay between two different actions. To reuse our hairdresser example, imagine that in addition to reminding the customer of their appointment the day before, they also want to send an email the day after their appointment to thank them and offer them 10% off their next appointment. Here’s how to implement this using Courier’s automations:

Sending two scheduled emails in one automation

As this involves sending two different emails, you will need to create a second email template for the 10% off offer. Create a new template with the following body:

Dear {name}, 

We hope you were satisfied with your hair appointment yesterday, and
we would like to offer you 10% off your next booking.

Thanks,

The {salonName} Team

Now that you have both email templates ready to go, you can create your automation in Courier. The automation sends the first email, then there is a delay (in the example below, there is a two-minute delay, but for real-world use, you would probably set it to two days), and then it sends a follow-up email. We will continue to use the PHP Crunz package to kick off the automation at the right moment (one day before the customer’s scheduled appointment), meaning that the second follow-up email will be sent one day after their appointment.

To follow along with this example, you will need to have followed the steps in the “Prepare your PHP environment” step explained earlier.

In your tasks directory in your PHP project, create a file called scheduleAutomationTasks.php and paste in the following code:

<?php

use Crunz\Schedule;
use Courier\CourierClient;
use Dotenv\Dotenv;

// Configure environment variables - set the .env directory to the parent of the Tasks directory
// Environment variables are stored in a variable so that they can be passed to the scheduled task, which will not have access to the current global namespace
$dotenv = Dotenv::createArrayBacked(__DIR__ . "/..")->load();

// Configure scheduler
$schedule = new Schedule();

// Configure the Courier PHP SDK - note the first null is the API path, of which we will use the default
$courier = new CourierClient(null, $dotenv['COURIER_AUTHORIZATION_TOKEN']);

// Create a new scheduled task
$task = $schedule->run(function () use ($courier, $dotenv) {

    echo "Running " . __FILE__ . "\n";

    // Invoke an automation using the Courier PHP SDK
    $automation = (object) [
        "steps" => [
            [
                "action" => "send",
                "recipient" => $dotenv['TEST_AUTOMATION_RECIPIENT_USER_ID'],
                "template" => $dotenv['TEST_AUTOMATION_NOTIFICATION_TEMPLATE_ID_1'], // Reminder email
                "brand" => $dotenv['YOUR_COURIER_BRAND_ID'],
                "data" => [
                      "name" => "John Doe",
                      "salonName" => "Cutting Edge"
                  ]
            ],
            [
                "action" => "delay",
                "duration" => "2 minutes" // You will probably want to delay by days or hours, but minutes are easier for testing
            ],
            [
                "action" => "send",
                "recipient" => $dotenv['TEST_AUTOMATION_RECIPIENT_USER_ID'],
                "template" => $dotenv['TEST_AUTOMATION_NOTIFICATION_TEMPLATE_ID_2'], // Follow-up email
                "brand" => $dotenv['YOUR_COURIER_BRAND_ID'],
                "data" => [
                      "name" => "John Doe",
                      "salonName" => "Cutting Edge"
                  ]
            ]
        ]
    ];
    $result = $courier->invokeAutomation($automation);
});

// Schedule the automation for a specific time
$task->on('13:30 2023-07-01')
    ->description('Sending scheduled automation');

return $schedule;

Ensure you’ve updated your .env file with any configuration you need to run this automation:

COURIER_AUTHORIZATION_TOKEN	Courier API key, found in Settings
TEST_AUTOMATION_RECIPIENT_USER_ID	Find your user ID in Courier’s list of users
TEST_AUTOMATION_NOTIFICATION_TEMPLATE_ID_1	The notification template ID for the “Hair appointment reminder” email template
TEST_AUTOMATION_NOTIFICATION_TEMPLATE_ID_2	The notification template ID for the “Hair appointment — 10% off” email template
YOUR_COURIER_BRAND_ID	Choose your brand and find its ID in its “brand settings” or URL

Now run vendor/bin/crunz schedule:run --force, and you will receive the two different emails with the specified delay in between.

Dynamic automations API documentation

To understand all the features that automations can offer, you can play around with our dynamic request builder in Courier’s [automation API documentation][20]. This allows you to build up your PHP automation request dynamically by adding request parameters. For example, if you add your preferred Courier brand ID in the “brand” box, your brand ID will be automatically added to a PHP request on the box on the right. You will need to select the “PHP” button to get a PHP request; however, other languages are available at the click of a button.

One of the key features of a Courier automation is the series of “steps” that make it up. To understand the different steps that can be part of an automation, see Courier’s extensive documentation.

Option 3: use Courier’s no-code automations designer to build complex logic around scheduled emails

The automations designer is a UI tool for building automation templates in Courier. An automation template offers a way to reuse Courier automations, and because they can be created in the Courier UI, they are super easy to create. Even your non-developer colleagues will be able to create automation templates using Courier’s simple drag-and-drop canvas.

For this example, we will use a “remember to pay your taxes” email, as this email could be sent on a schedule (April 1 of this year) or as a recurrence (April 1 every year).

Create a notification template

Create a new notification template with the subject “Tax deadline approaching,” and use the AI content generator to create some text for the body of your email. This may looks something like this:

Dear {name},

The end-of-year tax deadline is fast approaching. If you haven't yet filed your taxes, you can do this using our app:

{appUrl}

If you have any questions or concerns, please don't hesitate to contact us.

Thank you,

The {companyName} Team

Now that your template is complete, click Publish Changes.

Create an automation template

Navigate to automations, and click New Automation. Rename your automation from “Untitled Automation” to “Tax Deadline Reminder.”

To define the trigger for your automation, drag the Schedule trigger onto the canvas.

For a one-off scheduled email, change the Type of the Schedule node to Date, and enter the date and time you want your notification to be sent — in this case, we will choose midnight on April 1, 2024.

For a recurring email, change the Type to Recurrence. Then set a start date of April 1, 2024, 00:00, an end date of April 1, 2028, 00:00, and a frequency of Yearly. This will ensure the reminder email is sent for the next five years.

Next, drag a Send action onto the canvas, and ensure a line connects the bottom of the Schedule node to the top of the Send node so that it’s clear that the send action follows the schedule trigger.

Enter refs.data.user_id as the user that the email should be sent to, and select your “Tax deadline approaching” notification template from the drop-down box. Now, click on Edit next to Advanced to edit some advanced properties.

We will use the Advanced area to add some data to send to your automation template. This includes the user_id referred to in the previous paragraph plus any variables that your Tax deadline approaching notification template may be expecting.

Add this JSON to the Data section of the Advanced area:

{
  "name": "John Doe",
  "user_id": "courier-user-id",
  "appUrl": "example.com/file-taxes",
  "companyName": "Acme Ltd"
}

Finally, click Publish changes. Your email notification will be sent on April 1, 2024, at midnight.

Sending digests on a recurring schedule

If your reason for sending recurring emails is that your users are subscribed to regular news or updates from your app, you may want to set up an email digest. A digest allows you to avoid overwhelming your users with too many emails by condensing a large number of emails into one regular email update. Courier now offers the ability to send email digests. For more information, see the documentation.

Conclusion

Sending scheduled or recurring emails is not the simplest thing to do in PHP, as it doesn't have a task scheduler built into the language. On top of this, using a third party library like Crunz to deal with scheduling includes an extra layer of complication, in that you have to edit your crontabfile to hand over scheduling responsibility from your cron system to Crunz. This requires at least a basic understanding of how cron jobs work, including the syntax needed to run them.

The simpler option is to remove any need for scheduling tasks in PHP by using Courier's automation designer. This is a no-code solution that brings all your send logic inside the Courier UI. Aside from simplicity, an advantage of this is it allows your non-developer colleagues to be able to review or edit the logic around sending scheduled emails.

On the other hand, if it's more important to you to keep your send logic locked down and version controlled, and if you're prepared to get to grips with using Crunz, then you just need to decide whether you want to send a simple email (either a single email or a recurring one) — in which case you should use option 1 — or if you need to add more logic to the sending of your notifications, with the possibility of chaining together multiple steps — in which case option 2 is best.

If you haven’t yet joined Courier, you can sign up today and get started immediately. If you’re an existing Courier user, you can easily try scheduling one of your existing notification templates in our automations designer, or use our PHP SDK to get started with scheduled and recurring emails.

A Developer’s Guide to Notification APIs

Oleksii Klochai — Wed, 26 Jul 2023 13:41:04 +0000

While marketing-related notifications are often handled by marketing automation platforms, engineering teams require notification infrastructure that is designed for automated product-driven notifications. This might be a simple SMS password reset notification or new user onboarding email sequence. Or it may be a more complex notification tied to a feature of the application, such as an approval request sequence.

The infrastructure required to handle these notifications is extensive. Logic is typically required to trigger on an event, follow a specific workflow, personalize content, follow compliance guidelines, respect user preference, and work intelligently across channels (eg. email, SMS, push, in-app inbox, chat, etc). And it may require advanced send logic such as batching, digesting, throttling, and scheduling of notifications.

This is precisely what notification APIs solve. A notification API is a combination of backend infrastructure and both server- and client-side SDKs that enable developers to build notifications in web and mobile apps. It's free to signup and try Courier, the leading Notification API, yourself. Otherwise, read on to learn more.

Rather than developers spending time and effort building and maintaining the infrastructure on their own, Notification APIs give developers everything they need to create optimized, product-driven notifications that users will open and interact with.

Notification APIs are used together with communication APIs like Twilio, Messagebird, Slack, and FCS—acting as an abstraction layer to enable notification use cases. As a result, integrating notifications into an application and maintaining that infrastructure becomes a swift and future-proof process.

In this guide, we delve deeper into notification APIs, their role in transactional and marketing notifications, practical use cases, and the indirect benefits they offer.

Understanding and using notification APIs

Here are some examples of Notification API features. These are capabilities that add notification capabilities to communication APIs such as Twilio, Microsoft Teams, MessageBird, Slack, and so on.

Multi-channel send: Notification APIs allow for dispatching notifications across multiple channels, like email, SMS, and push notifications. This frees developers from the complexities of maintaining individual infrastructures for each channel, streamlining the process considerably. For instance, an HR application might dispatch a job offer requiring a signature via SMS, a channel offering urgency and external reach, while using a tool like Slack—an internal, less urgent channel—for onboarding tasks with a new employee.

Delivery status awareness across channels: A unique feature of notification APIs is their ability to track delivery status across all channels. This means, if an email, SMS, or push notification has been successfully delivered, it's accurately logged and reported. This insight enables developers to understand the efficacy of their communication across different platforms.

Additionally, some sophisticated notification APIs also monitor “read statuses.” This means that when a user reads a notification on one platform, it can potentially halt the delivery or alter the display of notifications on other channels, for example marking them as opened or read.

Automations: From fetching the latest data for inclusion in a notification to setting up advanced delivery timings and rules across channels, notification APIs automate much of the orchestration process. Automations within notification APIs reduce manual effort and potential errors. This might involve sending a time-delayed, multi-channel sequence of notifications that stop as soon as the user reads them. Alternatively, it could involve digesting and batching frequent notifications based on preset or user-defined frequency or even throttling messages that trigger too often.

Template management: Many notification APIs offer tools for developers to efficiently design, manage, and repurpose notification templates across various channels. These include pre-made templates as well as the option to create your own, eliminating the necessity of crafting notifications from scratch every time. This allows developers to focus more on the message and its intended impact, enhancing efficiency and overall user engagement.

Central logs and reporting: Robust logging and reporting capabilities are integral to notification APIs. This is especially relevant for notifications because it can present delivery status across channels in a single view. These features provide invaluable insights and aid in troubleshooting.

User preferences: Notification APIs provide a simple way to collect and respect user preferences for notification topics, channels, and frequencies, ensuring notifications don’t overwhelm users. Eg. a user might want to receive billing notifications via both SMS and email. But they may want to receive system error notifications via PagerDuty. And they may want to hold all comments on a project, to be rolled up into a single email digest every week. All of this is possible with a Notification API, which provides both the frontend components for the UI as well as the backend logic to respect these preferences. If all notifications get sent through a notification API, the service becomes a useful tool for controlling users’ notification preferences.

Web and mobile notification center (Inbox): In addition to external channels like email, Slack, and SMS, it often makes sense to hava a notification center, or "inbox" that lives inside of the web or mobile app. This typically also includes a bell icon with a change badge that counts number of messages, as well as related push notifications. A notification API will not only handle all the back-end logic for this functionality, but it will typically also offer a complete set of web and mobile SDKs for building the frontend experience. This allows developers to construct a fully functional in-app inbox and preference center with a notification API, elevating the overall user experience with minimal additional development time. Here's an example of Courier's inbox offering.

Internationalization: Notification APIs offer the advantage of internationalization. If the API manages message templates, it’s possible to select a template appropriate for each user’s region and language or even work in sync with a translation API to serve translated versions of notification content. This ensures that each user receives personalized and localized notifications, further improving user engagement and satisfaction.

By leveraging a notification API, a developer can save time on building these features without sacrificing the end users’ experience or creating technical debt.

The role of notification APIs in transactional versus marketing notifications

Notification APIs are typically used for transactional notifications. However, the transition away from moment-in-time marketing campaigns to ongoing Growth loops, is making Notification APIs more appropriate for marketing notifications than traditional marketing automation tools. To understand why that’s the case, let’s quickly define these two notification categories.

Transactional notifications are often triggered by user actions, such as making a purchase, resetting a password, or receiving a direct message. Or they may be tied to the functionality of a product feature - like a commenting feature in the app where you want to notify a person of an @mention. As their name suggests, these notifications are tied to specific transactions or interactions a user has with the application, playing a continuous role in user experience. They might rely on external channels like email and SMS or, for SaaS apps, they may be used with internal channels such as Slack, MS Teams, and PagerDuty.

Notification APIs prove particularly useful for transactional notifications due to their dynamic and event-triggered nature. By leveraging APIs, these real-time, personalized messages can be handled as they are generated, ensuring relevance.

On the other hand, marketing notifications are traditionally associated with promotional time-bound campaigns for a product, offer, or service. These messages focus on driving conversions or sales. Unlike transactional notifications, marketing notifications usually aren’t specific to the user or their activity in the app but instead get sent to larger groups of users. Marketing notifications also focus on external channels like email, SMS, push, and in-app.

Marketing notifications have traditionally been managed through a marketing platform due to their mass distribution nature and the connection to marketing campaigns. Specialized marketing platforms typically address the need for features such as opt-in logic to comply with anti-spam regulations, campaign management, and detailed analytics of the conversion process.

However, product growth experiments now cross the divide of marketing and are often more appropriate for Notification APIs than marketing automation tools. For example, if a user hits a key usage lifecycle milestone in your application, you may want to trigger a notification with a unique offer or with best practices to ensure their success. These kinds of notifications can drive higher application engagement and overall monetization of the app.

Over time, notification APIs have the potential to bridge the gap between transactional and marketing notifications. This potential stems from notification APIs’ ability to offer more personalized, event-driven marketing notifications that adhere to the user’s behavior and preferences.

In essence, notification APIs offer a robust framework that supports both transactional and marketing notifications, creating a cohesive and engaging user experience.

Benefits of using a notification API for developers

Notification APIs offer numerous indirect benefits that enhance efficiency, increase flexibility, and improve the developer experience.

One key advantage of notification APIs is provider independence. APIs abstract the underlying implementation details, allowing developers to switch providers (eg. from Postmark to SenGrid) swiftly if necessary without disrupting the overall application function. They can even provide failover between channels and providers without having to build out complex logic.

Notification APIs also offer consistency in notification formatting and delivery across various channels. Consistency improves user experience by ensuring each message is uniform, regardless of the channel through which it is sent.

From a developer’s perspective, APIs simplify the integration and management of notification systems. Developers don’t need to write boilerplate code for every new channel or message type or worry if their abstractions will carry over into a new provider’s API schema. Instead, they leverage the API’s functionality and use whichever providers they need, which can save considerable time and effort.

Sample use cases for notification APIs

Here are some examples of what you could build in your product using a notification API:

Status updates: Inform users about the progression of their initiated actions, such as “Your order is out for delivery” in a food delivery app context.
Appointment reminders: Remind users about upcoming appointments, deadlines, or important dates.
Approval requests: Request user approval for specific actions, such as document sharing or data access.
Authentication management: Handle password resets or two-factor authentication prompts.
Confirmation requests: Ask users to confirm potentially irreversible actions or decisions, such as deleting data.
Billing notifications: Inform users about upcoming payments, send payment confirmations, or notify them of billing issues.
Automated invites: Send automated invitations to events or cooperative endeavors.
Digests: Provide digests or summaries on user-selected topics at a frequency and channel set by the user.
E-commerce: Handle cart abandonment notifications, shipping updates, or requests for credit card updates.
Product engagement: Prompt users to return and complete a task, enhancing user engagement.
Survey requests: Solicit user feedback through surveys or review requests.
Welcome and user onboarding messages: Help new users get started with welcome messages and onboarding instructions.
Notify about a user’s activity: Alert users about new logins or changes to a shared project.
Platform engagement: Encourage users to engage with a platform or service more frequently.
Critical alerts: Notify users about critical issues, such as security alerts, product downtime, or other urgent matters.

In each of these use cases, notification APIs streamline the process of sending timely, relevant, and personalized notifications to users, enhancing user engagement and satisfaction.

Conclusion

Notification APIs have emerged as tools that enable developers to build product notification experiences that users love. By offering a streamlined way to manage notification content, delivery logic, internationalization, compliance, and user preferences, notification APIs reduce the complexity of building and maintaining the underlying infrastructure.

Notification APIs also help improve the user experience. By running all notifications through a single service, it’s possible to offer users more flexible preferences and cross-channel syncing of notification statuses. Prior to Notification APIs, only the largest, most sophisticated engineering teams could build this level of infrastructure in-house.

If you are interested in using a notification API, Courier is considered the leader in the market, funded by Twilio, Slack, and Google and used by companies such as Comcast, LaunchDarkly, Contentful, and Lattice. Courier is free to use for up to 10,000 notifications per month.

Using Prisma to Address Connection Pooling Issues in Serverless Environments

Oleksii Klochai — Mon, 06 Dec 2021 14:57:32 +0000

This article discusses what “serverless” environments are, why developers choose to deploy their apps to them, and how the Prisma Data Platform solves the problems that can arise regarding database connection pooling.

Choosing which tools you will use to build your application, and which platform you will be deploying to in production, are early and vital decisions that you will have to make when building a product.

Using an ORM like Prisma speeds up the development process, while serverless hosting reduces the ongoing cost and resource overhead of ensuring your application’s availability to your customers.

What is Prisma?

Prisma is a next-generation ORM (Object-Relational Mapping) library for Node.js and TypeScript.

Prisma allows you to build your app in JavaScript or TypeScript and work with your data as objects rather than SQL or NoSQL queries. These objects are mapped to a database using a schema that generates all the types and conversions required to accurately store your objects in your database platform.

The Prisma toolset includes developer tools for generating database migrations so that your database is always in-sync with your data mode as defined in the Prisma schema. In addition, the cloud-based Prisma Data Platform provides tools like user/role management and a data browser that allow you and your team to collaboratively manage your data online.

Using Prisma in your projects means spending less time worrying about your database, and more time to focus on building your app.

In addition to being a great aid to development, the Prisma Data Platform discussed in this article makes Prisma a flexible and efficient way to manage database connections for your application with minimal fuss.

What is “serverless” and why do developers “go serverless”?

Serverless hosting is a means of delivering your app to your user without having to build and maintain a server to deploy it to.

It may sound strange, but it is a cost effective way to deploy applications. Serverless cloud hosting providers like AWS Lambda and Vercel take care of all of the infrastructure required to run your application.

Here are some of the top reasons why developers are going serverless.

Reduced infrastructure requirements

The hosting provider administers all of the infrastructure required to host your app—maintaining it, keeping it up-to-date, and most importantly, keeping it secure. The provider deals with the day-to-day burdens of hosting.

Streamlined deployment

With serverless hosting you are provided tools to readily upload, run, and monitor your code. When a request comes in, your code is launched in a container and executed. The serverless environment discards the container when it is no longer needed.

Reduced costs

In addition to the time and resources saved by not having to maintain your own server infrastructure, you also save on the cost of running a full server 24/7. Many serverless hosting providers like AWS and Azure will only bill you for the resources you use.

Scalability

Serverless hosting offerings like AWS Lambda and Azure Functions can support sustained high load thanks to the cloud providers’ globally distributed infrastructure. In addition, such systems are well-suited for handling bursts of high load amid periods of lower use due to their automatic scaling functionality.

The issues with “connection pooling” in serverless environments

Any database, serverless or not, has a limit on the number of open connections that it can handle at one time. For each open connection, the database system like PostgreSQL or MySQL reserves network, memory, and compute resources so that it’s able to handle any incoming requests through each connection.

In a serverless environment your code does not run constantly. A user makes a request (whether it’s viewing a webpage or requesting an API resource), and a tiny containerized executing environment (called an instance) running only the code required to serve the request is launched. The request is served, and the instance is destroyed.

This is efficient, but there is one problem. In traditional hosting environments with a single server that runs your application, a single instance of the application can service multiple user requests.

In a traditional hosting environment a single instance of the application will be managing a single connection pool to your database. The connection pool ensures that any database queries are within the connection and timeout limits that you have configured. It coordinates the re-use of database connections and prevents the database server from being overloaded.

In a serverless environment, a new instance of your code is launched for every user request. Each instance will be unaware of the others, resulting in multiple connection pools. As these separate connection pools are not aware of one another, they cannot coordinate to ensure the database server is not overloaded.

In a serverless environment, there is no shared connection pool. This creates the risk that a small number of user requests exhaust the database connection limit causing the application to stop working.

Methods of dealing with with connection pooling issues

There are three key ways in which the modern developer can deal with connection pooling issues in a serverless environment.

External connection poolers

One method is to use an external connection pooler. By moving the task of coordinating database connections outside of your serverless app, an external connection pooler solves the issue of the separate execution instances not being able to coordinate with each other.
Not all database servers have an external connection pooler. If this path you choose to mitigate the issue, you should carefully select which tools and platforms will be used in your project early in the development process.

The Prisma Data Proxy is an example of an external connection pooler approach.

Adjusting your code

Another method to overcome connection pooling issues is to ensure that your code is written in a way that accounts for the serverless environment in which it will run. Some cloud providers do reuse resources between requests, so structuring your code so that connections can be maintained between requests is a way to reduce database load.

However, this approach is limited and will only help alleviate the problem to some degree.

Fine tuning your database server

An important step in deploying to a production environment is to monitor and profile your application. Knowing how your application will be used and how busy it will be allows you to determine what resources to allocate. With this information, you can optimize your database connection to reduce the chance of overloading it. For example, you can reduce the connection timeout for inactive connections so that your database is less likely to be spending resources on a connection that’s not going to be used. Another option is to increase the connection limit on the database, but handling more connections will likely require more compute resources.

In addition to supporting these traditional methods of dealing with connection pooling issues, the Prisma Data Platform introduces a reliable and readily configurable database proxy that solves connection pooling issues—regardless of the database server or database host in use.

Solving connection pooling issues with Prisma Data Proxy

Prisma has introduced a new service that effectively solves the connection pooling issue when deploying to serverless environments like AWS Lambda and Vercel.

The Prisma Data Proxy acts as an intermediary between your application code and the database, effectively acting as an external connection pooler for any database supported by Prisma.

Flexible ORM and proxy with external connection pooling

Using the Prisma Data Proxy solves the connection pooling issue without you having to drastically alter your code or spend extra time tweaking your database connection configuration to account for the serverless environment.

The Prisma Data Proxy also reduces the size of the data bundle that you must upload to your serverless hosting environment. Many of the database functions are outsourced to the highly performant Prisma Engine binary hosted by the Prisma Data Proxy, so they do not need to be included with your deployment bundle.

Part of the Prisma Data Platform

The Prisma Data Proxy is part of the Prisma Data Platform, a cloud based platform that helps manage and collaborate on application data.

The Prisma Data Platform includes a powerful databas tools to assist you and your team during the development process. This includes the Prisma Query Console, which enables you to view and manage your live data through a simple interface. It allows you to gain insight into how your application is used and to quickly fix any arising data issues.

The benefits of serverless hosting and Prisma

Serverless hosting in combination with the Prisma Data Platform provides a set of collaborative development and deployment tools for developers who simply want to get on with building their product.
Building and running serverless applications has become a very attractive option for developers due to the reduced resources and costs, and an easier scaling approach.

However, when developing your application you will have to ensure its suitability to be run in a serverless environment. There is nothing inherently wrong with the serverless concept, but there are differences to traditional hosting configurations that must be considered when coding to deploy in such an environment.

The Prisma Data Platform is being actively developed to address the challenges of deploying data-intensive apps to modern serverless platforms while allowing you to use the database and database host you are already comfortable with.

To learn more about databases in the Serverless era and a sneak peak into Prisma's vision for the Prisma Data Platform, check out the talks from the Prisma Serverless Conference.

Get started with the Prisma Data Platform

The Prisma Data Platform, including the Prisma Data Proxy, is currently available in Early Access.

Online documentation is available to get you started, so that you are ready to implement the Prisma Data Platform in your project when it is released.

See the Prisma Data Proxy in action or learn more about how to easily integrate the Prisma Data Platform into your project.

And if you are ready to try Prisma Data Platform out, get started today!