DEV Community: Josh Endemann

Delving Back Into React: Building a Website for a Local Construction Company

Josh Endemann — Sun, 22 Dec 2024 23:51:37 +0000

After a brief hiatus from working with React, I decided to dive back into it. Originally, I planned to start with Next.js, as it's the modern framework everyone’s talking about. However, I realized that jumping straight into it might be overwhelming since I hadn’t worked with React in a while. Instead, I opted for a refresher by building a project in vanilla React—and what better way to do that than to solve a real-world problem?

The Project: A Website for Down to Earth Contractors

A local construction company was in need of a modern website to showcase their services, highlight past projects, and provide a way for potential clients to get in touch. This seemed like the perfect opportunity to brush up on my React skills while creating something meaningful.

Key Features of the Website

Responsive Design

The website is fully responsive, ensuring an optimal user experience on desktops, tablets, and mobile devices.

Dynamic Content

Each service—excavation, grading, demolition, and more—has its own dedicated page with descriptive content and imagery.

Contact Form with EmailJS

This was my first time integrating EmailJS into a project. The contact form allows users to submit inquiries, which are sent directly to the company’s email. Setting this up was a learning curve, but it was satisfying to see it work seamlessly.

A React Refresher

Working on this website was a great way to revisit fundamental React concepts. I extensively used the useState hook for managing form data and displaying dynamic status messages. Structuring the components, managing props, and styling with CSS were all valuable exercises that reminded me why I enjoy working with React.

The Process of Building

Planning and Structure

I started by outlining the site’s structure: a homepage, a services section with individual pages, a gallery, and a contact page. Breaking the project into smaller components helped me stay organized and focus on one feature at a time.

Challenges and Solutions

EmailJS Integration

Setting up EmailJS was new territory for me. Understanding how to configure the service with my project required some trial and error, but the result was worth the effort. It’s exciting to see how easy it is to integrate third-party tools into a React application.

Styling the Navbar

Ensuring the navbar was responsive and intuitive across devices took some tweaking. I learned more about CSS and how to use conditional class names effectively in React.

Enjoying the Journey

The process of building this website reminded me how much I love learning by doing. There’s something addictive about solving problems, seeing the results of your work, and knowing that you’re creating something valuable.

Looking Ahead

This project has rekindled my passion for React. Moving forward, I’m excited to:

Rebuild My Portfolio Website

My current portfolio is outdated, and I’m eager to create something that better reflects my skills and projects.
Learn More React Fundamentals

While this project was a great refresher, there’s always more to learn. I’m planning to dive deeper into state management, performance optimization, and testing.
Experiment with Next.js

Once I’m more comfortable with React again, I’ll tackle Next.js to explore server-side rendering and other advanced features.

Conclusion

Building the Down to Earth Contractors website has been a rewarding experience. It’s a reminder that practical projects are the best way to learn and grow as a developer. If you’d like to check out the code for this project, feel free to visit the repository:

GitHub Repository: Down to Earth Contractors Website

Building a Band Website: Navigating the Backend Challenges with Roles and Permissions

Josh Endemann — Mon, 16 Dec 2024 03:06:01 +0000

Building the backend for my band's website has been an exciting, challenging, and deeply educational process. Along the way, I’ve tackled a variety of issues—from setting up the comment section to refining the role-based permissions system. In this blog post, I’ll walk you through some of the hurdles I faced, how I solved them, and the valuable learning experiences that came out of the process.

Setting Up the Comment Controller, Route, and Model

The first challenge I ran into was setting up the comment system, which would allow users to make comments and reply to others. As we all know, handling user interactions like comments can get complicated quickly, especially when trying to build a scalable and clean solution.

Here’s what I did:

Comment Model: I started by defining the comment schema in MongoDB using Mongoose. Each comment has an associated user, content, and timestamp. For replies, I used a reference to the parent comment, allowing users to have nested conversations.
Comment Controller: I created functions for adding, deleting, and replying to comments. One issue I encountered was ensuring that the correct user could only edit or delete their comments. This required setting up strict checks in the controller and making sure the API routes were protected with authentication and authorization logic.
Comment Route: Once the controller was working, I set up routes that allowed users to post new comments, reply to existing ones, and delete comments. The routing required validation and error handling to ensure that users didn’t perform actions they weren’t authorized to do.

Troubleshooting involved several rounds of testing to get the comment threading functionality right. Specifically, handling nested replies and ensuring that users couldn’t delete comments they didn’t own took some time. However, after working through these edge cases, I was able to provide a clean commenting experience for the users.

Ensuring Routes Work Seamlessly

After getting the comment functionality working, I turned my attention to the other routes for user management, album creation, and more. One of the key challenges was making sure all the routes were protected correctly, particularly ensuring that only authorized users could access specific resources.

This is where I introduced role-based access control (RBAC) through the checkPermissions middleware. By implementing this middleware, I could easily enforce permissions for different types of users (e.g., admins, fans, or band members). This also required thorough testing to ensure that the routes were working as expected and that the roles were being checked correctly.

Roles and Permissions

Roles and permissions were the real challenge, but also the most rewarding. Initially, I was planning on having separate controllers for fans and band members—one for each type of user with their own set of logic. However, I reached out to the Node.js Slack group to get some advice, and the community suggested an alternative approach: use roles and permissions to handle access control in a more unified and scalable way.

