1

Skip Line
By: Yauheniya Nikulyak
&
Thach Doan
CST 499: Capstone
Dr. Eric Tao, Brian Robertson, and
Cassandra Eccles
05/14/2020

Executive Summary
 2

The Quickbite Menu app offers services to local restaurants to display their menu openly

for customers to be able to order while not having to wait in line at the store. Our services help

restaurants have a faster turn-over for customers, shortening the time customers have to wait in

line. The problem with many popular small restaurants is the ordering process. Many spend

longer time in line waiting to order their food than to pick up their food. This will be mentally

draining and will have a higher chance of them not returning to the restaurant. Everyone will be

affected by this problem. Everyone has to wait in line everywhere they go now and we do not

want to make people wait in line for 15 minutes just to order a drink. Our app will help shorten

lines to at least half the people in line if they use our app. This app will cut down people's wait

time by 15 minutes.

With food industries blooming, we believe that in a couple of years this app can be used

at many locations. Currently, there are many similar apps such as Doordash and Uber eats, but

we believe that this app can be used in malls, airports, and schools. We can have many displays

in the middle of the food court at the mall or airport, while people can order using the display

screens. The restaurants will then receive orders, process the order, and have customers pick up

their orders by buzzer or over the intercom announcing numbers. We are a small team that will

test out the app for a client and hope they can put to good use of this product. If by chance it will

succeed, we will work on plans to expand by setting up a server and charging a small percentage

based on the monthly income. We will manage all the hardware and software if we ever plan to

charge.

TABLE OF CONTENTS

Introduction/background 4
 3

Problem 4
Solution 5
Client’s goals 5
Client’s project objectives 6
Software development team/freelancer’s goals 6
Software development team/freelancer’s project objectives 7
Stakeholders and Community 8
Evidence of the problem 9
Benefits of the solution 10
Feasibility Discussion 11
Functional decomposition of the project 12
Selection of design criterion 13
Final Deliverables 14
Approach and Methodology 15
Ethical Considerations 15
Food industry and employment 15
Legal Considerations 16
Privacy 18
Timeline/Budget: 18
Usability Testing/Evaluation 19
Final Implementation 21
Conclusion 25

Introduction/background
Our mission is to create an app that will help local restaurants speed up their productivity

and generate better customer service. Our main client right now is a local tea store that we

know. Our app will introduce customers to having access to order their products through a

display of choice from the restaurant. This display can be an iPad, an Android, or just a big
 4

touch screen monitor. The display will show all the items the restaurant offers and customers

can make a selection that they want to order by pressing the plus icon or cancel by pressing the

minus icon (will adjust based on the client needs). There are many similar apps such as

Doordash and Ubereats. Those similar apps are all based on online ordering. Our app will

mainly focus on customers who want to spend time hanging out with friends at a local restaurant.

Problem

How long are you willing to wait in a line to get your favorite food or drink from a local

restaurant? I often go to my favorite tea store, but most of the time I find it frustrating that the

line tends to never end. The wait time is usually 30 minutes per order, so when I find myself

there, I usually get upset and frustrated. Now, often when I think about going to that same store,

I will start to question myself, “How long is the line; is it worth waiting 20 to 30 minutes for one

single drink?” This once led me to leave for a different place that had a faster turnaround. The

problem is that customers have to spend time waiting in a line and when they are seated or

served, they have to wait longer until the order is ready. Our client needs a solution to the

problem to reduce the wait time for the customer. This is a major issue for their small business;

however, they still see great success in their business. They do worry about losing customers

because the wait can sometimes be longer than 20 minutes to buy a drink or two; this will make

customers not want to return in the future. I’ve seen instances where a customer would walk to

the store and see the line just to turn around and go home.

Solution

Our project is to design a simple menu and order creation for local or small business

owners who can not afford to buy an expensive system for their store. The project will allow
 5

customers to order as they walk into the store and not have to wait too long for the order to be

