Coffee Jukebox

The 3rd screen UI was done by my teammate Mayank Padhi and the details can be found in his blogpost . The admin, after logging in, should be able to access two things: The feedback by the customers. The song requests by the customers. So, a different user is created within the Hasura project and selection and deletion rights have been assigned to the tables "songrequests" and "complaints" tables. So after the login, the page is loaded by two menu's, one beside the other populated by the queries made in the background. Each complaint and song request is along with a button to delete it too, since if the issue is resolved, it is no longer required by the owner. The first view of the admin console Deleting a complaint Deleting a Song Request Along with these screens, we have also developed a "player" for our app that actually interacts with the database and plays the songs in the queue and if the queue is empty, it plays a ra...

The 2nd screen UI and authentication was dealt by my teammate Mayank Padhi and the details can be found in his blogpost . The backend part of the second screen is similar to the first page. The request is made to retrieve the song details from the database with the necessary authentication and the response is passed through template and the Song list is populated. Something like this: The 2nd screen of the Webapp However, unlike the first page's accordion bar, this accordion has an extra button (Add): Expanding an accordion in songlist page This helps in users to add their choice of song easily. Clicking on the add button adds the song to queue. Also to prevent adding same song in queue twice, an alert is shown if the song is added to queue or if the song is already in queue. This is done by checking if the song is already in queue first by a simple count query before the actual insert request. If the count is 0, the song is inserted else an alert is displayed that it is...

The 1st screen app's UI and authentication part was dealt by my teammate Mayank Padhi and the details can be found in his blogpost . After the sample UI design, it is time to get real and get the real data from the database and use that to populate our first page( the songs queue page). So, as soon as the authentication takes place, another request is sent to get the songs list in queue via the data endpoint of our project. The response data of each song is then sent passed through a template creating function that fills all the details of songs at the right places and an accordion tab is ready. Similar process occurs with the rest of the data and then the HTML is then populated with our queue list, something like this: First look of our Home Screen Now, if you click on any of the song tabs, you will get the song details of that particular song. Like this: Song details on clicking a tab The "Get the List" button would take you to the app's 2nd screen. the s...

After the data modelling , we needed to test our database for some Authentication requests to the Hasura auth endpoint. The registeration can be done by going to the /signup endpoint and login with the appropriate details can be done by going to the /login endpoint. The sample requests are as follows: Sign Up request to auth endpoint using username, password parameters Login request to auth endpoint using username, password parameters The link to the collection of authentication requests using Postman is here .

The previous blog covered the data modelling of our app. Now it is the time to test the working of our database using some sample queries to the data endpoint of the database. Some of the sample queries made through Postman are: Insert to Song Queue Select all songs in the song database Select all songs in the songs queue The link to the API query collection is here .

After the app idea  and wireframing of app , the next task is the Data Modelling for the app. You need to have a clear idea of what data you are going to need and how to reduce redundancy of data in your tables. In our case, we developed the database schema using Dia , a free software for designing schema using simple tools. The final database schema is as follows: Database schema for Coffee-Jukebox The musicdb is the main table that contains all the song details in the shop's database. The table songsqueue has m_id as the foreign key to musicdb's m_id so that only songs in the database can be added to the songs queue. Also, since we limit one song queue per user, the userdevice acts as primary key to songsqueue table. To maintain the queue order, the timestamp addtime has been added as a column to this table. The tables also have been developed in the hasura development environment.

The Hasura Local Development setup's latest instructions are available here . The latest instructions have been simplified. The instructions below had helped me set the local development on Windows earlier: Open Command Prompt. Type minikube start. The first time you type in this command, the minikube ISO will download. After the download and install inside VirtualBox, you get a message saying that kubectl is now configured to use the cluster. Something like this: Fig 1. First time starting minikube Type minikube ip to get your local cluster's ip address. This will help you in accessing the kubernetes cluster via Windows. Go to  https://beta.hasura.io/settings  to get your API token and open your Command Prompt and type  curl -H 'Authorization: Bearer <API_TOKEN>' -d '{\"ipaddr\": "\MINIKUBE_IP\"}' https://cloud.beta.hasura.io/v1/localdev , where <API_TOKEN> is replaced by the token you got earlier and MINIKUBE_IP is ...