🗓️ Today’s Topics

• Models for your collaborative project
• Designing the urls you need
• Review permissions & CORS

🎯 Project

Today you should have your models nailed down and be able to work with them in the admin and the shell – that is, you can save them to the database and retrieve them, and all the relationships work properly.

You should have a WRITTEN DOWN plan for at least the basic set of urls that your front-end will need. You may make changes to this as you go but you need a place to begin.

When creating your list of endpoints, remember: only build what you need.

• What lists or collections of data will you need to return?
• What single resources will you need to return?
• What HTTP methods will you need to support for your urls?
• Which routes will need to be authenticated and which do not require authentication?
• Will you need to restrict any actions at the object level?

By Friday

Your API should…

• be returning JSON for GET requests for questions and answers / cards and friends
• be able to accept POST requests to create questions and answers / cards and friends

🔖 Resources

• A Long (Mostly Helpful) List of Things to Keep In Mind When You’re Building an API -> Many of these best practices you get for free with DRF; some are included with packages we use; and some of this is advice for the choices you have to make in the code you write.
• Overview of creating an API -> Nothing much new in this article, but it is a good summary and high-level overview of how to go about creating an API with DRF.
• How to Save Extra Data to a DRF Serializer -> This is essential for adding in extra info that is not included in your serializer, like the user (from request.user) that is associated with the object you want to create.

Permissions

• DRF Permissions
• Built-in Permission Classes in DRF
• Custom Permissions in DRF
• Pro-Tip: Logical operators with DRF Permissions

CORS

• MDN CORS
  • MDN Access-Control-Allow-Origin Header
• Julia Evans comic explaining CORS better than MDN does
• Another great visual explanation of CORS
• Django CORS Guide
• django-cors-headers

Databases: Deeper Dive into the Theory Behind the Best Practices

• An Introduction to Database Normalization
• Video on the first normal form
• Video on the second normal form
• Video on the third normal form

👾 Code

• Example Library API

🎯 Collaborative Project

This week you will begin work on a project with both front- and back-end teammates. This project is due next week at the end of the Phase.

The front-end will build a React application that will make AJAX requests to the back-end application built with Django and Django REST Framework. There are no strict rules about who works on front-end or back-end, so your team can decide how best to use your resources.

Your team can choose between two projects. They will both give you practice doing what you have been doing (building an API or building a React application based around CRUD functionality) but they present some different problems to solve.

Choose the one that sounds more fun or interesting to you.

Options

Social ECards

• Project description
• Social ECards assignment invitation

QuestionBox

• Project description
• QuestionBox assignment invitation

Whichever one you choose, your whole team is building the same one.

How to accept the assignment and create the repos on GitHub

The back end will work in their own repo and the front end will work in their own repo, so for the same project each team will have two repos.

One back-end dev should accept the assignment invitation and name the team something like “Team Yeti Back-end” (whatever your team name is!). Then the other back-end dev(s) should accept the assignment and choose the right team. All back-end folks on the team clone that same repo.

One front-end dev should accept the assignment invitation and name the team something like “Team Yeti Front-end” (whatever your team name is!). Then the other front-end dev(s) should accept the assignment and choose the right team. All front-end folks on the team clone that same repo.

If you are the only dev in your repo, you may choose not to use pull requests, although you can, and it is still a good idea to use branches. If you have two backend devs on your team, you must use pull requests.

When you start work in this repo, you should delete the README at the root so it doesn’t conflict with the files you will create for the project. You can save it somewhere else – it’s just a Markdown file. When you start your Django or React app, you should install it at the root of the repo directory, not in a subdirectory (you do this by specifying the current directory with a . instead of a project name). This will make deploying easier.

The Teams

⛈ Team Thunder: Gerardo, Manny, Jamie, Hillary

⚡ Team Lightning: Shawna, Joey, Stephen, Jessica

How to work as one team

