Sending Emails Asynchronously Through AWS SES

Leonardo Losoviz

2018-11-13T14:30:53+01:002018-11-13T14:40:42+00:00

Most applications send emails to communicate with their users. Transactional emails are those triggered by the user’s interaction with the application, such as when welcoming a new user after registering in the site, giving the user a link to reset the password, or attaching an invoice after the user does a purchase. All these previous cases will typically require sending only one email to the user. In some other cases though, the application needs to send many more emails, such as when a user posts new content on the site, and all her followers (which, in a platform like Twitter, may amount to millions of users) will receive a notification. In this latter situation, not architected properly, sending emails may become a bottleneck in the application.

That is what happened in my case. I have a site that may need to send 20 emails after some user-triggered actions (such as user notifications to all her followers). Initially, it relied on sending the emails through a popular cloud-based SMTP provider (such as SendGrid, Mandrill, Mailjet and Mailgun), however the response back to the user would take seconds. Evidently, connecting to the SMTP server to send those 20 emails was slowing the process down significantly.

After inspection, I found out the sources of the problem:

1. Synchronous connection
   The application connects to the SMTP server and waits for an acknowledgment, synchronously, before continuing the execution of the process.
2. High latency
   While my server is located in Singapore, the SMTP provider I was using has its servers located in the US, making the roundtrip connection take considerable time.
3. No reusability of the SMTP connection When calling the function to send an email, the function sends the email immediately, creating a new SMTP connection on that moment (it doesn’t offer to collect all emails and send them all together at the end of the request, under a single SMTP connection).

Because of #1, the time the user must wait for the response is tied to the time it takes to send the emails. Because of #2, the time to send one email is relatively high. And because of #3, the time to send 20 emails is 20 times the time it takes to send one email. While sending only one email may not make the application terribly slower, sending 20 emails certainly does, affecting the user experience.

Let’s see how we can solve this issue.

Paying Attention To The Nature Of Transactional Emails

Before anything, we must notice that not all emails are equal in importance. We can broadly categorize emails into two groups: priority and non-priority emails. For instance, if the user forgot the password to access the account, she will expect the email with the password reset link immediately on her inbox; that is a priority email. In contrast, sending an email notifying that somebody we follow has posted new content does not need to arrive on the user’s inbox immediately; that is a non-priority email.

The solution must optimize how these two categories of emails are sent. Assuming that there will only be a few (maybe 1 or 2) priority emails to be sent during the process, and the bulk of the emails will be non-priority ones, then we design the solution as follows:

• Priority emails can simply avoid the high latency issue by using an SMTP provider located in the same region where the application is deployed. In addition to good research, this involves integrating our application with the provider’s API.
• Non-priority emails can be sent asynchronously, and in batches where many emails are sent together. Implemented at the application level, it requires an appropriate technology stack.

Let’s define the technology stack to send emails asynchronously next.

Defining The Technology Stack

Note: I have decided to base my stack on AWS services because my website is already hosted on AWS EC2. Otherwise, I would have an overhead from moving data among several companies’ networks. However, we can implement our soluting using other cloud service providers too.

My first approach was to set-up a queue. Through a queue, I could have the application not send the emails anymore, but instead publish a message with the email content and metadata in a queue, and then have another process pick up the messages from the queue and send the emails.

However, when checking the queue service from AWS, called SQS, I decided that it was not an appropriate solution, because:

• It is rather complex to set-up;
• A standard queue message can store only up top 256 kb of information, which may not be enough if the email has attachments (an invoice for instance). And even though it is possible to split a large message into smaller messages, the complexity grows even more.

Then I realized that I could perfectly imitate the behavior of a queue through a combination of other AWS services, S3 and Lambda, which are much easier to set-up. S3, a cloud object storage solution to store and retrieve data, can act as the repository for uploading the messages, and Lambda, a computing service that runs code in response to events, can pick a message and execute an operation with it.

In other words, we can set-up our email sending process like this:

1. The application uploads a file with the email content + metadata to an S3 bucket.
2. Whenever a new file is uploaded into the S3 bucket, S3 triggers an event containing the path to the new file.
3. A Lambda function picks the event, reads the file, and sends the email.

Finally, we have to decide how to send emails. We can either keep using the SMTP provider that we already have, having the Lambda function interact with their APIs, or use the AWS service for sending emails, called SES. Using SES has both benefits and drawbacks:

Benefits:

• Very simple to use from within AWS Lambda (it just takes 2 lines of code).
• It is cheaper: Lambda fees are computed based on the amount of time it takes to execute the function, so connecting to SES from within the AWS network will take a shorter time than connecting to an external server, making the function finish earlier and costing less. (Unless SES is not available in the same region where the application is hosted; in my case, because SES is not offered in the Asian Pacific (Singapore) region, where my EC2 server is located, then I might be better off connecting to some Asia-based external SMTP provider).

