Search for a command to run...
Hey 👋🏻 !
I'm Kevin, a full-stack developer running a digital prototyping company with my business partner called Spin Up.
When I'm not consulting and building for clients, I'm writing content here, curating my newsletter or creating videos.
Outside of work, I enjoy handing out with my wife and sons - camping, hiking and kayaking or just curling up with a good book.
No comments yet. Be the first to comment.
We'll discuss why React applications need servers and how to build them in Next.js without using a custom server.
There is so much to say about authentication, right? Not only that but everyone seems to have very definite opinions about the perfect setup. Since most of my time is spent building rapid, digital prototypes - I tend to find myself leaning on 3rd pa...
SVGs are great! They are scalable vector graphics. As they are vector based they can be scaled to be huge or tiny and they won't pixelate. They are made up of XML describing the paths and shapes needed to make the final image. They are an excellent c...
One of the strengths of using WordPress as your content backend is that you have a lot of choice. You can decide where to host your instance, how to organise your content types and how many different users and roles you want to introduce. I don't kno...
I realised last night that I've been writing a lot about why Headless WordPress is a great solution but haven't been clear about what headless actually means. Every website or application that you use is made up of at least two components. There is t...
I think being able to code is a super power. I also think that we are often too quick to use this super power. https://twitter.com/dolearning/status/1319262958279643137?s=20 A week ago, a friend who works for a charity approached me. They were using ...
I'm a big fan of the JAMStack and WordPress. I think they are excellent companions, adding value both to content creators and developers. I'm glad to say, I'm not alone. However, it doesn't take long before you come across the view that this combinat...
With Next API routes serverless functions become much more accessible. But in a serverless world, maintaining a connection with a database isn't achieved in the same way.
Previously we may have provisioned, maintained and benefited from persistent servers. When our server starts, it connects with and maintains a connection to our database.
Any web-request that requires information from the database would use this connection.
Here is how I might have achieved it with Mongoose & MongoDB.
const mongoose = require('mongoose');
require("dotenv").config();
mongoose.connect(process.env.MONGO_URL, {
useNewUrlParser: true,
useFindAndModify: false,
useCreateIndex: true,
useUnifiedTopology: true,
});
const db = mongoose.connection;
db.on('error', console.error.bind(console, 'MongoDB connection error:'));
Once declared and bound, this database connection is available throughout the application. We can carry out read/write operations to our database and gather the content for our clients.
In high-traffic situations, you have a few options. They are generally quite manual though. If you get a lot of traffic, you could increase the pool of connections. This allows for multiple requests and responses to be dealt with simulataneously. You could also increase the number of servers to handle the requests, behind a load balancer normally. Or, you could heavily cache your responses allowing for less demand on the database layer.
With Next, each API route is deployed as a serverless function. As one of these routes is accessed, the function spins up and processes the request. For some time after that request, the environment remains active.
Previously, we have been able to assume that the connection is alive. Now, like Schrödinger's cat, it could be either alive or dead. Until we observe it.
Our code then changes then to check whether we have an active connection.
// /utils/db.js
import mongoose from "mongoose";
require("dotenv").config();
export default async () => {
// here is where we check.
if (mongoose.connections[0].readyState) return;
try {
// Using new database connection
await mongoose.connect(process.env.MONGO_URL, {
useNewUrlParser: true,
useFindAndModify: false,
useCreateIndex: true,
useUnifiedTopology: true,
});
console.log("Connected to database.");
} catch (error) {
console.log("DB error", error);
}
};
The other consideration is that each specific route is atomic. This means that we need to check for the database status in each route rather than centrally. So, our utility from above needs to be imported and used on every route.
import connectToDb from "utils/db";
export default async (req, res) => {
await connectToDb();
...
};
Now that every route is handled separately, our environments will automatically provide more of that route if it is needed. We don't have to keep a server up and running when we don't need it. We also don't have to provide a whole new server if it is only one or two routes that are being requested more often.
Serverless doesn't mean no server, but rather no server that we are responsible for! These functions are generally very reliable. Not only that, if one crashes another will spin up to take its place.
Thoughts or ideas? Let me know if I'm missing anything, here or on Twitter.