How I built a product that failed and won

It was almost a year ago that I started building a self-destructing tweets app, just like Snapchat’s snaps…

… and nobody used it.

The not-so-short intro

In 2017 I set out to create a self-destructing tweets application. Nothing impressive but it helped me learn a lot of things.

First, I set out to design it all by myself — failed miserably. At that point I reluctantly decided that the best thing to do is to use a ready-made theme.

I was reluctant to do that, at first, because at that time I was also acting CTO of a startup and we have decided to use an off-the-shelf admin theme with off-the-shelf UI, and everything was off-the-self not working.

So, although the UI theme we had used for the startup already had a React version, it was far from perfect. Actually, it was far from working.

It felt like the React version was added just to boost sales, and had no style guide, no tests, nothing you could hold on to if you needed to learn more about that specific React code.

Back to my failed project, I decided I would pick a theme that’s in static HTML and convert it to whatever I needed. But it took me two whole weeks of researching on Dribbble and Behance then paying for an Adobe CC membership and then end up replicating with almost 100% accuracy a design I found on Dribbble, to realize I won’t be able to design anything properly for my app.

Not nice at all, if I account for the wasted time, but I learned a thing or two about design and found some neat fonts along the way.

I kept my technical mistakes to a minimum, since I more or less applied the principles I already knew about application design, deployment and technology choices.

Basically, I tried to create a solution that would leave room for more flexibility in the future. Just like Uncle Bob Martin taught us!

Along the way, I learned how to interact with the Twitter API, how to use AWS Lambda, solidified my knowledge of AWS ECS deployments, and a lot more things I will detail below.

The project is called Ephemeral.ly and it is still online if you want to check it out. I’d also love some feedback to know if I should continue to pay for the domain name.

The “architecture”

Many people banter over this on the Internet, but I built the application as a monolith.

Should you build a monolith and then migrate to microservices? Should you start with microservices directly? This is on everybody’s minds nowadays.

But why limit yourself? Why migrate to microservices at all?

Maybe microservices are not such a good idea for you. Maybe your monolith works just as well. I tried to buid the application as a modular monolith. This means that I created decoupled modules that I could bring together in any way I saw fit.

I extracted the core logic that interacts with the Twitter API and with the database in a separate module, then created separate modules for the website and for the AWS Lambda functions.

My final application structure is outlined in the screenshot below:

My application modules in GitHub

The Twitter API

This was my first encounter with the Twitter API. I never integrated anything with Twitter, at least not at the level required to interact directly with its API. I’ve used integration libraries before, but they only required an API token and would perform their magic.

I learned to retrieve posts, delete posts, use the search functionality to filter for tweets with specific contents and hashtags.

I initially dumped the logic into a single Express.js application, which I later modularised. I took the API logic along with the database interaction logic and moved it to a module called ephemeral.ly-core.

The web app

This was the easy part. Creating an Express.js app is pretty trivial for any Node.js developer with a bit of experience. There are a lot of modules you can use to put a decent app together and the documentation and learning resources are more than plenty.

Once I set out to modularize everything, I created a separate repository called ephemeral.ly-webapp that hosted only the webapp and nothing more. It would install its dependencies via yarn — I chose yarn because it has a better management of git+https:// URLs and it doesn’t choke when it needs to install a node module from a git provider like GitHub, BitBucket or GitLab.

MongoDB

This is a pretty common choice for small web projects so there’s nothing very interesting I’m going to say about MongoDB, except for the fact that I learned to work around Mongoose’s memory-munching objects.

I added .lean to most of my Mongoose queries, to prevent it from creating its big custom objects and eat up my EC2 instance’s RAM.

AWS Lambda

This was by far the most interesting problem to solve.

To mimic Snapchat’s ephemeral nature, I needed some sort of background job that would look up and delete tweets that reached their expiry date. At first I thought about using cron jobs. The problem is that I needed at least an EC2 machine, then configure the cron schedule, and that didn’t look appealing at all. Especially because if I needed to debug a malfunction with the cron jobs, I had to SSH into a Linux box, and debug inside the command line.

I thought that Amazon must have something that provides a similar functionality and sure it does. It’s called AWS Lambda and in combination with AWS Cloudwatch you can mimic a cron job 100%. The advantage is that the infrastructure is fully managed by AWS.

You don’t have to concern yourself with OS updates, package updates, etc.

All you have to do is to configure your stuff correctly and make sure your code works properly.

Deployment to ECS

The second most interesting thing was deploying the application on AWS Elastic Container Service — ECS.

ECS takes your Docker containers and runs them on EC2 machines. The setup is not difficult but you have to go through a bit of trial and error to properly configure your target groups, services, load balancer rules and attach your EC2 machines properly. Took me a couple of hours to get it right, even though I’ve performed it a couple of times before.

The main advantage of running the app on ECS is that you make use of all the resources on your EC2 machines since it stuffs every EC2 machine with your app containers.

Lessons learned

I built a failing product, from the start. Nobody besides me and an ex-coworker, who was polite enough to create an account and test it, used the app — Big thanks, Tudor, you’re an original gangsta’! .

Here’s what I learned, while building Ephemeral.ly.

AWS Lambda is an amazing service. FaaS is an amazingly useful and flexible solution for any kind of software project. Why keep resources locked and running when they have nothing to do?
Cron jobs that run on infrastructure that requires 0 maintenance from my end feels good.
Monoliths are not inherently bad. As long as you’re thoughtful when you “design” them, you may even get a boost in development speed if you go on the monolith path. Just be careful to build flexibility in, from the start.
Node modules installed from Git can be used in production, too. Not recommended but comes in handy if you don’t feel like publishing something “private” to npm.
Vue.js is actually a useful library. I used Vue for the tweets list since it was so handy and required little setup. Wanted to do it with React.js but this was a good opportunity to experiment with another library.

Bonus #1 — I got some amazing ideas for a course on technology migration / refactoring.

Bonus #2 — Many of the concepts I learned, I used to build the startup I was working on, at the time.

Bottom line

Unless you waste other people’s money, building a product you know it will fail, and insisting on it even if the failure is obvious, go ahead and knock it out of the park. You should build a lot of things, because that’s the only way you put whatever you learned from books and tutorials into practice.

Learning is a form of procrastination, if it is not followed by practical actions.

You will get to improve your technical knowledge, your software design choices as well as your decision-making. It certainly gave me a lot of information about the way I make technology choices, and it enabled me to look at myself from the perspective of my collaborators.