App idea

You have an app idea. You approach a software developer to figure out how to get it built. You get bombarded with jargon you’re not familiar with and asked for things you’re not sure exist. You walk away confused, eventually drop the idea and move on with life.

Sound familiar? Let’s clear it out and make this process more fruitful for you.

Building blocks of any tech product

You can broadly split a product into two parts:

Frontend — the looks

This is what a user sees and interacts with, and can take many forms — typically a website, an Android and/or iOS app. These can all exist simultaneously for a product. When building the frontend, the key concept is to keep your UI (user interface) as simple and intuitive to use as possible. The user doesn’t need to or want to know the inner workings of your product. From the tech perspective, the frontend is kept as “dumb” as possible. The “thinking” is handled by the...

Backend — the brains

Where the magic happens. All your core business logic, processing and data comes from here. Your backend does all the heavy lifting for your product so that your frontend, which runs on hardware with restraints like low processing power and limited battery life, doesn’t have to. This backend typically runs on computers that companies like Google and Amazon provide on rent, aka the cloud. It connects with your databases, runs all the searches, figures out what discounts apply to what, and then packages the data in a way that’s easy to use for your frontend.

There’s another important bit that links these two together:

APIs — the glue

API stands for Application Programming Interface, but what it is, is basically a contract between your frontend and backend on how they’re going to communicate. Since frontends and backends can be built in so many ways, this provides a common language for the two to communicate. It provides a way to ask for your frontend to ask for things from your backend.

So how does all this come together for a real idea? Let’s see how we can build the DailyDog, a place for sharing all the good doggo pictures.

- - -

Say we want to build an Android app and website for the user to see the pictures with. The product should let users upload pictures of their dogs, and search for pictures of their favourite breed of dog. The architecture for this product would look like:

Overview of the DailyDog. Credits - Sharang Khandelwal

Let’s see how a typical user flow on the app would go:

The user wants to upload a picture of their dog. They browse through their gallery, find the right picture, and hit “upload” on the app. What happens under the hood is that the app calls the upload dog picture API of the backend, which has been defined like so:

Given a picture of a dog, the backend will store the picture so that it can be used and seen at other places within the product.

And just like that, the picture has been saved along with the rest of the pictures in the dog pictures database. This can now be shown in different places within the app, like on other user’s feeds.

Now the user wants to look for pictures of golden retrievers. The user punches in “golden retrievers” in the search bar and hits “go”. The app takes this request from the user and calls the search API of the backend. The search API goes like this:

Given a dog breed, the backend will look through all the dog pictures it has to find pictures of that breed, and pass back that collection to the frontend.

The backend goes through the database of dog pictures that it’s been storing up this whole time, finds the right pictures, and sends them back to the app to display.

Because we’ve chosen to split the responsibilities of the product between the frontend and backend rather than keeping everything on the app, we get a few really good benefits:

  • We don’t need to keep a copy of all the dog pictures on our phones, which saves us a lot of space.
  • We can reuse the APIs we’ve created for uploading and searching images when we’re creating the website. The backend doesn’t really care about whether an app or a website is asking for the pictures, as long as it follows the API contract.
  • We only need to write the logic of how to search in one place: the backend. Since our frontend is “dumb” and the backend is doing all the work, this reduces the work needed to create, say, an iOS app in the future.
  • We can update the content coming from the backend without the frontend ever needing to update. It would be annoying to have to update the app every time you wanted to get the latest dog pictures!

This is the essence of a client-server architecture, which is what most modern tech products are built around. You would likely want to adopt this pattern if you’re thinking of building anything non-trivial.

- - -

We hope this has been useful for you. Don’t be shy to say hi if you have an idea that you need help building!

Originally published on Medium.

go  top