Inspired by this tweet, and the whole podcast episode, I've deiced to give a simplistic search with RSC a try.
npm install
npm run init
npm run seed
npm run dev
-
The RSCs make fetching directly from the DB an effortless action.
-
To be perfectly honest, I'm not sure that is a good thing. It might lead to very brittle codebases with server-code mixed with FE code.
-
When working in larger codebases, the separation of concerns is paramount. If you do not separate different code "areas", you will get lost within spaghetti code.
-
Of course, not everyone works with larger codebases. If you have a small app, fetching in RSCs directly via DDB query makes perfect sense.
-
-
-
Regardless of your opinion on the 👆 is, you have to agree that the ability to use Node libraries and functions in RSCs is fantastic.
-
Next.js is getting quite complex with the number of configuration options. The app directory is NOT ready and has subtle bugs. It is a very good thing that they call the feature "beta", but I guess a lot of people will still depend on its features for mission-critical apps.
- For example, I wanted to cache per search param value, mainly the
name
parameter. I could not achieve this via Next.js configuration, and when I did not force the page to be "dynamic" next decided to treat it as static page. This is a regression. It seems like they broke something.
- For example, I wanted to cache per search param value, mainly the
-
No matter what I did, I could not force the
fetch
to function as described in the docs. Maybe it was because I was using thepages
API routes?- Well, the route handlers feature broke as soon as I added
?
name=...` to the URL.
- Well, the route handlers feature broke as soon as I added