DEV Community: Alex McKean

Designing a Relational Database for a Cookbook

Alex McKean — Tue, 02 Jul 2019 14:48:09 +0000

When I'm not programming I'm cooking. I love looking through cookbooks and finding new and interesting recipes. Having browsed through my fair share of books I started to notice a pattern in the types of recipe attributes displayed. I thought it might be a good exercise to design a relational database based on cookbook recipes.

Background

So what makes up a relational database? Relations! In a relational database everything is connected. With all things being connected we could just create one large table with hundreds of attributes types, but we don't. Why is that? Data Integrity! Data integrity is the overall completeness, accuracy and consistency of our data. In order for our database to have Data integrity it needs to have these three features.

No Repeating Values
No Incorrect Values
No Broken Relationships between tables

So how can we achieve that? We do so by breaking up the data into multiple, manageable, and unique tables. We then connect these tables through relations. When it comes to relations there are only three types we can use (really two, but we'll get to that). These types are:

One to One - (ex: One person has one Passport and one Passport has one Person)
One to Many (ex: One Person can have many credit cards but many credit cards can only have one person)
Many to Many (ex: Many classes have many students while many students have many classes)

That last one seemed hard to read and understand right? It is. Plus it doesn't work. The reason it doesn't work has to do with a concept called Parent-Child relationships. Lets look at the "one-to-many" example and try to figure out who is the parent and who is the child. Out of the Person and the Credit card which can't exist without the other? The credit card! There are no magical limitless credit cards floating around that aren't assigned to someone. So, in this scenario, the parent is the person and the card is the child. Now lets look at the "many-to-many" relationship. Whose the parent and child there? On one case a student can't be a student without attending a class. On the other case is a class really a class without students? Here lies why many-to-many relationships don't work. We have no clear parent.

We solve this problem by breaking up the "many-to-many" relationship into two "one-to-many" relationships. This way we have a clear parent and child. So if we were to model the students and classes tables we'd have something like this.

Where the "Student-Classes" table would be a child to both the student table and the class table.

DB Design

Okay, so armed with this knowledge let's build out a database for cookbook recipes! Let's take a look at a recipe and pull out the relevant information.



Recipe Title: Simple Cheese Pizza
Recipe Description: A great pizza that's really easy to make. 
Recipe Ingredients:
2.5 cups All Purpose Flour
1 Packet Yeast 
1.5 teaspoons Sugar
0.75 teaspoons salt
2 tablespoons Olive Oil
0.75 cups warm water
1.25 cups cheese
1 cup tomato sauce

This seems like enough information for us to start with. Looking at the recipe above what data is truly dependent on a single recipe? I would argue the "Recipe Title" and the "Recipe Description", so let's put that into a table.

Okay so now let's look at the ingredients section. First, we know that a recipe has many ingredients, but also an ingredient has many recipes. I can use 2.5 cups of flour in another recipe, so there is no need to repeat that value again in my database. We can also argue that I can use 2.5 cups of some other ingredient in my database, like 2.5 cups of brown sugar. So is there a need to continuously repeat 2.5 cups in a database? I'd argue not.

Let's work with an individual ingredient and expand that to all ingredients for a recipe. When looking at an ingredient we notice some key features, we have: measurement quantity, measurement unit, and ingredient. Below show this with "1 cup tomato sauce".



1 = measurement qty
cup = measurement unit
tomato sauce = ingredient

We could then create three tables based on these three features.

Okay, so we have all our information represented, but how do we connect that recipe table with the three ingredient tables. We use a join table!

What does this database allow us to do? Well, let's take a look at two pizza recipes.



Recipe Title: Simple Cheese Pizza
Recipe Description: A great pizza that's really easy to make. 
Recipe Ingredients:
2.5 cups All Purpose Flour
1 Packet Walmart Yeast 
1.5 teaspoons Sugar
0.75 teaspoons salt
2 tablespoons Olive Oil
0.75 cups warm water
1.25 cups cheese
1 cup tomato sauce


Recipe Title: Simple Cheese Pizza with Pepperoni
Recipe Description: A great pizza with pepperoni that really easy to make. 
Recipe Ingredients:
2.5 cups All Purpose Flour
1 Packet Walmart Yeast 
1.5 teaspoons Sugar
0.75 teaspoons salt
2 tablespoons Olive Oil
0.75 cups warm water
1.25 cups cheese
1 cup tomato sauce
1 bag pepperoni

We know that our recipe title and recipe description are different hence we need to store both those values, but look at the ingredients. Nothing really changes except for the "1 bag pepperoni" at the end. Do we really need to duplicate all those values? Well what would happen if we did? Let's look at "1 Packet Walmart Yeast". If Walmart went out of business odds are Walmart Yeast would cease to exist. So we'd have to find a substitute for that yeast and then change not one, but two records. That doesn't seem that hard, but now imagine that we had 10,000 recipes using Walmart Yeast. That's a lot of changing. With the above database we'd only have to change one table value instead of 10,000! Thank you relations!

Conclusion

There is no single right answer to database design, but there are a lot of wrong answers. Database design is equal parts art and science. It requires having a deep understanding of the relationships between all the data you are trying to connect. I have found when I don't focus enough time on proper database design my apps become inflexible and inefficient. At the beginning the concept was tricky for me to grasp, especially modeling many-to-many relationships. I'm curious on your thoughts on database design and if its worth spending a large amount of time on. Let me know!

Building a FullStack App in a Month. Here are some lessons I learned.

Alex McKean — Wed, 19 Jun 2019 19:14:53 +0000

Over the past month I really challenged my self to take an idea in my head and build out a product. I wanted to build something that not only could be shown off to potential employers, but something I could eventually use. The app is a cookbook where a user can: search for recipes, add searched recipes to a menu, then generate a shopping list based on those recipes. To build this app the main tools I used were React, Redux, Rails, and PostgreSQL. I learned a lot going through this process, but there are three main lessons that stood out.

Don’t be afraid to Break Things

You will crash your app. When this happens don’t panic, take the time and work through the problem. Some problems will take an hour to solve, some will take weeks. Don’t let the fear of tackling a problem for a week stop you from implementing something new. Initially, I let this happen. I took out features from my app because they lacked a clear defined path for implementation. My app was losing the core things that made it cool because I didn’t know how to build them. When you strip away all the features that make your app cool what you're left with is a glorified todo list, and no one wants to spend a month building that.

There's no harm in making a new branch and experimenting/testing some ideas. I learned more trying and breaking things than I ever did on set lesson plans. Worst case scenario switch back over to your stable branch with no harm done.

Read Up on the Libraries Your Implementing into Your App

Whenever you are implementing an external library in your app, read up on it. I spent many hours trying to solve problems that could have been fixed with a quick glance at a repo’s issues page. Quality of an external library’s docs was a big factor, for me, on whether I'd use it or not. This was my process in researching certain libraries.

Read the official documentation for the library
Check out the repos Issues
Look up questions related to the library on stack overflow
Read articles about the library

Initially, I felt this process was excessive. It felt I was wasting time reading instead of actually trying to implement with code. What I found was that I had a better understanding of the library, and when it came time to actually use the library I knew potential problems that could arise and where to look to solve them.

Design, Design, Design!!!

Please, if there is one thing to take away from this post it is this, spend time designing. My design process was: sketch out what the app would look like, then jump into code. I suffered. Without proper design you can really lose control of your apps. Here are some problems I had that were attributed to poor design.

Duplicate components
Too many class based components the could have been functional
Unnecessary CSS
Duplicate code
A lot of unnecessary local state
A way too complicated file tree

As of today my app is functioning and works, but maintaining it would definitely be difficult. For me, I think a good exercise would be a rewrite with an emphasis on design and maintainability using tools like esLint and standards like airBNB style guide.

Final Thoughts

Overall, I really enjoyed the process. It really is satisfying taking an idea in your head and transforming it into a product. Even more satisfying were the lessons I learned along the way. If you have any questions or want to share things you've learned feel free to reach out!

User Authentication for a Rails API using Knock

Alex McKean — Tue, 11 Jun 2019 17:28:24 +0000

The goal of this post is to set up user authentication using a JSON web token (JWT) for a Rails API.

Normally, when I am working with rails I use a session based authentication. This means I let my server side do all the heavy lifting. With token based authentication I'm not gonna store anything on the server, but I will create a unique encoded token that will be needed anytime I'm accessing the backend. This token will be placed in the header of my requests (as a credential) and be used anytime I need to authenticate a user. To begin there are really two routes I can take. I can build my own token based authentication solution in rails (reinventing wheels), or I can see what open source solutions are available. We're gonna see what's available.

A quick Google search of "rails api JWT authentication gem" should lead us to Knock.

nsarno / knock

Seamless JWT authentication for Rails API

knock

Seamless JWT authentication for Rails API

Description

Knock is an authentication solution for Rails API-only application based on JSON Web Tokens.

Why should I use this?

It's lightweight.
It's tailored for Rails API-only application.
It's stateless.
It works out of the box with services like Auth0

Is this being maintained?

~~Yes~~ No Yes!

Currently being maintained with the help of @andrerpbts ❤️

Slowly moving through the backlog of issues & PRs and starting to build a roadmap for the next version.

Getting Started

Installation

Add this line to your application's Gemfile:

gem 'knock'

Then execute:

$ bundle install

Requirements

Knock makes one assumption about your user model:

It must have an authenticate method, similar to the one added by has_secure_password.

class User < ActiveRecord::Base
  has_secure_password
end

Using has_secure_password is recommended, but you don't have to as long as your user model implements an authenticate instance…

View on GitHub

Knock was built solely to provide an authentication solution for Rails APIs using JWTs, exactly what we want. Knock has a very good Readme so to begin we're just gonna follow that.

First thing we're gonna do is add the necessary gems to our gemfile. These gems are...

gem 'knock' # Authentication Solution
gem 'bcrypt', '~> 3.1.7' # To hash our passwords
gem 'active_model_serializers' #Used to serialize our data (Note: As of this writing AMS is undergoing large development changes, if looking for another solution I'd recommend fast_jsonapi)
gem 'jwt' #Ruby implementation of RFC 7519 OAuth JWT standard
gem 'rack-cors' #this is a necessary for communication with our client

Next lets run bundle install. Now we are ready to start implementing Knock. First thing we are going to do is create a knock initializer, this will contain all the information about our configuration options in relation to knock.

$ rails generate knock:install

The initializer file will look as so in its simplest form...

Note: When generating this initializer we are given a bunch of configuration options. These options are a good idea to implement, but for the sake of this post we are gonna keep it simple.

Next thing we need to do is implement a Token Controller. This will provide a way for our users to sign in.

$ rails generate knock:token_controller user

After generating this controller we will also need to add a login route to our routes file. This would be a good time to talk about namespacing. A really good way to keep your code clean and organized is to name space it. For this project we are gonna prepend all of our routes with /api/. To accomplish this, we want to use namespace :api in our routes file as well as nest all of our controllers under an api folder. The route file at this point is shown below.

While our user token controller at controllers/api/user_token_controller.rb will look like this.

Note: For this project we are using Rails 5.2 we need to include the skip_before_action :verify_authenticity_token. If we do not include that in the UserTokenController we will get a 422 response from our server when we try to log in. I found this out looking at the issues on github. It is always a good idea to look at those before implementing.

Now the next steps are to implement the model, controller, serializer, and accompanying migration for a user. To do this I used a scaffold generator.

For this application our user will have the following data...

The model looks as follows.

What we have above are validations for the presence of all parameters, as well as a unique email, and a password of minimum length of 7. We also have the method has_secure_password. This is critical for knock to work. According to the documentation Knock makes one assumption about our user model. It must have an authenticate method, similar to has_secure_password. We are able to call this method due to our bcrypt gem. It is recommended to just use has_secure_password, but we don't have to as long as our user model implements an authenticate method with the same behavior.

We also need user routes in our route file. For now, we will have all the user routes available to us. Our routes file will now look like this.

Next we need to work on the controller. Since we used a scaffold generator a lot of our method are created. We will, however, need to make two methods. The methods are

find #A method that we will use to find a user based on an email
set_user #A method that will set the user.

These methods are shown below.

We will also need to add a find_user route to our routes file.

By this point we should have what we need to log in a user. So let's create a user and use Postman to log them in.

In my seeds file

Then in postman...

Headers

Body

And what we will get back will be our token.

What we would then do is place that token in the header of our request as a credential, and every time we want to access a resource the controller in charge of that resource would authenticate the user. An example of this is shown below in a controller for one of my projects.

What I hope to do next is take the inputs we did in postman and replicate that in React. I plan on writing that post up soon! Thanks for reading and if you have any questions please let me know!