In this chapter, let’s discuss some basic strategies we applied to the backend, and I will explain how we deal with the interaction between Cook app and Customer app. In the end, you will find a video demo showing the basic flow of these two apps at Version 2.
When implementing the backend business logic, there are lots of complex long tasks. For example, after user create his account for the first time, you may want to save this activity to the database for future tracking, and also send a registration confirmation email to the user. If we put all the logic in one endpoint request, it will take a long time to process while the client side cannot do anything but waiting.
One of the smartest ways to decouple the functionalities is to respond user immediately after the account is created. For the activities saving and email tasks, we send to the Asynchronous task scheduler. For Django, Celery is a popular one and we deployed it to the AWS SQS.
There are many other cases the asynchronous scheduler can play an important role, like in asynchronous thread handling and dealing with concurrent matching problems.
When implementing the Rest API, it’s better to have the API used for iOS and for the Website Frontend be the same API, which means to implement one API system on the backend to adopt both client sides.
However, in practical, there are some differences between the Web and iOS. Therefore, it’s better to put some tags in the URL endpoint or in the Post to have them judged in the backend.
Similarly, adding version tag in the header of HTTP request and performing the correlative business logic in the backend is a popular way to handle different versions of the API.
If you don’t do any location limitations, after the app is published on App Store, your app would become accessible to worldwide users. However, this may not be what you want. We can add the location check on the iOS side, plus a triangle of latitude and longitude to restrict the users. If the user does not belong to this triangle area, an alert window would pop up on the first time he opens the app, once the user clicks OK he will quit the app.
Another trick fix the time zone issue is always saving the UTC format to the database, since the iOS clients may come from different time-zone areas. Thus, the local time converting should be designed to be more convenient on the client side.
- When cooks add a time to his meal, convert it to UTC format and send to backend.
- Save UTC format time to the database.
- When customers search the the meal, convert local time to UTC format, embed it in the request to the backend, and query from database.
- Response the query result to customers, at the customers side, convert the UTC format to the local time and display on customers’ screen.
Nowadays there are plenty of different architectures. Personally speaking, I think the frameworks like Django, Ruby on Rails or MEAN still remain as the suitable ones for small startups. The server-less framework is a new fashion for some startups. While, in most cases, the choice of web framework usually depends on the team’s familiarity towards it.
We are using a typical and easy architecture (dynamic-static separation).
Figure 1. Elastic BeanStalk with S3 architecture (from AWS)
There are two servers and two databases on Elastic BeanStalk (one for development and one for production). The scale up servers are managed by the Elastic BeanStalk.
This architecture stands out as the heavy business logic is only processed by the servers on the Elastic BeanStalk. While the static and large files come from AWS S3 server, which will decrease the traffic from the main servers on the Elastic BeanStalk.
The largest difficulty of the product is the system design problem. How to design a robust and completed interaction system between the cook and customer iOS apps on both backend and iOS side? It’s actually a state machine design problem.
Obviously, the key point is to figure out how many cases needed in your app. Unfortunately, there are not too many blog/article references because it’s too customized and specific by nature. I have discussed with Mr. Hao, the Senior Engineer in our team, to make an initial draft with continuous trial and errors.
Here’s the first draft of the interaction system, LOL.
Figure 2. The draft of interaction system
Here is the complete diagram.
Figure 3. Final user flow of interaction system
It is my first time to design two apps communication from end to end. Definitely it is not an easy task. I really like to share more details with you guys, but the most important thing is to practice as we didn’t make it perfect at the first time.
All statuses defined in the database and every status transition will need a database query. Probably a better way is to add a Redis cache in front of the database to reduce traffic.
The reason of charging for the customer after he making the order is to ensure the customer is capable to afford the fee and simplify the following process, especially if the charge is failed. If we made the charge later (for example, after the cook accepts the order) and it is failed, we would have to deal with both cook and customer sides, which consumes more resources.
After the entire transaction completed, the customer needs to review the cook first and then the cook has to review the customer first to receive the review from the customer. Because if the cook could see the review from the customer, he would not be likely to leave objective review to the customer.
In addition, the push notification is used to notify both sides but is not good enough. To ensure the user who turns off the notification can receive notice, we make a design of sending corresponding email to him and popping up a notice page once he opens the app.
Thanks for your reading! The next and last chapter will display plenty of activities and marketing images for you.