DEV Community: michaella latkovic

How to deploy a Rails API backend on Kubernetes with Amazon EKS and RDS

michaella latkovic — Tue, 14 Jan 2020 04:33:26 +0000

Recently I built a React Redux application with a Rails API backend called Root (you can see blog here). I thought it would be fun exercise to deploy my app on Kubernetes. I decided to use EKS to run Kubernetes on AWS as I've been wanting to learn more about AWS services as well.

1. Setup Pre-Requisites

Make sure to install the following:

The Amazon EKS docs have a good overview of installing the AWS CLI, eksctl, kubectl, and the AWS IAM authenticator.

2. Update database.yml

In the Rails API code, the database.yml file needs to be updated to allow for the environment variables we need to pass to connect to the production database. Running off of a centralized database is probably the biggest difference between running the app locally in development mode on my laptop and in production mode in the cloud.

production:
  <<: *default
  database: <%= ENV['DB_NAME'] %>
  username: <%= ENV['DB_USERNAME'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_URL'] %>
  port: 5432
~~~


### 3. Write the Dockerfile

To containerize the application, we need to create a Dockerfile in the root directory of the rails application. This defines how our container is built by the docker runtime.


DOCKERFILE for backend:

FROM ruby:2.6.1

Create a local folder for the app assets

RUN mkdir /backend
WORKDIR /backend

Install required tooling

RUN apt-get update && apt-get install -qq -y build-essential nodejs libpq-dev postgresql-client --fix-missing --no-install-recommends

Set our environment variables

ENV RAILS_ENV production #run the app in production mode
ENV RAILS_SERVE_STATIC_FILES true #serves static files (better performance)
ENV RAILS_LOG_TO_STDOUT true #ensures our rails logs will be exposed from the container (useful for debugging!)

Copy and install Gems from our Gemfile

COPY Gemfile /backend/Gemfile
COPY Gemfile.lock /backend/Gemfile.lock

RUN gem install bundler -v 2.0.2

RUN bundle install --deployment

COPY . ./

EXPOSE 3000

Start the puma server

CMD bundle exec puma -p 3000


Now, we'll use the Dockerfile to build a container image we can run on the Kubernetes cluster. Navigate to the root directory of the backend app and build the Dockerfile:

{% raw %}`docker image build -t backend:1.0 .`

**Note: the '.' at the end of that command means build in the current directory. A super helpful resource I used was: [Docker Deep Dive](https://www.amazon.com/Docker-Deep-Dive-Nigel-Poulton/dp/1521822808/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1578946525&sr=8-1)**


Lastly, you can run the container to see if the image build worked.

`docker container run -d --name backend -p 3000:3000 backend:1.0`

You can test it by running `docker ps`. You should see something like this:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ebbf78152a56 backend:1.0 "/bin/sh -c 'bundle …" 4 seconds ago Up 2 seconds 0.0.0.0:3000->3000/tcp backend


Note that this will expose the container on http://localhost:3000, but will not render any data as we have not connected the container to our database!

### 4. Push Docker images to cloud

In order to run our container on the Kubernetes cluster, we need it stored somewhere the cluster can access. I used [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) to host the container image, it was super simple to setup! 

1. Create the ECR repository (I called mine 'backend')
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/672my3onfgvzxazidpq1.png)


2. Push images to ECR. ECR gives you a really nice set of instructions on how to do this right from the console!
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/q1ndad24erkvdag4v7nz.png)

    a. Retrieve our ECR credentials:
    {% raw %}`$(aws ecr get-login --no-include-email --region us-west-2)`

    b. Tag the image for ECR
    `docker tag backend:1.0 <account ID>.dkr.ecr.us-west-2.amazonaws.com/backend:1.0`

    c. Push the image to ECR:
    `docker push <account ID>.dkr.ecr.us-west-2.amazonaws.com/backend:1.0`

3. See your image and get the URI. Once your image is pushed to ECR, you can see it in the console (or using the AWS CLI). You'll need to get the URI for the image in order to run it on your cluster.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/gbyalyotg6sulfeg8wek.png)

### 5. Create EKS cluster

