When the CMS Becomes the Bottleneck

Website projects tend to force a compromise. Drag-and-drop builders like Wix and Squarespace put publishing power in the hands of marketers, but they box developers in when it comes to customization. WordPress offers more room to build, yet it depends on third-party plugins that can lag behind on updates and open the door to security problems. On the other end, static site generators such as Gatsby and Hexo give developers full control but put even minor content edits out of reach for non-technical teams, which is rarely acceptable for a busy corporate site.

The middle ground is a CMS that treats the backend as code while keeping the front end manageable for content creators. HubSpot’s CMS Hub takes this approach: it is built on a CRM platform and lets developers add serverless functions that behave like integrated plugins. These functions are easier to develop, deploy, and maintain than their WordPress counterparts, and they sit alongside a publishing experience that does not require engineering help.

What a Serverless Function Adds

With serverless architecture, you write and run application logic without provisioning or operating the servers underneath. HubSpot’s serverless functions are useful for more than simple request handling. They can read and write data to HubDB or the HubSpot CRM, subscribe a website to third-party services such as Google Forms, run event registration flows, or forward form submissions to other endpoints.

Function source lives in the developer file system and is managed either through the Design Manager UI or the HubSpot CLI. The CLI workflow is particularly useful: you can generate and edit functions in your local editor, then push the changes up to your HubSpot account. The examples below use the CMS Boilerplate as the starting point and assume a CMS Hub Enterprise account, or the free developer testing account. A working knowledge of JavaScript is required, and a quick start through HubSpot’s developer docs will help if you are new to the platform.

A Practical GET Request for News Data

A common scenario for a serverless function is proxying an external API so that a secret stays off the front end. Any API that authenticates with a key is unsafe to call directly from browser code, because the credential becomes visible to anyone inspecting the network traffic. Routing the call through a serverless function keeps the key on the server and returns only the data the page needs.

To demonstrate, we can build a function that fetches news articles that mention “HubSpot” from NewsAPI.org. This requires registering for an API key from that service first.

From the HubSpot CLI, create the function scaffold:

cd local-cms-dev
mkdir myfunctions
hs create function

The tooling prompts for a few details:

  • Folder name: myfunctions/getnews
  • JavaScript file name: getnews
  • HTTP method: GET
  • URL path: getnews

The CLI reports that the endpoint /_hcms/API/getnews has been created. Once the code is uploaded, the function will be available at that path.

Open myfunctions/getnews.function/getnews.js. This file starts with boilerplate that makes a request to HubSpot’s own search API. Replace its contents entirely:

const axios = require('axios');
const API_KEY = '<YOUR_API_KEY_HERE>';

exports.main = async (_, sendResponse) => {
   
};

The code pulls in the axios HTTP client and exports a main function, which is the entry point HubSpot invokes when the endpoint receives a request. For simplicity the API_KEY constant is defined directly in this file; in a production project you would add it through the CLI’s hs secrets command rather than checking it into source control.

Now add the following code to the body of main:

const response = await axios.get(`https://newsapi.org/v2/everything?q=HubSpot&sortBy=popularity&apiKey=${API_KEY}`);
sendResponse({ body: { response: response.data }, statusCode: 200 });

The function issues the GET request to the NewsAPI endpoint and passes the returned payload back to the browser using sendResponse. Running this API call on the server avoids exposing the API key, which an equivalent frontend call would do.

Push the code to HubSpot with the CLI:

hs upload myfunctions myfunctions

This uploads the local myfunctions folder into a newly created folder of the same name in your account’s Design Manager.

Once uploaded, the endpoint works immediately. Visiting /_hcms/API/getnews in a browser returns a JSON list of news articles that mention HubSpot — no front-end styling applied, but the data is ready for consumption. From here, the natural next step is to wire that output into a HubSpot template so the articles render as a dynamic webpage. That requires template work outside the scope of this example, but it completes the loop: a scheduled or on-demand fetch of news with no server infrastructure to own and no credential leakage.

Building Beyond the Brochure

For a small site that changes infrequently, any CMS will get the job done. The calculus changes when the goal is a substantial digital presence that must grow with the organization. HubSpot’s CMS Hub is aimed at that threshold: it combines API-level control with a publishing interface that does not demand engineering involvement. Development can proceed through a local CLI, an IDE of choice, and version control, rather than being pinned to a browser-based editor.

The serverless function walkthrough above is one narrow slice of what the platform supports, but it demonstrates the core mechanism: custom backend logic deployed seamlessly into a CMS that keeps the rest of the stack — hosting, scaling, security maintenance — someone else’s concern. Further exploration is a matter of picking a workflow and signing up for a developer test account. Additional comparisons are available in HubSpot’s breakdown of WordPress alternatives, Martin Fowler’s analysis of serverless architectures, and the official HubSpot serverless functions documentation.