prepared and cooked. Everything can be prepared for customers as they wait to be served or

seated. The app will take in orders, once the customers have submitted their order, it will send

the order directly to the kitchen so the cook or preparer could process the order. The food or any

other items will be served to their table when customers are seated.

Client’s goals

1. Improve wait time and satisfaction of the client’s customers. Wait time is a metric.

2. Increase income with an improved wait time, serve, or order preparation time. Income is

a metric.

3. Attract more customers. Number of served customers is a metric.

Client’s project objectives

Run a study by involving modern mobile technologies in customer service, hoping that the

addition of a mobile ordering system improves metrics described in goals.

Narrowing down:

1. Create a high-level proposal of the ordering system that works on customer’s mobile

devices and allows submission of an order to the kitchen personnel.

2. Find a software development team (or a freelancer).

a. Ask them to design the system UI for customers and for personnel.

b. Ask them to evaluate the effort in terms of time and money.

3. If proposal (2) is affordable, request the team to initiate the work; otherwise, continue to

search for an affordable option (2).

 6

4. Propose amendments from personnel after the 1st development iteration is completed.

5. When the amended product from (4) satisfies the requirements, train the personnel to use

the new system.

6. Run the study for a period of time (weeks, months) to see if the product improves metrics

from the goals.

7. Based on the outcome of (6) make the next strategic steps.

Software development team/freelancer’s goals

1. Find a customer to provide a project to build.

2. Perform software development to get client’s satisfaction.

3. Receive compensation for the work in the form of money or any other beneficial

agreement.

Software development team/freelancer’s project objectives

1. Collect the requirements from the client.

2. Propose a high-level system design.

3. Propose UI mocks to the customer.

4. Provide estimations in terms of time and money. See if there is a space for negotiation.

5. Amend, validate, and signoff system designs and User Interface.

6. Choose programming languages, frameworks, and systems and platforms to develop and

host the product.

7. Implement the next (first if there is no previous) version and request feedback for

improvements.

8. Repeat (6) until the client is satisfied.

9. Collect and analyze the experience received during the development of the product.
 7

10. Decide if any changes are needed in (6): were the chosen programming languages,

frameworks, and systems and platforms effective? Are there any better alternatives?

11. In the case of the Quickbite project, decide if the client is satisfied with their metrics.

○ If they are, then develop the next steps to promote and franchise the product to

other places.

○ If they don’t, then decide if other studies at other restaurants are needed.

Stakeholders and Community

List of stakeholders

1. Our client: a business owner who requests the idea validation/experiment/product.

2. Our client’s customers: they may potentially get an improved quality of the service.

3. If the client achieves one of their goals (quality, speed, efficiency, and income

improvements), it may benefit the community by changing the industry, allowing more

working places.

4. Development team

a. We’ll get our first work contract.

b. We’ll earn more experience in the development process, technologies, customer

communication, and business development.

c. Depending on a way that the project goes we may get one of the following

artifacts:

i. potential monetary compensation;

ii. more work requests;

 8

iii. product as a completed business experiment if our client decides to invest

in the further development (start in more places, franchising, etc).

As our first stakeholder is our client, they will define the business requirements of their

product idea/experiments. The will share the details of how the project layout will look like and

will make the final decision in their menu display. They will also provide pictures for the menu

for their shop to be displayed. They will eventually make the final decision to use our app that

we provided or just choose to take it to test and put it aside. The community will be our client’s

customers or anyone that is ready to make an order. They will use the app and if they do not like

it, they will leave feedback and if it does not work out they will no longer be using the app.

Generally, as a community there won’t be much negative effect; just testing if they like

the functionality of the app. At worst it will just waste some time out of their day. A possible

outcome is making their lives a little more convenient. While it will greatly benefit the

community if they can catch on and use it to save time instead of wasting it standing in line and

being frustrated. For our clients to be affected, they must spend time and resources to test out the