It turns out there are a lot of ways to create an EKS cluster! I used eksctl as it was simple and easy. The [eksctl docs](https://eksctl.io/introduction/getting-started/) have a great overview of how to use eksctl to create a Kubernetes cluster on AWS.

To create my EKS cluster, I ran:
`eksctl create cluster --region us-west-2 --name root --managed`

This command creates an EKS cluster in Oregon named 'Root' (the name of my App) with an EKS managed node group.

The cluster takes a few minutes to create, when its done, you can see it in the AWS console:
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/vv73ltbxw4b2peyjcb9a.png)

You can also see that the cluster is running by seeing the running nodes with kubectl – `kubectl get nodes`

NAME STATUS ROLES AGE VERSION
ip-192-168-66-201.us-west-2.compute.internal Ready 25h v1.14.7-eks-1861c5



### 6. Create RDS Postgres instance

The biggest difference between running the app locally and in Kubernetes is that instead of a single instance of the app using a database running on my laptop, lots of copies of my app (potentially) need to share a single database.

I read a few examples of people running Postgres in Kubernetes, but since my goal was to run this on AWS, I wanted to use [Amazon Relational Database Service](https://aws.amazon.com/rds/) to set up my Postgres database in the cloud.

Again, using Amazon RDS was extremely easy to use. There are a lot of options, I selected 'free tier' as a pre-configured setup as I'm not going to be scaling this app beyond a few tests. In production, you can select much larger instances to host the database.

You can even have RDS create the database for you when you provision the instance. This lets you skip the {% raw %}`db:create` step when configuring the database later. I opted to have RDS create my database 'backend'.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/ub5thhynfr3mvlza38dv.png)

When creating the database, it's important to setup the username, password, and port correctly. I used the default username, had RDS auto-generate a secure password, and set the port to 5432 - which is the default postgres port and **the port I had configured way back in my database.yml file**!

Some additional things to remember when setting this up are to ensure you allow for network connections between the database and the Kubernetes cluster. It is important that you create the DB in the same VPC as your K8s cluster. This ensures easy connectivity with the running API server. I also added the [security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) used by the cluster to the database ensure that my API containers are not blocked from communicating with the RDS database.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/6lfqq9ifgdhikkkqaj4f.png)

Because we're not running a highly-available database, RDS lets you select which Availability Zone (AZ) to run your database instance in. I left this to 'none' which seems to mean "run anywhere". In production I would probably run this as highly-available (across multiple AZs) or select an AZ that matches the AZs where we run the backend API server containers/nodes to minimize cross-AZ traffic ($$).

### 7. Setup our database credentials

When we run our backend container, we need to securely pass the login credentials to our container as environment variables. We'll do this with a K8s secret. I used [this blog](https://www.engineyard.com/blog/kubernetes-tutorial-running-a-rails-app-in-kubernetes) as a guide to set up the secret.

#### Steps:

a. Encrypt your username and password for the RDS database using base64 encryption `echo -n "<username>" | base64` and `echo -n "<password>" | base64`. Keep track of the output!

b. Create a yaml file for the secret:

db-creds.yaml

  apiVersion: v1
  kind: Secret
  metadata:
    name: db-creds
  type: Opaque
  data:
    username: <base64 encoded username>
    password: <base64 encoded password>


c. Create the secret on the cluster: {% raw %}`kubectl create -f db-secret.yaml`


### 7. Create the K8s deployment

We're finally ready to run our app! To do this, we need to write a k8s deployment yaml file that specifies the container we want to run and passes all the correct environment variables for connecting to the RDS database. Note, when writing these files, _spaces matter_. I use atom to make sure everything lines up!

backend.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: backend # name of the deployment
labels: # these labels apply to the deployment
app: root
component: backend
spec:
strategy:
type: Recreate
template:
metadata:
labels: # these labels apply to our container
app: root
component: backend
spec:
containers:
- name: backend # name of our container
image: .dkr.ecr.us-west-2.amazonaws.com/backend:1.0 # the URI that we got from ECR
env:
- name: DB_URL
value: root..us-west-2.rds.amazonaws.com # URL of our database endpoint
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: db-creds
key: username # use the encoded username from the K8s secret db-creds
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-creds
key: password # use the encoded password from the K8s secret db-creds
- name: DB_NAME
value: backend # our DB is named backend
ports:
- containerPort: 3000 # expose the running contianer on port 3000
name: backend


