How to Design any App

Any App?

It is a bold title, but the method we introduce here is effective for most apps, can be applied even without using the Codomat, and you can use it with just a basic understanding of two concepts: frontend and backend.

Frontend

Frontend is the visible part of the app, it is the site you interact with or the app you install on your phone. Designing this part is straightforward because it is inherently visual. You basically design how your app looks visually and you are set. This part is solved

backend

The backend is the back office of your app. This is where your business rules are: what the user sees when they open your app, who can see what, etc. This part can get complicated, this is where the method simplifies the process.

The Method

Here is a simple method to think about your app, regardless of your technology choice. To design your app, you only need to answer three questions:

1. Which data you need to store?
2. How the data should be created?
3. How the data should be accessed?

This method works with a broad range of apps, but for brevity, let’s take the classical example: a TODO list. We want users to be able to login, create TODO tasks and check them when complete. Now let’s answer our three questions:

1. What data do we need to store?

We will obviously store user data and tasks for each user. Thinking about data without structure can get messy and overwhelming. It helps to think in terms of entities. This way we can say we have the user entity and the task entity. The user entity might have attributes like username and password hash. The task entity might have attributes like task description, whether it is done or not, and which user created the task.

2. How should this data be created?

Now that we defined the data to store, how should this data be created? A user entity is created with regular sign up, no special rules here. What about task entities? Remember that each task entity has to store which user created it. So this attribute should be set to the currently logged in user. This is the only rule we need to ensure the data is created in a sane way.

3. How should the data be accessed?

The final question is how the data should be accessed. In a multi user app, we want users to be able to access only their own data. Again the case is clear for user entities: a logged in user will access only their own user entity. As to task entities, we don’t want a user to read or update the tasks of other users. So the rule here is that a logged in user can access task entities if and only if they are the one who created the entity.

That is all. Once you answer these three questions, building your API becomes straightforward no matter what technology choices you make. If you opt for using the Codomat, building your API becomes as easy as writing one file.