How To Build An App Like Twitter: Part 1

Twitter is a hot topic these days, due to its recent acquisition. Whatever your thoughts on the current owner are, you probably think it would be really cool to create the next big social media app. Today, you'll learn how to design such a system.

The Goal

What does it mean to "build an app like Twitter"? Let's list the components that make up a system like that:

• An API that serves real-time updates
• An app that runs on both Android and iOS
• A website, too

There's way more involved if you want to make something truly production-ready, but the above is a good starting point for mobile apps powered by an API.

To actually build this, you'd need a team of engineers. The purpose of this article is to teach the basics of system design. Hopefully, it opens your eyes to how powerful software can become, as well as how to plan a complex project.

How To Design The System

Modern software has lots of moving parts. For example, your backend and mobile app are 2 completely separate programs, and they have to send messages to each other over the Internet to communicate. It's prudent to plan how various components will interact before starting to code.

For a social media app, I would plan:

• A RESTful API (or GraphQL/gRPC if you want). An API, or application programming interface, allows clients to interact with the server. For example, Twitter's API allows the mobile app to make a Tweet from text and photos you upload.
• Use WebSockets to deliver real-time updates to clients. For example, your API could have an endpoint that creates a WebSocket, and sends data every time a new Tweet is posted. Use async programming (i.e. Observables), to manage event pushing within your application.
• Share as much code as possible between the Android and iOS apps. You can either write both apps in using the same stack (Flutter, Xamarin, etc.), or share native C/C++ libraries between your apps.
• Within the app, cache specific responses from your API, so that your app can support some amount of offline use. For example, you can store the most recent timeline updates in a cache, so that if the user disconnects from the Internet, they can still view content that's already been downloaded.

What Programming Language To Use

It doesn't really matter what language you use on the backend. Facebook ran on PHP for years, and Twitter ran on Ruby. If you don't know where to start, then TypeScript is a good choice for the backend, or Java.

As for the mobile app, the language you use is determined by the platforms you want to target. I recommend to use the Dart language, because Flutter lets you write apps for both iOS and Android. Otherwise, you'd have to use Objective-C or Swift to create an iOS app, and then Java or Kotlin to create an entire separate Android app.

And for the website? Use TypeScript with either React or Angular. If you're using Dart and Flutter, you might also consider using AngularDart, which is a port of Angular to Dart. If you use either TypeScript or Dart, you can share some code from the server with the client, eg. API type definitions.

High-Level Steps To Implement

It's up to you what to build first; however, I recommend following the "test-driven design" strategy. In test-driven development, you write your test code first, and then write code to implement your application interface. This way, it's easier to be sure your code is correct.

Opinions vary greatly on what the best way to manage a software project is. Your best bet is to try a few different strategies out, until you figure out what suits your working style best.

After planning the app's features and writing a design doc, I would immediately start working on building the API:

1. Write the interfaces and unit tests first. This is essentially a "specification" of how your API should behave.
2. Write code for the server, until all the unit tests pass. This is TDD, simplified.

Before moving on to the mobile app, I would then create some infrastructure to make it easier to write and test client-side code. Write a i in Dart, also TDD. This library should be an abstraction over calling your HTTP API. This way, the code within your app's individual pages doesn't have to concern itself with low-level HTTP details.

Finally, I'd start working on the app. I recommend Flutter, because it targets Android and iOS, but if you only intend to target one platform, then pick the appropriate tooling here.

1. Build the app, with each component connecting to single resource in the API
2. Do the same for the website, using React instead of Flutter

What's Next?

If you liked this article and want me to write a "Part 2," click this button to vote:

I want part 2

See you next week,

Tobe Osakwe