Run this deployment with {% raw %}`kubectl create -f backend.yaml`. You should see:



```
$ kubectl create -f backend.yaml
deployment.extensions/backend created
```



You can check that the pods are running via `kubectl get pods`:



```
$ kubectl get pods
NAME                       READY   STATUS    RESTARTS   AGE
backend-68469b6dd4-8lcxl   1/1     Running   0          11m
```



You can describe the deployment and pods to get all sorts of interesting information - `kubectl describe pod/<pod ID>`

Remember way back in the Dockerfile when we set rails to log to STDOUT? Now this comes in handy because we can run `kubectl logs <pod ID>` to see the logs for our rails app. This can be very helpful in troubleshooting!

### 8. Configure the database

Now that our rails app is successfully running, we need to configure our database. You only have to do this once, the first time you set up the app. Future containers that run will automatically connect and find the configured database and data.

#### Steps
a. Exec (open a shell) into the running pod with `kubectl exec -it <pod ID> -- /bin/bash`. You're now executing commands inside of the running container!
b. Run `bundle exec rake db:migrate` to configure the database.
c. If you have seed data, you can add it to the database by running `bundle exec rake db:seed`

You'll see a ton of output as the database is setup by rails.
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/gp3bwlacok3vdxsojlwq.png)

### 9. Test your running API server!

We now have our backend rails API running on Kubernetes! You can test this out by setting up port forwarding to expose the deployment as a URL in our browser.


Run `kubectl port-forward deployment/backend 3000`. The 3000 means that the port forward will both listen and serve traffic on port 3000.



```
$ kubectl port-forward deployment/backend 3000
Forwarding from 127.0.0.1:3000 -> 3000
Forwarding from [::1]:3000 -> 3000
Handling connection for 3000
```



Visit the URL for our API in the browser: http://127.0.0.1:3000/api/v1/platforms

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/fdxz3919jfj9d4yu8p53.png)


Congratulations, the backend API is up and running!

### Next steps

The first half of my app is now running in a container on Kubernetes with an RDS Postgres database on AWS. In the second part of this blog, I will share how I containerizing my frontend and connected it to the backend. Stay tuned!

Root. A simple react redux application with bootstrap

michaella latkovic — Tue, 24 Dec 2019 19:35:23 +0000

I wrote a quick overview of the react redux app I built recently. I wanted to build an app I would actually find useful while also practicing building a React/Redux application.

I brainstormed any challenges I was having that could be aided with the help of a useful app. As I am constantly learning and taking online courses, I began to think about all the digital platforms I use.

Udemy, Coursera, Khan Academy, EdX, online textbooks... with so many wonderful resources online, it would be great to have one place you can go to manage and organize all your learning platforms!

I created Root. Root allows you to consolidate all your digital learning platforms into one application.

You can see all your courses for a single application.

Each course, also has the functionality to add to do items.

Backend - a rails api

I built the backend as a Rails API with a PostgreSQL database. I wanted to keep this app simple (at least to start) - I included 3 models as a basic framework.

Platform
Course
Todo

For serialization I used the active_model_serializer gem and intentionally nested everything into the platforms index page.

Frontend - react/redux/bootstrap

To organize the frontend architecture, I have 3 containers and 12 components.

The top-most component, the App component, is responsible for three main things.

It renders the NavigationBar and Jumbrotron components. It renders The Platforms container, which holds all other containers and components. It also renders a Layout component and holds the same layout for entire application.

      <NavigationBar/>

      <Jumbotron/>

      <Layout>

        <PlatformsContainer/>

      </Layout>

Overview: Containers + Components

App
Navigation (functional)
Jumbotron (functional)
Layout (functional)

Platform Container
Platforms (functional)
Platform (functional)
PlatformInput

Course Container
Courses (functional)
Course (functional)
CourseInput

ToDo Container
ToDos (functional)
ToDoInput

The redux store holds the platforms which will hold all courses and each course's todos as this is this way I designed my backend. This meant I could use only one single reducer, the platformsReducer which made it easier on the frontend to keep track of which platform courses and todos belong to as I always returned platforms.

(expanded - to show courses nested)

I built 4 actions fetchPlatforms, addPlatform, addCourse, and addTo.

