The Newsletter Service: The Requirements





The Newsletter Service: The Requirements

As mentioned in the previous article, I will outline the feature requirements and tech to build them.

I have started so many projects that I never finished and the main reason was the scope was too huge, I had so many features on the backlog and most of it was on the backend stuff so some I never reached a phase where I saw things coming together. So in this saas, I decided to limit the scope to launch an MVP as fast as possible.

So what are the requirements:

  • A user should be able to get a custom email address on signup based on their username, which can be Twitter or GitHub or their choice.
  • A user should be able to get all newsletters received in a week's range.
  • A user is able to mark an issue as read or programmatically handle that on the client based on scroll events.
  • A user is able to mark newsletter email as spam which would be saved to avoid future issues received.
  • A user should be able to highlight sections of a newsletter and save them [not on MVP]

So what about the tech, how am I going to achieve building out this saas app:

  • Haraka: is an SMTP server open-source project that enables receiving, sending, and managing emails.
  • Paddle: to handle monthly/yearly subscription payments from users. Stripe is not available in my country.
  • Graphql: Been using it for a while now and love using it over (used to hate it way back, but I find the developer experience, also the community has matured over the years, with tools such GraphCDN that enable developers to take advantage of Fastly's CDN for fast responses. It's not replacing REST at all but it's a handy tool to actually play around with.
  • NodeJS/Express: For the backend, I work with Golang, and Node sometimes Python on a day to day but picked Node, just a preference you can use any language or framework "it's just a tool".
  • Next/React: I have my reasons on why I prefer Next,
    • Its performant,
    • You can achieve a thin client unlike SPA's
    • SEO is much better
    • Fast build times, making the developer experience amazing
    • I can build custom APIs within it and take advantage of Vercel's edge computing.
  • S3 Bucket: Those emails need to be stored somewhere and the database isn't one of them, never save HTML stuff on the database for read-performance reasons.
  • Postgresql/Prisma: Well all that data from users needs to be saved somewhere and Postgres is the right database for this job because most of the data will be related and Postgresql handles that perfectly, trust me I tried MongoDB it does not work great with relationships[its a whole mess to achieve that might do an article in the future], I think it only has one-to-one.

And that's it for the requirements side of things, next will be a log of what I have done so far and probably the launch date.