Drawbacks:

• Not many stats for monitoring our sent emails are provided, and adding more powerful ones requires extra effort (eg: tracking what percentage of emails were opened, or what links were clicked, must be set-up through AWS CloudWatch).
• If we keep using the SMTP provider for sending the priority emails, then we won’t have our stats all together in 1 place.

For simplicity, in the code below we will be using SES.

We have then defined the logic of the process and stack as follows: The application sends priority emails as usual, but for non-priority ones, it uploads a file with email content and metadata to S3; this file is asynchronously processed by a Lambda function, which connects to SES to send the email.

Let’s start implementing the solution.

Differentiating Between Priority And Non-Priority Emails

In short, this all depends on the application, so we need to decide on an email by email basis. I will describe a solution I implemented for WordPress, which requires some hacks around the constraints from function wp_mail. For other platforms, the strategy below will work too, but quite possibly there will be better strategies, which do not require hacks to work.

The way to send an email in WordPress is by calling function wp_mail, and we don’t want to change that (eg: by calling either function wp_mail_synchronous or wp_mail_asynchronous), so our implementation of wp_mail will need to handle both synchronous and asynchronous cases, and will need to know to which group the email belongs. Unluckily, wp_mail doesn’t offer any extra parameter from which we could asses this information, as it can be seen from its signature:

function wp_mail( $to, $subject, $message, $headers = '', $attachments = array() )

Then, in order to find out the category of the email we add a hacky solution: by default, we make an email belong to the priority group, and if $to contains a particular email (eg: nonpriority@asynchronous.mail), or if $subject starts with a special string (eg: “[Non-priority!]“), then it belongs to the non-priority group (and we remove the corresponding email or string from the subject). wp_mail is a pluggable function, so we can override it simply by implementing a new function with the same signature on our functions.php file. Initially, it contains the same code of the original wp_mail function, located in file wp-includes/pluggable.php, to extract all parameters:

if ( !function_exists( 'wp_mail' ) ) :

function wp_mail( $to, $subject, $message, $headers = '', $attachments = array() ) {

  $atts = apply_filters( 'wp_mail', compact( 'to', 'subject', 'message', 'headers', 'attachments' ) );

  if ( isset( $atts['to'] ) ) {
    $to = $atts['to'];
  }

  if ( !is_array( $to ) ) {
    $to = explode( ',', $to );
  }

  if ( isset( $atts['subject'] ) ) {
    $subject = $atts['subject'];
  }

  if ( isset( $atts['message'] ) ) {
    $message = $atts['message'];
  }

  if ( isset( $atts['headers'] ) ) {
    $headers = $atts['headers'];
  }

  if ( isset( $atts['attachments'] ) ) {
    $attachments = $atts['attachments'];
  }

  if ( ! is_array( $attachments ) ) {
    $attachments = explode( "n", str_replace( "rn", "n", $attachments ) );
  }
  
  // Continue below...
}
endif;

And then we check if it is non-priority, in which case we then fork to a separate logic under function send_asynchronous_mail or, if it is not, we keep executing the same code as in the original wp_mail function:

function wp_mail( $to, $subject, $message, $headers = '', $attachments = array() ) {

  // Continued from above...

  $hacky_email = "nonpriority@asynchronous.mail";
  if (in_array($hacky_email, $to)) {

    // Remove the hacky email from $to
    array_splice($to, array_search($hacky_email, $to), 1);

    // Fork to asynchronous logic
    return send_asynchronous_mail($to, $subject, $message, $headers, $attachments);
  }

  // Continue all code from original function in wp-includes/pluggable.php
  // ...
}

In our function send_asynchronous_mail, instead of uploading the email straight to S3, we simply add the email to a global variable $emailqueue, from which we can upload all emails together to S3 in a single connection at the end of the request:

function send_asynchronous_mail($to, $subject, $message, $headers, $attachments) {
  
  global $emailqueue;
  if (!$emailqueue) {
    $emailqueue = array();
  }
  
  // Add email to queue. Code continues below...
}

We can upload one file per email, or we can bundle them so that in 1 file we contain many emails. Since $headers contains email meta (from, content-type and charset, CC, BCC, and reply-to fields), we can group emails together whenever they have the same $headers. This way, these emails can all be uploaded in the same file to S3, and the $headers meta information will be included only once in the file, instead of once per email:

function send_asynchronous_mail($to, $subject, $message, $headers, $attachments) {
  
  // Continued from above...

  // Add email to the queue
  $emailqueue[$headers] = $emailqueue[$headers] ?? array();
  $emailqueue[$headers][] = array(
    'to' => $to,
    'subject' => $subject,
    'message' => $message,
    'attachments' => $attachments,
  );

  // Code continues below
}