Bootstrap

One thing that was important to me for this project was to really understand Bootstrap. For all my prior projects, I have done all by CSS by hand, which was great because I wanted to really understand how to do all the styling without help.

However, I am at place where I feel comfortable and can now upgrade to Bootstrap and save TIME!

Once I got the hang of importing the react-bootstrap components - the app really came together. The bootstrap docs are fantastic!

To see all this code in detail, feel free to visit the GitHub repos!

Root - backend repo

Root - frontend repo

Next Additions:

These are additions and functionalities that I'm currently working on adding:

*Add a user model.
*Ability to login/sign up for an account.
*Delete/Edit a platform/course/todo
*Check off a todo

Happy coding,
Michaella

big O - big picture

michaella latkovic — Mon, 28 Oct 2019 00:16:52 +0000

One of the wonderful things about coding is that there are usually a multitude of ways to solve any single problem. However, could there be a right or wrong way to code an algorithm as long as the result is giving you the desired output?

In reality, there are definitely better ways of solving problems.

So what does better really mean? Better means more efficient.

But given two algorithms, how do you measure better? A very simple approach could be measuring the seconds it takes to finish executing.

This approach presents with a problem - if I measure the time it take on my computer, and then let's say you run that same algorithm and measure the time on your computer, it will actually vary in time! Not only will different machines record different times, the same machine will record different times as well! This isn't a very reliable method of comparison - especially since for some very fast algorithms, speed may not be precise enough.

Instead of measuring seconds, we can measure the number of simple operations the computer has to perform.

How do we do that?

Big O is a way we can describe algorithms and compare them relatively.

The most simple explanation I've heard is this:

Big O allows us to talk about how the runtime of an algorithm grows as the inputs grow. In other words, we can compare the relative growth rates of different algorithms.

Common rates of increase are depicted in the graph below:

Examining this graph, we can see that the best rate of increase is no increase at all - O(1). Ha! Wonderful.

This isn't always practical so we can use this graph as a visual of how the other rates compare. Given O(n) and O(n²) for example - as the number of inputs increase, O(n) increases linearly while O(n²) increases quadratically! Yikes!

3 Helpful Rules to Remember

1. Constants don't matter, drop them.

O(5n) --> O(n)
O(15) --> O(1)
O(5n²) --> O(n²)

2. Smaller terms don't matter. Drop them.

O(n + 5) --> O(n)
O(10n + 25) --> O(n)
O(5n² + 3n + 2) --> O(n²)

3. Two loops is always better then a nested loop.

A good easy rule to follow when seeing a nested loop is to multiple by the number of nested loops to give you the Big O.

For the below example of a simple nested loop, the Big O would be n * n = O(n²)

While for two individual loops - Big O is O(n)

Happy Coding,
Michaella

Note: I've been using Big O in talking about time complexity - but there is also space complexity (how much memory we need in order to run an algorithm) which we can use Big O to compare as well. This is a different topic which I did not go into, but I highly encourage you to read about it as for the same algorithm, you can have different Big O's for time and space complexity!

Graph Image Source

Home Grown Books - building a Single Page Application

michaella latkovic — Fri, 25 Oct 2019 22:26:47 +0000

Home Grown Books is a Single Page Application (SPA) with a JavaScript frontend, a backend API built with Ruby and Rails, and a PostgreSQL database.

Starting this project, I wanted to keep it as simple as possible to give myself the focus to understand how all the pieces work together before jumping into a super complicated app! Users have the ability to add and delete books - as well as add reviews to books they have read.

The first thing I built was the backend - looking back, this was simple compared to what was coming in the frontend.

For the backend architecture - I only have two models - Book and Reviews.

Book has_many Reviews
Reviews belong_to Book

I created the necessary controller actions and serializers to display the json. I used the gem 'active_model_serializers' and added the associations between these two models so when I visited the index page on localhost:3000/books - you have all books and all associated reviews for each book.

For the frontend, I built App, Books, Book, and BooksAdapter classes to organize the Javascript code.

I built 4 AJAX calls covering 3 of the CRUD (CREATE, READ, UPDATE, DESTROY) actions summarized below:

CREATE
*Create a book
*Create a new review

READ
*List all Books

DELETE
*Delete a book

Reflections