This insight was a game-changer. Instead of writing separate controllers, I could create one set of routes and use middleware to enforce different permissions based on the user’s role. For example:

Admins could manage users, assign roles, and access analytics.
Band members could create and edit their own albums and tracks.
Fans had the ability to interact with the content (like, comment, etc.) but had no administrative privileges.

With this approach, I was able to consolidate the logic for managing users and their actions into a single set of routes, making the code cleaner and more maintainable. The permissions were tied to each user’s role, and the middleware made sure that each action was properly authorized.

The system was flexible enough to allow for detailed control over each user’s abilities, and I had to debug several issues around ensuring that the middleware was properly intercepting requests and checking the user’s permissions. The solution involved structuring the code in a way that each route, depending on the action, would be checked against the user’s roles and permissions.

Once everything was set up, I was able to have clear control over who could do what—whether it was adding content, managing users, or simply commenting.

What's Next? Moving Forward

With the backend now mostly functional, I’m moving on to working on the favorites controller and rating controller. Once these are complete, I’ll start building the frontend for the website. It’s been a journey full of problem-solving and a lot of learning along the way.

I’ll admit, the backend for this website might be overkill for the scope of the project, but it’s been a great opportunity to dive deep into backend development and understand how robust systems can be built with the MERN stack. I’m excited to move forward with the frontend and begin the next chapter of this project.

Building this website has been incredibly fun and rewarding, and I’m looking forward to seeing how it all comes together in the end!

This post was a journey through my process of solving backend challenges. If you’re working on a similar project or are considering building a web app with user authentication, role-based access, and more, I hope this gives you some insight into the problem-solving mindset needed to tackle these issues. Stay tuned for updates on the frontend development!

My Journey Through Modeling Data and Advanced Mongoose: Lessons Learned

Josh Endemann — Tue, 10 Dec 2024 01:19:04 +0000

I'm always excited to build my skills and grow my understanding of how backend development works. Recently, I completed the Modeling Data and Advanced Mongoose section of Jonas Schmedtmann's Node.js course, and wow, what a game-changer! Here's what I learned, why it was valuable, and how I plan to apply these concepts to my band's website.

1. The Power of Mongoose Schemas

One of the key concepts I dove into was Mongoose schemas. I learned how schemas define the structure of data in MongoDB collections. By using schemas, you can enforce rules for the data, such as requiring specific fields, setting default values, and even applying validation rules.

For example, I created schemas for documents like users, tours, and reviews. On my band’s website, I’ll apply this by defining schemas for users (fans and band members), album data, comments, and show schedules. Setting clear rules ensures that all data entered into the site remains consistent and valid.

Key takeaway: Schemas give your data structure and make it easier to debug issues early on.

2. Virtual Properties and Indexes

Virtual properties were a revelation—they let you define properties that aren’t stored in the database but can be dynamically calculated. For my band’s website, I plan to create virtual properties like "fan since", which calculates the length of time a user has been part of our community, based on their signup date.

Indexes will be a huge boost for performance, especially for fields like band member names or album titles. They’ll make searches and queries much faster.

Key takeaway: Virtuals and indexes make your app faster and more dynamic without overcomplicating your database.

3. Advanced Query Features

I’ve gained confidence in using Mongoose middlewares and aggregation pipelines, which I’m excited to implement on the website.

Mongoose Middlewares: These will help me automate processes like updating timestamps for band members' profiles when they post new content.
Aggregation Pipelines: This will allow me to calculate stats like the most popular albums based on user favorites or the average ratings of shows.

Key takeaway: These advanced tools will make the band’s site more interactive and user-focused.

4. Referencing and Embedding Data

I learned how to link data using referencing and embedding. For my band’s site, this means:

Referencing: Connecting user profiles to their comments, favorite songs, or photos.
Embedding: Storing static data, like a setlist for a concert, directly in the show document for quick access.

By combining these strategies, I can make the site both flexible and efficient.

Key takeaway: Choosing the right relationship strategy helps balance flexibility and performance.

5. Using Data Validation to Improve Data Quality

Data validation is essential for creating a smooth user experience. On my band’s website, I’ll use built-in validators to ensure:

Emails are valid when fans sign up for accounts.
Usernames follow proper guidelines for band members and fans.
Comments don’t exceed a certain character limit to maintain readability.

Custom validators will also come into play, like making sure event dates don’t overlap or song titles aren’t duplicated.

Key takeaway: Validation helps keep the data clean and the user experience smooth.

How This All Fits Into My Band’s Website

My band’s website will showcase tracks, albums, and upcoming shows while giving fans a space to interact with us. Here’s how I’ll integrate these features:

Fans can sign up and comment on albums or shows, with their data validated and securely stored using Mongoose.
Band members will have personal profiles where they can share bios, photos, and updates, linked dynamically using referencing.
Albums and songs will have ratings and favorite counts, calculated using aggregation pipelines.
Show details and setlists will be efficiently modeled and served to fans, making navigation fast and seamless.

Completing this course section has equipped me with the tools to make all these features come to life.

6. Challenges and Growth

