DEV Community: Bertrand Masabo

Online Food Ordering App (8)

Bertrand Masabo — Mon, 12 Apr 2021 20:41:43 +0000

Hi, welcome to the last post of Online Food Ordering App series.

In the previous posts we built API endpoints for authentication and managing orders. We've also built our frontend react and react-native apps and connected them to the API endpoints.

In this post, we are going to implement the view orders list, view single order, update order status, view menu, and place order features on our front-end apps.

Project Steps
1. Backend - Project Setup ✔️
2. Backend - Authentication - Sign Up ✔️
3. Backend - Authentication - Login & Logout ✔️
4. Backend - Place Order ✔️
5. Backend - View Orders List & View a Specific Order ✔️
6. Backend - Update Order ✔️
7. Front-end - Authentication ✔️
8. Front-end - Place Order, View Orders List, and View Order Details 📌

Before we start, take a look at this PR and update the backend code. We added the payments endpoint, a script to create the menu and we updated the fetch orders list to accommodate both the admin and the customer.

Mobile app

Before we begin our implementation, let's think for a minute about the user flow we want for our customer.

A logged-in customer launches the app and they immediately see a list of menu items divided into 3 tabs (Breakfast, Lunch/Dinner, and Drinks). Each item has an image, a name, a short description, a cost/price, and size. To switch to a different tab, a user swipes the screen left or right, or they tap on the tab name. To add an item to the cart, a user simply taps on the item. Tapping on the item already in the cart increases its quantity by 1. To remove an item from the cart a user simply taps on the item from the cart screen. From the cart screen, a user can navigate to the payment screen where they will be able to confirm their order by making payment by card.

A user can also see the list of orders he/she has placed and their details by tapping on the basket icon in the bottom navigator. Finally, a user will be able to see his/her account information by tapping on the account icon in the bottom navigator.

The screens of our app will be divided into 2 main parts (AuthStack and HomeStack) whereby AuthStack will contain all the screens related to authentication (LoginScreen, SignupScreen, and VerifyScreen) and HomeStack will contain nested stacks (MainStack, OrdersStack, and AccountStack).

MainStack will contain screens allowing the user to view the menu, interact with the cart, and make a payment.

OrdersStack as the name suggest will contain screens for viewing the list of orders a user has placed and each order details.

AccountStack will contain just one screen to display the user's account information and a logout button.

Great! Let's get started.

Install the dependencies we are going to need:

yarn add react-native-dotenv react-native-credit-card-input react-native-paper-tabs react-native-pager-view @react-navigation/material-bottom-tabs react-native-stripe-payments

In the context directory, create a dataReducer.js file and paste the following code inside:

ADD_MENU: will receive an array of menu categories and their items and will save it in our state in a variable called menu.

GET_MENU: will receive a category name then loops through the menu categories to find if that category exists then will save it's items in a variable called menuItems.

ADD_TO_CART: will receive a menu item and append it to a variable called cart.

UPDATE_CART: will receive an item then checks if that item is in the cart before replacing it with the new item.

REMOVE_FROM_CART: will receive an item id then loops through the cart array to find an item with that id and delete it.

CLEAR_CART: will remove all items in the cart array.

ADD_ORDERS: will receive an array of orders list the save it in the state in a variable called ordersList.

Create a DataProvider.js file and paste the following code:
Create a src/navigation/menuTabs.js file like this:

In this file we create a MenuTabs component that receive 2 props: menuItems (an array of menu items for the selected category) and handleChangeIndex (a function to switch tabs). We created a handleAddTocart function which will help us to modify an item before adding it to the cart and to dispatch messages after the item is added to the cart.

The component returns 3 tab screens where each tab screen will use the ListItems component to display the data or the CustomCaption component to display that items were not found. Also, each tab screen is associated with an index number starting from 0. We'll see how this index number will be useful in a minute.

Let us now create the main screen and use the menu tabs we just created above.

Create a src/screens/MainScreen/MainScreen.js file like this:

In this file we created a MainScreen component that fetches user data, cart and menu items from our global state. We created a handleChangeIndex function that receives an index number (tab screen index) and dispatches a function that will trigger the GET_MENU action. We used the useEffect hook to trigger the handleChangeIndex function when this component mounts to get data for the first tab screen.

This component will render a welcome message, the user's address, the menuTabs component and the CartButton component to view the cart contents if the cart is not empty.

Let us now create the last screen for MainStack.

Create a src/screens/PaymentScreen/PaymentScreen.js file like this:

In this file we created a PaymentScreen component that has 2 functions: handlePaymentInit and handleCreditCardForm. When this component mounts, it displays a title, an image of credit/debit cards accepted, and a button to make payment. When the button is clicked, it triggers the handlePaymentInit function which triggers an internal state update of showCardForm to display the CreditCardForm component.

The CreditCardForm component receives an onChange props which is a function that gets executed as we fill the form and returns a formData object composed of 3 properties: valid, values, and status. We are interested in valid and values properties.

valid is a boolean which will be true once all the fields of the form are filled correctly.

values is an object of the form field values. It has the following properties: number (card number), expiry (MM/YY), and cvc (3-digit cvc/ccv). Learn more here.

So, in the handleCreditCardForm function we check if the user has filled the form correctly, then we extract the form values and build a cardDetails object. We then proceed to validate the cardDetails object by using the isCardValid method from react-native-stripe-payments.

If the cardDetails are valid, we hit our API endpoint for payments to create a paymentIntent. The payment intent returned from calling our API contains a clientSecret string that we use along with the cardDetails object to confirm the payment with stripe.

If the response returned from confirming the payment contains an id, that means the payment is successful then we proceed to prepare the payload for the order and hit our backend endpoint to place an order. If the order is placed successfully, we reset our stack navigation then navigate to ordersListScreen.

NOTE: this implementation is a bit naive because there are some edge cases we did not account for, for example, what if the payment is successful but the order cannot be placed? What happens then?

One solution would be to extend our order statuses and allow a user to place an order before making the payment then once the payment is confirmed we approve the order.

Cool!

Lastly, we wrapped everything in a try and catch so if anything goes wrong the user will be notified via the Alert component.

NOTE: our services in src/utils/api.js were starting to become messy, so we refactored the code to look like this:

Make sure you update the authentication feature to use the updated services as well.

The screens for our MainStack are now done. Let us implement OrdersListScreen and OrderDetailsScreen for OrdersStack next.

Create a src/screens/OrdersListScreen/OrdersListScreen.js file like this:

In the OrdersListScreen component we used the useEffect hook to add a focus event listener which will be triggered every time this screen is focused. In the event listener we fetch the list of orders and dispatch an action to save the data in ordersList global state variable. The component will display the list of orders if found or a no orders found text. We have also implemented a handleOrder function which will receive an id then navigates to OrderDetailsScreen.

Create a src/screens/OrderDetailsScreen/OrderDetailsScreen.js file like this:

In this component we fetch an order's details by using the orderId parameter from props, save the data in internal state variable orderDetails then we render the information.

The screens for OrdersStack are now done. Let us create the one screen for AccountStack.

Create a src/AccountScreen/AccountScreen.js file like this:

In this component we are just displaying the user information from the global state variable auth. We have also moved our logout implementation in this component.

Now that our screens are done, let us create the stacks mentioned above.

Inside src/navigation create a new directory called stacks and inside stacks create the following files: MainStack.js, OrdersStack.js, and AccountStack.js.
Inside AccountStack.js paste the following:
Inside OrdersStack.js paste the following:
Inside MainStack.js paste the following:

The last piece of the puzzle is to put together the stacks we created above and add the data context provider in App.js.

Let's do it.

Move HomeStack.js in src/navigation/stacks/ and update it to look like this:

Let's go over what we did in this file.

HomeStack is the component that will be mounted as soon as a user logs in or when a logged-in user launches the app and he/she is authenticated. There are a couple of things we want to do before this component renders:

We need to fetch the menu and save it in our global state.
While fetching the menu, if the user's token happens to be expired (from the backend) we automatically log out the user (on the frontend).
If the user's token is valid and the menu data is found or not, we proceed to render the tab navigator.

Finally, update src/App.js to look like this:

Run the app on an emulator or a physical device and you should see the screens below:

MainScreen

OrdersListScreen

OrderDetailsScreen

AccountScreen

To create a splash/launch screen, check out this article.

For reference, here's the repo for the project.

Admin view orders list, view single order and update order

For the admin app we are going to use Material UI's Collapsible Table component to display the orders. Each row in the table will have a button to reveal the details where the admin will be able to see the contents of an order along with a Update status and user info buttons to update the status of the order and view the details of the user respectively.

We have also implemented pagination to 5 rows per page but you can change this value according to your needs.

Great. Let's start by installing React Spring to add small animations to our app.

Install React Spring:

$ yarn add react-spring

Update src/utils/api.js to look like this:
Create a src/pages/OrdersListPage/OrdersListPage.js file and paste the following inside:

In this component we fetch the list of orders from the backend then use the CustomTable component to display the data.

we have also used the useSpring hook from React Spring to add a fade animation to our component.

Among the new components we created include CustomTableRow, CustomTableFooter, and TablePaginationActions and the result will look like the image below:

And that's it, the admin will now be able to view and update orders.

NOTE: There are lots of features we can add to improve our app. For instance, the first page of the dashboard could contain a summary or an overview of the data in our app like the number of orders for a given period of time, the amount of profit made, the most bought items, etc. We could also leverage the power of websockets to make our app show real-time data or add notifications for when an order is placed or any other action.

This concludes our series.

To recap, we've built a REST API using Node, Express, and Postgres then we built frontend apps in React and React-Native to use the API. We've also covered JWT authentication, unit, integration, and end-to-end testing along with continuous integration and continuous delivery (CI/CD).

I hope this series was useful to you. If you have a question, a comment, or a suggestion let me know in the comment box below.

Thank you for your time, until next time, cheers!

Online Food Ordering App (7)

Bertrand Masabo — Fri, 05 Mar 2021 18:38:52 +0000

Photo by abillion on Unsplash

Hi, Welcome to part 7 of this series.

Today, we are going to implement authentication on our front-end apps.

We are going to start with the admin web app then proceed with the mobile app.

Project Steps
1. Backend - Project Setup ✔️
2. Backend - Authentication - Sign Up ✔️
3. Backend - Authentication - Login & Logout ✔️
4. Backend - Place Order ✔️
5. Backend - View Orders List & View a Specific Order ✔️
6. Backend - Update Order ✔️
7. Front-end - Authentication 📌
8. Front-end - Place Order, View Orders List, and View Order Details 🔥

Let us begin with the admin web app (gourmet-admin).

Make sure the main branch is up to date with the remote main branch
Create a new ft-authentication branch off the main branch
In your terminal, run the following command to install the packages we are going to be using:

yarn add @material-ui/core @material-ui/icons @material-ui/lab axios cross-env history parcel parcel-bundler react-hook-form react-router-dom

Install dev-dependencies:

yarn add -D axios-mock-adapter @babel/core @babel/preset-env @babel/preset-react

Inside src directory create the following directories: components, context, navigation, pages, and utils.
Inside src/components directory create the following directories: CustomDrawer, FormButton, FormInput, Loader, Title, and ToastNotification.

I have seen a lot of people who like to put their test files in a separate __tests__ directory in the project root and it is totally fine. For me though, I like it when a test file is right next to the component it is supposed to test. I think it makes more sense this way.

That being said, we are going to be creating a component with its test file in the same directory.

Let's start with a title component that we will use throughout our app to display page titles or headings.

Inside src/components/Title create two files: Title.js and Title.test.js
Inside Title.js paste the following:
Inside Title.test.js paste the following:

Do not pay attention to that import of render and screen on the second line for now. We will implement src/customRender.js before running our tests.

Cool!

Implement the remaining components like here

Let us now create a reducer that we will use to update our authentication state.

Create a src/context/reducers/authReducer.js and paste the following inside:
Create a src/contenxt/AuthState.js and paste the following inside:
Create a src/utils/history.js and paste the following inside:
Create a src/context/theme.js file and paste the following inside:

Before creating the navigation of our app, let us create the three pages we will need for the authentication feature namely LoginPage, Dashboard, and NotFound.

Inside src/pages create the following directories: Dashboard, LoginPage, and NotFound
Create a src/pages/NotFound/NotFound.js file and paste the following inside:
Create a src/pages/Dashboard/index.js file and paste the following inside:
Create a src/pages/LoginPage/LoginPage.js file and paste the following inside:
Create a src/utils/validations.js file and paste the following inside:
Create a src/utils/api.js file and paste the following inside:

Now we can create our routes and app navigation.

What we want to achieve is when a user (admin) visits our web app, he will land on our login page then when he logs in, he will be redirected to the dashboard.

Let us implement a wrapper route that we will use to render protected routes like the dashboard.

Create a src/navigation/ProtectedRoute.js file and paste the following inside:
Create a src/navigation/Routes.js file and paste the following inside:

Now we need to wrap our routes with our AuthProvider so that our components can have access to our state and ThemeProvider to be able to use Material UI components.

Create a src/navigation/index.js file and paste the following inside:

Now we just need to hook this Providers component in our main App and we are good to go.

Update src/App.js to look like the following:

Let us now update our scripts in package.json and launch our app.

Update scripts to look like the following:
Update public/index.html to look like the following:
Now run yarn start --open to tell Parcel to build our app and launch it at http://localhost:1234.

When the app launches it should look like the image below:

Great!

Let us now take care of our tests.

Update scripts in package.json to look like the following:
Create a src/customRender.js file and paste the following inside:

Learn more about how this file is useful here.

Create a src/pages/LoginPage.test.js and paste the following inside:

In this file we are testing if the page renders correctly, validation errors then we mock HTTP requests to our API to test scenarios such as when there is a network issue, when the user trying to login does not exist or when the user exists but he/she is not an admin and finally we test a successful login.

Run yarn test to run the unit and integration tests with Jest. When the test runner finishes you should see each test file's status and the test coverage.

At the moment I have 96% coverage which is not bad. You could use the coverage table to investigate the uncovered lines and write either unit tests or integration tests to cover them and increase coverage.

Now we can commit our changes to GitHub and open a PR to trigger a build on CircleCI.

If all goes well, go ahead and merge the PR and we can proceed with the mobile app.

For reference, check out this branch

For our mobile app we need to implement sign up on top of login and logout.

Let's do it.

Switch to the Gourmet project directory that we created in the previous post and make sure the main branch is up to date with its remote
Create a new ft-authentication branch off the main branch
Install dependencies by running:

yarn add @react-native-async-storage/async-storage @react-navigation/native @react-navigation/stack @react-native-community/masked-view react-native-gesture-handler react-native-reanimated react-native-safe-area-context react-native-screens react-native-paper react-native-vector-icons react-hook-form axios prop-types

Install additional dev-dependencies:

yarn add -D axios-mock-adapter

Inside src create the following directories: components, context, navigation, screens, and utils and in each directory create a component file and its test file like here
Create a new src/utils/storage.js file and paste the following inside:

This code will help us to interact with the storage by using the AsyncStorage package to create, fetch, and delete data.

Create a new src/utils/validations.js and paste the following inside:
Create a new src/utils/api.js file and paste the following code inside:

Let us now create our context providers and consumers.

Create a new directory reducers in src/context/
Create a new src/context/reducers/AuthReducer.js file and paste the following code inside:
Create a new src/context/reducers/AlertReducer.js file and paste the following code inside:
Create a new src/context/AuthProvider.js file and paste the following code inside:
Create a new src/context/AlertProvider.js file and paste the following code inside:
Create a new src/context/theme.js file and paste the following code inside:

