Technical: how to build an app like Front App?
Technical: how to build an app like Front App?
Front app (frontapp.com) is a web-based email client that makes it easy to manage shared inboxes like support@company.com.
I'm curious how the mailing server side of such an app work. Do they use an existing mail server (Gmail?)? How would I go about building a similar basic version of this app?
Having been part of a startup which was working in the same space, here are some of the tools/approaches we used.
a. Providing search, each customer can have 100's of thousands of e-mails and the same e-mail can be part of inboxes of more than one customer
b. Collaboration on top of emails
c. Realtime notifications for comments and likes atop emails
d. Perceived realtime sync b/w email server and the application.
It's a great engineering problem to be solved, however, there is a lot of eventual consistency involved in systems like these. They aren't as smooth as their youtube videos most of the time :).
Wow thanks for the great explanation.
So if I'm focusing only on customers who have Gmail, how would my app (or Front) onboard them? I.e. what configurations do I need the customer to do (e.g. any changes to the DNS records)?
Also, would my app use Oauth2 to access the customer's inboxes or would I ask the customer to set up a Google service account to avoid having their users refresh their consent every time the refresh token expires?
Your SAAS app will be doing an OAuth based authentication with Gmail. Ideally, the customer doesn't need to do anything special other than login via OAuth which should give your app access to Gmail data via api's.
Think of inbox data as a db, all your app needs is access to that db. I don't see a use-case where dns records would be needed to be touched.
If I recall correctly Gmail also supports accessing their SMTP server using access token instead of username/password. Things might have changed but it's worth looking into it.
Yes, you need some kind of periodic/cron job to keep refreshing the access and refresh token. And yes, the customer needs to re-authorize the app if the token expires or new scopes are added. Ideally, access token should be refreshed before refresh token expires to keep the UX smooth.
Brilliant, thank you!
Keep in mind that if you intend to integrate with gmail's API, you need to be prepared to shell out $15k to $75k for security assessment. See https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems
Ouch, brutal. How to go about ensuring I pass the assessment? Is it even realistic for a one-person startup to pass it? Be interesting if anyone who has gone through it could share.
I'm going to go through it in the next few months, so I haven't done it yet but I've talked with the security firms in question. It's definitely doable for a one-person startup to pass, as long as you've worked as a developer before and this isn't the first thing you've ever built.
They're mostly just looking for things like that you haven't hardcoded passwords in your source code, you aren't vulnerable to XSS or SQL injections, etc. As long as your hosted on Elastic Beanstalk or Heroku you should be able to meet the infrastructure requirements without an additional devops person.
The tricky thing is that you need to go through it once per year, and because people have an insanely high bar for adopting email-related products, realistically this means that you need to be prepared to go through it 2 or 3 times before you start making money. You might get lucky and get traction faster than that, but I think it would be a pretty big gamble to just assume that you will. Because you're a startup you'll be at the low end of the cost spectrum, but I would still allocate 20k per year to this.
Also for new apps they aren't going to let you launch until you pass the security assessment, which means that after you finish building your MVP it will likely be a few months before you can actually launch. The actual assessment will only take a couple weeks, but then there will likely be several weeks of back-and-forth with both google and security firms before and after the assessment.
There is a decent description of what they're looking for here: https://support.google.com/cloud/answer/9110914?hl=en
Note that you will also have to apply for OAuth verification, where they will confirm that you are compliant with the Gmail API TOS and the extra rules for sensitive scopes. The big danger you want to avoid is spending a couple years building something and then finding out that you weren't allowed to build it in the first place.
Second @kailash’s comments. There is a lot of duck tape behind the scenes and code to handle edge cases especially with emails.
Interesting, can you give an example of an edge case? I am just starting with getting to know email payload structures (built a simple app that pulls my Gmail messages and shows them in HTML)
This comment was deleted 8 years ago
Sendgrid also has a inbound parse api that will send you a payload to your API of choice https://sendgrid.com/docs/for-developers/parsing-email/setting-up-the-inbound-parse-webhook/ if you'd rather not figure out how to build/parse handle smtp/pop3 and emails.
That's awesome, I'll have a look at it.
This comment was deleted 7 years ago