What stood out most to me was how every feature I learned builds toward making an application more efficient, secure, and user-friendly. While some concepts (like aggregation) felt tricky at first, working through real-world examples gave me the confidence to start using them in my own projects.

What’s Next?

As I build the band's website, I’ll continue applying these Mongoose techniques to ensure it’s reliable, scalable, and fun to use. This is just the beginning of combining my skills as a developer with my passion for music.

If you’re also learning Node.js or MongoDB, I highly recommend diving into these concepts—they’re challenging but rewarding!

Feel free to share your thoughts, tips, or even just tell me about your own projects. I’d love to connect and grow together!

If you’re interested in connecting or following my journey, feel free to check out my profiles:

Thanks for reading!

Authentication and Security in Web Development: Lessons Learned and Implementation Plans

Josh Endemann — Sun, 01 Dec 2024 23:58:02 +0000

Over the past few weeks, I’ve been diving deep into the authentication and security section of Jonas Schmedtmann’s Node.js course. This experience has given me invaluable insights into securing modern web applications, and I’m excited to apply this knowledge to my band’s website as part of my portfolio project. In this blog, I’ll discuss what I’ve learned, why it’s important, and how I plan to implement these practices.

Key Lessons on Authentication and Security

1. The Fundamentals of Authentication

Authentication is the process of verifying a user’s identity. From the course, I learned about:

Password hashing: Hashing passwords using algorithms like bcrypt ensures that even if the database is compromised, passwords remain secure.
JWTs (JSON Web Tokens): These are widely used for user authentication in stateless systems. They enable secure communication between the client and server without storing session data on the server.
OAuth and third-party login: For seamless user experiences, integrating services like Google or Facebook login is often preferred.

2. Authorization and Access Control

Once a user is authenticated, the next step is determining what they’re allowed to do. Some highlights include:

Role-based access control (RBAC): Defining roles like “admin” or “user” to restrict access to specific resources.
API protection: Using middleware to guard sensitive routes against unauthorized access.

3. Data Validation and Sanitization

Unvalidated inputs are one of the biggest security risks. I learned how to:

Validate user input with tools like Joi or express-validator.
Sanitize inputs to prevent attacks such as SQL injection or cross-site scripting (XSS).

4. Password Reset Mechanisms

Secure password reset functionality involves:

Generating time-sensitive reset tokens.
Sending reset links via email securely (using Nodemailer).
Implementing additional checks, like IP logging, to detect unusual activity.

5. Rate Limiting and Brute Force Protection

Tools like express-rate-limit and helmet play a key role in safeguarding against brute force attacks. They limit repeated requests from the same IP, making it harder for attackers to guess login credentials.

6. Secure App Configuration

Best practices in configuring a secure Node.js app include:

Storing sensitive data in environment variables.
Using libraries like dotenv to manage configurations.
Setting secure HTTP headers with helmet.

How I’m Applying This to My Band’s Website

For my band’s website, security will be a top priority. While the primary focus will be on showcasing our music and events, I’ll also include features like user accounts for fans, ticket purchases, and possibly even an admin dashboard.

Here’s how I plan to integrate what I’ve learned:

1. User Authentication with JWTs

I’ll use JWTs for a seamless and secure login experience. Fans will be able to create accounts to save favorite tracks, join newsletters, or purchase tickets. Admins will have additional access to manage event schedules and inventory.

2. Password Security

User passwords will be hashed with bcrypt before being stored in the database. I’ll also include a robust password reset system to make it user-friendly yet secure.

3. Role-Based Authorization

I’ll implement RBAC to ensure:

Fans can only access general features like track downloads or event booking.
Admins can update event details, manage ticket sales, and upload media files.

4. Secure Payment Gateway

For ticket purchases, I’ll integrate a third-party payment service like Stripe. I’ll ensure that all payment data is handled securely with HTTPS and strict backend validation.

5. API Rate Limiting

To protect the site from potential brute-force or DDoS attacks, I’ll use express-rate-limit to cap the number of login attempts and safeguard APIs.

6. Data Validation and Sanitization

Every form submission (e.g., signups, ticket bookings, or feedback) will be validated and sanitized to prevent injection attacks and maintain data integrity.

7. Secure Deployment

I’ll deploy the application using a platform like Vercel or AWS with HTTPS enabled and all sensitive environment variables securely managed.

Why This Matters

In today’s web landscape, users expect fast, functional, and—above all—secure applications. By implementing strong authentication and security measures, I can provide a trustworthy experience for users while building my own confidence as a developer.

For my band’s website, it’s not just about protecting data but also about delivering an experience where users feel safe engaging with our platform. As this project progresses, I’m looking forward to combining my passion for music with my growing expertise in web development.

Stay tuned for updates!

Conclusion

Learning authentication and security has been a transformative experience. It’s empowering to know that I can build not just functional but also secure web applications. With these practices in place, I’m confident my band’s website will stand out both as a showcase of our music and as a professional-grade portfolio project.

If you’re working on a web app and want to discuss authentication or security practices, feel free to reach out! I’d love to collaborate and learn even more.

Error Handling in Node.js

Josh Endemann — Thu, 21 Nov 2024 21:00:37 +0000

A Deeper Dive of my notes