Finally, function send_asynchronous_mail returns true. Please notice that this code is hacky: true would normally mean that the email was sent successfully, but in this case, it hasn’t even been sent yet, and it could perfectly fail. Because of this, the function calling wp_mail must not treat a true response as “the email was sent successfully,” but an acknowledgment that it has been enqueued. That’s why it is important to restrict this technique to non-priority emails so that if it fails, the process can keep retrying in the background, and the user will not expect the email to already be in her inbox:

function send_asynchronous_mail($to, $subject, $message, $headers, $attachments) {
  
  // Continued from above...

  // That's it!
  return true;
}

Uploading Emails To S3

In my previous article “Sharing Data Among Multiple Servers Through AWS S3”, I described how to create a bucket in S3, and how to upload files to the bucket through the SDK. All code below continues the implementation of a solution for WordPress, hence we connect to AWS using the SDK for PHP.

We can extend from the abstract class AWS_S3 (introduced in my previous article) to connect to S3 and upload the emails to a bucket “async-emails” at the end of the request (triggered through wp_footer hook). Please notice that we must keep the ACL as “private” since we don’t want the emails to be exposed to the internet:

class AsyncEmails_AWS_S3 extends AWS_S3 {

  function __construct() {

    // Send all emails at the end of the execution
    add_action("wp_footer", array($this, "upload_emails_to_s3"), PHP_INT_MAX);
  }

  protected function get_acl() {

    return "private";
  }

  protected function get_bucket() {

    return "async-emails";
  }

  function upload_emails_to_s3() {

    $s3Client = $this->get_s3_client();

    // Code continued below...
  }
}
new AsyncEmails_AWS_S3();

We start iterating through the pairs of headers => emaildata saved in global variable $emailqueue, and get a default configuration from function get_default_email_meta for if the headers are empty. In the code below, I only retrieve the “from” field from the headers (the code to extract all headers can be copied from the original function wp_mail):

class AsyncEmails_AWS_S3 extends AWS_S3 {

  public function get_default_email_meta() {

    // Code continued from above...

    return array(
      'from' => sprintf(
        '%s ',
        get_bloginfo('name'),
        get_bloginfo('admin_email')
      ),
      'contentType' => 'text/html',
      'charset' => strtolower(get_option('blog_charset'))
    );
  }

  public function upload_emails_to_s3() {

    // Code continued from above...

    global $emailqueue;
    foreach ($emailqueue as $headers => $emails) {

      $meta = $this->get_default_email_meta();

      // Retrieve the "from" from the headers
      $regexp = '/From:s*(([^?s*n/i';
      if(preg_match($regexp, $headers, $matches)) {
        
        $meta['from'] = sprintf(
          '%s ',
          $matches[2],
          $matches[3]
        );
      }

      // Code continued below... 
    }
  }
}

Finally, we upload the emails to S3. We decide how many emails to upload per file with the intention to save money. Lambda functions charge based on the amount of time they need to execute, calculated on spans of 100ms. The more time a function requires, the more expensive it becomes.

Sending all emails by uploading 1 file per email, then, is more expensive than uploading 1 file per many emails, since the overhead from executing the function is computed once per email, instead of only once for many emails, and also because sending many emails together fills the 100ms spans more thoroughly.

So we upload many emails per file. How many emails? Lambda functions have a maximum execution time (3 seconds by default), and if the operation fails, it will keep retrying from the beginning, not from where it failed. So, if the file contains 100 emails, and Lambda manages to send 50 emails before the max time is up, then it fails and it retries executing the operation again, sending the first 50 emails once again. To avoid this, we must choose a number of emails per file that we are confident is enough to process before the max time is up. In our situation, we could choose to send 25 emails per file. The number of emails depends on the application (bigger emails will take longer to be sent, and the time to send an email will depend on the infrastructure), so we should do some testing to come up with the right number.

The content of the file is simply a JSON object, containing the email meta under property “meta”, and the chunk of emails under property “emails”:

class AsyncEmails_AWS_S3 extends AWS_S3 {

  public function upload_emails_to_s3() {

    // Code continued from above...
    foreach ($emailqueue as $headers => $emails) {

      // Code continued from above...

      // Split the emails into chunks of no more than the value of constant EMAILS_PER_FILE:
      $chunks = array_chunk($emails, EMAILS_PER_FILE);
      $filename = time().rand();
      for ($chunk_count = 0; $chunk_count  $meta,
          'emails' => $chunks[$chunk_count],
        );

        // Upload to S3
        $s3Client->putObject([
          'ACL' => $this->get_acl(),
          'Bucket' => $this->get_bucket(),
          'Key' => $filename.$chunk_count.'.json',
          'Body' => json_encode($body),
        ]);  
      }   
    }
  }
}

