Here at SparkPost we have a “single-page JavaScript app” that consists of about 50,000 lines of early 2015-era Angular 1.x code spread across more than 400 files. It’s not a small app. And as you’d expect with almost any language or framework over a period of 2 years, we’ve gotten pretty familiar with Angular’s good, bad and ugly sides. Angular 2, having been released as “Final” in September of last year, would seem like a pretty natural fit for us. But the title of this post has already given it away: we’re most likely not upgrading to Angular 2.

Why not Angular 2? Mostly because of a migration path that makes a strong case for considering almost anything else and maybe somewhat because of TypeScript, but if I’m being honest it’s mostly because it’s nice to try new things. We’re not an agency with a new greenfield project kicking off every few weeks or months where we can test out the latest pre-alpha releases of our favorite cleverly-named JavaScript libraries. Fifty thousand lines of code changes slowly. But that’s when the “tools app” showed up.

A rare greenfield project

Our team was asked to build a set of email tools that wouldn’t live inside of our existing app. These “hardcore email tools” help developers with deep cut email setup—the kind of stuff we already take care of for SparkPost customers —so we wanted them to have their own space out from behind our login. Suddenly, we had a place to explore something new [cue harp music].

We came up with some important criteria for what we’d use to build this new app:

  • It needed to be easy to learn
  • It needed to be fast to build
  • It needed to be something we could build in the open
  • It needed to not be Angular
  • It needed to probably just be React

After considering these criteria carefully and thoughtfully as a team, we came to a surprising decision to give React a try. At the time, I was the leading React expert on our team by way of having completed one Udemy course on the subject, so I began to throw something together.

Some things we accidentally did right

We already had a small part of the app designed and built. It’s hard to underestimate the value of a designed, styled, and approved working prototype of even just a small part of your app. The time that could have been spent arguing over button placement and wording was replaced with figuring out how to get a React app off the ground.

Speaking of which, we used Create React App. Think “html5boilerplate for React apps,” or maybe “Ember for React apps.” CRA gives you a working React starting point complete with all the dependencies (literally, it might download all of the dependencies) and with a working baseline Webpack configuration. Again, this let us focus on what we were actually building. And when you’re ready, CRA lets you “eject” and take control of the whole setup. It’s fantastic and you should use it.

You should also find a designer who can do both. And by both I mean design and understand React. I know this is a very unfair thing to suggest because it really seems to be incredibly hard to find, but we found one of these magical unicorns and they’ve been invaluable. (I even looked up “invaluable” just now to confirm that it does mean really freaking valuable.) If you can, make it a priority to hire this kind of person for your team. (And thanks for being awesome, Jon.)

We also made a decision early on to build the app using only setState / local state, i.e. no Flux, no Redux, etc. We eventually added Redux—another topic for another time—but starting with a simple React app made it much easier to onboard new developers who were getting up to speed with a lot of things at once. Not to mention, waiting on Flux also lets you decide if you really need it at all.

A few other things I’d recommend based on our first-timer experience:

  • Use Jest for your testing. Jest comes with Create React App and despite being 100% Mocha/Chai across all of our other projects, it was too hard for us to deny how great Jest is. Notably, the amazing Jest CLI and Snapshot testing have both been especially useful additions for us.
  • Use the dev tools. There are ones for React (Chrome, Firefox) and ones specifically for Redux if you use it. They’re free, they work great, and they’re incredibly useful.
  • Find a group of people you trust, ask them for advice, and do what they say. I’m fortunate to have friends in our local meetup group (CharmCityJs) and in the NYC JavaScript community (BoroJS), both with active Slack teams. Being able to ask “what do people use for x?” has been a huge help because really, you just need to pick something. Trusting someone else is as good a reason as any.

Fifty thousand lines of code changes slowly

So what about that 50,000-line Angular app? We won’t be migrating it to React, at least not directly, and it can’t really survive as an Angular 1.x app forever, either. But here’s an interesting thing I noticed as I was getting familiar with React: in some ways, it’s not that much different than Angular. Here’s an Angular 1.5+ component:

If you pretend the template string is some JSX and it gets returned from that controller’s render method, you basically have a React component (at least structurally). So instead of trying to haul 400 files’ worth of old-school, big-controller Angular code into a new framework, our plan is to focus on the patterns. Specifically, the patterns of “small, focused components” and “unidirectional data-flow”. I’ll talk more about that second part in a later post about our adventures with Redux, but refactoring our giant controllers into small Angular components has two big advantages:

  1. React isn’t forever. Any large-app rewrite/refactor is going to take a while, and if you haven’t noticed, the JavaScript ecosystem moves pretty quickly. By focusing on refactoring our existing app to use better patterns, we get it prepared to migrate to whatever happens to be the best solution at the time, when we’re finally in better shape to make that move.
  2. Iterative, incremental development is dangerous. One of my favorite images of how “agile development” should work is a drawing by Henrik Kniberg from a Spotify presentation, explaining how to be iterative in a productive way. You’ve probably seen it before:
react agile illustration

If we spend 6 to 9 months or more trying to rewrite the app in React and don’t succeed, run out of time, or have the work shelved for other priorities, we end up with nothing useful at all. But with the refactor-first plan, the worst thing we end up with is a better, more maintainable Angular app. In other words, it’s an easy decision.

Angular, React, Kumbaya

No lie, we had a lot of fun building our new tools app in React/Redux. It’s a great library with a fantastic ecosystem and a lot of good patterns. But to be honest, our Angular app already works, and that’s fine. If you’re maintaining a big legacy app, remember:

  • Find small greenfield projects where you can build something with new tools.
  • Focus on patterns, and figure out how you can incorporate those patterns into your legacy app without having to rewrite the whole thing.

As I mentioned before, we built this in the open, so feel free to check out the code as well as the live app itself. If you’re coming from an Angular app, I’ve written up a bunch of notes about learning React that may be helpful for you, too. If this post was interesting to you for any reason at all, check back often as we continue to write more about our adventures with Angular, React, and front-end development. If you have any questions or if there’s anything else specific you’d like to hear about, let us know!

–Jason Rhodes

At SparkPost, we love email. The way you feel about those pictures of your cat you posted on Instagram? That’s how we feel about email. But we know not everyone shares our excitement about email RFCs. Which is why we work to share our knowledge of email standards and make sure that setting up and sending email is as easy as possible for as many people as possible. Except for you, Mr. Western Union scammer.

Email has grown a lot over the past 40+ years and along the way several standards have cropped up, meant to combat spam, phishing, and spoofing. Keeping up with these standards and implementing them correctly can be tough. On the flip side, setting them up the wrong way can really hurt your business. Set up incorrectly, your email won’t get delivered or, more dangerously for your customers, will let any malicious sender impersonate you online, even to the point of letting someone change your content while it’s in flight.

That’s why today we’re happy to announce the release of three new tools for building and verifying the state of your email. I’ll walk you through each of them quickly and how they can help you win the trust of ISPs and your users.

DKIM Validator

DKIM is a content authentication standard meant to let ISPs (Internet Service Providers, the ones who manage the inboxes you send to) verify that the email you sent is the one they received and that no content has changed since it left your system. DKIM requires you to set up a special DNS record with a public key and other metadata that receivers use to verify the content of the message they receive.

Our DKIM Validator lets you safely verify that your DKIM is set up correctly. It will give you a unique email address; send to that address from your domain (through the system you’re validating) and we will check your DNS entry and make sure the email we received complies with the DKIM policy you set up. We’ll even give you recommendations if we find something that could help you out.

Find something surprising in the results and want to share them? We got ya covered: all results are deep-linkable for easy sharing (click the “Share” button, and we’ll even put the URL in your clipboard).

Not sure about any of this DKIM stuff? Sign up for a SparkPost account and we’ll take care the hard parts for you.

SPF Builder

SPF is a standard used by ISPs to verify that an email addressed “from” your domain is coming from a server that you’ve specifically said is allowed to send for your domain. Setting up a correct SPF DNS record is one of the best ways to combat spoofing attacks and keep your email reputation high.

The thing is, SPF is deceptively complicated. There are only a handful of simple mechanisms in the SPF standard, but when they’re combined into your domain’s record, it soon becomes a complicated tree of hosts, any of which can send for your organization. It’s quite easy to be too broad and leave yourself open to spoofing attacks, or be too narrow and have your email appear to be illegitimate.

That’s why we made the SPF Builder – it will walk you through a series of simple questions to build out your SPF record. You don’t need to know any special syntax, we’ll translate everything for you and even copy it to your clipboard for easy pasting into your favorite DNS provider!

SPF Inspector

Whether your SPF record came from our builder or is artisanally hand-crafted, it’s good to check the validity of your record once it’s live. Our new SPF Inspector will not only verify your record’s syntax (and the syntax of any others you’ve included), it will also show you all IPs and hosts that are allowed to send on your behalf. If we find anything wrong, or slightly not great, we’ll give you a heads up along with some pointers on how to fix what’s not quite right.