Error handling is an essential part of building robust and reliable applications. Throughout my learning journey in the Node.js course by Jonas Schmedtmann on Udemy, I've gained valuable insights into how errors can be managed more effectively in a Node.js application. In this post, I'll explain some of the key error-handling techniques I've implemented to improve both development and production environments.

1. Custom Error Class: `AppError`

One of the first things I learned was the importance of creating a custom error class to handle errors in a structured way. By extending the built-in Error class, we can create errors that carry additional properties such as the status code and a flag indicating whether the error is operational or not.

For example, an error in my application can carry a message, a status code, and a status (whether the error is a "fail" or "error"). The isOperational flag helps differentiate between trusted operational errors (such as a user validation failure) and unexpected programming errors. This custom error class allows for standardized error responses and makes the error-handling process more efficient.

2. Centralized Error Handling Middleware

In any Express-based application, error handling needs to be centralized to ensure consistency across the application. By implementing a dedicated error-handling middleware, I was able to handle errors uniformly for both development and production environments.

In development, the error handler provides detailed information about the error, including the stack trace, which is valuable for debugging. However, in production, we avoid exposing sensitive error details to end users. Instead, the system sends a simplified error message, ensuring the user isn't overwhelmed with technical information. This helps protect sensitive application details while still providing helpful feedback when something goes wrong.

3. Handling Asynchronous Errors with Middleware

Asynchronous operations like database queries and API calls can often result in errors that are not handled properly. Without proper error handling, unhandled promise rejections can crash the application or cause it to behave unexpectedly.

To address this, I implemented a middleware that wraps all asynchronous route handlers in my application. This middleware automatically catches any errors from async operations and passes them to the next error-handling middleware. This approach eliminates the need to manually handle each asynchronous error in every route, simplifying the code and making it more maintainable.

4. Custom Error Handling for Database Issues

When working with databases, errors can arise from various situations such as invalid IDs, duplicate fields, and validation issues. I added custom handling for these errors to provide meaningful feedback to the user.

For example, when an invalid ID is provided in a request, the application returns a specific message indicating that the ID is invalid. Similarly, when a user tries to submit a value that already exists in the database (like an email address), the application returns a helpful message suggesting an alternative. This approach improves the user experience by clearly pointing out what went wrong and how they can fix it.

5. Handling Unhandled Promise Rejections

Unhandled promise rejections are a common issue in Node.js applications, where a promise is rejected but the error isn't properly handled. This can lead to the application failing silently or behaving unexpectedly. To prevent this, I added a global handler for unhandled promise rejections. When such an error occurs, the application logs the error details and shuts down the server gracefully. This ensures that the application does not crash suddenly and that resources are cleaned up before exiting.

6. Handling Uncaught Exceptions

Uncaught exceptions (errors that are thrown and not caught anywhere in the application) can also cause the application to crash or behave unpredictably. To handle this, I set up a global handler for uncaught exceptions. When an uncaught exception occurs, the application logs the error details and shuts down the server cleanly. This ensures that the application terminates properly, freeing up resources and preventing memory leaks.

Conclusion

These techniques have helped me handle errors more effectively and have given me a better understanding of how to build more resilient Node.js applications. As I continue to learn and implement more advanced concepts, I’ll be able to refine and expand my error-handling strategies further.

By having a centralized error-handling system and addressing common issues like unhandled promise rejections and database errors, I've been able to create a more stable and user-friendly application. I'll start to incorporate this into my band's website and I will keep improving my error-handling strategies as I move forward with my Node.js journey.

Next up I will be learning how to incorporate Users into the two projects. Can't wait!!

Overcoming Challenges with GridFSStorage Integration

Josh Endemann — Thu, 21 Nov 2024 02:25:28 +0000

Yesterday, I spent some time learning about Document, Query, and Aggregation Middleware, as well as validators in MongoDB. Feeling accomplished, I decided to shift gears back to developing my band’s website. My next task seemed straightforward: enabling my database to handle larger files using GridFSStorage.

Diving In: Research and Initial Setup

I began by researching the necessary tools and installed multer, gridfs-storage, and gridfs-stream. With the documentation in hand, I created a utility file for configuring Multer. Next, I moved on to my route handler and implemented a new POST('/upload') route. What seemed simple quickly spiraled into a larger, more complex task.

Debugging: The Unexpected Roadblocks

My first hurdle came with the persistent error:

upload.single is not a function.

After some investigation, I traced the issue back to my MongoDB connection. To resolve this, I moved the GridFSStorage setup into my server.js file to ensure proper initialization. With that adjustment, I resolved this particular error and was able to move forward.

However, as I tested file uploads via Postman, another issue arose:

TypeError: Cannot read properties of undefined (reading '_id').

This error baffled me. Console logging the file details revealed that the file was being created, but something was missing. Despite hours of troubleshooting, I couldn’t pinpoint the exact cause.

A Breakthrough: The Power of Community

After two exhausting days working in Wisconsin’s harsh weather and nights spent debugging, I turned to Stack Overflow. Within minutes, I found the solution: the version of MongoDB I was using wasn’t compatible with GridFSStorage. Downgrading to a compatible version solved the issue almost instantly.

Reflection and Moving Forward