app. As for benefits, if this does work out, it will increase their efficiency. They will have a

faster turnover of customers, the ordering system will help them build great statistics for their

own products and what to order in inventory weekly or monthly. Good statistics of what to order

will decrease expenses going out and increase productivity. If this app will gradually be rolled

out to malls, food courts, airports, etc. This will be convenient for people who are short on time,

want to have a decent meal, those who do not want to stress over logistics, and want fast service.

Evidence of the problem

The reason we got this idea is from a client: Nhanh Nguyen. He owns a local tea store

that sells both drinks and snacks. His store generates a decent number of customers but the
 9

owner told me many times that because of the line, it would take longer than 20-30 minutes for

customers to receive their orders. The owner wants to speed up the process and make it more

modern and convenient for the customers. He feels that if customers keep on waiting for their

drinks, eventually they would go somewhere else. The tea business in San Jose is very

competitive; there are many tea stores at every zip code.

When I was in high school, I used to work at the mall. When we worked at a mall, we

usually had half an hour for lunch and everyone had lunch at the same time of day. How can we

get food and have a decent lunch when the lines for every restaurant at the food court are very

long? This Menu App is needed to save people's time in many ways.

The store owner above wants to run a business experiment by introducing an ordering

improvement. While the project is requested by a single business owner to validate their idea, it

may have potential success and application in other places such as cafes and restaurants that have

long waiting lines. It may also lead to different approaches/development requests.

Benefits of the solution

Happier customers will attract more customers by word of mouth and a faster turnaround

will make more revenue. The app will also collect statistics on how many orders customers

make for certain types of items. Stores can get better statistics of what a customer’s favorite

items are and what products/ingredients the store needs to order. Restaurants will be able to set

up how and where they want to display the app menu in the store or provide quick access to the