Even though you have two separate codebases and separate applications, you’re working together to ship a single product on time. You can make product decisions together even though you will implement features separately.

We’ll check in on the projects in class; front and back end teams will continue to meet separately.

Remember to read the README very carefully.

🥅 Your goals tonight 🥅

• Choose a project.
• Understand the project requirements thoroughly and discuss what you need to build.
• Outline a plan for what you’ll need to do. This can be a text outline, sketches of user flow, basic wireframes; for back end you’ll need to draw ER diagrams to plan your models and start a list of endpoints you think you will need.
• WRITE YOUR PLANS DOWN. You can use any tools you like as long as the content you create is shareable. Some tools that might be useful: Trello, Google Docs, Excalidraw, Miro. Make sure everyone on your team has access to this documentation.
• You are encouraged to work with other front or back end devs on other teams to share ideas, solutions, and resources.
• Come to your front- or back-end class meeting prepared to give progress reports and ask for help on what you’re working on.

We haven’t yet covered everything you’ll need to be able to do this project, so that will be our task this week and next.

Git Workflow

Working with other developers in a shared codebase means that the workflow you’ve been using so far will have to change. We will cover this in class together. Here are the slides for reference.

Git Collaboration slide deck

Today’s topics

• React Trivia review
• Forms in React
• Understanding what “logged in” means
• How to handle authentication in a React application

🎯 Collaborative Project

Begin talking to your teammates and planning the team project. You should have detailed wireframes, an idea of user flow (how your user interacts with your UI), and a plan for components done by tomorrow.

Start with: What does my user see when they first land on this page? What will they do? What happens next?

No writing code yet! We’ll cover working together on GitHub tomorrow.

🔖 Resources

Forms

• React Mental Models: Working With Input
• Controlled vs uncontrolled form inputs in React
• Dave Ceddia: React Forms

Working with Local Storage in React

• use-local-storage-state -> You would npm install use-local-storage-state to use it in your code
  • Check out this custom hook code example, which shows how you could implement this yourself (you could even borrow this code and use it in your project instead of the above library if you wanted to!).
  • Using the Web Storage API

React Mental Model

Review the core concepts of how React works by reading these visual guides.

• What is React?
• React Mental Model: Cutting Holes in HTML
• Props & State explained

Today’s Topics

• Token authentication in DRF with Djoser
• CORS headers

🎯 Collaborative Project

Work with your team. Tonight, plan out your models – please draw a diagram! – and write down a list of the endpoints you think you will need. It should take you some time to talk this through! What data will those endpoints have to return and what data will they need to accept, if they are POST or PUT/PATCH endpoints?

Your list of planned endpoints should look something like (this is a partial list using examples from Habit Tracker. You’re going to need a bunch more endpoints than this). Keep in mind that you should include endpoints ONLY if you need them, so think about the project requirements.

Example planning for endpoints:

No writing code yet! We’ll cover working together on GitHub tomorrow.

📖 Read | 📺 Watch | 🎧 Listen

• Finally Understand Auth in DRF - a Will Vincent talk -> Will isn’t using the Djoser library but he does a great job of reviewing different auth strategies and why you would choose one or the other. Watch this for a better understanding and overview of authentication.
• Julia Evans comic explaining CORS better than MDN does
• More Julia Evans on the Same Origin Policy
• Simple Is Better Than Complex: How to Implement Token Authentication in DRF This does NOT use Djoser, but it’s a great walkthrough of some of what Djoser does for you if you would like more detail.

🔖 Resources

Authentication

• Djoser documentation
• DRF docs: Token-based authentication
• The Ultimate Tutorial for Django REST Framework: Login and Authentication This uses the Djoser library.

CORS

• MDN CORS
  • MDN Access-Control-Allow-Origin Header
• Django CORS Guide
• django-cors-headers

Permissions

• DRF Permissions
• Pro-Tip: Logical operators with DRF Permissions