For simplicity, in the code above, I am not uploading the attachments to S3. If our emails need to include attachments, then we must use SES function SendRawEmail instead of SendEmail (which is used in the Lambda script below).

Having added the logic to upload the files with emails to S3, we can move next to coding the Lambda function.

Coding The Lambda Script

Lambda functions are also called serverless functions, not because they do not run on a server, but because the developer does not need to worry about the server: the developer simply provides the script, and the cloud takes care of provisioning the server, deploying and running the script. Hence, as mentioned earlier, Lambda functions are charged based on function execution time.

The following Node.js script does the required job. Invoked by the S3 “Put” event, which indicates that a new object has been created on the bucket, the function:

1. Obtains the new object’s path (under variable srcKey) and bucket (under variable srcBucket).
2. Downloads the object, through s3.getObject.
3. Parses the content of the object, through JSON.parse(response.Body.toString()), and extracts the emails and the email meta.
4. Iterates through all the emails, and sends them through ses.sendEmail.

var async = require('async');
var aws = require('aws-sdk');
var s3 = new aws.S3();
      
exports.handler = function(event, context, callback) {

  var srcBucket = event.Records[0].s3.bucket.name;
  var srcKey = decodeURIComponent(event.Records[0].s3.object.key.replace(/+/g, " ")); 

  // Download the file from S3, parse it, and send the emails
  async.waterfall([

    function download(next) {

      // Download the file from S3 into a buffer.
      s3.getObject({
        Bucket: srcBucket,
        Key: srcKey
      }, next);
    },
    function process(response, next) {
          
      var file = JSON.parse(response.Body.toString());
      var emails = file.emails;
      var emailsMeta = file.meta;
        
      // Check required parameters
      if (emails === null || emailsMeta === null) {
        callback('Bad Request: Missing required data: ' + response.Body.toString());
        return;
      }
      if (emails.length === 0) {
        callback('Bad Request: No emails provided: ' + response.Body.toString());
        return;
      }
      
      var totalEmails = emails.length;
      var sentEmails = 0;
      for (var i = 0; i 

Next, we must upload and configure the Lambda function to AWS, which involves:

1. Creating an execution role granting Lambda permissions to access S3.
2. Creating a .zip package containing all the code, i.e. the Lambda function we are creating + all the required Node.js modules.
3. Uploading this package to AWS using a CLI tool.

How to do these things is properly explained on the AWS site, on the Tutorial on Using AWS Lambda with Amazon S3.

Hooking Up S3 With The Lambda Function

Finally, having the bucket and the Lambda function created, we need to hook both of them together, so that whenever there is a new object created on the bucket, it will trigger an event to execute the Lambda function. To do this, we go to the S3 dashboard and click on the bucket row, which will show its properties:

Then clicking on Properties, we scroll down to the item “Events”, and there we click on Add a notification, and input the following fields:

• Name: name of the notification, eg: “EmailSender”;
• Events: “Put”, which is the event triggered when a new object is created on the bucket;
• Send to: “Lambda Function”;
• Lambda: name of our newly created Lambda, eg: “LambdaEmailSender”.

Finally, we can also set the S3 bucket to automatically delete the files containing the email data after some time. For this, we go to the Management tab of the bucket, and create a new Lifecycle rule, defining after how many days the emails must expire:

That’s it. From this moment, when adding a new object on the S3 bucket with the content and meta for the emails, it will trigger the Lambda function, which will read the file and connect to SES to send the emails.

I implemented this solution on my site, and it became fast once again: by offloading sending emails to an external process, whether the applications send 20 or 5000 emails doesn’t make a difference, the response to the user who triggered the action will be immediate.

Conclusion

In this article we have analyzed why sending many transactional emails in a single request may become a bottleneck in the application, and created a solution to deal with the issue: instead of connecting to the SMTP server from within the application (synchronously), we can send the emails from an external function, asynchronously, based on a stack of AWS S3 + Lambda + SES.

By sending emails asynchronously, the application can manage to send thousands of emails, yet the response to the user who triggered the action will not be affected. However, to ensure that the user is not waiting for the email to arrive in the inbox, we also decided to split emails into two groups, priority and non-priority, and send only the non-priority emails asynchronously. We provided an implementation for WordPress, which is rather hacky due to the limitations of function wp_mail for sending emails.

A lesson from this article is that serverless functionalities on a server-based application work pretty well: sites running on a CMS like WordPress can improve their performance by implementing only specific features on the cloud, and avoid a great deal of complexity that comes from migrating highly dynamic sites to a fully serverless architecture.

(rb, ra, yk, il)

It was 1995 and the universe was deep in battle…

A fearsome empire was striving for world domination and crushing their competitors with an iron fist.

Their strategy?

Embrace, extend, extinguish.

Meanwhile, an impertinent upstart was lurking in the wings?—?one that would eventually bid to overcome the empire.

The upstart’s motto?

Don’t be evil.

Ok, this might sound like the intro to a superhero movie.

But it’s the tale of two of the mightiest corporations of all time: Microsoft and Google.

The killer twist?

The good guys turned to the dark side.

They took Microsoft’s rallying cry and made it their own.

Standards exist for a reason

I’m sitting in my favorite coffee shop as I write this. Their lattes are strong and the wifi is speedy.

Of course, once in a while, I have login problems, or poor data speeds?—?but it’s rare.

It’s rare because hardware manufacturers and software developers have agreed on a standard. In fact, a few of them: as Andy Tanenbaum said,

the nice thing about standards is that you have so many to choose from.

Our modern world relies on people agreeing to work by common rules. And in the online sphere, this begins with open standards. As the principles state:

Open standards make it possible for the smallest supplier to compete with the largest. They make data open for any citizen to audit. They unlock the transformative power of open source software.

Think of good old plain text files.

For the English-speaking world, the underlying standard is ASCII, which sets down the rules for encoding the alphabet as 0s and 1s.

Now, imagine a universe in which you had to pay a $1 licensing fee every time you wanted to read or write a text file in ASCII. It would be a nightmare, right?

Luckily, that would never happen. Because we have rules.

But sometimes, people try to game the system

Take HTML, the standard language for writing web pages, invented in the ’90s by Tim Berners-Lee.

The HTML specification has evolved over the years, and the W3C acts as a forum for gaining specification consensus from large players such as Adobe, Apple, Google, Intel, and Microsoft.

But there’s been a history of skirmishes, with different companies proposing their own variants. During the first browser wars, Netscape proposed a tag, while Microsoft came up with , which was meant to cause text to scroll in various directions.

There’s no problem with that (apart from lousy aesthetics), right? Wrong. Because only Netscape Navigator knew what to do with , and only Internet Explorer knew what to do with .

They were modifying a standard so that it would only run with their software.

They were trying to build a monopoly.

The quest for domination

Microsoft famously coined the phrase “embrace, extend, extinguish” to describe their strategy for dominating markets where competitors benefited from open standards.

Here’s an example of how it played out.

Back in the day, the most powerful PC software package was Lotus 1–2– 3. It was the classic killer app for the IBM PC and Microsoft’s MS-DOS operating system.

To overcome Lotus, Microsoft knew it had to embrace what made the product unique. This meant it had to load Lotus files and the macros that came with them. Enter Excel, a spreadsheet program that initially ran on Macs.

The functionality of Excel was as similar to Lotus as it could be without being a blatant rip-off. So close, in fact, that people could switch from Lotus to Excel with minimal pain.

What’s more, Microsoft used the graphics capabilities of Macs to equip Excel with a cool GUI. This was a leap ahead of standard MS-DOS packages like Lotus 1–2–3.

Next, Microsoft extended by creating Office: the holy trinity of Excel, Word, and Powerpoint, all running together on Windows. By 1995, these programs were working together well, and although there were a number of word processors to choose from, there weren’t any compelling competitors for Excel on Windows.

Microsoft sharpened their competitive edge with company discounts and clever Office 95 marketing, and as a result, most major businesses were adopting it as their standardized software suite?—?and Excel was part of the bundle. No need to buy a standalone package like Lotus 1–2–3.

Meanwhile, Symphony?—?the Lotus integrated package for MS-DOS that aimed to compete with Office?—?never prospered and was eventually abandoned. Microsoft had officially extinguished Lotus 1–2–3.

They wanted Office to become the gold standard for productivity software. And they succeeded. But not long after establishing the dominance of their desktop operating system, Microsoft realized that another challenge was looming.

The World Wide Web was becoming wildly successful, to an extent that few people had foreseen.

Not only could people browse websites that were outside Microsoft’s control, but Netscape introduced the JavaScript scripting language which allowed developers to write code that ran in the browser. In effect, Netscape was inventing a new operating system, distributed between the client-side browser and the remote server.

Even worse, content on the web was platform-agnostic: browsers worked just fine on Macs and Unix as well as Windows, so an application that ran in the browser would rip open the Microsoft business model.

In order to get a piece of the action, Microsoft launched Internet Explorer (IE) in 1995 as a direct competitor to Netscape Navigator. Initially, it only had a tiny market share: less than 10% by the close of 1996. So this was more of an air kiss than a full embrace of the internet.

Things heated up with the release of IE3, bundled as a free component of Windows in 1996, and integrating a number of apps that were part of the Microsoft ecosystem: an internet mail client (later to become Outlook Express), an address book, and the Windows Media Player. IE4 continued the extend theme by bundling programs for the chat and video conferencing.

At the same time, Microsoft re-engineered the Windows desktop look and feel to make it more like browsing a web page. How did Netscape Navigator fit into this cozy set up?

Not at all?—?it functioned increasingly worse on the Microsoft operating system. By the end of the decade, Internet Explorer had 86% of the browser market.

– Game over for Netscape.

Today, Microsoft is working hard to shed its ‘evil’ reputation, contributing to open source and supporting open standards.

But we may have a new villain on our hands…

Google: the new king of Embrace, Extend, Extinguish

It was March 31, 2004.

The headlines were in a frenzy:

Google, the dominant Internet search company, is planning to up the stakes in its intensifying competition with Yahoo and Microsoft by unveiling a new consumer-oriented electronic mail service.

At the time, the news seemed outrageous. A search engine company? Launching a free email service? With an alleged storage capacity of 1GB?—?500 times bigger than what Microsoft’s Hotmail offered?!

In fact, when April 1st rolled around and Google issued a press release officially announcing Gmail, most people took it as a far-fetched hoax.

But Gmail was no April Fool’s Day joke.

Boasting massive storage, a slick interface, instant search, and personalization options, it was real?—?and revolutionary.

Not only did Gmail blow Hotmail and Yahoo Mail out of the water, but it was also the first app with the potential to replace conventional PC software.

According to Georges Harik, who was responsible for most of Google’s new products at the time:

“It was a pretty big moment for the Internet. Taking something that hadn’t been worked on for years but was central, and fixing it.”

Google had officially extended email. And, while they didn’t extinguish other email providers entirely, they certainly came close.

Then there’s AMP. The Accelerated Mobile Pages Project (AMP) is a technology that enables web pages to load more rapidly on mobile devices.

AMP was originally targeted at news publishers, to compete with Facebook’s Instant Articles, but it has now far outstripped the latter, after being adopted by platforms such as Reddit, Twitter, and LinkedIn

As a strategy, AMP is Google’s most brazen. It serves as a vehicle for routing users through the Google Content Delivery Network even if they’re reading content from other websites. Sites that don’t adopt AMP get pushed out of Google mobile search results and into oblivion.

Or, extinguished.

There’s also the infamous case of Google Reader, which dug the grave for RSS (Rich Site Summary).

RSS’s decline was evident before Google axed it, but killing Reader dealt a massive blow to any of RSS’s remaining momentum. Google said themselves they wanted to consolidate users onto the rest of their services?—?none of which support any open syndication standards.

Tech writer Ed Bott summarizes eloquently:

The short life and sad death of Google Reader tells a familiar story of how Google swept into a crowded field, killed off almost all credible competition with a free product, and then arbitrarily killed that product when it no longer had a use for it.

Last but not least, there’s PDF.

To recap:

PDF was a proprietary format controlled by Adobe until it was released as an open standard in 2008. When it was published by the International Organization for Standardization as ISO 32000–1:2008, control of the specification passed to an ISO Committee of volunteer industry experts. In 2008, Adobe published a Public Patent License to ISO 32000–1 granting royalty-free rights for all patents owned by Adobe that are necessary to make, use, sell, and distribute PDF compliant implementations.

PDFs have a feature that allows forms to be submitted. This feature previously worked on all PDF viewers (such as Adobe Acrobat and Apple Preview). That is until Chrome started their own viewers for PDF files.

As Google’s browser gained market share (now hitting over 60% in the usage stakes), most people began viewing PDFs in Chrome’s native PDF reader. But, here’s the kicker: Chrome doesn’t support all of PDF’s features.

For example, my company, JotForm, has a feature called fillable PDF Forms. It lets you create PDF forms, which you can submit.

So, forms created with Adobe or JotForm’s PDF tool often don’t work on Chrome. We have to instruct people to use Adobe Acrobat instead, which creates needless friction.

In a nutshell, Google’s behavior prevents us from investing more deeply in the PDF Forms.

Our feature is being extinguished before our eyes.

So all of this begs the question:

Does Google really support open source?

Google vs. Apple

In 1995, it was Microsoft vs. Netscape.

In 2018, it’s Google vs. Apple.

The only difference lies in strategy. Google is playing the long game to take Apple down.

Rather than create products that are a dramatic improvement on Apple’s, they make them almost-as-good, or equally good?—?and cheaper.

Take Chromebooks. They aren’t as slick and speedy as Macbooks. But they offer similar usability?—?and you can buy three for the cost of one iPad. Plus, they’re brilliantly marketed.

Or Android. It’s as close a replica to iOS as you can imagine.

Or Pixel. Compared to the iPhone, it has a better camera, faster charging, smoother performance, and a more useful digital assistant, for a lower price.

Google is extending with their growing selection of products, including an Amazon Echo competitor, a smart router, TV, a VR headset, and a list of nest devices. Although these products will work mostly with iOS devices, they will work better with Android phones, and/or the Pixel.

All of these factors make migration look increasingly more promising. Apple has been cutting manufacturing costs while pricing its products ever higher, which means the user experience has plummeted.

Not to mention the scandal that erupted when we learned that Apple deliberately slows older products in a bid to encourage users to upgrade.

All of these factors lay fertile ground for Google to overtake Apple.

In fact, Apple customer loyalty is arguably the only real obstacle in Google’s way. But if enough people get frustrated with Apple’s pricing strategy, it could signal the end of Apple’s reign as we know it.

The drive for innovation

Twenty years ago, the browser wars were raging.

There was stiff competition?—?and that was a good thing because it prevented a monopoly.

With competition comes innovation. In fact, this period of intense rivalry led to the web we have now.

But today? The startup culture is less “what can we build next?” and more “what’s our exit strategy?”

The Big Tech Five continue to swallow up smaller companies. And as their monopoly grows, I’d argue that innovation is dwindling.

Openness and added value are being sacrificed at the altar of revenue and market share. And Google is at the forefront of this. Most recently, Chrome announced their “most controversial initiative yet”: fundamentally rethinking URLs across the web. Without a URL, the only way to access a page is via Google.

Ed Bott compares Google to Godzilla:

… sweeping through the landscape and crushing anything in its path because few startups can compete with a free product from Google.

And he’s right. Google’s convenience and power are overwhelming. But we can’t let that blind us to the reality of what they’re doing.

However you look at it, embrace, extend, extinguish is pivotal to Google’s strategy. Granted, no one in Google is sending explicit instructions as Bill Gates once did, but they don’t need to?—?the end result is the same.

EEE certainly looks different today than it did in 2000; it’s subtler, friendlier, more politically correct.

But it’s just as dangerous. The war isn’t over. We must fight to diversify the internet, uphold open standards, and stamp out monopoly.

Few of the current crop of page builders are as simple as Mozello. You don’t need any previous experience, Mozello takes care of everything for you. Just run through the quick set-up and you’ll have a working website, online, in minutes.

Mozello is a surprisingly easy-to-use platform that offers you the opportunity to create a personal or business site, with no design or code knowledge. But where it really excels is in lowering the entry-level for anyone hoping to create an ecommerce site.

Mozello is also an ideal option for web designers and developers who need to develop a site simple enough for a client to self-manage. Mozello is so simple to use, your client can make any changes they like, without blowing up your phone every 5 minutes.

Ultra-Fast Setup

Creating an account with Mozello couldn’t be easier. Just navigate to the site, enter your email address and a password.

Mozello will ask you for an account name, but don’t worry about getting this right, because you can always change it later. Decide whether you want to create a brochure, a blog, or even an ecommerce store.

Once you’re ready to publish your site you have a simple choice. You can either publish under a free Mozello web address, or use a domain name. Using a domain is probably best for most users, and Mozello allows you to use one you already own, or register a new name.

48 Mobile-Ready Templates

Once you’ve created an account, Mozello presents you with 48 template designs to choose from.

Unlike some page builders, Mozello’s templates have a whole heap of variety, there’s something here for everyone, so you can be sure you’ll find something you love.

Each of the templates is mobile-ready, meaning that your site will work perfectly across all devices.

Mozello’s templates cover 90% of the use cases you’ll ever need, but if you do need to create something out of the ordinary, rest assured that all of Mozello’s templates are easily customizable.

Simple to Customize

Mozello has fewer features than some site builders, but by making the difficult design decisions and baking them into the defaults, Mozello allows you to focus on creating a distinctive brand.

You can change your color scheme with a single click, and choose from professionally curated Google font pairings, without needing any special understanding of design.

It takes about 20 to 25 minutes to get a site up and running on Mozello’s platform—even an ecommerce store—few site builders can boast that kind of speed.

If you’re running the type of business that has a bricks-and-mortar counterpart, then you’ll appreciate the ability to easily add a map, and if you’re running an international business you can even post content in multiple languages, with just a few clicks—perfect if your customers speak dual languages, like English and Spanish.

Easily Edit Content

Editing content is a breeze with Mozello. Just click on the item you want to edit, and it will switch to edit mode. You can switch text and images, and even edit styles inline to adjust the site design.

As well as editing on-page content, Mozello gives you the power to edit the meta data of the page that search engines will use to rank your site. You can easily edit title tags, insert Google Analytics, and integrate your site with social media.

Create an Online Store

There are plenty of site builders available, but very few of them allow you to create a fully functional ecommerce store with no experience. All the features you need to promote your products, from fast payments, to coupon codes, are all included.

Mozello’s store is packed with the type of features you normally only expect from a premium provider, even the free version. Designing a store could not be easier, because it’s all built around your product catalog; simply define your products, adding a name, a description, shipping costs, and the terms of sale.

For stores with more than a few products, you’re going to want to create some categories. And Mozello even has that covered: each product can be assigned a category, so if you’re selling sporting goods, you can group the equipment by sport, by gender, or even by price range. You can even add product variants, allowing you to offer customers different options.

Perhaps best of all, you can customize your catalog layout, as well as the layout of product images. So no matter what you’re selling, you can present it in a way that encourages sales in your sector, helping customers browse, and boosting revenue.

Mozello gathers every order you receive, so you can process them for your new customers. And because this all takes place in the same simple-to-use interface, it’s easy for anyone to run an online store. You can even manage your ecommerce store from your cellphone, making it simple to run your whole online business right out of your pocket—great for anyone working remotely.

If you’re managing a larger store you’ll benefit from the Premium Plus plan which delivers tons of extra functionality, and is easily capable of handling hundreds of products, but for many fledgling stores, the free starter plan is a risk-free route to getting online.

An Excellent Entry-Level Site Builder

Mozello is designed to allow anyone, even those with no design or code knowledge, to create a website easily.

The live site editor is simple to use, but if you do run into a problem, Mozello is backed by a friendly support team that answers email queries promptly.

Mozello doesn’t offer all the bells and whistles of some big-name providers, and that focus on essential tools is exactly what most first-time website builders need.

Free by default, meaning that anyone can build a site with no risk, if you want to up your game then there is a premium plan for just $7 per month and a premium plus plan for $14 per month. If hassle-free web design is what you’re after, give Mozello a look.

[ — This is a sponsored post on behalf of Mozello — ]

Add Realistic Chalk and Sketch Lettering Effects with Sketch’it – only $5!

Source

A common need when writing vanilla JavaScript is to find a selection of elements in the DOM and loop over them. For example, finding instances of a button and attaching a click handler to them.

const buttons = document.querySelectorAll(".js-do-thing");
// There could be any number of these! 
// I need to loop over them and attach a click handler.

There are SO MANY ways to go about it. Let’s go through them.

forEach

forEach is normally for arrays, and interestingly, what comes back from querySelectorAll is not an array but a NodeList. Fortunately, most modern browsers support using forEach on NodeLists anyway.

buttons.forEach((button) => {
  button.addEventListener('click', () => {
    console.log("forEach worked");
  });
});

If you’re worried that forEach might not work on your NodeList, you could spread it into an array first:

[...buttons].forEach((button) => {
  button.addEventListener('click', () => {
    console.log("spread forEach worked");
  });
});

But I’m not actually sure if that helps anything since it seems a bit unlikely there are browsers that support spreads but not forEach on NodeLists. Maybe it gets weird when transpiling gets involved, though I dunno. Either way, spreading is nice in case you want to use anything else array-specific, like .map(), .filter(), or .reduce().

A slightly older method is to jack into the array’s natural forEach with this little hack:

[].forEach.call(buttons, (button) => {
  button.addEventListener('click', () => {
    console.log("array forEach worked");
  });
});

Todd Motto once called out this method pretty hard though, so be advised. He recommended building your own method (updated for ES6):

const forEach = (array, callback, scope) => {
  for (var i = 0; i < array.length; i++) {
    callback.call(scope, i, array[i]); 
  }
};

…which we would use like this:

forEach(buttons, (index, button) => {
  console.log("our own function worked");
});

for .. of

Browser support for for .. of loops looks pretty good and this seems like a super clean syntax to me:

for (const button of buttons) {
  button.addEventListener('click', () => {
    console.log("for .. of worked");
  });
}

Make an array right away

const buttons = Array.prototype.slice.apply(
  document.querySelectorAll(".js-do-thing")
);

Now you can use all the normal array functions.

buttons.forEach((button) => {
  console.log("apply worked");
});

Old for loop

If you need maximum possible browser support, there is no shame in an ancient classic for loop:

for (let i = 0; i < buttons.length; ++i) {
  buttons[i].addEventListener('click', () => {
    console.log("for loop worked");
  });
}

Libraries

If you’re using jQuery, you don’t even have to bother….

$(".buttons").on("click", () => {
  console.log("jQuery works");
});

If you’re using a React/JSX setup, you don’t need think about this kind of binding at all.

Lodash has a _.forEach as well, which presumably helps with older browsers.

_.forEach(buttons, (button, key) => {
  console.log("lodash worked");
});

Poll

Twitter peeps:

const els = document.querySelectorAll(“.foo”);

// which loop do you use? one of these? other?

— Chris Coyier (@chriscoyier) November 7, 2018

Also here’s a Pen with all these options in it.

The post A Bunch of Options for Looping Over querySelectorAll NodeLists appeared first on CSS-Tricks.