Asynchronous JS + time
This project was a great learning experience - I went into this thinking it would only take a couple days.

It is a totally different experience when you are building projects from start to finish - I truly understand why EVERYONE says if you want to learn something, build something with it.

I definitely struggled getting some of my fetch requests working correctly and ended up going through code line by line investigating what is being console logged at each step. One thing I will definitely use more of on my next project are the devtools Chrome provides. I realied too heavily on just console.log when using breakpoints is so helpful!!

This guide was super useful if anyone needs a refresher!
https://developers.google.com/web/tools/chrome-devtools/javascript/

I can't believe I forgot about these...

CSS
For the previous projects that I've built, I was a little intimidated by CSS. Since the focus of the projects wasn't on the frontend, I always used templates that I could tweak CSS slightly and it usually turned out OK.

This time around, I wanted to build from scratch to really get comfortable with CSS and how it interacts with JS.

I knew I wanted a grid layout of all the books so I naively started building out divs and trying to get all the sizing to match up - this was not ideal. I learned from a fellow coder about the magic of flexbox.

I researched the difference between CSS flexbox and CSS grid (flexbox is made for one dimensional layouts whereas grid is made for two dimensional layouts) and decided flexbox would suffice for my app needs.

It took time, but it was definitely worth it! It can be easy to be overwhelmed with all the different properties you can assign - but it's actually kind of fun - and the best way to learn is simply testing it all out.

Git commits - continued

In the last blog that I wrote, I reflected on the importance of committing frequently and my troubles with not doing so initially. This time around, I am happy to report that I was much more thoughtful on the frequency and the thoughtfulness of the messages of my commits. Although, not yet perfected, and knowing this is still something to keep improving on with each project that I build - I wanted to end on a good note - because even if we are always learning and improving - we need to celebrate our small wins.

Happy Coding,
Michaella

Social Grads - my first Rails App.

michaella latkovic — Fri, 02 Aug 2019 02:05:17 +0000

The end is here! Well... at least the end of the Rails section of the Learn.co Software Engineering curriculum.

For the project, I created a web application called Social Grads - a social tool for graduate school submissions. This app was inspired by the forum section of The Student Doctor Network - if you have never been to this site, it's AMAZING.

When I was applying to grad school myself, I spent MANY hours reading anything and everything I could on this site. Two of my favorite (and super popular) forums are "The All-Encompassing, "What are my chances" thread!" and "Applied, Interviewed, Rejected, Attending" - the latter is truly what inspired me to create Social Grads. I know the pain of scrolling down to read every last post hoping to find any information on who is applying to what school, what their background is, and most importantly, did they get in?

Social Grads takes this forum and creates a tool where users can create an account and add their information to a user profile. Users can sign up for a new account or login via GutHub.

Once logged in, they can add submissions for each program they are applying to as show below:

Not only is this an easy way to keep track of all the programs you are applying to, you can also easily search the site for other users - look at their profiles, see the submissions they have created and even look at college profiles with a summary of all the submissions by the Social Grads community who have active submissions at that school.

Reflections

User experience & urls

I added my nested routes after I had already done a fair amount of work on the rest of my app and view pages. When I was reviewing my application I noticed that while my app was redirecting to the correct views, my urls didn't always follow a consistent path that would make sense to a user as they are navigating the application. Essentially, the application was functioning correctly but would likely cause confusion once deployed in the real world. This exercise highlighted that it is critical to not get lost in thinking about our applications from the developers point of view - but to always remember to think about the design from the user's perspective.

Focus on MVP

A challenge I saw myself falling into was getting overwhelmed with all the features I could add or wanted to add. I would spend time thinking through everything to realize a few hours passed and I hadn't added a single feature. I learned that it is better to hit that MVP to meet the requirements of the project even if there is a lot more potential. To keep momentum through this journey, I need to focus myself and know that I can always continue to build on this project later as well. This is something I will have to remember when it's time to build the final project for this program.

Commit F.R.E.Q.U.E.N.T.L.Y

One of the biggest lessons this project has taught me is to be more thoughtful and frequent with my commits. I used to commit features as a package (login, logout, new, edit etc...)

This method worked for a while - it was neat and clean. If I wanted to see all code that went with adding a feature, I had it all in that single commit. However, this is not the best use case for commits.

