The Lockdown Coder: Next.js vs Create-React-App. (Undercard: Persistent Data)
My coding journey started in March 2020 and at this point in my story it is September 2020 and I have been fully immersed for 6 months. For the first two months I had learned Dart and Flutter. The next four months thereafter I had covered HTML, CSS and Javascript to use within React and Node.js. I was getting jaded and a little weary with the chopping and changing and not settling on a solution or stack that worked for me.
Server-side rendering and Next.js was the latest tech that had piqued my interest and forced me to consider whether I was losing focus and should simply stay the course with Create-React-App. Before committing to a new framework and learning all over again I needed to read up more on Next.js. It didn’t take long to persuade me; honestly, the more I read the more I was convinced this was some serious kit worth spending time on. Netflix, Uber and Twitch are using it and they’re some heavyweight organisations. With a puff of the cheeks and a deep sigh I started to get into it by re-writing one of my previous projects: a medical consultancy website for a friend of mine.
What’s so good about Next.js anyway?
Like Create-React-App, there’s an easy one-line code to set up a Next.js app: npx create-next-app my-app . You now have a directory called my-app with the bones of a Next.js app ready to go. Next.js is another React framework that makes it easy to create yourself a React app so I wasn’t learning something completely foreign but I needed to get to grips with how Next.js is structured differently.
For example, previously I was using react-router-dom to manage the routes within my app. Next.js has a default directory called /pages and any file you include in the /pages directory is automatically available as a route. Easy!
On the server-side I was using Express and creating my own custom Node.js server. Next.js has a default directory called /pages/api and any file you include in the /pages/api directory is automatically available as an API endpoint. You are required to write Node.js code for the files in this directory — and just like that, suddenly you’re coding in the back-end. The learning points from using Express can mostly be applied here too.
The knockout blow for me is static site generation combined with getStaticProps — allowing you to fetch data at build time. If your site does not need up-to-the-second data from an API (e.g. fetching a list of categories for an online clothing shop) then fetching this data at build time means Next.js has a version of the data it can serve up to users and it’s lightning fast because there is no waiting time for fetching it. To go one step further, you can actually configure getStaticProps and set a time for revalidation. For example, if I set revalidate: 60 then my app will initiate a data fetch every 60 seconds and when the new data is available it will be served up to users instead — handy for blogs. Now there is no need to re-build your app in order to fetch new data.
There is a whole lot more that Next.js offers out-of-the-box especially when it comes to optimisation and I have been impressed with it. It’s worth looking over the developer documentation and getting a feel for what else it can offer you.
Data is King
Having jostled with Next.js and Create-React-App it’s time to turn the attention to data. If we want dynamic apps we need data, pure and simple. I’ve covered how I have used REST APIs to fetch external data and I explained how React hooks can help manage local state. However, I have yet to touch on databases even though it is something that I needed and had learned to incorporate much earlier on in my coding development.
There are many databases and one popular one is Mongo DB. In fact, it is so popular that it is part of the MERN stack, which you may have heard of. MERN stands for Mongo DB, Express, React and Node: four key technologies that provide a full-stack (front-end and back-end) solution for building modern day apps. So, now you know how impressive Mongo DB is — except I didn’t realise it when I was starting out and went with Google Firebase instead!
Google Firebase is impressive in its own right even though it’s not mentioned in any acronyms I know of. Firebase is a collection of tools you can use to build your app. It has two database options: Cloud Firestore and Realtime Database. However, what drew my attention to Firebase in the first instance wasn’t actually the databases but its Authentication tool. It makes it super easy to create login and sign-in pages with email/password or Google sign in authentication. Firebase can be a useful resource to consider when building out an app as it can support you with databases, authentication, cloud storage and hosting. Nevertheless, you’ll want to check out their pricing structure to make sure it works for you although there is a generous free tier that will satisfy many developers.
Cloud Firestore took a little getting used to as it is a NoSQL database and organises data into collections and documents and makes it OK (!) to duplicate data. Data is synced in real-time so you have access to the latest data when you need it, which is handy if you want to create a messaging app, for example. There’s a bit of configuration you’ll need to go through in order to setup Cloud Firestore for your app but once you figure it out it’s a decent database you can rely on.
Whenever I did any reading around databases I kept coming across CRUD. It stands for Create, Read, Update, Delete: the four basic functions of persistent storage. You’ll want to figure out how to do each of these four functions with any database you choose. The word ‘persistent’ also tends to crop up and this relates to the lifespan of data, if you will. For example, we have a simple text input on a page and we type, “Hello” into it. If we refresh the page then we lose the data and we’ll see an empty input again. If we need the data to ‘persist’ we would expect to see “Hello” in the input even after we refresh the page. There are different ways to achieve this.
Using a database like Firestore could be an option. You save the word “Hello” into a specific location in Firestore and the app checks this location when it renders the page and displays a value if one exists.
The browser itself can also store data through local storage or session storage. Data held in session storage persists as long as the tab remains open. Close the tab and you lose the data. Data held in local storage persists longer, across browser sessions with no expiration date so even when you close your tab and browser you can reopen it and the data will still be available to you when you navigate to back to the website.
Redux and React: A match made in heaven?
When we need to pass data around our app, as with everything related to coding, there are many ways to achieve it depending on what you need. With React Hooks, you can rely on useState to set a value and call that value from wherever you need. In conjunction with API calls this is a useful way of storing and using data within a component but this data does not typically persist. However, you can pass the data to other components as props so you have access to this data in those components in a cascade-like fashion. This is a handy feature but when you want to pass data to a component that is not immediately accessible in the ‘parent’ component (where the source of the data is held) it quickly becomes problematic.
Enter Redux. Redux was covered in the freeCodeCamp course and is a library that helps you manage application state. After you set up a Redux store you can save data to the store from anywhere in your app and retrieve the data from anywhere you want also. It makes it very convenient to work with data. Setting it up isn’t totally straightforward and it might make you think twice about using it (you’ll be thinking actions, reducers, type, what?) but once you’ve got the hang of Redux it is a really useful tool. I know other developers talk about using context to pass data around in your app and I have tried it briefly and thought it was great but I have only dabbled. It’s worth a look into.
Data is a deep subject and you may well find an approach that works better for you. For what it’s worth, I would like to try Mongo DB to see how impressive it really is but at the moment I’m drawn to Headless CMS (Content Management System) solutions and using this as my primary data source. Find out what I’m talking about with Headless CMS in the next story.
Part 1: What I managed in 12 months with no coding experience
Part 2: Getting to grips with Flutter
Part 3: Beyond mobile apps and into the web
Part 4: Building on my React foundation
Part 5: Components and classes and hooks, oh my!
Part 6: Next.js vs Create-React-App. (Undercard: Persistent Data)
Part 7: Headless WordPress, WooCommerce and Stripe