All your results are shareable, just like the DKIM Validator. In addition, if you are signed in to your SparkPost account, we’ll keep a history of the domains you inspect over time. That becomes really useful as you start to manage and send from several domains.

Find SPF too confusing? Send through SparkPost and we’ll handle all the messy SPF details for you!

Go Check ‘em Out

We’re really proud of these SparkPost email tools and we think they will make your life easier and your email better. Do you have ideas for other tools that would help you send better email? Let us know on Twitter, Slack, or in the comments!

— Cole Furfaro-Strode

Here’s the full press release on the SparkPost email tools

Email Tools in an API World Laptop w Gears

Modern Email Tools Available To You

Email has a long heritage of standards and specifications, many of them are truly great and some are even followed. Implementing these standards requires considerable knowledge. Tools ease our work by encompassing that knowledge, packaging it up and making it available to all. One strong measure of a tool’s worth is its effectiveness at embodying knowledge and reducing cognitive load on the wielder.

The world of email tools is almost as rich as its body of standards. We have myriad services, applications, libraries and commands for configuring, testing, orchestrating and tracking our various messaging activities. The email industry is hugely advanced in the orchestration, delivery and tracking spaces, since those are where the broadest commercial interest lies. Unfortunately, tooling for email service configuration and testing is less advanced, possibly since those tools would merely improve engineers’ lives.

Suffice to say, there is still considerable knowledge required to configure, verify and troubleshoot one’s email estate.

Let’s look at a typical setup task that most email senders have grappled with: configuring DKIM signing for an email sending domain. DKIM allows you to take responsibility for the messages you send by associating your sending domain with your mail. Don’t worry too much if you don’t 100% follow all these steps. The intent is to show level of effort.

DKIM Setup: The Old School Way

Here are some outline steps we might follow to start signing our email.

  1. Generate an RSA key pair:

2. Extract just the public key:

3. Form our DKIM DNS record from public key:

4. Have our DNS provider publish the DKIM record under

5. Configure our email service to sign using your private key.

With that done, these ancillary points are left as an exercise for the reader:

DKIM Setup: The SparkPost Way

Ok, let’s try that again, this time using the SparkPost API.

  1. Ask SparkPost to create our sending domain and a matching DKIM key pair
    (we can also do this in the app):

2. Form our DKIM DNS record using API result
(Hint: SparkPost will show us the fully-formed record here):

3. Have our DNS provider publish the DKIM record

4. Verify our setup by clicking the DKIM record test button for your sending domain in SparkPost

Side note: Here are all the tasty the details on using SparkPost to manage and verify sending domains and also using the SparkPost API sending domains endpoint itself.

Much Better…

Now we’re a tiny bit biased but we do love our email API and it certainly reduces the user’s cognitive load here. Questions we no longer need to worry about:

  • What size should the RSA key be?
  • What even is an RSA key pair?
  • How do we invoke the openSSL toolkit correctly?
  • How do we handle our private key material safely?
  • How do we format our DKIM DNS record?

That single API call executes sending domain configuration, creates our DKIM keys and formats our DNS record all at once. There’s less to do, less to understand and fewer places to stub our toes along the way.

…But Not Perfect (Yet)

…and yet there are further submerged rocks to run aground on here. The DNS record could be fat fingered during publication, the DNS provider may truncate the record and what do you do if there’s an existing DKIM DNS record for your domain? How do we diagnose each of these and how do we verify the end-to-end DKIM signing and verification process?

These are all issues and questions we’ve seen in production use. Clearly, there’s more we could do, as a tool-loving developer community, to help each other be more reliably successful, faster and just plain happier in our work. Just as SparkPost has an email API, DNS services have record management APIs. Combine these with the modern web and we could build far better experiences for each other. For starters, how about:

  • A DKIM verification tool explicitly designed for diagnostic and remedial use (stay tuned for next week’s post!)
  • A modern validating SPF record editor
  • Open DMARC as a service

Against a background of modern API-driven workflows, email tooling looks a generation or so out of date. In the SaaS email infrastructure community, we can do better. Isn’t it about time for a new generation of messaging tools?

If you liked, hated, agreed, disagreed or just want to chat about email infrastructure, tooling, APIs or anything else, come join our burgeoning Slack Community. We’d love to hear from you.