Now we can create the first screens of our app. We are going to create a signup screen, verify screen, login screen, and home screen. The home screen will only be visible to logged in users. Let us first create the screens then we can separate them in AustStack and HomeStack.

Inside src/screens create the following directories: HomeScreen, LoginScreen, SignupScreen, and VerifyScreen
Inside src/screens/SignupScreen create two files: SignupScreen.js and SignupScreen.test.js
Inside src/screens/SignupScreen/SignupScreen.js paste the following code:
Inside src/screens/SignupScreen/SignupScreen.test.js paste the following code:
Inside src/screens/VerifyScreen create two files: VerifyScreen.js and VerifyScreen.test.js
Inside src/screens/VerifyScreen/VerifyScreen.js paste the following code:
Inside src/screens/VerifyScreen/VerifyScreen.test.js paste the following code:
Inside src/screens/LoginScreen create two files: LoginScreen.js and LoginScreen.test.js
Inside src/screens/LoginScreen/LoginScreen.js paste the following code:
Inside src/screens/LoginScreen/LoginScreen.test.js paste the following code:
Inside src/screens/HomeScreen create two files: HomeScreen.js and HomeScreen.test.js
Inside src/screens/HomeScreen/HomeScreen.js paste the following code:
Inside src/screens/HomeScreen/HomeScreen.test.js paste the following code:
Create a new src/navigation/AuthStack.js file and paste the following code inside:
Create a new src/navigation/HomeStack.js file and paste the following code inside:
Create a new src/navigation/Routes.js file and paste the following code inside:
Create a new src/navigation/__tests__ directory and inside create a Routes.test.js file with the following content:

Now let us wrap our routes with the providers we created earlier and the React-Native-Paper provider.

Update src/App.js file to look like the following:

If we were to run our tests they would fail because we haven't yet wrapped our providers around components and screens in the test environment. To do so, update test-utils.js to look like the following:

Now run the tests again and they should pass.

If you get errors make sure jest.config.js, jest.setup.js, and setupFiles.js look like below and run tests again:

Alternatively, you can run the app on your emulator or physical device to test that everything works as it should.

That's it for today! Push the authentication branch to GitHub, open a PR, wait for the Continuous Integration workflow to succeed then merge the PR.

For reference, check out this branch.

In the next post, we will wrap up this series with the following features:

Place order (mobile app)
View orders list (mobile app and admin web app)
View single order details (mobile app and admin web app)

Thank you for your time. See you in the next post!

Online Food Ordering App (6)

Bertrand Masabo — Thu, 04 Mar 2021 21:08:36 +0000

Photo by abillion on Unsplash

Hi, Welcome to part 6 of this series.

Today, we are going to wrap up the backend of our app "Gourmet" by implementing the functionality that allows the admin to update the status of an order placed by a customer.

We are also going to set up our front-end client apps namely the web app for the admin and the mobile app for customers.

Project Steps
1. Backend - Project Setup ✔️
2. Backend - Authentication - Sign Up ✔️
3. Backend - Authentication - Login & Logout ✔️
4. Backend - Place Order ✔️
5. Backend - View Orders List & View a Specific Order ✔️
6. Backend - Update Order 📌
7. Front-end - Authentication
8. Front-end - Place Order, View Orders List, and View Order Details 🔥

Let us begin by writing our tests.

Ensure the main branch is up to date with the remote main branch
Create a new ft-admin-update-order branch off our main branch
Update tests/orders.test.js and add the following ADMIN UPDATE ORDER test suite along with the new messages. Dont' forget the conflict status code.

Update src/utils/messages.js and add the new messages

Update src/validations/orders.js and add the updateOrder function which will help us to validate the status.

accepted, onthemove, and completed are the only allowed values.

Update src/middlewares/orders.js and add the validateUpdateOrder function and checkOrderStatus function.

The checkOrderStatus function will help us to avoid updating an order status to a value that it already has thus saving up a bit on our server resources. For example, if the admin has already accepted an order, there's no point of accepting it again.

Update src/controllers/orders.js and add the updateOrder method

Finally, update src/routes/adminRoutes.js and add the update order route. The final adminRoutes.js file should look like the following:

And that's it!

If you run the tests again, they should all pass which means everything is working as it should.

Now, go ahead and commit the new changes to GitHub and open a PR. After a successful Travis build, merge the PR to trigger a new production build on Heroku.

Note: There's a bug I caught on signup. Check out the fix on this PR if you had not caught it.

Our simple backend is now done. Let us now set up the front-end client apps.

Admin Panel React App

This web app will help the admin of Gourmet restaurant to manage the orders of customers.

For now, the admin will be able to fetch all the orders, fetch a single order details, and update an order's status to let the customer know the progress of their order.

Later on, we could add more features like user management, staff management, analytics, inventory management and any other feature that would improve the processes of Gourmet as a business.

We are going to deploy this admin web app to Netlify, but you could use any other cloud service.

Going forward, I assume you are familiar with React. If not, check out React Offical Docs and Create React App.

Let's get started.

Using Create React App, create a new React app called gourmet-admin
When done, follow the instructions on your terminal to launch your new app in the browser
Install and configure React Testing Library. More info here
Refactor App.js to remove unnecessary boilerplate code and App.test.js to use React Testing Library then run yarn test to make sure the tests are passing
Add the project to a new GitHub repo, setup CircleCI and Netlify as our CI and CD respectively
Configure test coverage with both coveralls and CodeCov
Commit the changes to GitHub, open a PR to trigger a build job on CircleCI to run our tests.
When the build is successful, go ahead and merge the PR to trigger a new deploy build on Netlify.

This is going to be our workflow for the admin app going forward.

For reference, check out this branch

Customer React Native App

This mobile app will help customers to view the restaurant's menu and to place orders.

We are going to build a very simple Android React Native app but if you want an IOS version as well, it is fairly simple to configure it.

Let's get started.

If you are not familiar with React Native, follow this offical guide to learn how to setup the dev environment and core concepts.
Using React Native CLI, create a new React Native App called Gourmet
Make sure you can launch it on an emulator or a physical device
Configure ESLint, Jest, and setup React Native Testing Library
Remove unnecessary boilerplate code from App.js, refactor App.test.js, and run tests to make sure they are passing
Add the project to a new repo on GitHub, setup CodeCov, and GitHub actions
Commit the changes to GitHub, open a PR, wait for the workflow to succeed then merge the PR

For reference, check out this branch.

The basic implementation for our front-end apps is done. In the next post we will implement authentication in the following manner:

Thank your for reading, see you in the next one!

Online Food Ordering App (5)

Bertrand Masabo — Tue, 26 Jan 2021 12:39:07 +0000

Photo by abillion on Unsplash

Hi, Welcome back to part 5 of this series.

In today's post we are going to implement the functionality that allows a customer to view an order they have placed and for the admin to view a list of orders placed by customers as well as a specific order's details.

Project steps

Let us begin by implementing the functionality to fetch an order by it's id from the perspective of a customer. We are going to add checks to verify if the id submitted is valid, if the order it refers to exists, and finally, if the user who is making this request is the one who placed that order.

Later on, we could build on top of this functionality to add features such as Quick re-order and Order live-tracking.

Update src/utils/messages.js and add the following new messages:

Update tests/orders.test.js and add the customer get order test suite:

In the last two test cases we placed a new order, then we try to fetch it by it's id. We are also checking to see if the data object in the returned response has all the information related to that order, like its contents, and the details of the user who placed the order.

Update src/validations/orders.js and add the getOrder function which will help us to validate the order id:

Update src/services/services.js and add the findOrderByConditionAll function that will help us to find an order given certain conditions. In this case, we want to find an order given it's id and the id of the user who placed it. Sequelize allows us to use logical operators to filter queries as you would with normal SQL queries. Learn more here. We can even go as far as fetching associated models provided that we have made these associations before. In our case, we want to fetch the order's contents and the details of the user who placed it.

