ivonne-hernandez · February 1, 2022 17:43
diff --git a/Mod_4_Prework b/Mod_4_Prework
 ## Capstone Project Prep
 Now that you’ve completed the tutorial, take a moment to write a reflection on your experience to help solidify what you’ve learned.

 Brief summary of what you researched
 I researched GraphQL, which is a different style for building an API. 
 GraphQL uses a single endpoint and a strictly-typed schema through which all requests are sent. 
 The schema defines the resources available for retrieval in addition to the accepted parameters when fetching the data.  
 Typical REST APIs require loading from multiple URLs (endpoints) that can over or underfetch data and requires the client to know the exact location of each service. 
 GraphQL APIs obtain all of the data that an app requires in a single request (endpoint) and has the capability to allow clients to define the shape of the response for each request (i.e. what information is sent back to them).

 How does it extend your current programming foundation?
 GraphQL extends my current programming foundation by allowing me to explore a different way to build an API.

 If you were asked in an interview about the topic you researched, what would you want to highlight?
 I would highlight that while GraphQL is all the rave today, it would only make sense to use it over a REST API if there were going to be a
 lot of changes to it in the future or if the application is maintained across multiple form factors and platforms (e.g. iOS, Android, React-Native). 
 REST APIs have been around for a really long time and although there are some seemingly useful features
 in GraphQL like a single endpoint, client-defined shape of a response, self-documented schema amongst many others, REST APIs are optimal for CRUD applications
 because the bulk of the work is done on the client's side at the time of the request. 

 In a gist/document answer the following-questions at a high-level. We will discuss this further during week 1.

 What does CORS stand for?
 CORS stands for Cross-Origin Resource Sharing.

 Why is it necessary?
 CORS is necessary because it allows servers to specify not only who can access the assets, but also how they can be accessed.
 Cross-origin requests are made using the standard HTTP request methods. Most servers will allow GET requests, which allows external
 origins to read their assets. Other HTTP requests like PATCH, PUT or DELETE, however, may be denied to prevent malicious behavior to its assets.
 List of domains that it's allowed. cors.allowed origins, This tells the browser who is allowed. Make a list of allowable domains.

 Why is this important for the Capstone?
 This is important for the Capstone because we don't want to allow just anyone to be able to modify or delete the assets of our application.

 ## Legacy Code Experience
 In a gist or document, write down your approach and considerations for how you familiarize yourself with the existing code as if you were implementing a solution to the issue you’ve selected. You can use these questions as a guiding point.
 Issue:ability for user to delete their account #44

 Where will you start in the codebase, and why did you decide to start there?
 I would start by seeing if there was an endpoint created in order for a user to delete their account (so I'd checkout the FE first and see if it's there and if it's not, I'd check the backend). 
 I decided to start there to see if this was even a feature that was implemented in the codebase. If not, then that would mean that I would have to create it from scratch in the BE first and then use it in my apiCalls file in the FE.

 What is familiar to you about the codebase?
 The thunks and utils file look like the apiCalls file that we usually create. Everything is organized into a component.

 How are you identifying what files are relevant to your issue?
 By seeing if they call the delete user endpoint.
	## Capstone Project Prep
	Now that you’ve completed the tutorial, take a moment to write a reflection on your experience to help solidify what you’ve learned.

	Brief summary of what you researched
	I researched GraphQL, which is a different style for building an API.
	GraphQL uses a single endpoint and a strictly-typed schema through which all requests are sent.
	The schema defines the resources available for retrieval in addition to the accepted parameters when fetching the data.
	Typical REST APIs require loading from multiple URLs (endpoints) that can over or underfetch data and requires the client to know the exact location of each service.
	GraphQL APIs obtain all of the data that an app requires in a single request (endpoint) and has the capability to allow clients to define the shape of the response for each request (i.e. what information is sent back to them).

	How does it extend your current programming foundation?
	GraphQL extends my current programming foundation by allowing me to explore a different way to build an API.

	If you were asked in an interview about the topic you researched, what would you want to highlight?
	I would highlight that while GraphQL is all the rave today, it would only make sense to use it over a REST API if there were going to be a
	lot of changes to it in the future or if the application is maintained across multiple form factors and platforms (e.g. iOS, Android, React-Native).
	REST APIs have been around for a really long time and although there are some seemingly useful features
	in GraphQL like a single endpoint, client-defined shape of a response, self-documented schema amongst many others, REST APIs are optimal for CRUD applications
	because the bulk of the work is done on the client's side at the time of the request.

	In a gist/document answer the following-questions at a high-level. We will discuss this further during week 1.

	What does CORS stand for?
	CORS stands for Cross-Origin Resource Sharing.

	Why is it necessary?
	CORS is necessary because it allows servers to specify not only who can access the assets, but also how they can be accessed.
	Cross-origin requests are made using the standard HTTP request methods. Most servers will allow GET requests, which allows external
	origins to read their assets. Other HTTP requests like PATCH, PUT or DELETE, however, may be denied to prevent malicious behavior to its assets.
	List of domains that it's allowed. cors.allowed origins, This tells the browser who is allowed. Make a list of allowable domains.

	Why is this important for the Capstone?
	This is important for the Capstone because we don't want to allow just anyone to be able to modify or delete the assets of our application.

	## Legacy Code Experience
	In a gist or document, write down your approach and considerations for how you familiarize yourself with the existing code as if you were implementing a solution to the issue you’ve selected. You can use these questions as a guiding point.
	Issue:ability for user to delete their account #44

	Where will you start in the codebase, and why did you decide to start there?
	I would start by seeing if there was an endpoint created in order for a user to delete their account (so I'd checkout the FE first and see if it's there and if it's not, I'd check the backend).
	I decided to start there to see if this was even a feature that was implemented in the codebase. If not, then that would mean that I would have to create it from scratch in the BE first and then use it in my apiCalls file in the FE.

	What is familiar to you about the codebase?
	The thunks and utils file look like the apiCalls file that we usually create. Everything is organized into a component.

	How are you identifying what files are relevant to your issue?
	By seeing if they call the delete user endpoint.