React and redux have definitely tught me a lot more about the freedom JavaScript offers, as well as the useful tools they provide for comparmentalization, separation of concerns, and the use of objects throughout an application. It’s nice to see the ways that React can help to separate everything in a JavaScript project to help with organizaion, speed, and access. It makes intuitive sense to work with Object Oriented Jacascript and have everything separated into its specific category of objects and components and then the internal purposes within. This definitely seems like something that comes more and more in handy the larger an application gets.
One of the things I noticed the most about Javacript right off the bad is the flexibility it offers over a much more structured language like Ruby. In many ways this is liberating, but in many ways it’s very intiidating. I appreciate how much generosity it offers in different approaches, problem solving, and multiple solutions to a problem. Because the developer is responsible for definint so many aspects of it, it is easier to bend Javascript around the developer’s will and update it for different needs.
Going into this project i felt pretty nervous; I didn’t feel like my understanding of Rails was really setting in after having gone through all of the lesson modules, but I anticipated that, like with my other projects, my comprehension would be completed through executing the project (fortunately I was right).
Authentication in coding essentially serves as a safety net for program or user generated content in the database to ensure that the person attempting to access it is a person who ought to be accessing it. When the user attempts to access a specific piece or group of content, they are sending a request to the app server saying “Hey, I’d like to create/ update/ destroy, may I please?” The authentication is a figurative barrier between the user and that content that the server has to decide whether they are allowed to interact with and in what ways. The request is generally sent in the form of an HTTP header for the program to read, and if, for instance, the user sends a request that doesn’t include in their iauthentication, the server returns an error message saying “If you want to access this, I’m gonna need to see your credentials”. These credentials–the unique authentication– need to match between the user’s stored info and the database’s stored info, so the authentication takes places as essentially a conversation between the two parties. Metaphorically, the server is saying “What’s the secret password?” and the user get request needs to contain that secret password in order to gain entry. The purpose of this is to prevent a person from being able to access or alter information that they should not be able to access or alter.
For this project I wanted to incorporate something that I was already interested in outside of the project that I could potentially use after it was completed, so I decided to create a website for organizing a book reading group some friends and I had discussed. Adding, viewing, editing, and deleting books to and from a collection seemed like a perfect way to implement the CRUD requirement. I build the project around the concept that indicidual users could log into the website and add books to a reading list for the other members to view. When adding a book to the reading list, a user includes the title, the author, the genre, as well as a short blurb about the content of the book. This seemed to me like a good way for a group of people to organize and share books with one another and to keep an itemized list of future ventures. Once a user adds a book, that unique user is the only one who is able to edit or delete the book from the dadabase. This would ideally be done once the book club has completed the book and discussed it in whatever in meeting format works for them.