GitHub: https://github.com/TomMirfin

LinkedIn: https://www.linkedin.com/in/tom-mirfin/

No, I haven't taken up gardening! Seeding is a way of working with SQL and JavaScript together as one, we also tried our hand at some Endpoint testing.

This blog may be a bit shorter than others as I am currently working on a full backend project for the course!

Monday -Seeding 🌱

Seeding is a way to put large amounts of data into a database programmatically, before now, I was manually inputting a fairly large amount of data manually into the database but, in the real world, this could be thousands, even millions of lines of data. Nobody wants to be doing that by hand!

In steps seeding - with some clever lines of JavaScript combined with SQL inputs, you could input one line or a million lines of data, it works all the same.

It goes a little something like this:

This is a lot to read (and even more to understand) but essentially this code is creating some tables, and entering some data into the tables. Easy, right?

The answer is actually no, in fact, the code snippet above is from a database I created over the weekend so I could fully understand the concept in more detail. I am very glad I did as it really cemented some difficult concepts we were working on throughout the week.

Tuesday - Super Test! 🦸🏻‍♂️

So, what do we do with this data once it is safely inputted into our database? Well, just like on many popular websites, users often want to access that data. This is typically done through API endpoints. For example, a request to retrieve coding-related information from a hypothetical database might look like this: https://api.example.com/coding.

To make these reliable they need to be tested, in comes SuperTest! ST is a way of testing endpoints to make sure they work in the intended way, this also includes error handling.

So, I make calls to the API, some I expect to work and give me a desirable response, and some I don't expect to work but throw me the correct error!

So for example here I'd write a test that gives me an array of treasures objects, within the object I've told ST that I need each object to look a certain way for me to be able to pass the test, if everything is good, we also get a status of 200.

And here is a test for a bad request, I'm sure we have all seen bad request 404 in our time!

There is obviously a whole lotta code going on in the background to get these tests to work but this is a nice whistle-stop tour.

By the end of Tuesday, I was feeling the burn once again, the pace of the course was as relentless as ever and I did feel like I was falling behind in my understanding!

Wednesday - Middleware

On Wednesday, we delved into the world of middleware, a concept graciously offered by Express! Express allows us to leverage middleware functions for enhanced control and functionality. Unlike promises, which often involve the use of .catch(), middleware in Express operates slightly differently in terms of error handling. Instead of a direct correlation with .catch(), we utilize middleware functions and tap into Express's robust error-handling mechanisms.

To illustrate, let's consider a scenario: imagine an error arises in our code. With middleware, Express catches this error and gracefully hands it over to an error handler. This error handler, in turn, channels the issue to a separate error function, ensuring a streamlined and organized approach to managing errors within our application.

This abstraction might seem complex, but it proves invaluable in maintaining code clarity and handling errors effectively. As we continue our journey through Express, we'll explore real-world examples that showcase the practical application of middleware in error-handling scenarios. So buckle up, as middleware becomes a powerful ally in our Express adventures!

Thursday - .env.test / .env.development

When conducting tests on our database, it's crucial to operate with two distinct databases. This ensures that the data crucial for our real-world applications remains intact and unaffected by testing procedures—after all, nobody wants their personal data messed with by developers!

Beyond preserving the sanctity of our production data, employing separate databases comes with an additional advantage: the ability to use distinct environment variables. This not only enhances security but also allows us to conceal any sensitive information that we wouldn't want to be publicly exposed. As we navigate the intricacies of database testing, this dual-database approach proves invaluable in maintaining data integrity and safeguarding user privacy.

Friday - Complex Queries

When querying a database, things can get messy very quickly, some queries are huge and we need a way to be able to break these down into smaller chunks.

Although this code may look quite weighty, we essentially start with a standard query string of `SELECT * FROM treasures` which would select all of the columns associated with the treasures table.

Underneath the query string, there is a lot of conditional logic depending on what we want out of the table. For example, if the user wants the ages sorted by Age in ascending order we would then add this statement to the original query string resulting in a query of SELECT * FROM treasures ORDER BY age ASC

This code base was the largest I have worked on by this point and I had to remind myself to continuously break things down into smaller pieces.

<footer>

What. A. Week. I came out of this week feeling very overwhelmed. Even looking back now writing this post a week later it feels like an age since we covered some of these topics. This week was by far and away the most difficult on the course and I know a few of us felt it.

Although I would not normally advise this, as I previously mentioned, I did recreate the project we worked on through the week, by myself from scratch (it's also on my GitHub). It really did help with my understanding of everything we covered during the week. But also gave me fairly high blood pressure.

Next week (now this week) I am completing my first backend project on which the front end will be built. it's a big week!

</footer>