Coding with Callie

Eeek! Mindi Weik will be the guest speaker at this week's meet-up! Join us on Thursday (September 19) at 8PM EST for her session 🥳

For my Project Planning Tool application with Coding with Callie I have been focusing on the user account; creating a sign-up form and log-in form along with log-in and log-out functionality. This has also involved form data validation on sign-up, password hashing and saving new users to a database. A tool that was new to me which I have used in the project was the React Router useOutletContext hook, allowing you to share data between parent and child routes without having to pass props down through components. The parent route provides context using a context prop on an <Outlet /> component and the child route can access this context using the useOutletContext hook. I've also learnt about using a JWT token which when used is generated after username and password verification by the server and then sent back to the client. This is stored in local storage or a cookie. For subsequent requests the client includes this token in the Authorisation header. The server then verifies and if valid processes the request. Onto user account maintenance...

Thank you so much, Gerald Dagher, for being our guest speaker last week! If you missed it, you can check out the recording: https://lnkd.in/eTNfEQXV

Update on Building in Public, my Project Planning Tool is coming along. This week, I made it so users can now create an account, log in and out, and implemented toasts to provide clarifications where needed. I learned a lot this week from Coding with Callie. I learned what sanitizing data was. You sanitize raw HTML data to prevent malicious code patterns from user input. Sanitizing it allows you to prevent cross-site-scripting attacks and removes HTML and JavaScript code which can enable them. It also helps ensure that the input is in a valid format when being inserted into your database. Bcrypt is a widely used library to hash passwords. Hashing essentially is to turn plaintext into an unintelligible series of numbers and letters. We hash passwords as one of the major preventative measures minimizing hackers from obtaining passwords. This was also my first time setting up an authentication route using NestJS, which helps keeps certain routes "protected" from users who shouldn't have access to those routes. Make sense that if you don't have an account you should have access to an application you need an account for. Lastly, Callie Stoscup highlighted being cautious of the error messages provided during user creation/login. It's good to let users know that something is wrong and that the application isn't just buggy. But, providing error messages with too much information can be costly. Error messages like "wrong username/password combination", "username is taken", and/or "email is taken" gives hackers a lot of information they could use.

This week I worked on setting up the frontend, backend, database and connecting them for my Coding with Callie project planning tool. I also setup database migrations with MySql and Prisma. I found that #Prisma docs are well laid out and they were very easy to follow! No wonder it’s so popular. #React #MySql #Prisma #Node

During the project setup stage of the Build in Public Challenge with Coding with Callie, I recently gained hands-on experience in full-stack web development by connecting the frontend with the backend and integrating a PostgreSQL database. Along the way, I tackled challenges like troubleshooting a failed migration and fixing issues with PostgreSQL. I also sharpened my version control skills with Git, pushing my work to GitHub.

This week I’ve added some new features to my Project Planning Tool. Users can now create an account, log in, log out, and use the header to navigate to other pages depending on if they’re signed in. Also there will be success and error toasts. I don't have a logo so yes I used my favorite football team for now. Coding with Callie New things I learned this week: Sanitizing Data: I used NestJS’ ValidationPipe and sanitize-html. Sanitizing data on the frontend and backend means cleaning and validating any input data to ensure it is safe and does not contain harmful code, such as SQL injection or cross-site scripting (XSS) attacks. On the frontend, sanitization involves validating user inputs before sending them to the server. On the backend, it involves double-checking and cleaning data received from the frontend before processing or storing it in a database. Imagine you receive a letter in the mail. Before you read it, you make sure there’s nothing dangerous inside, like a hidden harmful substance. Chakra UI: A component library for React apps. Sets of pre-built, customizable components that you can use to build web interfaces quickly. These components include buttons, forms, modals, and many others. Hashing passwords: This a process where a plain text password is converted into a fixed-length string of characters, typically using a cryptographic hash function. This hash is stored instead of the actual password. When a user logs in, the system hashes the entered password and compares it to the stored hash. If they match, the login is successful. Hashing is a one-way process, meaning you can't easily convert the hash back to the original password, which enhances security. For this I used Bcrypt, which has “salting”, this adds a random value (salt) to the password before hashing, which ensures that identical passwords result in different hashes Auth Guard: This a feature in NestJS, that protects routes from being accessed by unauthorized users. It acts as a gatekeeper, checking whether a user is authenticated, has a JWT, before allowing them to access certain parts of an application. If the user is not authenticated, the Auth Guard can redirect them to a login page or return an error. This helps secure the application by ensuring only authorized users can access sensitive routes or resources. 

Curious what differentiates a professional software development environment from a personal project? 🤔 Join our meet-up this week to learn all about it from Gerald Dagher!

Last night's live coding meet-up was super fun 🤩 We continued work on our React frontend. We styled the individual book cards and the container in which they live, made the books main page responsive, and explored different ways to achieve our desired design. We weighed the benefits of grid vs. the simplicity of flexbox and started working on the 'Add a book' form. It's been a while since I've used vanilla CSS, so it was fun to debug and learn some new tricks 🥳 https://lnkd.in/ezcpuSFb

💻 For this week’s Coding with Callie Deploy in Public challenge, I learned about the importance of having multiple availability zones (AZs) in your AWS set up, and how to set up a load balancer to route traffic to my EC2s in these different AZs. Hypothetically, my application would be running on one of my private EC2s in one of my availability zones. In the event that one AZ goes down, by having a second AZ, my load balancer can route traffic to the AZ that is active and healthy, effectively preventing my application from going down with the AZ. You may be wondering what could cause an AZ to go down. Well there are many factors like natural disasters and power outages, network or hardware failures, software bugs, human error, security breaches, planned maintenance, or the AZ’s reliance on third-party dependencies that are having issues. As you can see there are many reasons why you would want to have multiple AZs, and depending on the size of your application, you may require more than 2 AZs. Basically, AZs are insurance. And with a set up that has multiple AZs, load balancers are doing the work of routing the traffic to your private EC2s. With a load balancer set up, AWS’ session manager is used to “sign in” to the private EC2. This is in contrast to a set up with one AZ where public instances act as a load balancer, and a bastion host is used to SSH into the private EC2. With this challenge, I did a deep dive into ports and how they are used. Ports enable computers to differentiate between different kinds of traffic, like email vs. webpage traffic. The Transmission Control Protocol (TCP) indicates which port a data packet should go to, for example, HTTP data should be routed to Port 80. There are 65,535 possible port numbers, but the most commonly used ones are: 🛣 Ports 20 and 21: File Transfer Protocol (FTP) for transferring files between a client and server 🛣 Port 22: Secure Shell (SSH), a tunneling protocol that creates secure network connections 🛣 Port 25: Simple Mail Transfer Protocol (SMTP) for transferring emails (used in the past) 🛣 Port 587: secure SMTP, used today for transferring emails 🛣 Port 53: Domain Name System (DNS) for matching human-readable domain names to machine-readable IP addresses, which enables users to load websites and apps without memorizing a bunch of IP addresses 🛣 Port 80: Hypertext Transfer Protocol (HTTP) 🛣 Port 443: HTTP Secure (HTTPS), the secure and encrypted version of HTTP 🛣 Port 123: Network Time Protocol (NTP), a port allowing computer clocks to sync with each other, which is essential for encryption 🛣 Port 3389: Remote Desktop Protocol (RDP), the port users can use to remotely connect their desktop computers from another device If you've made it to the end of this post, I hope you learned something new! Finally, in the comments is a screen recording of me accessing my private EC2 via AWS' Session Manager, as well as using the load balancer's DNS address to view my custom HTML page: