Not too long ago we started moving our team and product architecture from Full Stack PHP to a service-oriented, 12-factored, concern-separated model here at ReFUEL4. Of course there are pros and cons to this kind of team and product organization, but to us the pros have been far greater than the cons.
The basic idea
As a whole product team, this leads to large gains in efficiency. Now all of a sudden our mobile app becomes much more easily accomplished. The same goes for an admin panel and for many other views into the same data.
For hiring managers, this makes finding great people easier. You no longer have to find full-stack pros. You now only have to find people who are either great at frontend or backend, not both.
Small steps first
While for an organization, splitting concerns is clearly optimal, for an engineering team that is used to operating in a full-stack fashion, it’s always good to start with small steps first.
One of the easiest ways to get used to operating in this separated fashion is to start with splitting email services off your full stack architecture by implementing a frontend / backend hand off process. Similar processes can later be used to transition other architectural pieces until the whole architecture is service oriented.
Email is a great place to start because:
-
Email is copywriting and design heavy, so it's a great place to bring more designers, marketing and frontend people into the fray.
-
Now when marketing wants some email copy changed, they don’t have to ask a developer. They likely already use MailChimp for the newsletter, so they can just login and change the email template.
-
Sending email the old way from your own server is complicated and doesn’t play well with modern spam filters. Using a dedicated email service provider (ESP) will result in better deliverability.
-
ESPs offer open and click tracking.
-
Most ESPs allow you to see and audit every email sent. This means that if a customer says they didn’t get your email, you can actually go find out if it was sent and look at the final rendered email they got sent with just a few clicks.
Here’s what we’re going to do:
So in order separate concerns for email, we’ll start by designing an email template in MailChimp, creating some dummy data and testing with Postman, and sending the actual email with Mandrill (our ESP). Finally we’ll hand off to our backend team, who can implement the Mandrill send with whatever technology they choose.
