Planning for Project Success
Learning Goals
- Take an opportunity to share cross program knowledge and ask questions
- Discuss expectations between FE & BE and what that communication can look like
- Review JSON contracts and how you can leverage documentation as a team
- Revisit what is CORS and why it’s important especially in the capstone project
Sharing Cross Program Knowledge
Warm Up
Being in a combined cohort leaves many opportunities to discuss and learn from each other, but it’s often tricky to make that time when there are competing priorities. We want to set aside some time before you get into your capstone project to think about the knowledge that you’ve obtained and the questions you still have for the opposite team. What assumptions might you have? What is the opposite team used to having in order to be successful?
Take a few minutes to write down your thoughts to the following:
- You’ve learned a lot from the last 3 mods, but your cross program team may not be as familiar with the content you’ve learned. Highlight a few pieces that you’ve learned at Turing and maybe one project that you worked on.
- As a FE/BE developer, what do you need to be successful in a cross program team?
- As a FE developer, what APIs have you worked with? What did you find that was valuable when working with that data? (documentation, different endpoints, the way data was structured, etc.)
- As a BE developer, what do you need to know about with the FE in order to setup data in a specific way? Does data manipulation always need to happen in the BE?
- Write down at least one or 2 more questions that you’d love to hear more about from your peers.
We’ll hop in breakout rooms afterwards for you to discuss, and then have a few shareouts when we come back together as a class.
In breakout rooms:
- Fill out this Jamboard answering the following!
- What assumptions do you make about the FE?
- What do you know about the BE?
- What questions do you still have?
Setting of Expectations around Communication
As you’ve likely learned in many of your previous projects, communication is often key to a successful project. The same will be important for the capstone project as the FE and BE teams work together. Here are a few suggestions you will want to take note of:
- Regular Standups & Retros
- Use standups to discuss what was accomplished the previous day, what you’re committing to today, and what blockers your team is running into. Standups are often kept short but are a great way to start the day and stay up to date with where things are.
- Retros are also an effective way of reflecting and iterating as a team, looking over the project board, refining the backlog, & planning for the next sprint. There are a number of formats that can be used to offer feedback during retros with some of them being listed here.
- Keeping one project board up to date
- Make sure to set up a GH organization and utilize one project board on GitHub. Having one project board takes out the guess work of what other teams are working on. You can always use labels to filter out between what FE & BE is working on or what still needs to be done for the current sprint.
- Connecting the FE and BE quickly
- Even if it’s just setting up a basic BE server with one endpoint and a rough FE application, getting them to talk with each other is going to be massive in the beginning. Add to this deployment and CI, and your project is setup from the get go for the rest of your sprints. The great thing about this is once you push something up or merge a PR, you know if it works or not!
JSON Contracts
A JSON contract, also known as a JSON API contract or a JSON schema, is a set of rules that define how data is formatted and structured in a JSON (JavaScript Object Notation) document.
Setting up a JSON contract is crucial for FE and BE teams communicating via JSON APIs. This document defines expectations between the teams, and it should be updated whenever the expectations change.
As you can see from these JSON schema docs, setting up a JSON contract can get pretty complex. They can also be as simple as a collection of restful endpoints, including parameters, status codes, and example JSON responses. See a good example here .
Why is this important?
If you are able to discuss as a cross team what the data looks like and create a JSON contract, your immediate team will have a better idea on how to move forward.
Before you start coding, set up a Mock server in Postman . Use your JSON contracts as a guide for how the mock endpoints behave.
While the BE team begins to setup the tables and endpoints, the FE team can use the mock endpoints you created to get some quick data to work with while building the UI and various components of the app. This is much better than scrambling to get a BE up quickly and FE working without any endpoints, especially when you are learning new tech on top of it.
As things get setup and you’re ready to connect the FE and BE, it should be be easy to replace that mock server with the actual live endpoints and all should work the same!
Also note that of course this data can change. Make sure to keep documentation up to date. If BE needs to change the data type of a property or obtain more data, and vice versa for FE, make sure to notify the other team and reflect that in the docs!
Reviewing Intermission Work: What is CORS?
In Breakout Groups
Pull up your gist/document that you filled out from the intermission work, and discuss in groups on what you found out about CORS:
- What does CORS stand for?
- Why is it necessary?
- Why is this important for the Capstone?
CORS is…
CORS (Cross-Origin Resource Sharing) is an HTTP header that allows servers to indicate what other origins than it’s own have permission to load its resources. The origin is defined by the hostname (domain), scheme (protocol), and port of the URL used to access it. You can see examples where URLs have same origins and different orgins as well here!
CORS is actually a direct response to the Same-Origin Policy which is a security mechanism that restricts how a document/script loaded by one origin can interact with a resource from another origin. Although this is not as secure as authentication/authorization, you can think of it as an additional layer of security that helps prevent malicious attacks on your website. If you didn’t have the same origin policy in place, you could have facebook open in one tab and then go to another site and be able to access all of your private information. Same thing if you had a tab open with your bank info.
CORS is something you will need to enable in your capstone project so that the FE & BE can talk to each other. It is something the BE will need to incorporate so that the FE can talk with and access data from the BE server. There are various packages/gems out there in all languages including JS, Rails, and Python, that allow you to enable CORS by adding an “allow list” containing which domains may have access to your data. If you’re interested in reading up more in CORS, definitely check out the MDN docs!