This experience, though frustrating, turned out to be a valuable learning opportunity. It reinforced the importance of persistence and effective debugging. I documented the challenges and solutions in my coding journal, ensuring I’ll have a reference for future projects.

Looking ahead, I plan to dive deeper into error handling and tools like the ndb debugger as part of the Natours project. Meanwhile, for my band’s app, I’ll revisit the roadmap to determine the next priority. The journey of learning and building continues, and I’m ready to hit the drawing board again.

Sometimes, the path to progress is rocky, but it’s all part of the process.

Today’s Progress: Adding an Aggregate Pipeline

Josh Endemann — Tue, 19 Nov 2024 01:41:28 +0000

Introduction

Today, I focused on learning about the Aggregate Pipeline through the Natours project from a course on Udemy. The Aggregate Pipeline is a powerful tool for processing data in MongoDB, and I can see its significant value in various backend projects. Through the Natours project, I was able to implement aggregate pipelines for tour statistics and create a monthly plan.

Creating Tour Stats and the Monthly Plan

To get started, the instructor used an async function wrapped in a try-catch block to handle errors. For the tour stats, an aggregate pipeline was implemented using the Tour.aggregate method. The pipeline first matched the documents based on a minimum rating average, followed by a group stage that computed statistics like:

Number of tours
Number of ratings
Average rating
Average price
Minimum price
Maximum price

The results were then sorted based on the average price in ascending order.

For the monthly plan, the instructor set up a year variable by extracting the year from req.params.year, converting it into a number, and passing it into the pipeline. The pipeline started by unwinding the startDates array to output a document for each individual date. A match stage was added to filter tours within the specified year, with $gte (greater than or equal to) for the start of the year and $lte (less than or equal to) for the end of the year. The pipeline then grouped the documents by month and calculated:

The number of tour starts
The names of the tours (which were pushed into an array)

Afterward, the addFields stage was used to add a field for the month, and the results were sorted by the number of tour starts in descending order (-1 for descending). Finally, the results were limited to 12 months, showing data for a year.

Key Takeaways

The Aggregate Pipeline is undoubtedly an invaluable tool for backend development, particularly when dealing with large datasets that require complex queries and calculations. By using aggregation, I was able to extract meaningful insights from data, which will be extremely helpful for any future projects.

I’ve already practiced using the aggregate pipeline in my merchController.js for my band's website. Going forward, I'll experiment with more pipelines as I continue to build and refine my backend. One challenge I'll face is adding recording files to the tracks database and grouping them into albums, which will require careful planning and data modeling.

Next Steps

Having integrated the aggregate pipeline into my merchController, I plan to take a short break from this feature. Over the next few days, I'll focus on expanding my data sets, particularly by adding recording files for my band's tracks and determining the best way to group them into albums.

Additionally, I’ll continue working on the Natours project to further hone my skills with new tools and features.

Conclusion

Today was a productive learning day. As a developer with a family, I strive to make the most of my time. Recently, I’ve been maximizing my 1-hour commute to and from work by listening to the Udemy course. This allows me to absorb the lessons while spending time with my wife and kids at home. While listening and reviewing the content is helpful, practice remains key to reinforcing what I've learned.

Feel free to check out my GitHub repository for this project, and don’t hesitate to connect with me.

Today’s Progress: Implementing APIFeatures

Josh Endemann — Mon, 18 Nov 2024 00:10:25 +0000

Introduction

Today, I focused on implementing APIFeatures in my band's website. This functionality includes filtering, sorting, pagination, field limiting, and aliasing. I gained these skills from a Udemy course and applied them step by step to enhance my project.

Creating Sample Data

To start, I created a variety of products in my merchController. These included a Din hat, shirt, sweatshirt, CD, and vinyl. Each item had unique attributes such as different quantities and prices. This allowed me to test each feature against a realistic dataset and ensure my implementation worked as intended.

Step-by-Step Implementation

Initially, I built all the features directly within the merchController.js file. As I worked, I tested each feature using Postman to verify its functionality:

Filter: Allowed querying products by attributes like price or quantity.
Sort: Enabled sorting by attributes such as price or date created.
Pagination: Broke down results into manageable pages.
Field Limiting: Returned only specified fields in the response to reduce payload size.
Alias: Created an alias route (/top-5-merch) to display the cheapest merchandise.

Once all the features were functional, I refactored my code. I extracted the logic into a reusable APIFeatures.js utility file located in a utils folder. This improved the structure and readability of my code. I then imported APIFeatures into merchController.js and cleaned up the controller by replacing inline logic with modular methods from APIFeatures.

Key Takeaways

While refactoring, I learned how to effectively use this.query and this.queryString in place of req.query and query. This approach made the code more reusable and modular. I also revisited how to use Postman to test features, entering various query parameters to confirm the functionality of my code.

Additionally, I implemented an alias for the route /top-5-merch. This feature displays the cheapest merchandise in the database. Moving forward, I plan to incorporate similar aliases in other controllers. For instance, I envision creating a "top tracks" feature to showcase the most-played or most-liked songs once fans can "like" tracks.

Next Steps

Now that I have integrated APIFeatures, I will continue learning through my Natours project. Practicing new concepts from the course in both projects has proven to be an effective way to solidify my understanding. I will keep building on this foundation and add new features as I progress.

