Collecting user emails on a Gatsby site with Vercel Serverless Functions and MongoDB
April 17, 2020
"...though modern Americans have more choice than any group of people ever has before, and thus, presumably, more freedom and autonomy, we don't seem to be benefiting from it psychologically."
- Barry Schwartz, The Paradox of Choice
There are myriad options for collecting information from users. Before code can be written, decisions have to be made; for my purposes, I chose to use Gatsby, ZEIT Now, and MongoDB, but here I want to briefly get into my use case and possible alternatives. If you don't care about the why and just want to know the how, skip ahead to the implementation.
Why
I am currently building a mobile app called Hangbored, which began with me needing an interval timer for training finger strength for climbing. While I await review and approval on my app's first release, I want users to be able to sign up on a landing page for early access. As of right now the app itself requires no back end, but at some point it might need one, so I want whatever system I build now for collecting emails to have the potential to scale.
Why serverless?
My use case right now is incredibly simple -- I only need to store a list of emails. I could easily spin up a relational database to serve this purpose, but I'd rather not go through the hassle of creating a server for such a simple service. The lambda function that we deploy on ZEIT Now performs much like a route in an Express server. But spinning up a server takes time, and as I was already building this landing page with Gatsby and Now, I knew that deploying serverless functions could be included as a part of my existing service.
Why write server-side code at all?
Secrets. We need credentials to establish a connection to our database, and some sort of layer needs to exist between the client and the database in order to establish this secure connection.
Why MongoDB?
I don't want or need to create schemas, migrations, etc. Still, it would be nice to have a service that is scalable in the future. I will likely want to create user accounts in the future, and I can do so by adding additional properties to my existing user object in MongoDB instead of starting from scratch.
How
Briefly:
Create a project
For this project I started with a Gatsby site, but you can use whatever you want. Probably the easiest way to do this would be to run npx gatsby new email-example in the command line.
Create a ui
It doesn't really matter how you get a form on a page. With React, it could look something like this:
function Form() {
const ref = React.useRef(null);
const handleSubmit = (e) => {
e.preventDefault();
axios
.post("/api/emails", { email: ref.current.value })
.then((payload) => {
console.log("payload: ", payload);
})
.catch((error) => {
console.log("error: ", error);
});
};
return (
<form onSubmit={handleSubmit}>
<input
aria-label="email"
placeholder="Enter your email"
ref={ref}
required
type="email"
/>
<button type="submit">Submit</button>
</form>
);
}
Because our api will be served from a different endpoint in development, and because we want to avoid having to speficy this route or deal with potential CORS errors, we need to configure a development proxy in gatsby-config.js with the following code:
module.exports = {
proxy: {
prefix: "/api",
url: "http://localhost:3000",
},
...
With other javascript frameworks such as create-react-app, you would add this line to your package.json:
"proxy": "http://localhost:3000",
For the time being this won't do anything, so we need to create an endpoint at that location.
Create an api
Create a folder at the root of this name project and call it /api. All files within this directory will become serverless functions available at endpoints that reflect the file structure here unless you prefix them with _ or ., so /api/signup.js will automatically create the endpoint /api/signup, and so on. signup.js can just look like this for now:
module.exports = (req, res) => {
if (req.body && req.body.email) {
res.status(200).send(`received ${req.body.email}`);
} else {
res.status(422).send("error");
}
};
If you don't have the Now cli installed, do that now by running npm i -g now. Running now dev This will create development builds for both site and api.
Connect to MongoDB
If you don't have a Mongo account, it's best to follow these instructions when it comes to setting up an Atlas account and database. Pay special attention to the instruction to create 'whitelisted connections from anywhere', as this could cause headaches in the future. Following these instructions, We need to create a free tier cluster and a database users with a collection emails.
If you didn't already do so, install mongodb:
npm i mongodb
Secrets
For now, we just need secrets available for local development. We can create a .env file in the root of our project, ensuring that it is included in a .gitignore in case we might commit this code somewhere. Add your Mongo uri there:
MONGODB_URI=mongodb+srv://<user>:<password>@my-cluster-uf345.mongodb.net/<database-name>?retryWrites=true
Later we will want this secret available to our api as well,so store your secret in Now, changing my-mongodb-uri to whatever you want and adding your own username, password, and database name:
now secrets add my-mongodb-uri mongodb+srv://<user>:<password>@my-cluster-uf345.mongodb.net/<database-name>?retryWrites=true
... and create a now.json file in the root of your project so Zeit knows to use this secret in this project. The key here is what your app's reference to the variable will be (matching whatever we put in .env), and the value is a reference to whatever you called your secret on the line above:
{
"version": 2,
"env": {
"MONGODB_URI": "@my-mongodb-uri"
}
}
At this point we need to edit our api to complete this connection between api and server. Change api/emails.js to the following:
const url = require("url");
const MongoClient = require("mongodb").MongoClient;
// Create cached connection variable
let cachedDb = null;
async function connectToDatabase(uri) {
if (cachedDb) {
return cachedDb;
}
const client = await MongoClient.connect(uri, {
useNewUrlParser: true,
useUnifiedTopology: true,
});
const db = await client.db(url.parse(uri).pathname.substr(1));
cachedDb = db;
return db;
}
module.exports = async (req, res) => {
try {
const db = await connectToDatabase(process.env.MONGODB_URI);
const collection = db.collection("emails");
collection.insertOne(req.body, (err, data) => {
if (err) {
res.status(422).send(err);
} else {
res.send("success");
}
});
} catch (error) {
res.status(400).send(error);
}
};
The connectToDatabase function is used to cache the database connection and enable pooling because creating database connections is expensive. At this point, restart the now server with now dev and verify that emails are recorded in MongoDB. Whether or not things go successfully, your user would probably appreciate some feedback. I updated my simple Form component as follows:
function Form() {
const [state, setState] = React.useState({});
const ref = React.useRef(null);
const handleSubmit = async (e) => {
e.preventDefault();
setState({ loading: true });
axios
.post("/api/emails", { email: ref.current.value })
.then(() => {
setState({
loading: false,
success: true,
});
})
.catch((e) => {
let err = "Something went wrong :(";
if (e.response?.data?.errmsg?.includes("duplicate key")) {
err = "You've already signed up!";
}
setState({
loading: false,
err,
});
});
};
return (
<form onSubmit={handleSubmit}>
{state.success ? (
<p>
Thanks for signing up! <br /> You'll be the first to know about the
newness.
</p>
) : (
<div>
<div>
<input
type="email"
placeholder="example@hi.com"
ref={ref}
required
aria-label="email"
/>
<button type="submit">
<span>Sign up</span>
</button>
</div>
</div>
)}
{state.err && (
<div>
<p>{state.err}</p>
</div>
)}
</form>
);
}
Conclusion
Using ZEIT Now is just one of the many ways one can spin up a landing page to accept user signups. For my purposes, it turned out to be the easiest. In the unlikely scenario that traffic for my small sideproject skyrockets, I will be able to scale. In the scenario that I decide I don't like whitelisting all IPs and want more customization for my lambda, I can always switch to something like AWS, where your first 1 million requests each month are free. But for now, I would much rather spend my limited free time on building my actual app rather than this (admittedly corny) marketing page.