app by a quick URL (for example, http://eat.at/EDDYTEA). The app will benefit many small

businesses for better planning as well as helping owners manage resources. It will be important

that everyone can save plenty of time instead of wasting time waiting in line.
 10

When restaurants are opened, they generally want better income and more customers to

shop there. Customers are essential but with more customers there can be problems with

customers waiting in line too long. We’ve seen this plenty of times during our stops by our

favorite local spots. In order to solve this problem, we came up with the idea of this app to allow

restaurants to display their menu of items close to their front door, or where restaurants choose to

place their app menu. This will allow customers to order as they walk in or when they hang out

with their friends at a table. This will help improve the lines to be less crowded and generate a

faster turnover rate.

Feasibility Discussion

With technology now trying to make everything convenient for everyone. Doordash,

Ubereats, and Grubhub are some of the apps that allow someone to order food online and have it

delivered to their own home. These apps will take in orders of restaurants they choose and send

out the order to that restaurant. The restaurant then takes that order through its system, and prep

the order. Those apps will have someone pick up the item and deliver it to the person ordering it.

While these sound great for a restaurant but it comes with a charge. Doordash charges

restaurants 20 percent per order (Yelo, n.d.). Ubereats comes at a stepper price of 30 percent per

transaction (Cameron, 2018). While we use these services the prices can be a little higher than

the original price compared to shopping at the store (Pisani, 2018). What’s more important: all

these services do not solve the problem of customers in line.

The process of what these apps do is very similar to what we are trying to establish.

Convenience for customers to order. They use an online ordering system which sends orders

directly to clients without waiting in line, while using these apps and through user location. So

their location can be anywhere in the U.S. which is really convenient if one is too lazy to leave
 11

the house. We are processing through the store and everything will be within the store location.

The difference in this process is when we order through these online services the wait time for

one to process this order. Sometimes the wait can be longer than just to make a quick stop to our

nearest store and pick it up. We are also not sure if the person picking up our food took care into

handling our food; we have to consider the price will also be higher for food ordered. Our app

will mainly focus on in-store orders, this is for people who like to gather together and hang out

and have a fun time with friends.

The pricing of each product can be much higher when one uses those online apps that are

provided. Each item can cost up to 20-30 percent of its original price; delivery fees can also add

up over time. Since our app is focusing more on in-store prices, what you see is what you will

pay; no extra charges for services fees or delivery fees. We do not have to worry about what can

be in our food or if we trust our delivery person.

Functional decomposition of the project

The project’s functionality is designed to allow customers to order without waiting in

line. This helps customers feel that the restaurant's wait time restriction is easy and has a greater

chance of them returning. It's made to help the restaurant’s owner have a better turn over rate in

customers with faster services.

Our layout design was simple; the design has pictures of each item displayed so

customers are aware of what they are ordering. When customers click on a picture of an item

they like, another menu pop-up allowing them to select different types of the selected items and

options to customize their drinks however they prefer. Users can also remove items in their

shopping cart.
 12

With a shopping cart option, it allows customers to be aware of what they have on their

shopping list. This allows customers to not double order, not miss items they want, or remove

items they do not want. Shopping carts also let users be aware of how much they have spent.

This also leads up to payment. Payment can be an important step; if we miss this we can miss out

on the entire project. We plan to use the Spring Boot tool that helps us implement this

procedure.

Last but not least is our microservice system. When customers are finished with their

orders, we would like the kitchen to receive the order and try to process the order as it comes in.

We are going to use RESTful API to allow micro services to communicate with each other.

Selection of design criterion

Before we started our app, we thought that using Android Studio would be our main

focus in our design criterion since most of our app mainly focuses on human interaction. Using

Android Studio may seem like a good choice, but we only learned it in one course and it required

many weeks of extra learning. When Cst438 rolls around, this is where we were introduced to

micro services and Spring Boot. From this class, we got a clear understanding that there are

many tools that Spring Boot has that help us with our project. Spring Boot has many “tool”

options such as: “security service for payment”, “security” for login in. Spring Boot uses Java

language which we have plenty of experience with and it also allows us to use Thymeleaf

template engine to render HTML web pages. We decided to use Bootstrap to make the

application look nice, Javascript and jQuery to provide different functionality. While our apps

rely heavily on databases to display products, we used necessary dependencies to connect the

Spring Boot application to the MySQL database, like mysql-connector-java and spring-boot-
 13

starter-data-jpa library. As a result, Spring Boot appeared to be a perfect match to use in building

our apps.

Final Deliverables

When our client receives our final product, we are going to provide a simple

demonstration including: documentation about each functionality, system requirements, and

setup instructions. They are also given an option to create an account personally to log in to use

our app or we can provide an account for them. Our app then launches when the right

credentials are entered. When our app launches it will display all the images of products that are

on sale in-store. We will use human interaction, so users can make a selection of drinks when

pressing on the images. Users can also change the size of their drinks or add extra ingredients to

their drinks. Users will also be able to see what is under their cart when clicking on the shopping

cart icon. They will be able to check out and enter the type of payment which will either be

Paypal or credit cards. Once orders are sent in, we need a way for the client to know what order

has been sent in. We will set up a back-end server to receive this information in the kitchen.

With all these given we will also provide them with an agreement for fixing bugs and extra

support if needed.

Approach and Methodology

We will use Spring Boot for the server-side development. This is a Java-based framework

that supports the quick development of RESTful interfaces and effective database connections.

We will use the Bootstrap UI/Javascript framework for client-side development. Springboot and
 14

Bootstrap are one of the most popular and well-supported frameworks. The code will be stored in

a private GitHub repository.

In every project, we must have a well-executed plan to be successful and accomplish our

goals. This project will take us about 6 weeks, so we must constantly get feedback. Testing can

be done anytime by using the Agile methodology and will not restrict us to phases, which will be

our ideal development procedure. We are planning to use PivotalTracker

(www.pivotaltracker.com) as an online dashboard to keep track of our tasks and provide a

timeline of when to complete each task. We will organize stand-up meetings to let everyone in

the team know about the progress, difficulties, and concerns. Each week we will have project

planning and grooming meetings to help correct the chosen approach, work, and flow.

Ethical Considerations

Food industry and employment

When it comes to making money, people have different views of what is right and what is

wrong. New startups like Doordash and UberEats disrupt existing consumer ecosystems

radically, changing people's lifestyles and customer behavior. These startups change the industry

in the way that there is no need to look for places to eat outside of someone's home anymore.

User-friendly applications allow quick access to the kitchens of many restaurants and cafes and

30-minutes delivery transportation of the food to a person. However, these applications hurt

some businesses with their pricing politics because delivery fees are high. If a given restaurant

opts out of delivery, the business risks becoming obsolete and losing customers. Sometimes

entrepreneurs create kitchens in low-rent spaces and post menus on a website. This allows taking
 15

orders via the internet. They don't need to hire waitstaff, buy furniture, or rent places with high-

traffic locations. Sometimes quality suffers as in comparison to old-fashioned places where

customers have to go out and visit a physical location to have food. Takeouts with delivery

services may have issues with delivering wrong items, losing food, or delivering late.

Restaurants can lose customers because of the delivery service.

Our application is not meant to disrupt or change the industry. We don't ask restaurants to

change their model and fire people because some professions aren’t needed anymore. We want

to optimize the queuing and ordering system for places that work in an old-fashioned manner.

Legal Considerations

Recently because of the Covid19, there are many small businesses that have started to

launch their apps similar to what we have. Many of the features are very similar, but we mainly

focus on in-store instead of ordering online. Grubhub, Doordash, and UberEats apps have some

functions similar to what our app has. These ideas are pretty similar to our product, so the

copyright of this app does become a concern. While restaurants display pictures of their

products, what happens if those pictures are not what they are offering? This can come in

question if we took pictures of some existing restaurants and just ignored copyright laws. There

are more concerns that we want to solve with the help of legal advisers. What if a restaurant is

under franchising, can they use our app or is it illegal to use third-party apps? As I asked and

understood that if a business bought the franchise they can use and launch their own app as they

wish for their store.

A possible legal issue is food poisoning when a customer may order and consume

something that causes some sort of infection, sickness, or allergy. Potentially a customer may file
 16

a lawsuit against a business. However, in practice, not everyone is allowed to produce/cook food

and sell it to customers. Each business goes through a set of diligent reviews from the Health

Department to get a Food Service License, Building, and Employee health permits. Also, it is up

to a business owner on how to organize various ordering systems and whether to use mobile or

other devices. Their responsibility is to make it in a safe and reliable manner so customers and

employees are protected from health and life threats like bacteria, infections, viruses, dirt,

expired, or poisoned food/components. We are building an ordering system or an addon to some

existing ordering systems to help a business owner organize their orders better. We don’t change

their cooking techniques or the way they deliver their products. However, we may explicitly

waive the liability of the developers in the contract.

Security issues can also come in affect when we are asking customers to enter their

payment method. Are we held reliable for their information being stolen if our app gets hacked,

or in-case an employee decides to explore bugs in our app to record customer information? This

though does run through our head as we create this app. Would Paypal cover the lost or will our

clients have to take a hit?

Privacy

As security is very important we would like to keep all our customers protected and feel

safe while using our app. We will follow the best practices in order to store customer data

(whether private or payment related) in our application. There are techniques to store data in an

encrypted way per customer, salting passwords, and using a modern O-Auth authorization

system. Using an existing reliable payment gateway like PayPal may even help with not storing

payment-related customers' data at all. We will also have an encrypted account before our app

launch so non-authenticated users can not log in to have access and spread bugs.
 17

Timeline/Budget:

Before the class starts: Gathering data to start developing an interface and layout.

Week 1: Inserted data into MySQL database. Paper layout designed interface. $0

Week 2: Created interface and received feedback from the client. $0

Week 3: Created logics for the website. $0

Week 4: Created back-end servers to receive messages from the frontend.

Week 5: Tested logic and all functions and added miscellaneous.

Week 6: Finalized small details and created a project video for the presentation.

Week 7: Fixed video presentation feedback from teachers and present Capstone.

Week 8: Turned in the report, proposal, and all necessary files. $0

Total budget: $0

Originally our proposal was that we have 8 weeks to finish the project. Due to the

Capstone presentation being in weeks 7 our timeline was moved up to 2 weeks so some of our

tasks were moved up by 2 weeks.

Usability Testing/Evaluation

“What needs to be tested with UI user study/client communication” (Travis, 2016).

The SkipLine application was developed for a broad audience. The user interface is

simple in its design and functionality. As a result, people with different comfort levels of

technology, interests, age, and occupation would be able to use it.

The project would be tested by a client who was interested in developing this application.

Also, we are going to ask some of our family members for user feedback. To collect feedback
 18

from different age categories we also included the youngest and the oldest family members. The

youngest user is 11 years old and the oldest one is 70.

The main questions that would be asked to users are the following:

● Is this application attractive?

● Is the application easy to use or confusing?

● Would users use this application in real life?

The main tasks our client would test are the following:

1. Is he able to see a tea shop menu properly?

2. Is he able to select a menu category?

3. Is he able to select a product from the category?

4. Is he able to customize a product by adding different add-ons?

5. Is he able to adjust the quantity of the product?

6. Is it possible to go to a shopping cart and adjust a shopping cart?

7. Is it possible to place the order?

8. Is it possible to pay for the order?

9. Does kitchen staff see at their side the order placed by the customer?

10. Is the kitchen member able to assign an order to itself?

Our team met the client via Hangouts to test the application. The client shared his screen

over Hangouts so we were able to see all his actions and reactions. The client was satisfied with

the laconic menu representation. He could easily access the desired menu category and easily

select a product to order. It took him about 15 seconds to get familiar with all add-ons for the

product to customize it if he wanted. We asked the client to try an option to adjust the quantity of

the product before adding it to the shopping cart and that was done successfully. Before testing
 19

the shopping cart, the client added several items to have more testing options. At a shopping cart,

the client was able to delete 2 different items, he checked the subtotal price, taxes, and total price

that all met his own calculations. He was not able to check payment as it is a “dummy” for now,

but we are planning to use Paypal and Stripe in production. The only place the client had a

problem was a kitchen microservice as he was a little stuck on how to assign an order to a

particular kitchen member. But as this stage is still a work in progress, we'll fix it by the

Capstone festival and show the client an improved version. As a result, we saw that the client

didn't have any problems and was satisfied with the user part of the application, but had some

issues with the kitchen part of the project.

All users gave mostly the one and the same feedback. Thus, they all noticed that

application design needs improvement to become more attractive. The younger users were able

to quickly identify how to use the application as well as the older users but not as fast. The

younger audience said they would likely use the application on the way to the tea shop to escape

any wait time. Some of them said they would like to use it after they would be seated to escape

the order line. The older audience said that application usage depends on how they feel, if they

have a meeting with friends, or if they are pressed on time; but overall they also liked it.

As a result, we have some things to fix before the Capstone festival like kitchen

microservice to assign the order to the kitchen member easily and maybe the overall application

appearance. As a long term perspective, we have to work seriously on the payment part to make

it secure, add an option to get a printed receipt or by email and add an option for users to create

an account if they want their previous orders to be saved and reused during the next visit.
 20

Final Implementation

Skipline has 3 different servers and each of them has its own functionality. The frontend

server that we built will contain Human Interface. While the backend server will acknowledge

what the frontend server is sending information to. Let us start going through each functionality

and we're going to introduce our frontend first.

Frontend server contains two subcomponents: user interface for customers and user

interface for staff.

UI for customers contains viewing categories and product lists, editing the cart,

proceeding to checkout to populate user contact and payment data, completion of the order and

viewing the receipt. Our main page is for users to select the 6 options we have displayed: Coffee,

Milk Teas, Slushy freeze, Smoothies, SpecialTeas, and Food. Users can choose any of the

selections from these 6 options but can only select one option at a time. These 6 options have

very similar functionalities, so we described one function instead of all 6. Once users have

selected an option of choice on the main page, the page will change into different options to

choose from. If users choose an option like “Coffee”, it will lead to the coffee pages. On the

“Coffee” page, there would be displays of products that the store sells that are related to only

coffee. If the user decides to order, they can select the choices of coffee they want. After

selecting the coffee of their choice, another page will display showing different functionality

options to choose from. These functions are the size of their drinks, adding extra ingredients into

their drinks, and increasing the quantity of their drink. On this page, there are three other

functions that are also available. The three functions are: Continue shopping, cancel, or add to

cart. “Continue shopping”, allow users to remain on the page and add what necessary items they
 21

like, while “cancel” restarts and delete the current choice, and “add to cart” will add what is

being selected in to cart.

While Homepage functions have pretty much one function and that is to lead the user

back to the main page. This can benefit users in many ways, we do not want users to keep on

pressing back to return to the previous page. If a user has gone through 10 different pages we do

not want the user to press back 10 times, this will be very annoying for the user. With the back

button, we can also see our previous page, this can be very unsafe for security purposes.

Customers can go back to previous customer orders and can see their payment credentials which

will be very bad for us.

The “Shopping Cart” function is very important. This will display what customers have

added to their cart. There are a couple of built-in functions under the cart. One of them is being

able to view what is in the cart, such as the name of the drink, price of the drink, and how many

of that quantity was selected. If we can view, we can also delete the order from the cart. The

“Delete” option is necessary in case customers decide not to want an item. We do not want

customers to redo the whole order just because of an item they do not want. What happens when

customers want to add more items to their cart? This is where the “Continue shopping” option

function comes into effect. This option enables customers to add more items. Lastly, we can not

forget about the “CheckOut” function. This function will let us finalize our selection and lead to

the payment function.

The two other server components are microservices.

The first one is the Common Product Information Service responsible for retrieving

categories, product and price data from its own MySQL instance that holds that data. It uses the

REST approach and JSON as an underlying format for data transfer (REST allows other formats
 22

like XML, SOAP or Protobuf). It will hold a symmetric key to pass to MySQL so the database

could decrypt its data and encode it for TCP transfer.

The second microservice is Order Processing Service component to process order

submissions and payments from customers, order updates and authentication requests from staff

members. It uses its own MySQL instance not shared with the Common Product Information

above. A different symmetric password will be used for the 2nd microservice

One of the most important parts of the application is security. Everything below is stored

on our servers with the one exception: we don’t store credit card information and rely on a

payment processor. Security must be applied to:

● customer data;

● orders created by them;

● staff data: personal and credentials;

● financial data: orders made by customers.

There are two main types of security in regards to the data: data can be at transfer and can

be at rest.

Data at rest means the whole application traffic must be secure. Communication between

browser and front-end server must happen under SSL with domain certificates issued and

verified by a well known public authority, for example, Thawte. Communication between the

front-end server and microservices must also be secured with the help of SSL. Microservices

may also use Internet domains with SSL certification (same as with the browser to front-end

server) or use custom/private certificates without a signature provided by authorities like Thawte,

but must do it over the private local network to avoid possible impersonation of a participating

component. This protects data between a user and our servers while at transfer.
 23

The data at rest includes orders, customer and staff data. It will be encrypted and stored

on disks with the help of MySQL and symmetric encryption when communicating parties hold a

private password. Also, to avoid security leaks, credit card information is passed directly to the

payment process and never stored by us. HTTP forms will also be protected with CSRF tokens to

avoid Cross-Site Request Forgery attacks.

Front-end and microservices may hold secure salts (used to salt staff members passwords

for hashcode calculation) and private or symmetric keys (for MySQL above). These are critical

highest priority data items that can’t be leaked. Storing them on the disk or in some accessible

shared place for IT administrators is not recommended. The best approach is to use industry

proven automated solutions like Amazon Key Management Service, Google Keystore or Heroku

Secure Key. All these solutions allow accessing keys once they are needed in an application

component. While an application component works, the secure item (private key or symmetric

key) is held in the memory where it is only allowed to be accessed by the same process. When

the process stops, the secure item is erased from the memory and it has to be re-requested from

the secure store provided by Amazon, Google, Heroku or any other cloud/hosting provider.

Conclusion

In conclusion, we just want to help save people’s time in their everyday lives. We do not

want someone to spend too much time waiting in line just to get a quick bite to eat or drink. In

this report, we have a brief description of who our client is and what our application’s main

purpose is. We stated the problem that the owner of the restaurant feels that they are afraid that

customers are not happy with the wait time spent in line just to order what they want. We stated

the solution with that in the form of our application, which will lessen the time customers have to
 24

wait in line. The benefits of using our application compared to other applications that are similar

to what we are doing are no charging fees. We give a brief description of our timeline of the

development phase, and our goal for each week is to accomplish the task our client is asking for.

We discuss how we came up with the method to develop this application and why we used those

methods. How our final product will look like and how each function works together to form

this application. We also give a brief discussion of our testing and what needs to be tested.

Finally, we want to consider what legal matters would affect us when the application is launched.

The legal matters that would be considered are copyrights and security purposes. Are we selling

customer information? We explored these factors in our legal issues in this report.

Our design allows customers to order through our application. After customers have

made an order, the order will then be sent directly to our kitchen to be prepped. The kitchen will

then receive the order; they will be able to see through our backend server the customer’s order

and customizations added. The kitchen then will prepare the order and process it there; this will

cut downtime for customers in line to order from the cashier. This is mainly our design for this

project. The customer orders, the kitchen receives the order, prepares the order, and skips the

middleman.

While this is my first real-life assignment, learning how to work with microservices is a

bit harder than creating regular one server applications. If you would ask me what microservices

were a couple of weeks ago, I would probably not be able to answer the question. After finishing

this project, I’m able to get a deeper understanding of microservices and the pros and cons of it.

In the near future, if this application is successful, I can see it being used in the school cafeterias,

food courts in the malls, or food courts in the airports. I believe it will save people who are

shopping at the mall a lot of time because they won’t have to stand in line to order. We created
 25

this application in mind for small local restaurants to increase their efficiency and with the hope

of generating an increase in customer turnover and increasing their annual income.

REFERENCES

Cameron, K. (2018, March 26). Why Uber Eats Will Eat You Into Bankruptcy. Forbes.

https://www.forbes.com/sites/cameronkeng/2018/03/26/why-uber-eats-will-eat-you-into-

bankruptcy/#48ab483b21f6

Pisani, J. (2018, Feb 4). Fast food is coming to your doorstep, but it can cost more. USATODAY

https://www.usatoday.com/story/money/food/2018/02/24/fast-food-coming-your-doorstep-but-

can-cost-more/359219002/

Travis, D. (2016, Jan 15). The 1-page usability test plan

https://medium.com/@userfocus/the-1-page-usability-test-plan-dbc8c3d7fb54

Yelo. (n.d). How DoorDash Works | Business Model & Revenue Sources Explained.

https://jungleworks.com/doordash-business-model-how-doordash-works-earns-revenue/
 26

Appendix A
Travis, D. (2016, Jan 15). The 1-page usability test plan

https://medium.com/@userfocus/the-1-page-usability-test-plan-dbc8c3d7fb54
27
 28

Appendix B

Final Implantation Microservices diagram

29
30