Conclusion

Today’s work was a significant step toward making my band's website more robust and user-friendly. By focusing on practical application and refactoring, I improved both the functionality and maintainability of my project. I’m excited to continue this journey and further enhance my skills.

Feel free to check out my GitHub repository for this project here, and don’t hesitate to connect with me!

Week in Review: Progress on My Band’s Web Application Backend

Josh Endemann — Sat, 16 Nov 2024 15:21:48 +0000

This week, I focused on building the backend for my band’s web application. My primary tasks included developing routes, defining schema models, and setting up controllers, all while successfully connecting the application to a MongoDB Atlas database.

Challenges and Solutions

One of the initial hurdles I faced involved troubleshooting naming inconsistencies across exports and imports. Through debugging, I resolved these issues by carefully aligning names in my codebase.

Another significant challenge was connecting the app to the MongoDB database. After some investigation, I discovered that the <PASSWORD> placeholder in my config.env file didn’t match the <password> key referenced in the server.js file. Once corrected, the connection was established successfully.

Progress So Far

With the connection in place, I tested the endpoints using Postman. I started with the merchandise routes, as they were straightforward to validate. I then tested and documented all available endpoints for the Albums, Merch, Shows, Webcasts, and Tracks models.

Current Focus

I am currently implementing advanced API features to enhance functionality, including:

Sorting
Filtering
Advanced filtering
Field limiting
Pagination
Aliasing

Next Steps

Once the API features are complete, I will shift my focus to user authentication. My plan includes creating separate sign-up and login functionality for both fans and band members. Additionally, I will address error handling and begin refactoring my code to adhere to the DRY (Don’t Repeat Yourself) principle, improving maintainability and readability.

This week has been productive, with significant progress made in laying a strong foundation for the application. I’m excited to continue refining and expanding the project in the coming weeks!

Building a Music-Focused Web App for my band: Progress and Next Steps

Josh Endemann — Thu, 14 Nov 2024 01:54:02 +0000

Over the past few days, I’ve made significant progress on a web app designed for my band, where users can sign in, explore albums and live shows, download music, donate, and learn more about the band. This project is built with the MERN stack (MongoDB, Express, React, and Node.js), and I’m excited to share the new features I’ve been working on.

Recent Progress: Band Member & Fan Features
One of the main areas I’ve been focusing on is building out the core models and controllers for the app. These structures are key to ensuring smooth functionality as users interact with the app. Here’s what’s new:

Band Member Authentication: I’ve set up a bandMember.js model, which stores the band members' information like their name, role, and instrument. This model also supports authentication, so band members can log in securely using their credentials. The app uses JWT tokens for secure logins, ensuring that only authorized band members can access sensitive data like tour dates, setlists, and upcoming shows.

Fan Authentication: Fans can also create an account to log in and interact with the band’s content. The Fan.js model stores fan profiles, including favorite albums, shows they’ve attended, and other personalized details. Fans will eventually be able to interact more deeply with the app, such as commenting on shows, albums, and webcasts, and even liking tracks and performances.

Interactive Features for Fans: Fans won’t just be passive viewers of the app. I plan to implement features where they can like and comment on tracks, albums, live shows, and webcasts. This will allow them to engage more with the band’s content and become part of the community. These interactions will be stored and displayed on their profiles, and eventually, fans will be able to follow specific albums or shows to receive notifications about updates.

Webcast and Show Controllers: I’ve also been working on controllers for webcasts and shows. Webcasts will allow fans to tune in to live broadcasts of events, while the show controller will manage concert details, including tour dates, venues, and setlists. These features will help fans stay up to date with the band's live performances.

Keeping the Code DRY
A major focus for me has been ensuring that the code remains clean, efficient, and easy to maintain. This means reducing repetition and focusing on reusable code. To achieve this, I’ve:

Centralized Error Handling: I’ve implemented an error handling middleware that consolidates all error management into one place, making the codebase more manageable and ensuring that errors are handled consistently across the app.

Reusable Validation Middleware: Input validation has been standardized using middleware to ensure that all data passed into the app is correct and well-formed. This reduces the need to repeat validation logic in every route handler.

By making these improvements, I can add new features without bloating the code and keep everything manageable as the app scales.

Next Steps
Looking ahead, there are several key features I plan to work on next:

User Authentication (JWT): I will be refining the user authentication system for both fans and band members to ensure a smooth and secure experience.

Like and Comment Features: As mentioned, I plan to allow fans to interact with tracks, shows, albums, and webcasts by liking and commenting on them. This will help build a more engaging community around the band.

Testing and Bug Fixes: Once these features are integrated, I’ll focus on testing the app to ensure everything works as expected. I’ll also tackle any bugs or performance issues that arise during testing.

User Notifications: Fans will eventually be able to receive notifications about new shows, webcasts, or album releases. I’ll be implementing a system for sending notifications based on their preferences.

Conclusion
The app is coming together nicely, and I’m excited about the features on the horizon. By building a robust, interactive platform, I’ll be able to provide a deeper connection between the band and our fans. Stay tuned for more updates as I continue to build out the app, and I look forward to sharing more in the near future!

