Introduction

I am back. My attention was not so briefly stolen away, but now that's over and I'm back and hoping to pick up where I left off. Starting with finally writing this post. I think I originally went through this material back around the beginning of October, but it was so... inconsequetial to learning specifically Next.js that I put off writing up an analysis of my experiences until it fell through the cracks.

So I'm reading through the material again and reacting fresh.

And then I'm gonna move on to something more interesting and fun hopefully.

This chapter was about fetching the data for the database I just seeded. Which, admittedly, that is pretty fun

Topics covered

1. Learn about some approaches to fetching data: APIs, ORMs, SQL, etc.
2. How Server Components can help you access back-end resources more securely.
3. What network waterfalls are.
4. How to implement parallel data fetching using a JavaScript Pattern.

My biggest strengths here are definitely with APIs and SQL. ORMs (...Object Relational Models?) may well be a term I've heard before, but I couldn't explain it right now (I haven't actually reread the material yet; I'm writing this in real time). That means it's either something I haven't used in work before, or its so elementary that my brain discards the information (See also: whatever CRUD stands for¹).

I have a vague sense of what network waterfalls are as a concept, and parallel data fetching are what I am here for.

On the topic of APIs

APIs are great in my book. Maybe there's a better way to do what they do that I haven't been introduced to. Technology, norms and best practices can change so quickly and I am still not on the mailing list for the newsletter (and also many companies in my experience are just set in their ways, relying on methods that work and are predictable, even if they're not the very best).

But basically, APIs are a layer of abstraction that hide the inner workings of your application, in this case your database. Rather than expose the sensitive bits of your project, an API is the equivalent of building a special button (or maybe a doorbell?) with a specific purpose. A call is made (the doorbell is pressed), and the result is tightly regulated. Maybe the doorbell expects something before it works. Authentication. Authorization. An offering of data. Or else it rejects the call.

The beauty is, the doorbell presser never really gets a chance to peek beyond the door. If you have a database, you are keeping the precious database secrets safe. If you want the client to be able to gain access to the database's contents, all they need to do is ring the doorbell. The API will perform the operation and return the result to the client, who remains outside of the door.

Have I explained it enough yet? I am really quite proud of my doorbell analogy.

In the case of the Next.js tutorial, it makes a point of highlighting two uses of APIs irl:

1. Many third party services use an API
2. "If you're fetching data from the client, you want to have an API layer that runs on the server to avoid exposing your database secrets to the client." (basically what I just said)

Potential downsides? Idk. Like I said, I've used these a lot in the past, and it's possible the industry may have moved on, declaring something else to be the new "best practice". I suppose there is a consideration of balance to be made: how much functionality does each doorbell manage? I've been on projects that perhaps... overload an API with too much responsibility. And perhaps the opposite as well: too many APIs that could be consolidated for cleaner code.

Regardless, they are fun. And (as I understand it), they are not a thing so much as a concept. In Next.js, APIs are implemented via route handlers.

On the topic of Database Queries...

I know how to write SQL queries. More than the very basics. I'm quite proud of that fact. I'm not sure what the extent of my database knowledge is, but I can certainly handle CRUD.

Anyway, according to this section, ORMs are maybe an alternative to writing raw sequel queries? But literally no details are given, including the full acronym. ORM itself links to the "Postgres on Vercel" page in Vercel's documentation. They don't see fit to explain it (to be fair, they didn't really see fit to explain SQL either), so I'm guessing it's just not all that relevant in the Next.js tutorial project. Probably could be cut?

There are two cases given for when you may need to know SQL (and maybe but probably not ORMs):

1. When you're implementing the logic behind an API (and need to write the necesarry queries)
2. When you're quering the database directly for whatever reason from the react server components.

React Server Components that Fetch Data

Next.js applications recommend using React Server Components, at least according to the official documentation. I suspect it's possible that consulting Next.js user communities could have alternate recommendations. But fetching data using these React Server Components is allegedly still considered a relatively new approach, with some benefits:

1. Native support for asynchronous tasks like data fetching via Javascript Promises (something I have some prior experience with). It also mentions useEffect and useState or other "data fetching libraries" (something I do not have prior experience with)
2. You can keep all data fetching operations on the server: There's no back and forth with the client outside of sending the result
3. Another benefit of keeping things server side: you have direct access to query the database. No need to call/write a separate API

Why to know/use SQL (really quick)

1. Versatile
2. Industry Standard
3. Transferrable
4. the postgres.js library provides protections and SQL Injection attacks²

The rest of the chapter focuses on inserting the tutorial code into the tutorial application. TBH, it's been so long (> 50 days) since I first completed this section that I'm probably going to have to come back and review this. For my own purposes, I will need to create some basic databases to store user information (a bare minimum, I assure you!) and track book reading progress.

But honestly, for the sake of my patience and my passion, I need to put this chapter behind me now. (Does everyone feel like that sometimes?)