Note how we included the entire model of Contents and how we selected only the relevant fields that we want on the User model.

Update src/middlewares/orders.js and add the validateGetOrder and findUserOrderById function.

validateGetOrder will help us to use our getOrder validation function.

Note how instead of passing req.body to getOrder as a parameter, we pass req.params. This is because the id we want to validate will not be generated by the user, instead it will be mapped to our route. This means that, given a route /orders/:id, the id property is available as req.params.id.

In findUserOrderById we destructure that id from params then create a userId variable from req.userData (this is the id of the user who's making this request). Then we use id from params and userId to put together our condition object which we use in the findOrderByConditionAll service.

Update src/controllers/orders.js and add getSpecificOrder method:

Update src/routes/ordersRoutes.js to look like the following:

Now run the tests and they should all pass.

So far a customer can place an order and she can view that order's details.

Let's now see how fetching orders looks like from the perspective of the admin.

For the admin, we will create a new route path where all the admin related sub routes will go. This means that in our route index file we will have 3 parent routes: /api/auth, /api/orders, and /api/admin.

But before we create the routes, let us write our tests.

Update tests/orders.js and add the following:

Note how we added our new tests suite before and after CUSTOMER PLACE ORDER and CUSTOMER GET ORDER suites. This allows us to test the Not Found or Empty scenario and the Success scenario respectively.

In short, we are testing the absence of something, then create something, and finally test the presence of that thing. Does it make sense?

This is one way to do it though.

Let us now create a service that will allow the admin to fetch all the orders placed by customers, starting with the most recently placed:

Update src/middlewares/orders.js and add the findOrderById and findOrdersList functions:

To make sure the middlewares we just created are only accessible to the admin, we need to create another middleware that checks the role of the user who is making the request and then grants access or not.

Update src/middlewares/authentication.js and add the checkAdminRole function:

Update src/controllers/orders.js and add the getOrdersList method:

Now let us create the admin sub routes and include them in the main routes.

Create a new src/routes/adminRoutes.js file and paste the following inside:

Finally, update src/routes/index.js and include the admin routes:

Now run the tests and they should all pass.

Now we can commit our changes to GitHub, open a PR, wait for Travis to successfully build then merge the PR to trigger a new production build.

Thank you for following this series.

In the next post, we are going to wrap up our API with the functionality that allows the admin to update the status of an order.

The code in this post can be found here

See you in the next one!

Online Food Ordering App (4)

Bertrand Masabo — Sun, 24 Jan 2021 19:47:14 +0000

Photo by abillion on Unsplash

Hi, Welcome back!

In today's post we are going to implement the place order functionality, the admin account, and a sample version of our restaurant's menu. At the end of this post, a customer should be able to successfully place an order.

Project steps

Let's begin with creating the admin account. The admin account will have access to functionalities such as accepting orders placed by customers, blacklisting/whitelisting users, creating staff accounts, and creating menus among other things. Since this account will have access to sensitive information, we cannot just create an endpoint for it. We need to create a script that will create this account by skipping the signup process.

We also need a way to differentiate the users of our app by their roles namely customer, admin, and staff.

Customer refers to a user who will download our app from the Google play store to place orders.

Admin refers to the owner or manager of Gourmet restaurant. He/she should be able to create menus of dishes, create and remove staff accounts, and manage orders.

Staff refers to an employee in the restaurant who will be created by the admin or manager. In case the manager is not there, the staff account should also be able to manage orders as the staff on duty.

Let's begin by creating the roles. We will need to modify a little bit the sign up process we created in the previous posts to make sure a user who signs up is identified as a customer by default.

Create a new branch called ft-place-order off our main branch.
Create a src/utils/roles.js file and paste the following code inside:

Update Valid signup should return 201 test case in test/authentication.js to check if a signed-up user is a customer like this:

Update Valid login should return 200 test case in test/authentication_login.js to check if a logged-in user is a customer like this:

Update src/database/models/User.js and add the role field like this:

Create a new migration to add the role field on the User model by running the following command in your terminal npx sequelize-cli migration:generate --name add-role-to-user
Update the newly created src/database/migrations/**-add-role-to-user.js file to look like this:

Update src/controllers/authentication.js to add the role of customer on sign up like this:

Now run your tests and they should all pass. If you were to inspect the user created in the database, you should see that the user has a role of customer. This means that every user who signs up will be given a role of customer automatically. Awesome!

Admin account

Let's now create our admin account starting with the tests.

Create a tests/authentication_admin.js file and paste the following inside:

In the test case above we are checking if given the correct admin credentials, the admin can login successfully.

At this point this test case should fail because we haven't yet created the admin account.

Let's now create a script that will create the admin account and make the test case above pass.

Create a src/database/scripts/adminScript.js file and paste the following code inside:

In the code above we created a function called createAdmin that will first hash our plain-text admin password then call the findOrCreate method on the User model. findOrCreate method as the name suggests will first try to find if a record exists in the database, if it is found it will return its instance, if it doesn't exist then it creates a new record. we used this method because we want to be running our script automatically after each production build. If we were to use the create method, it would create the record the first time but would throw an error the second time as we would be trying to create a record that already exists.

Lastly we call createAdmin function and export it so that when we will execute this file, it will call this createAdmin function. Cool!

Update .env file and add the ADMIN_PHONE and ADMIN_PASSWORD environment variables. Let's now create a command to run our script.
Update package.json and include the script to create the admin account in pretest and heroku-postbuild commands. This way our admin account will be created before running our tests and after the production build respectively.

Now run your tests again and they should all pass. Great!

Place order

At this point we need to start thinking about what kind of information we should show to customers and what information to expect when they place orders.

We are going to create 4 additional models namely: Menu, Item, Order, and Contents.

Menu will refer to a category such as Breakfast, Lunch, Dinner, Drinks, etc.

Item will refer to the actual dish or drink such as Cheese Burger, Coke Diet, Orange Juice, etc.

Order will refer to the orders placed by customers and will contain details such as the total amount, order status, user Id, etc.

Lastly, Contents will contain each item details for a specific order.

Regarding model relations or associations, we need to link Order model with User model by adding a foreign key of userId to the Order model. We also need to link Order model with Contents model by adding a foreign key of orderId to the Contents model. And lastly we need to link Menu model with Item model by adding a foreign key of MenuId to the Item model.

Great! Now that we have an idea of the structure of our new models and associations, let's start implementing the place order feature.

As always, we will begin by writing our tests.

Create a tests/orders.test.js file and paste the following code:

Update src/utils/messages.js and add the new messages:

Create a new model called Menu with the following command npx sequelize-cli model:generate --name Menu --attributes name:string
Create another model called Item with npx sequelize-cli model:generate --name Item --attributes name:string,description:string,cost:decimal,size:string,image:string
Create a new migration to add the menuId field to our Item model by running npx sequelize-cli migration:generate --name add-menuId-to-item
Update the newly created src/database/migrations/**-add-menuId-to-item.js migration to look like the following:

Update src/database/models/item.js to add the relation/association between Item and Menu:

Update src/database/models/menu.js to add the One-to-many association between Item and Menu:

Create another model called Order with npx sequelize-cli model:generate --name Order --attributes total:decimal,status:string,paymentId:string
Create another model called Contents with npx sequelize-cli model:generate --name Contents --attributes itemId:integer,itemName:string,cost:decimal,quantity:integer
Create a new migration to add the orderId field to our Contents model by running npx sequelize-cli migration:generate --name add-orderId-to-contents
Update the newly created src/database/migrations/**-add-orderId-to-contents.js migration to look like the following:

Create a new migration to add the userId field to our Order model by running npx sequelize-cli migration:generate --name add-userId-to-order
Update the newly created src/database/migrations/**-add-userId-to-order.js migration to look like the following:

Update src/database/models/order.js to add the association between Order and Contents and between Order and User:

Update src/database/models/user.js to add the one-to-many association between User and Order:

Let us now create our validations for place order.

Create a src/validations/orders.js file and paste the following inside:

Do not forget to export the createErrorMessages function from src/validations/authentication.js

Create a new src/middlewares/orders.js file and paste the following inside:

Before we create the controller and route for placing orders, let's think about how a customer will place an order.

In the Gourmet mobile app, the customer will be presented with a menu that has a list of items to choose from. When the customer taps on the add button, the item's id, name, cost, and quantity will be added to their cart. Subsequent addition of the same item will increase the item's quantity and cost. On checkout we will use the cart's items to calculate the total amount of the order and when the customer pays for the order, we will include the paymentId for reference.

The following image shows a sample of the request's body which will be send to the server when a customer places an order:

The order is for one double cheese burger and two diet cokes.

The items inside the contents array is what we will save in our Contents model. And if we remember, we defined an association that will ensure an item has an orderId. We need a way to add an orderId to each item in the order's contents.

Let us create a function that will take our contents array and an orderId then add that orderId to each item inside the contents array.

Update src/helpers/misc.js and add the parseOrderContents function:

Update src/services/services.js and add the saveManyRows function:

The bulkCreate method unlike create, allows us to create multiple records at the same time.

We are now ready to create the controller and use these functions we created above.

Create a new src/controllers/orders.js file and paste the following:

In the placeOrder method we destructure the request's body to reveal total, contents, and paymentId. Then, we create our order Object will will have the total, paymentId, a default status of pending, and the userId. The userId's value is handed to us by the authentication middleware function checkUserToken through req.userData.id. we then save our order record then use the returned record's id to add it to each item in the contents array by calling the parseOrderContents helper function. We then call saveManyRows function to save each item in the Contents model.

Let us now create the place order route and use the controller we just created.

Create a src/routes/ordersRoutes.js file and paste the following inside:

Update a src/routes/index.js file and add the orders router:

Now run your tests and they should all pass.

And if you check the records in Orders and Contents tables in the database, you should see that our data is saved.

Gourmet Menu

One way to create the menu of our restaurant would be to create admin endpoints for creating, viewing, updating, and deleting the menu but for the sake of keeping things simple we will not do that. Instead, we are going to create organized data of our menu that we will insert directly in the database (seeds). When we are done with this series you can implement the above endpoints for managing the menu as the admin on your own since we will have covered all the concepts to do it.

Cool, let us create our seeds.

We are going to create a seed for creating 3 menus, namely Breakfast, Lunch/Dinner, and Drinks. We are going to create another seed for creating items in each menu.

Run npx sequelize-cli seed:generate --name menus command in your project root
Update the newly created src/database/seeders/**-menus.js to look like this:

Run npx sequelize-cli seed:generate --name items command in your project root
Update the newly created src/database/seeders/**-items.js to look like this:

Now let us update the scripts section in package.json to create a command that we will use to create the seeds.

Update scripts in package.json to add the seed command and to include the seed command on the pretest command:

Now we can add our new environments variables ADMIN_PHONE and ADMIN_PASSWORD to Travis and Heroku environments then commit our changes to GitHub, open a PR and merge it as we have done before.

And that's it for today!

In the next post we are going to look at how to fetch the list of orders and how to fetch a specific order's details. We will do this from the perspective of both the admin and the customer.

Thank you for reading!

See you in the next one!

The code in this post can be found here

Online Food Ordering App (3)

Bertrand Masabo — Thu, 31 Dec 2020 13:43:09 +0000

Photo by abillion on Unsplash

Welcome back!

Today we are going to finish implementing authentication for the backend of our app "Gourmet".

In this post we will implement the login and logout endpoints.

Project steps

Login

Create a new branch ft-authentication-login off our main branch
Update src/utils/messages.js and add the following messages:

Create tests/authentication_login.test.js file and paste the following inside:

If you run the tests, all Login tests should fail because we haven't yet implemented this functionality. Let's do it.

Update src/helpers/misc.js like this:

The isPasswordValid function will help us in checking if the password submitted by the user equals to the user's password saved in the database by leveraging bcrypt's compare function.

Update src/validations/authentication.js and the login function like this:

Update src/middlewares/authentication.js like this:

The validateLogin middleware function will help us to validate the login credentials by using our login validation function.

The checkLogin middleware function will help us to check if the user trying to login exists in our database and if the password provided is valid.

Update src/controllers/authentication.js and add the login method like this:

Finally, update src/routes/authRoutes.js to create the login route and connect our middlewares and controller

Now run the tests again and you should see that all our Login tests are passing. Nice!

Logout

What we want to achieve when a user logs out is to make sure that their JWT token becomes unusable. Since JWT doesn't have a functionality to force a token to expire, we will have to implement a custom solution.

If you have noticed, we provided a expiresIn: '30d', option in our generateToken function. This option controls the lifespan of our token, in our case it's 30 days. This is fine but imagine if a user logs in then logs out right away, this would mean that their token would still be valid for 30 days and if an attacker was to get hold of this token, they would be able to impersonate the original user. Now imagine if a user logs in then logs out again and they do this 5 consecutive times. We now have to deal with 5 unknown but valid tokens. Now imagine 1000 users doing this everyday - It could get out of hand very quickly.

Even though there's nothing we can do to force a token to expire before its expiresIn property, we can introduce a way to manage these tokens, especially for users who have logged out of our system.

Our solution is to store a user's token in a database when they logout. This database will be separate from our main database and ideally it should be very fast to make the writing and retrieving of data fast.

Redis is an ideal candidate for such a task because of its high performance and very low latency. Learn more about Redis here and here.

Let's now implement the logout functionality.

Download and install Redis and test that it works well with the ping/pong command
In our project root, run yarn add redis to install the Redis Node.js client
Update src/utils/messages and add the following messages:

Create a tests/authentication_logout.js file put the following code inside:

Create a src/config/redisClient.js configuration file like this:

Update the .env file and a REDIS_URL variable with a default port like this: REDIS_URL=redis://@127.0.0.1:6379.

If you are using credentials to connect to your Redis server then your URL would be like this: REDIS_URL=redis://USERNAME:PASSWORD@HOST_NAME:PORT_NUMBER

Update src/middlewares/authentication.js and refactor checkUserToken to this:

Here we are using the smembers method of Redis to retrieve all the members/values in a set. This method takes a string key (token) and a callback which returns an error or an array of values found. Check out this link for a list of all the commands/methods.

We then check if our token is in the tokensArray and return an appropriate error. tokensArray contains tokens of logged out users that have not yet expired. So to make a user logout, we just have to store their token in this set of key token.

Let's now implement the controller where we will store the user's token in that set.

Update src/controllers/authentication.js to add the logout method

Notice how we use the sadd method to add our token in a set of key token. When you use the sadd method, it appends your value to the set if the set exists. If the set doesn't exist it will first create it.

Cool!

Let's now create our logout route.

Update src/routes/authRoutes.js like this:

Lastly, let's update our Travis config file to tell Travis to install Redis-server before running our tests.

Update .travis.yml and redis-server in services like this:

And that's it!

If you run the tests again, you should see that all our authentication tests are passing.

Now we can commit our changes to GitHub and create a PR which will trigger a build on Travis.

The last step is to provision a Redis database for our production env on heroku. The process is similar to how we added the Postgres database.

Open the Resources tab on heroku and type Heroku Redis in the Add-ons search bar then select it. If "Heroku Redis" doesn't show up click here to find it in the market place then click on the install button and confirm.

Note: You might be asked to add a credit card but make sure sure to select the Hobby-dev plan so that they don't charge you for usage. You can always upgrade to a paid plan after you have tested that everything is working well.

If the provision of Heroku Redis is successful, it will automatically add a REDIS_URL env variable.

Now you can head back to GitHub and merge our PR.

After Heroku has finished building, you can open POSTMAN and test our new endpoints and everything should be working well.

That's all for today, our Authentication endpoints are finished.

Note: There are a few things we can do to improve our API. For instance, you might have noticed that the tokens of logged out users saved in our Redis database will stay there even after 30 days (after they expire). Since there's no reason to keep storing an expired token, we can set up a CRON job that will run maybe every day at midnight or every end of week or end of month to delete these expired tokens. But this is out of scope for this series now. I might write a post on how to implement such a functionality at the end of this series.

In the next post, we are going to look at user roles, how to create an admin account, how to create a menu of dishes, ...etc. At the end of the post a customer will be able to place an order.

I want to thank you who is reading this post right now. If you have a question, comment, suggestion or any other feedback, please feel free to drop it in the comment box below.

See you in the next post! Happy New Year! 🎉

The code in this post can be found here

Online Food Ordering App (2)

Bertrand Masabo — Sun, 27 Dec 2020 17:02:41 +0000

Photo by abillion on Unsplash

Welcome back!

Today we are going to start implementing authentication for the backend of our app "Gourmet".

In this post we will implement the sign up and verify endpoints.

Project steps

2. Backend - Authentication

Sign up

For users to register on our app, we will require their first name, last name, phone number, address, and password. If the values provided are valid, we will send a OTP (One-Time-Password/Passcode) via SMS to their phone number which they can use to confirm their registration.

Following the TDD approach, we are first going to write our tests then we will implement validations, middlewares, routes, controllers and finally we will configure Sequelize to be able to save data in the database.

Before we begin, ensure you have installed and configured Postgres properly as it's the database we are going to be using. Check out this article on how to install it on Ubuntu.

Our signup task is going to be made up of 2 sub-tasks, one for signing up and another for confirming the user's registration. Let's begin with the first one.

Ensure you are on your main branch then run git pull origin main to make sure your local branch is up to date with the remote branch
Run git checkout -b ft-authentication to create a new branch for today's task

As we build our API there are things that we will need often and to avoid repeating ourselves it's good practice to structure our code for re-usability. That being said, create a new directory called utils inside src. Create two new files statusCodes.js and messages.js inside utils.

Open src/utils/statusCodes.js and paste the following inside:

These are all the HTTP status codes that our API is going to use.

Open src/utils/messages.js and paste the following inside:

This file will contain all the response messages that our API will be returning to the client apps on top of status codes and other data.

Now let's write our tests.

Create a file called authentication.test.js in tests directory and paste the following inside:

In this file, we import our express app along with our assertion libraries (chai and chai-http) and our status codes and messages we defined above. We then define a base URL for our authentication routes and we initialize chai to be able to test http apps. Learn more about chai here.

We then define a SIGN UP suite to hold our 5 test cases. In the first test case, we are testing for when a user submits an empty request (tries to signup without providing any data), what response he/she should get. Notice the use of one of our status code and messages we defined earlier.

In the second test case, we are testing for when a user submits an invalid phone number. Notice the missing + sign on the phone number. The phone number must be in a valid international format since we will use it to send the OTP.

In the third test case, we are testing for when a user submits any other value apart from the required ones (firstName, lastName, phoneNumber, address, and password). Notice the email property.

In the fourth test case, we are testing for when a user submits valid values conforming to validation rules that we will define next. In this case, we expect a successful response that contains a status code of 201, a account created message, a JWT token that the user can use to authenticate for subsequent requests, and a data object containing details of the user. Notice how we expect the user's account status to be false since he/she has not yet verified it. Finally, we retrieve the token in a variable called userToken that we will use in other test cases when verifying the user's account.

In the fifth test case, we are testing for when a user tries to signup more than once using the same phone number.

At this point if you run the tests they will fail apart from Server initialization test which is exactly what we want.

Next up is to write code to make our tests pass.

Create the following directories config, controllers, database, helpers, middlewares, routes, services, and validations inside src directory.
Create a new file called authentication.js inside validations directory and paste the following code inside:

We will use this file for authentication validation. In the code above, we start by importing a library called Joi and our response messages we defined in utils. Joi is a powerful data validator for Javascript and I personally like it because it is robust and easy to use. Check out its docs here.

We created a function createErrorMessages to help us in - you guessed it - create validation error messages. The function takes error type and empty, min, max, and pattern custom messages as parameters and depending on the type of the error we assign a custom message. This function returns an object of error types and their messages.

We use the second function signup to define a schema of values that we want users to submit when signing up. Notice the use of Regular Expressions to enforce validation rules. If you're familiar with RegEx, it's pretty straight forward as our use-case is not too complex.

Finally we call Joi's built-in method validate on our schema and pass in a data object i.e. req.body and some options to return all errors at once and to prevent other values not defined in our schema. Check out Joi API for more details and advanced use-cases.

In case of errors, our signup validation function will return an errors object containing a details property. This details property is an array containing all the error messages. We need a way to extract and use the contents of this details property.

Create a misc.js file inside helpers directory and paste the following code:

In this file we define 3 functions:

We will use successResponse and errorResponse to return success and error responses respectively.
returnErrorMessages checks to see if the parameter errors is present then destructure its details property. We then format each message in our details array to make it more readable and then we use errorResponse defined above to return the result of these formatted messages.

If errors is null it means our validations are passing and we continue with the execution of the request. Think of returnErrorMessages as a middleware.

Let's now use this returnErrorMessages function.

Create a file authentication.js in middlewares directory and paste the following code:

Notice the use of returnErrorMessages by giving it the error object returned by our signup validation function as a parameter.

Before we implement our controller, let's update src/helpers/misc.js with the following:

Notice the additional functions: generateToken, generateOTP, and generateHashedPassword.

We will use generateToken to generate a JWT token based on the data passed in. Update your .env file and include the JWT_SECRET_KEY like JWT_SECRET_KEY=somesecretkey.

We will use generateOTP to generate a random six digit code that we will send to a user.

Finally, generateHashedPassword will be used to take a plain-text password, encrypt it and return a hash string which we will store in our database. For security reasons, You should never store plain-text passwords in your database.

Okay, let's implement our controller.

Create a authentication.js file in controllers directory and paste the following:

Our controller is where a request that has passed all validations and middlewares will end its journey. This where we will implement saving data in the database and sending OTP to users before returning a response to the user.

Let's implement our routes to see how it looks so far.

Create two files authRoutes.js and index.js in routes directory.
Paste the following inside src/routes/authRoutes.js:

If you remember, in our tests we defined our base URL as /api/auth/. This means we will be able to define /api/auth/signup, /api/auth/login, and /api/auth/logout routes respectively.

Let's implement the parent /api/auth/ route handler.

Paste the following inside src/routes/index.js:

Our endpoint is almost complete. We just need to let our express app know about it.

Update src/server.js to look look like this:

Run your tests again. This time around, some of them are passing.

Great Job if you managed to reach here! 🎉

Let's now implement sending OTP. When we finish, we will setup Sequelize in order to persist data in the database.

Starting with OTP implementation, we are going to use Twilio. Click here to create a Twilio trial account. After creating your account you should be given some credit you can use to buy numbers and send SMS in trial mode.

Trial accounts have some limitations, namely you cannot send SMS to unverified numbers. So in order to test this functionality, there are 2 options.

Option 1
You can upgrade your account.

Option 2
You can verify numbers you intend to use. Just remember to upgrade your account before going into production to allow everyone to signup.

We are going to use option 2 for now.

Login to your Twilio account. Click on the # sign that says Phone numbers on the left panel. On the phone numbers page, click Buy number button and proceed to search for a number you want. Make sure to tick the SMS checkbox.
Click on Verified Caller IDs then click on the red plus button to add and verify a number. Make sure to provide a valid phone number that you have access to because Twilio will send a OTP to verify it.

Once done, head back to VS Code and add the following keys in your .env file.

Let's now install the Twilio library.

Open your terminal in your project's root dir and run yarn add twilio
Create a twilioConfig.js file in config directory and paste the following:

In this file we initialize a twilio client instance that we can use throughout our app to send SMS.

Let's now use this client in our code.

Update src/heplers/misc.js to look like the following:

The sendOTP function will take a phone number and a message and it will take care of sending our SMS. Let's now use this function in our controller.

Update src/controllers/authentication.js like this:

Now run your tests again and you should get a OTP delivered to the number you specified in TWILIO_CUSTOMER_NUMBER env variable.

Great! Let's now implement Sequelize and save data in our database.

Since we already installed all the required sequelize library and plugins, let's start using them.

In your terminal, navigate to src/database and run npx sequelize-cli init. This command will create the following directories and files: config/config.json, models, migrations, and seeders.

The models directory will contain our models. Think of models as tables in a database.

The migrations directory will contain migrations which are modifications made to our models. We use migrations to change the structure our 'tables'. We can do things like add/remove/rename columns, add/change constraints on columns, etc.

Note that each time we modify the structure of our models we need to run migrations for those changes to take effect. More on this later.

The seeders directory will contain data that we want to inject in the database. Use-case: Imagine you want to test the login functionality. since we have already implemented the signup tests and we know it works well, we can use the seeders to insert in the database valid records of users thus skipping the signup and verify tests which will make our tests run faster. We will use seeders later in this series.

The config.json file will contain credentials to connect to our database. We will need to modify this file and make it dynamic to avoid exposing our database credentials. Let's do it right away.

Rename src/database/config/config.json to src/database/config/config.js
Replace the contents inside with:

Update your .env file and add the keys for development and test like below:

Notice the different database names for development and test.

Note that for now we don't need to provide credentials for production in our .env file. The production credentials will be provided to us by heroku when we "provision" (setup) a production database.

Replace src/database/models/index.js with the following:

This file will allow us to import our models dynamically by doing something like: import models from '../database/models' then destructure models to retrieve each model in models directory. This file also creates and exports a sequelize instance that we will be using to interact with the database.

Cool! Let's now use Sequelize to create our first model - User.

In your terminal run npx sequelize-cli model:generate --name User --attributes firstName:string,lastName:string,phoneNumber:string,address:string

This command will create 2 new files: user.js (our user model) and **-create-user.js (our first migration) inside models and migrations directories respectively.

Update package.json to include commands to create and drop the database as well as run the migrations like:

Notice we didn't include the pretest command on the test command since our CI service does this automatically for each build.

If we were to run our migrations right now, our database would be created with just the 4 columns defined when creating our model above.

Let's update our model and add more columns and create a new migration to apply those changes.

Update src/database/models/user.js like below:

In your terminal run npx sequelize-cli migration:generate --name add-password-otp-and-status-to-user to create a new migration that will apply the new columns we added to our model.

Tip: As migrations can become many as our app scales, it's good practice to name each migration with what it does. By looking at the name of the new migration, we would know that it add password, otp, and status columns to user model.

Replace the contents of src/database/migrations/**-add-password-otp-and-status-to-user.js with the following:

Check out this link to learn more about creating models and migrations.

If we were to run our 2 migrations now, all the 7 columns would be added to our user table.

One of the things I like about Sequelize is its nice API that allows to interact with the database without writting SQL queries like "INSERT INTO tableName VALUES(....". Oh! This API allows also to write those queries in case you wish to use them. Nice, right!

We are almost done!

Create a services.js file inside services directory and paste the following:

We will be using this file to create functions that will use Sequelize API to CRUD the database.

saveData function receives a model name and obj as parameters then calls the Sequelize built-in method create on the model and returns the data saved in the database.

Similarly we use findByCondition function to find if a record exists in a table given a conditon. Check out this link to learn more about these built-in model methods.

As you might have guessed, we will use findByCondition to check if a user exists in the database and saveData to save the user.

Okay, let's update src/middlewares/authentication.js to look like the following:

We need to run this function after the validations and before the controller.

Update src/routes/authRoutes.js to look like:

Lastly, let's update our controller to use the saveData function we defined in our services. Update src/controllers/authentication.js to look like the following:

In the code above we added the saveData and lodash's omit and pick methods to choose which properties should be in the userData object returned in the response and token respectively.

That's it! Our signup endpoint is done!

Now if you run your tests, they should all pass! Nice, right!

In case you run into a timeout error, make sure to update your script's test command in package.json by adding a timeout flag like below:

This allows to extend the default Mocha's timeout of 2 seconds for each test case to 8 seconds which will give enough time to our asynchronous functions to finish executing.

Verify

After users have registered and we have sent the OTP, we need a way to verify their phone number thus confirming their account registration.

We are going to implement verify endpoints, the first one will be to check if the OTP submitted by the user is correct. The second will be to re-send the OTP to the user in case there has been an issue and the user didn't receive the first OTP.

Open tests/authentication.js and add the following:

In the code above, we have added test cases for the verify and verify/retry endpoints.

In SIGNUP test suite, update Valid signup should return 201 test case like this:

Open src/utils/messages.js and add the following messages:

Open src/validations/authentication.js and add the following:

Open src/middlewares/authentication.js and add the following:

The validateVerifyOTP middleware will help us to use verifyOTP function to validate the otp submitted by the user.
The checkUserToken middleware will help us to check if a request contains the Authorization header then will try to decode the token to check if the who made the request exists in our database then returns the user's data or an error. This is how we will be able to link users with their requests.
The checkOTP middleware will help us to check if the otp submitted by the user is the same as the one we sent to them via SMS.
- Open src/services/services.js and add the following:

Open src/controllers/authentication.js and add the following:

Open src/routes/authRoutes.js and add the following:

Now all our tests should be passing. Let's now update our travis config file and package.json file before we commit our changes to Github.

Update .travis.yml file to look like this:

We added the services option and before_script command which will tell Travis to create a postgres database called gourmet_test before running our tests.

Update package.json to include a heroku-postbuild command.

As the name suggests, this command will run after each build. You can use it to run scripts that you want to execute before your app is deployed. Here we are using it to run our migrations automatically.

The last step is to make sure our CI service and production environments are up to date.

Login on Travis then open our gourmet-api repo then click on settings to add environments variables. Make sure to add each env variable with its value.

Head back to VS Code and commit our changes to github. Open a PR on github and wait for Travis to finish building. Both the branch and PR should show a successful build.

Before we merge this PR, let's create a production database on heroku.

On your app page on heroku, click on Resources tab then in the Add-ons search field type postgres. Select Heroku Postgres and in the confirmation modal click Submit order form. You should see a confirmation that the add-on heroku-postgresql has been added. Check out the docs for more info.
Click on Heroku Postgres to open it in a new tab then click on Settings tab then click the View credentials button.

You should see the credentials of our database. When you provision a database on heroku like this, it adds the DATABASE_URL env variable automatically on your app.

Let's now add the database credentials as env variables. Alternatively, you could use the DATABASE_URL variable in the database/config/config.js and database/models/index.js files.

On your main app's settings tab, click on Reveal config vars button and add each credential key and its corresponding value from the database we've just created.
Don't forget our Twilio credentials and JWT_SECRET_KEY

Now it's time to merge our PR which will trigger a production build on heroku.

Head over to github and merge the PR we created earlier.

Travis should build our merge commit successfully then Heroku should build successfully as well then run our migrations.

Now you could copy the URL of your app from heroku and test the endpoints we implemented with POSTMAN or Insomnia and everything should go smoothly. Check out the links to their docs below.

Today's task was huge because we covered a lot of things. But we have laid the foundation for Sequelize, validations, and middlewares. The next endpoints are going to be fairly straightforward.

In the next post, we will implement the login and logout endpoints.

Tip: To test your API as you build it, you should use a tool like Postman or Insomnia.

They are both great at designing and testing APIs and you can even do things like creating and hosting your API documentation.

Check out the Postman docs and Insomnia docs to learn more.

Note: The endpoints we implemented in this post are a bit naive. For example, we are not checking if a user's account is verified before verifying it. We should also limit requests to the endpoints that uses external resources since the billing of these resources can become a lot. Check out this library to learn how to limit the number of requests. About the other issue of checking if a user's account is verified before verifying it, we can achieve this by using a simple middleware function.

Thanks for reading and or following along!

See you in the next one!

You can find the code in this post here

Online Food Ordering App (1)

Bertrand Masabo — Wed, 16 Dec 2020 18:56:20 +0000

Photo by abillion on Unsplash

Today we are going to build an online food ordering app called "Gourmet". The app will be made of a REST API as the back-end and 2 react apps as the front-end, namely a react Admin Panel and a customer facing react-native mobile app.

Throughout the project, we are going to use the TDD approach, ES6, and CI/CD among other things.

Features

The following are the requirements for our project, but you can expand it and add more features as you wish.

Authentication: a customer should be able to signup, login and logout
View menu and place order: a customer should be able to view the restaurant's menu, select the items she wants then place an order.
View orders and order details: a customer should be able to view the orders she has placed and their details.
Update order: the admin should be able to view all the orders placed, their details and should be able to update a specific order.

Project steps

1. Backend - Project Setup

2. Backend - Authentication

3. Backend - Place order

4. Backend - View orders list and view a specific order

5. Backend - Update order

6. Frontend - Authentication

7. Frontend - Place order, view orders list, and view order details

1. Backend - Project Setup

To kick things off, create a github repo, copy your repo's URL, open your terminal, navigate to a directory where you wish your project to reside then enter the following command git clone https://github.com/<YOUR_GITHUB_USERNAME>/<YOUR_REPO_NAME>.git.
Alternatively, you could use GitHub CLI or SSH if you want.

After the above steps, enter ls command and you should see the name of your repo. Enter cd YOUR_REPO_NAME to go into your project directory and we are good to go.

Prerequisites

Make sure you have Node.js v10+ installed before proceeding by running node -v.

Run git checkout -b chore-project-setup-init to create a new branch for our first task of project setup.
Run yarn init -y to initialize a new project. Alternatively, you could use npm init but I prefer yarn for it's easy to read CLI output, faster package installation speed, and offline mode among other things. Google yarn vs npm to find out the pros and cons one has over the other.
Open your project in VSCode by running code . in the root directory of your project.

Dependencies

Run yarn add express body-parser cors dotenv joi jsonwebtoken lodash make-runnable moment morgan pg pg-hstore sequelize sequelize-cli sequelize-test-helpers bcrypt to install the packages we are going to be using.
Run yarn add @babel/core @babel/node @babel/plugin-syntax-class-properties @babel/plugin-transform-runtime @babel/preset-env babel-eslint babel-plugin-istanbul to install babel and its plugins which will help to convert our ES6 Javascript code into backwards compatible versions for older browsers and environments.

Dev-dependencies

Run yarn add --dev eslint @babel/register chai chai-http coveralls cross-env mocha mocha-lcov-reporter nodemon nyc to install dev-dependencies which are packages used mainly in development and testing environments.

Configure ESLint

Run yarn run eslint --init to start ESLint configuration.
Select Node only

If you are asked to install additional ESLint dependencies, select yes and Enter. This last step should look like the image below.

In the root directory of your project, you should see a new config file called .eslintrc.json. Learn more about ESLint here

Note: In the root directory of our project, there's a new file called package-lock.json will was created by npm after installing the additional ESLint packages. We are now using 2 package managers (yarn and npm). This is not ideal.

Let's stick to one (i.e. yarn).

Delete package-lock.json file and node_modules directory
In the terminal, make sure you are in the root directory of your project and run yarn install to install all our dependencies afresh

Configure package.json

Open package.json file in VSCode and the following scripts key with start and dev command to start our server in production and development environments respectively

Let's create that server.js file. In your terminal run mkdir src && touch src/server.js. You should see an empty server.js file inside src dir.
Make sure to update your main entry file to server.js as well.

Configure server.js

Let's test if our server can start up. Add the following statement console.log('Server is up and running'); in server.js and save. At this point you should see a ESLint warning because of that console.log() statement.

In the terminal, navigate to the project's root dir and run yarn dev. You should see 'Server is up and running' being logged in the terminal. Change 'Server is up and running' in server.js to 'Server is up!' and save, the server should restart automatically to reflect your new changes. This is made possible by the nodemon package we specified in the dev script and it's going to allow us to focus on building our api without worrying about stopping and starting our server each time we make changes.

Create a .babelrc configuration file in your project's root dir and paste the following inside:

Don't forget to replace 14 with your version of Node.

At this point our server is not doing much. Let's change that.

In your terminal run Ctrl+C to stop the server.
Create a .env file in your project's root dir and inside put PORT=4000 and save. This will be the port number our server will use in development and local testing environments. When we go into CI or production, the port will be provided dynamically by the platform we will be using, hence the process.env.PORT instead of hardcoding the port value. This .env file will also allow us to keep track of all the sensitive keys, secrets, and passwords that should not be exposed to the public. Remember to keep this file outside of version control systems. Speaking of which, let's do it right away.
- Create a .gitignore file in your project's root dir and add the following inside:
- Notice node_modules/ and .env. Basically, everything we put in this file will not be committed to github. Check out this article to learn more.
Replace the console statement inside server.js with the following code and save:
Run yarn dev and you should see the server running with message Live at 4000
Open your browser and navigate to http://localhost:4000 and you should see the following response: {"error":"Route not found"} which is exactly what we expect since we haven't yet implemented our API routes.

If you reached this step, CONGRATULATIONS!🎉🎉🎉

Just 1 or 2 things remaining and then we deploy our API 🔥

Tests

So far we have managed to implement the substructure of our API. Next up we are going to write tests, setup Continuous Integration and Continuous Delivery (CI/CD).

I recommend deploying your app early on because it helps to detect and debug issues when your codebase is still small. Another advantage is that you can ship features that your users can start using without waiting for the entire app to be done.

Okay, let's do it.

In the project's root dir, create a new dir tests and inside tests create a file called server.js and paste the following code inside:
Update your scripts in package.json and add a dev-test command like:

This is the command we will use in development to run our tests which will produce a nice table in terminal showing test coverage. We need another command for our CI service.

Add the test command like below:
When our hosted CI service will finish running the above test command, it will create a coverage directory which contains the coverage results of our tests.
Check out this link to add Travis-ci to your github repo. There's a lot more you can do with Travis, make sure to check out their docs.
Create a .travis.yml configuration file in your project root directory and paste the following inside:
Time to commit our changes.
- Run git add .
- Run git commit -m "chore(project-setup-init):pre-deployment"
- Run git push origin chore-project-setup-init
Back on github, raise a PR and you should see your branch build successfully.

Deployment

We want our production build to be based off the master/main branch of our github repo. Basically, we will be creating new branches, build features, test locally, commit to github then test with Travis-CI, then merge to main branch which will trigger a new build of our production build. Yes, I said build of a build 😆.

Signup on Heroku and login
Create a new app, then switch to the deploy tab then scroll down to deployment method and select GitHub and you should see a Connect to GitHub option below
Select your github username and your github repo. Type the name of your repo and hit search if it doesn't show up then click connect
You should see that your app is now connected to github and a Automatic deploys option below
on Automatic deploys select main/master branch, tick Wait for CI to pass before deploy, then hit Enable Automatic deploys button and that's it.
Head back to your PR on github and merge it. Travis-CI should build our merge commit successfully which will then trigger our production build on heroku.
On heroku, the Activity tab should show a Build succeeded status.
Hit Open app button and we should see our {"error":"Route not found"} error message. This is good. it's a good error 😄.

Conclusion

Our API is now live 🔥.

In the next post we will focus on implementing authentication namely signup, login, and logout functionalities. We will cover the concepts of JWT token, Postgres, and Sequelize ORM among other things.

Thank you for reading, see you in the next one!

Demo Link

GitHub Repo