Exploring MVC Architecture and Applying It to My Natours Project

Josh Endemann — Mon, 28 Oct 2024 01:54:57 +0000

Introduction to MVC Architecture
Today, I delved deeper into the Model-View-Controller (MVC) pattern, a fundamental design structure for organizing code in web applications. The core purpose of MVC is to separate the app’s components into three main areas, ensuring that each part has a single, focused responsibility. By understanding and implementing MVC, I’m not only making my project more manageable but also laying the foundation for future scalability.

Breaking Down MVC

Request Initiation:
Every interaction starts with a client request to the server, triggering the MVC process.
Router:
The router intercepts this incoming request and directs it to the correct controller based on the defined route and request type.
Controller:
Acting as a central coordinator, the controller processes the business logic and works with models to retrieve or modify data when necessary.
Model:
Models handle direct interactions with the database, taking care of any resource access or updates required.
View:
Once data is prepared by the controller, it is passed to the view layer. The view converts this data into a user-friendly format that the client will receive.
Response:
The view is sent back to the client as the final response, completing the cycle.

In essence, this cycle demonstrates the MVC flow, promoting a clean separation of responsibilities and making data handling more efficient.

Separating Application Logic and Business Logic
When organizing code with MVC, it’s crucial to differentiate between Application Logic and Business Logic, as they have distinct roles.

Application Logic:
Purpose: Handles the structural and technical aspects of the app, focusing on how the app functions without addressing the specific business problem it aims to solve.
Responsibilities:
Managing requests and responses.
Acting as an intermediary between models and views.
Maintaining the app’s technical workflow and structure.
Business Logic:
Purpose: Directly addresses the specific business problems the application is built to solve, enforcing business rules and workflows.
Responsibilities:
Ensuring that business needs are accurately represented in the app.
Enforcing business rules, such as:
Validating user inputs.
Creating new resources, like tours, in the database.
Managing permissions for actions (e.g., allowing only users who’ve purchased a tour to leave reviews).
Although there may be overlap, keeping application and business logic distinct is a powerful way to maintain a clean codebase.

Refactoring My Natours Project with MVC
In the Natours project, I began implementing MVC architecture by moving the tour schema and model into a separate tourModel.js file and assigning controller functions to manage business logic. This setup bridges the model and view layers with dedicated controller functions, organizing the project in a way that will make it much easier to expand and adapt in the future.

Refactoring for MVC has already made the project more organized and scalable. This approach sets a solid foundation for handling future features, integrations, or even scaling the application without creating excessive complexity.

Final Thoughts
Revisiting MVC today has been a real eye-opener. Breaking down each layer has shown me just how crucial separating responsibilities is for keeping projects scalable and maintainable. This clarity in MVC is already helping me build out Natours with a more organized, adaptable structure—one that’ll be much easier to grow over time.

Working with MongoDB.

Josh Endemann — Mon, 28 Oct 2024 01:05:22 +0000

In the past week, I’ve been diving deeper into backend development for my Natours project. A key part of this journey has been learning about MongoDB and how to implement it effectively. The transition has been eye-opening, especially as I explore MongoDB’s flexibility and ease of use in handling data for web applications. Here’s a breakdown of my experience, challenges, and insights as I started integrating MongoDB into Natours.

Why MongoDB?
MongoDB is a popular choice for developers building applications where data structures may be flexible, and it’s particularly well-suited for projects where document-based storage is advantageous. MongoDB’s NoSQL model allows for scalability and easy adjustments, ideal for the kinds of dynamic and user-driven features I’m implementing in Natours. The more I learn about MongoDB, the more I appreciate its flexibility compared to traditional relational databases.

Setting Up MongoDB Atlas and Compass
The first step was setting up MongoDB Atlas, a cloud database service that provides a fully-managed, scalable environment for MongoDB. Using Atlas makes it easy to get started without the need for a local installation, and it also comes with useful features like automated backups and monitoring tools.

Here's a quick overview of my setup process:

Atlas Account Creation and Cluster Setup:

I created an account on MongoDB Atlas and set up my first cluster. The Atlas UI guided me through choosing a free tier, configuring basic settings, and creating a database user with secure authentication.
Connecting to Atlas:

Once the cluster was up, I generated a connection string that I would use in my application. The MongoDB Atlas dashboard allows users to create and customize these connection strings with options like specifying database names, authentication credentials, and network restrictions.

Using Compass for Database Management:

I also installed MongoDB Compass on my Mac, which provides a GUI for exploring and managing MongoDB data locally. Compass has been a fantastic tool for visualizing the data structures, analyzing query performance, and even crafting complex queries as I refine the project’s backend.
Integrating MongoDB with the Natours Project
After setting up my database environment, the next step was to connect MongoDB to my project using the Mongoose ODM (Object Data Modeling) library. Here’s a look at how I implemented this integration:

Configuring Environment Variables:

I added the database connection details to a new config.env file in my project, ensuring sensitive information like credentials and database URLs stay secure. Environment variables are essential for securely managing application settings and configurations, and using them allows me to easily switch between different environments.
Setting Up Server Connection:

In my server.js file, I used the Mongoose connect method to establish the connection to the Atlas cluster. Here’s a snippet of how the connection code looks:

javascript
Copy code
const DB = process.env.DATABASE.replace(
'',
process.env.DATABASE_PASSWORD
);

mongoose.connect(DB, {
useNewUrlParser: true,
useCreateIndex: true,
useFindAndModify: false,
useUnifiedTopology: true,
}).then(() =>
console.log('DB connection successful!')
);

Creating the First Schema and Model:

I started with a basic tour schema and model to represent tours within Natours. I defined fields like name, rating, and price, including validation rules to ensure data integrity. Here’s a simplified version of the schema setup:

javascript
Copy code
const tourSchema = new mongoose.Schema({
name: {
type: String,
required: [true, 'A tour must have a name'],
unique: true
},
rating: {
type: Number,
default: 4.5
},
price: {
type: Number,
required: [true, 'A tour must have a price']
}
});

const Tour = mongoose.model('Tour', tourSchema);
Testing the Database Connection:

To verify everything was working, I created a test tour entry with a save() method. This allowed me to confirm that my schema was correctly set up and that data was being stored as expected in MongoDB.
Working with MongoDB’s Document Model
One of the standout aspects of MongoDB has been its document model, which allows data to be stored as flexible, schema-less documents. This makes it easy to adjust the structure as the project evolves without requiring extensive refactoring. Learning to work with MongoDB has taught me the importance of planning database schemas carefully, especially when handling relationships between data models in a NoSQL environment.

Challenges and Lessons Learned
As with any new technology, there have been challenges along the way. Some issues I encountered included:

Deprecation Warnings: I encountered some deprecation warnings from Mongoose, which I resolved by adding options like useUnifiedTopology: true.
Error Handling: Handling duplicate entries was another area where I had to adjust my code to avoid issues with MongoDB’s unique constraints.
These experiences have improved my troubleshooting skills and taught me a lot about managing a NoSQL database effectively.

Next Steps and Goals
I’m excited to continue building out Natours and applying what I’m learning about MongoDB and Mongoose. My next immediate step is to expand on the data models, adding new schemas and incorporating advanced Mongoose functionality like virtuals, query middleware, and data validation.

After solidifying my backend knowledge, I’ll be moving on to frontend development, where I’ll dive deeper into React with Next.js to round out my full-stack skills.

Having worked with MongoDB before, I’m excited to be diving back in and deepening my experience with this technology. It’s been great to get reacquainted with MongoDB, and I’m thrilled to be building more hands-on expertise as I integrate it into the Natours project. I am looking forward to documenting my experience as I continue to build the Natours project. Stay tuned for more updates and feel free to reach out!!

DEV Community: Josh Endemann

Delving Back Into React: Building a Website for a Local Construction Company

The Project: A Website for Down to Earth Contractors

Key Features of the Website

Responsive Design

Dynamic Content

Contact Form with EmailJS

A React Refresher

The Process of Building

Planning and Structure

Challenges and Solutions

EmailJS Integration

Styling the Navbar

Enjoying the Journey

Looking Ahead

Conclusion

Building a Band Website: Navigating the Backend Challenges with Roles and Permissions

Setting Up the Comment Controller, Route, and Model

Ensuring Routes Work Seamlessly

Roles and Permissions

What's Next? Moving Forward

My Journey Through Modeling Data and Advanced Mongoose: Lessons Learned

1. The Power of Mongoose Schemas

2. Virtual Properties and Indexes

3. Advanced Query Features

4. Referencing and Embedding Data

5. Using Data Validation to Improve Data Quality

How This All Fits Into My Band’s Website

6. Challenges and Growth

What’s Next?

Authentication and Security in Web Development: Lessons Learned and Implementation Plans

Key Lessons on Authentication and Security

1. The Fundamentals of Authentication

2. Authorization and Access Control

3. Data Validation and Sanitization

4. Password Reset Mechanisms

5. Rate Limiting and Brute Force Protection

6. Secure App Configuration

How I’m Applying This to My Band’s Website

1. User Authentication with JWTs

2. Password Security

3. Role-Based Authorization

4. Secure Payment Gateway

5. API Rate Limiting

6. Data Validation and Sanitization

7. Secure Deployment

Why This Matters

Conclusion

Error Handling in Node.js

A Deeper Dive of my notes

1. Custom Error Class: AppError

2. Centralized Error Handling Middleware

3. Handling Asynchronous Errors with Middleware

4. Custom Error Handling for Database Issues

5. Handling Unhandled Promise Rejections

6. Handling Uncaught Exceptions

Conclusion

Overcoming Challenges with GridFSStorage Integration

Diving In: Research and Initial Setup

Debugging: The Unexpected Roadblocks

A Breakthrough: The Power of Community

Reflection and Moving Forward

Today’s Progress: Adding an Aggregate Pipeline

Introduction

Creating Tour Stats and the Monthly Plan

Key Takeaways

Next Steps

Conclusion

Today’s Progress: Implementing APIFeatures

Introduction

Creating Sample Data

Step-by-Step Implementation

Key Takeaways

Next Steps

Conclusion

Week in Review: Progress on My Band’s Web Application Backend

Challenges and Solutions

Progress So Far

Current Focus

Next Steps

1. Custom Error Class: `AppError`