Two-thirds into this project, my master branch and my local directory somehow didn't align. I still had code that hadn't been pushed up because I was waiting to finish a feature. After much debugging (git stash, git pull, git rebase....) with the help of my instructors, the only thing that worked was:

git add .
git commit -m 'Please work.'
push --force

I forced all my code in one commit - luckily, this fixed my merge conflict but I lost some code.

Lesson learned. Commit frequently, even if it is a single addition of a link to a view page. You will thank yourself later!

Happy Coding,
Michaella

Sinatra Project: Fresh Bites

michaella latkovic — Wed, 19 Jun 2019 01:29:53 +0000

For the final assessment in the Sinatra section of the Learn.co Software Engineering curriculum— the task was to create a CRUD, MVC app using Sinatra.

I created a simple demo web application called Fresh Bites to practice using all the skills and tools I’ve learned so far. What is Fresh Bites you may ask?

Fresh Bites allows users to create an account to manage recipes for their furry best friends. Basically, I just wanted an excuse to use dog stock photos.

If you are looking to create a simple web app fast — here are the steps I took to get from concept to functional application.

Step 1 : Model Relationships

There were some benchmark specifications that were required as follows:

Include more than one model class
Include at least one has_many relationship on your User model
Include at least one belongs_to relationship on another model

I found it to helpful to draw out my relationships first — before even opening up my terminal to start building anything.

I knew I wanted a User model and Recipe Model to start with. I decided it would be a nice addition to add a Category Model which meant I needed to add a fourth and final Recipe_category Model as shown below:

Step 2: Corneal Template

I used the Corneal Ruby gem to lay out my basic app structure. Not only did this save time, it was pretty comprehensive as well! I definitely recommend trying it out!

Step 3: Database Migrations

With the help of ActiveRecord, I created database migrations for each of my models…I did relaize I forgot to add a user_id column to my recipes table which added one last migration. Luckily, using a few gems (activerecord, sinatra-activerecord, and rake), it is super easy to do all of this. To learn more about how these gems work to set up ActiveRecord to add a database to Sinatra applications — check out this post which I found super helpful.

Snapshot of final set of database migrations

Step 4: Model — View — Controller (MVC)

With the basic template already created with the Corneal gem — I went deeper with the MVC architectural pattern:

Snapshot of final MVC file structure

Creating my Models

Having already drawn out my model relationships, this was a a pretty simple task. I created my four models (User, Recipe, Category, and Recipe_category) all inheriting from Active Record. If you want to learn more about the details of how to do this — and quite frankly all that comes after — I highly recommend this guide.

It’s awesome, I advise to stop reading this and just go there 😊

Creating my Views

User — signup, login, index, and show view pages.
Recipe — index, show, new, and edit view pages.
Categories — only needed an index and show views.

In addition, I created a welcome and a logout view page.

FYI: The layout.erb file holds all of my styling to keep a consistent feel for all my pages. I used the yield statement in the layout.erb file where I wanted other view page content to be loaded.

Creating my Controllers

This is where we build out CRUD (Create, Read, Update, Delete) functionality.

I’ve summarized what controller actions I included in my application. I used this post as my guide for how to implement RESTful routes. If you are interested in the code, I’ve added a link to the GitHub repo at the end of this blog!

application_controller

route to my welcome page & a few helper methods

users_controller

index action (display all users) and show action (display a single user)
get request to display signup page and post request create a new user account
get request to display login page and post request to log into an existing account
get request to logout

recipes_controller

index action (display all recipes) and show action (display a single recipe)
new action to display new recipe form and create action to create a new recipe
edit action to display an edit recipe form and update action to update the recipe
delete action to delete a recipe

categories_controller

index action (display all categories) and show action (display a single category)

I listed the above in order of “MVC”, however, I prefer to write out Models, Controllers, then Views… or even more realistically Models, then alternate between Controllers and Views — as you create RESTful routes in the controller, creating corresponding views (erb files) and then testing it out to make sure it works.

There is a lot more that went into programming (debugging really) all the functionality and front-end design of the application but these are the steps I took in the beginning to at least get to a point where I have an application that was running!

If you are interested in the looking at the complete code — feel free to checkout the GitHub repo!