Last week's Netlify Compose conference saw the launch of a new platform designed to help enterprises manage their transition to a more agile, composable web architecture.

Netlify launches a new toolset to help enterprises migrate to composable web architectures

Netlify, key proponent of the Jamstack web architecture, has unveiled the Netlify Compsable Web Platform, a unified platform for developers, architects, marketers and content maintainers for building and deploying composable websites.

Netlify Composable Web Platform aims to modernise web architecture

Netlify, key proponent of the Jamstack web architecture, has unveiled the Netlify Compsable Web Platform, a unified platform for developers, architects, marketers, and content maintainers for building and deploying composable websites. Introduced October ...

Netlify Composable Web Platform aims to modernize web architecture

Netlify has introduced the launch of a new platform that will enable developers to build “modern, composable web architectures.” The Netlify Composable Web Platform connects content, data sources, code, and infrastructure, providing development teams with everything they need to build and ship modern websites.

Netlify launches new unified platform for building composable web architectures

Netlify Inc., the maker of a cloud-based platform that simplifies the development of web-based applications and webpages, today announced the launch of its Composable Web Platform for the enterprise that will allow customers to quickly build their own web applications with any components.

Netlify launches Composable Web Platform to simplify modern enterprise web architecture

Today at Compose 2023, Netlify, known for, creating Jamstack and reimagining modern web development, announced the Netlify Composable Web Platform, an industry-first platform for enterprises to build and implement modern,

New Netlify Composable Web Platform Clears Path to Enterprise Adoption of Composable Web Architecture

The attack was carried out using a newly discovered vulnerability in the HTTP/2 protocol, which is used by most websites today. The vulnerability allowed attackers to overwhelm servers using specially designed packets eventually making them unavailable to its intended users.

Google, Amazon, and other companies were able to mitigate the attack through a combination of techniques.

Netlify

netlify

In today’s fast-paced software development landscape, Continuous Integration and Continuous Deployment (CI/CD) have become crucial for ensuring high-quality software releases at a rapid pace. Netlify is a popular cloud-based hosting platform that provides an easy way to deploy static sites. By automating the deployment process with CI/CD, developers can focus on writing code and delivering features rather than manually deploying changes. In this article, we will explore how to set up CI/CD to Netlify for static site deployments. We will discuss the benefits of this approach, and provide a step-by-step guide for integrating Github with Netlify for a streamlined deployment process. For this article, I will be using a Hugo static site that I used to build a personal portfolio and blog for my audience to demonstrate the CI/CD pipeline. Please take a close look at the for the same. Github Repository II. Setting Up a Netlify Account In order to set up CI/CD to Netlify for static site deployment, you will need to create a Netlify account. If you already have a Netlify account, you can skip this section and move on to the next section. Netlify is a cloud-based service that offers continuous deployment, hosting, and serverless backend functionality for static websites. With Netlify, you can easily deploy and manage static sites with automatic CI/CD capabilities. Creating a account To create a Netlify account, go to netlify.com and click the “Sign up” button in the upper right corner of the page. You can sign up with your , , or account or by using your email address. Netlify GitHub GitLab Bitbucket Setting up a new site on Netlify Once you have created a Netlify account, you can set up a new site by clicking the button on the Netlify dashboard. From there, you will need to select the Git provider that hosts your repository. In this case, we will be using GitHub. “New site from Git” Linking the site to a GitHub repository After selecting GitHub as the Git provider, Netlify will prompt you to authenticate with your GitHub account. Once authenticated, you will be able to select the repository that you want to link to your Netlify site. After selecting the repository, you will be presented with a list of configuration options for your site. In the next section, we will discuss how to configure your GitHub repository for automatic deployments to Netlify. III. Setting Up CI/CD to Netlify CI/CD (Continuous Integration and Continuous Deployment) is a process that automates the building, testing, and deploying of code changes. By setting up CI/CD to Netlify for your static site via Github, you can ensure that your code changes are automatically tested, built, and deployed to your production site every time you make a commit. Netlify provides a simple and intuitive way to configure CI/CD for your static site. Here’s how to do it: Configuring the Build Settings on Netlify Before you can set up CI/CD to Netlify, you need to configure the build settings on Netlify. Netlify uses build plugins to configure the build process. Build plugins are reusable pieces of code that can be shared across different sites and projects. To configure the build settings, follow these steps: Go to your site’s settings page on Netlify. Click on the “Build & deploy” tab. Scroll down to the “Build plugins” section. Click the “Add build plugin” button. Select the “Build Command” plugin. In the “Command” field, enter the build command for your static site. For example, if you’re using Jekyll, the build command would be “jekyll build”. If you’re using Hugo, the build command would be “hugo”. Click “Save”. Configuring the Deployment Settings on Netlify Once you’ve configured the build settings, you need to configure the deployment settings on Netlify. Netlify provides several deployment options, including manual deploys, continuous deployment, and branch deploys. To configure the deployment settings, follow these steps: Go to your site’s settings page on Netlify. Click on the “Build & deploy” tab. Scroll down to the “Deploy notifications” section. Click the “Add notification” button. Select the deployment method you want to use. For example, if you want to use continuous deployment, select “GitHub”. If you want to use manual deploys, select “Manual deploys”. Follow the prompts to authenticate with GitHub and select the repository and branch you want to deploy. That’s it! Netlify will now automatically build and deploy your static site every time you push a new commit to the linked GitHub repository. If there are any errors in the build process, Netlify will notify you via email or Slack. IV. Setting Up CI/CD with Github Actions In the previous section, we set up the basic CI/CD configuration on Netlify. However, we haven’t automated the process yet. In this section, we’ll use Github Actions to automate our CI/CD process. Introduction to Github Actions Github Actions is a powerful tool that allows you to automate tasks directly in your Github repository. It works by defining workflows as code that are triggered by specific events such as push, pull request, or cron schedules. A workflow is made up of one or more jobs that can be run on different operating systems and virtual environments. Each job is made up of one or more steps that are executed in sequence. Steps are individual tasks, such as building and testing your code or deploying it to a server. Github Actions provides a wide range of pre-built actions, which are individual tasks that can be used within your workflows. These actions are reusable, making it easy to build custom workflows without having to write much code. Creating a Github Actions Workflow for the Static Site To create a workflow, we need to create a YAML file in the directory in our Github repository. This file defines the workflow and its associated jobs and steps. .github/workflows First, we need to define the event that triggers the workflow. In our case, we want the workflow to be triggered whenever changes are pushed to the branch. Here’s an example YAML configuration that achieves this: main codename: Deploy to Netlify
on:
  push:
    branches:
      - main Next, we need to define the jobs that make up the workflow. In our case, we only need one job, which will build and deploy our site. Here’s an example YAML configuration for the job: codejobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
      - name: Build site
        run: npm run build
      - name: Deploy site to Netlify
        uses: nwtgck/actions-netlify@v1
        with:
          publish-dir: ./dist
          production-command: echo 'No production command required for static site deployment'
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }} Let’s go through each step of the job: specifies that the job will run on a Ubuntu environment. runs-on: ubuntu-latest checks out the code from Github so that it can be built and deployed. actions/checkout@v2 installs the dependencies required to build the site. npm install builds the site using the build command specified in our file. npm run build package.json is an action that deploys our site to Netlify. nwtgck/actions-netlify@v1 specifies the directory containing our built site. publish-dir: ./dist is not required for static site deployments. production-command: echo 'No production command required for static site deployment' and are environment variables that contain the API key and site ID for our Netlify account. These are passed in as secrets in the Github repository settings. NETLIFY_AUTH_TOKEN NETLIFY_SITE_ID Once we’ve created this YAML configuration file, Github Actions will automatically detect it and run it whenever changes are pushed to the branch. main Configuring the Workflow to Deploy to Netlify Before we can deploy to Netlify using Github Actions, we need to configure the workflow to tell it where to deploy and how to authenticate with Netlify. First, we need to set up an access token in Netlify to allow Github to deploy to our site. To do this, navigate to the Netlify dashboard and click on the site we want to deploy to. Then, click on the “Settings” tab and scroll down to the “Access tokens” section. Click the “New access token” button, and give it a name that reflects its use, such as “Github Actions deployment.” Next, select the desired permissions for the token. For deployment purposes, we only need to grant the “deploy” permission. Once we have selected the “deploy” permission, click the “Generate token” button at the bottom of the page. Netlify will generate a new access token, which we need to copy and store safely in our Github repository’s secrets. To add the Netlify access token to our repository’s secrets, we need to navigate to the repository’s “Settings” tab and click on “Secrets” on the left-hand side. Then, click the “New repository secret” button, and enter “NETLIFY_AUTH_TOKEN” as the name of the secret. In the “Value” field, paste the access token we just copied from Netlify. Finally, click the “Add secret” button to save the token. Now that we have our access token set up and safely stored, we can add the deployment step to our Github Actions workflow. To do this, we need to modify the workflow YAML file we created earlier. We will add a new step at the end of the workflow to deploy the site to Netlify. Here’s an example deployment step that we can add to our YAML file: codename: Deploy to Netlify
  uses: nwtgck/actions-netlify@v1
  with:
    NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
    NETLIFY_SITE_ID: your_site_id
    DIR_TO_UPLOAD: your_dir_to_upload This step uses the “nwtgck/actions-netlify” Github Action, which simplifies the deployment process to Netlify. We need to provide the access token we just created, along with the site ID and directory we want to upload. To find the site ID, navigate to the site’s “Settings” tab in the Netlify dashboard and scroll down to the “Site details” section. The site ID will be listed under the site name. Finally, we need to specify the directory we want to upload to Netlify. This directory should contain the built version of our static site. The directory can be specified using the “DIR_TO_UPLOAD” parameter in the YAML file. Once we have added the deployment step to the workflow YAML file, we can commit and push the changes to Github. Github Actions will automatically run the workflow when changes are pushed to the repository, which will trigger the build and deployment process to Netlify. With everything set up, we can now sit back and watch as our site is automatically built and deployed to Netlify every time we push changes to Github. This is a powerful workflow that simplifies the deployment process and frees up time to focus on developing our site. V. Best Practices for CI/CD with Netlify and Github Setting up CI/CD to Netlify via Github is a powerful combination that allows for seamless deployments of static sites. However, there are some best practices that can help optimize the process and ensure smooth operations. Here are some tips for optimizing your CI/CD pipeline and managing your Github repository and Netlify site: : It’s important to test your deployment process regularly to catch issues early on. You can do this by creating a test branch and testing the deployment process on a separate staging site before deploying to production. Regularly test your deployment process : Make sure to use version control effectively by using clear commit messages, creating meaningful branch names, and enforcing code reviews. This helps keep your codebase organized and makes it easier to roll back changes if needed. Use version control effectively Netlify allows for the use of environment variables to keep sensitive information secure, such as API keys or access tokens. Make sure to use these variables and not hardcode any sensitive information into your deployment scripts. Use environment variables: Netlify has a limit of 15 minutes for the build time of each deployment. If your build time exceeds this limit, you may run into issues. To optimize build time, make sure to only install necessary dependencies and remove any unnecessary files or processes. Optimize build time: Caching is a great way to speed up build times and reduce the number of API calls needed. Netlify supports caching of dependencies, and Github Actions supports caching of build artifacts. Use caching: Keep an eye on your deployments to ensure they are successful and catch any errors early on. You can set up notifications to alert you of failed deployments or use tools like Sentry or New Relic for error monitoring. Monitor your deployments: Regularly backup your data to prevent data loss. Netlify provides built-in backup functionality, but it’s always a good idea to have an offsite backup as well. Backup your data: By following these best practices, you can optimize your CI/CD pipeline and ensure smooth deployments of your static site to Netlify. Remember to test regularly, use version control effectively, keep sensitive information secure with environment variables, optimize build time, use caching, monitor your deployments, and backup your data to prevent data loss. VI. Troubleshooting CI/CD Issues Even with the best practices in place, issues can arise during the CI/CD process that can cause headaches for developers. Here are some common issues and troubleshooting steps to help you diagnose and resolve problems with the deployment pipeline. Build Fails One of the most common issues that developers face is a failed build. This can be caused by a number of factors, including incorrect build settings, missing dependencies, or errors in the code. When a build fails, the first step is to check the build logs to identify the source of the problem. Netlify provides detailed logs that can help you diagnose the issue. Once you have identified the problem, you can make the necessary changes to the build settings or code to resolve the issue. Deployment Fails Another common issue is a failed deployment. This can occur if there are errors in the deployment settings or if there are issues with the Netlify API. When a deployment fails, check the deployment logs to identify the source of the problem. If the issue is with the deployment settings, make the necessary changes and try again. If the issue is with the Netlify API, you may need to contact Netlify support for assistance. Slow Builds or Deployments Sometimes, builds or deployments may take longer than expected. This can be caused by a variety of factors, including slow network speeds, large files, or complex code. To resolve this issue, try optimizing your code or reducing the size of your files. You can also consider upgrading to a higher-tier Netlify plan for faster build and deployment speeds. Caching Issues Caching can also cause issues during the CI/CD process. If changes are not reflected in the deployed site, it may be due to caching. To resolve this issue, you can clear the cache in Netlify or disable caching in your browser. Authentication Issues Authentication issues can also cause problems during the CI/CD process. If you are having trouble authenticating with Github or Netlify, double-check your credentials and make sure that you have the necessary permissions to access the repository or site. VII. Conclusion In conclusion, setting up CI/CD to Netlify for a static site via Github provides a streamlined approach to deploying code changes. It eliminates the need for manual deployment processes, saves time and increases productivity. To set up this process, you will need to create a Netlify account, link it to your Github repository, configure the build and deployment settings on Netlify, and create a Github Actions workflow. In the workflow, you will define the steps to build and deploy the site to Netlify. Github Actions is a powerful tool that allows for a wide range of customization, making it possible to fine-tune the deployment process to your specific needs. To optimize the pipeline, we recommend implementing best practices such as using Git branches and pull requests, setting up automatic testing, and monitoring the deployment pipeline for errors. In case of any issues during the CI/CD process, it is important to have a troubleshooting plan in place. This includes diagnosing and resolving issues with the pipeline, using tools such as logs and error messages to determine the root cause of the issue. Overall, setting up CI/CD to Netlify for a static site is a valuable addition to any development workflow. It simplifies the deployment process and frees up developers’ time to focus on building and improving the site itself. With the steps outlined in this guide, you can easily set up and customize the pipeline to fit your specific needs.

How to Set Up CI/CD to Netlify for Static Sites via Github 

I keep coming across situations where I need to Netlify about the to use while building my sites (eg. when building ). Multiple times now, I’ve not been able to find the correct documentation related to this quickly. Guessing that I’m not the only one facing this issue, I decided to write a quick article to offer a solution. tell Node version countmywords.in Default Node Version Netlify creates a to set up your site behind the scenes. The used to create this container defines the software versions installed (including Node). Docker container build image If you don’t specify a Node version explicitly, Netlify uses the that comes pre-installed in its Docker container. Once you build a site using the default Node version, Netlify locks or your site to that Node version so that your site’s builds continue using the same Node version even when the default Node version in Netlify’s Docker build image changes with time. Your deployment workflow will thus not break when Netlify updates its build image to use a newer version of Node as the default. default Node version pins For example, imagine that it’s late 2021 and you are using Node to build your Eleventy site on Netlify. Node is the latest version and it makes sense for Netlify to include it as the default Node version in its containers. Now, fast forward to March 2023. Netlify has updated the software versions included in its containers and Node is now its default Node version. For some reason you were not able to update your code during this time and your site still requires Node . 16 16 18 16 However, when you trigger a build on Netlify, your build still goes through without any errors. Because Netlify had pinned your site to use Node (to match the Node version used in the previous build), it used Node in the current build rather than Node (which would only be used in new projects). 16 16 18 Explicitly Specify a Node Version There are two main methods for specifying a Node version in Netlify builds: Set an environment variable called . NODE_VERSION Create a or file that is stored in the base directory of your code repository. .node-version .nvmrc You can specify the version information as the version number (full or partial) for any Node release or a string that accepts. Some examples are , , , and . You can read more about the supported inputs on nvm’s . nvm 16 16.2 18.5.0 node lts/fermium documentation Method 1: Set a NODE_VERSION Environment Variable Netlify allows you to set to configure your site’s build and functionality. Among other things, you can use them to specify the versions of some software available during the build. environment variables Netlify supports two kinds of environment variables- and . Site environment variables are set at the site level whereas shared environment variables are set at the team level and all the sites owned by a team has access to them. site shared In this article, to set the Node version for a particular site’s build. you will use a site environment variable Further, Netlify offers multiple methods to set environment variables. To reduce decision fatigue, you will use their UI to set site environment variables. To do so, select a site from the Netlify dashboard and go to . Site Settings -> Environment variables Method 2: Create a Configuration File Supported by a Node Version Manager Node version managers allow you to install multiple Node versions on a machine and switch to a particular one based on your project’s needs. Netlify’s build containers come installed with a Node version manager that can be configured using a file. You can specify a Node version by creating a or file with the version information and adding it to your base directory. .node-version .nvmrc An aside on these files. The file is fairly well-known these days as nvm has become the most popular version manager for Node. The file is a similar configuration file that is supported by a few . .nvmrc .node-version other version managers . Originally published on architchandra.com The featured image for this piece was generated with stable diffusion v2.1. Prompt: Software nodes.

Specifying a Node Version in Netlify Builds

Did you know Netlify Functions could break when renamed to the same name with a different casing? I sure didn't. What Are Netlify Functions? If you know what AWS Lambda or GCP Cloud Functions are, then Netlify Functions won't be a stranger to you. Netlify functions are serverless functions powered by Netlify's infrastructure. These functions are designed to allow you and me to quickly build and deploy serverless applications without the need for managing infrastructure or scaling concerns. One of the common ways we can use Netlify Functions is by serving API routes defined in frameworks like Next.js. Suppose I wanted to create some endpoints for my frontend application to call, like . /api/toast/<id> In that case, Next.js enables you to create your route within the same root directory under the directory. You can read more about it . /pages/api here Is This a Bug? I have been toying around with Netlify Functions to test a few APIs here and there to see how easy it is to integrate into a project. Over time, one of the routes I defined stopped working on my live deployment. And the worst part was that it worked locally. The route was a that took in an id called so I can fetch a piece of Toast by id (this is a simple test app, don't worry about it). dynamic API route toastId export default async (req: NextApiRequest, res: NextApiResponse) => {
  try {
    const { toastId } = req.query;
    // Fetch the piece of toast by id and do something with it...
  } catch (ex) {
    // ...
  }
}; Looking through the Git history to see what change may have broke, it didn't give too many hints as to how I broke it -- neither did logging out the value on my local deployment. What did help was logging out the value on the deployed instance of my test app. Turns out, my renaming of the dynamic route file from to broke what I initially deployed to Netlify. When I ran the server locally, the casing change took effect as expected. [toastid].ts [toastId].ts However, it was not reflected when deployed to Netlify. As a result, my route was not able to extract the path parameter using the following  code snippet: const { toastId } = req.query; // `toastid` was being populated instead After renaming the file from to , the route worked once more. [toastId].ts [toastid].ts Now, is this a bug or just an undocumented behavior? Unfortunately, I have yet to find an answer for this in the Netlify and Next.js documentation or StackOverflow and Github Discussions. Please let me know if any of you do! Tl;DR The name you choose for your routes in your Next.js app matters. It may not be apparent when you're working on it locally, but quirks such as this one on Netlify can throw a wrench into your application deployed in prod. Thanks for Reading! 💎 Thank you for taking the time to check out this post. For more content like this, head over to my actual . Feel free to reach out to me on and follow me on . blog LinkedIn GitHub

Casing Can Break Netlify Functions: Here's How

We'll be building a blog site with the Angular framework, Scully for static site generation(SSG) and then deploying the project on Netlify so that it can be accessible to the public. What this article covers Using Angular to build the blog architecture Installing Scully library to handle static site Generation Netlify deployment Demo of this project Repository for the demo Setup requirements We'll be using the following tools for this project Angular v13 Tailwind Scully Node v14.15 (or higher) is an application design framework and development platform for creating efficient and sophisticated single-page apps. It's an opensource frontend framework built by Google. Angular is a library used for generating static sites built with Angular and ushers you into the jamstack. SSGs generate static pages when you build your project so that what you publish/deploy is the already built pages which can be indexed by google(for some of that SEO good good) and served quickly to clients. Without scully, our angular project will go through client side rendering where each page of the application that is visited is rendered by the browser at runtime. Scully is a CSS utility library that is used to speed up the styling of applications by offering flexibility and conciseness. Tailwind Now that we have some background on the project, we can start building. Generating the Angular project Use the command below to generate a new angular project. You can name your project what you like. I have chosen angular-blog ng new angular-blog You'll see the following questions. We want routing and SCSS stylesheet format. ? Would you like to add Angular routing? Yes
? Which stylesheet format would you like to use? SCSS After the project has been generated, serve the application using the ng serve command ng serve You'll be greeted with the standard angular welcome template. Navigate to and delete the entire content (we don't want that welcome page showing up) and then place tags since this is where all our modules and components will be displayed based on the route configuration in app.component.html <router-outlet></router-outlet> app.routing-module.ts Installing Scully Run the command below to install scully and automatically make all the necessary configurations to the project ng add @scullyio/init During the installation, you'll get the question below. As at the time of this writing, is the most stable renderer so we'll choose that. pupeteer ? Which route renderer would you like to use?
  Scully platform server
> Puppeteer
  Playwright (beta) Here is what the terminal looks like after the installation process The schematic of the scully installation made a couple of changes which include; init installing the pupeteer plugin updating the by importing the app.module.ts ScullyLibModule updating the package.json file with scully commands for building and serving the generated pages "scully": "npx scully --",
  "scully:serve": "npx scully serve --" created a file which is the scully configuration file. scully.angular-blog.config.ts Adding Blog Support to Our Project Scully has a schematic for creating the blog section for our project ng generate @scullyio/init:blog This adds a lazy-loaded blog module's routes to the Angular application( ) and creates a folder for the blog's markdown files(where our blog posts will live). Below is the current route configuration in updated by scully. app.routing-module.ts ./blog app.routing-module.ts const routes: Routes = [{
  path: 'blog',
  loadChildren: () => import('./blog/blog.module').then(m => m.BlogModule)
}]; It also updates the with the blog routes to prerender. scully.angular-blog.config.ts A Few Other Configurations Now we have a module for our blog feature. The next things we need to do are; create a component for the list of blog posts using the command below ng generate component blog/blog-list create a component that will show the actual blog post content using the command below ng generate component blog/blog-post Fix up our route configuration in as below blog.routing.module.ts const routes: Routes = [
{
  path: '',
  component: BlogComponent,
  children: [
    {path: ':slug', component: BlogPostComponent},
    {path: '', component: BlogListComponent}
    ]
}
]; Lastly, we add the in the to handle routing in the module.This page will display the blog list and blog posts based on the route configuration in <router-outlet></router-outlet> blog.component.html blog-routing.module.ts Configuring the Route Entry Point for Scully After sorting out the module for our blog feature, we need to create an entry point for scully (typically the home page of our app). It is suitable to leverage the Angular lazy-loaded module feature for our app home page because this part of our app is separate from the blog part. Create a with the following command: home module ng generate module home --route=home --module=app-routing This updates the route configuration in with the path for the . Set its path to an empty string. app-routing.module.ts home module const routes: Routes = [
  {
    path: 'blog',
    loadChildren: () => import('./blog/blog.module').then((m) => m.BlogModule),
  },
  {
    path: '',
    loadChildren: () => import('./home/home.module').then((m) => m.HomeModule),
  },
  { path: '**', redirectTo: 'blog', pathMatch: 'full' },
]; You can always add a redirect below the route configuration for the blog module if you don't want the home page to be accessed yet. {path:'',redirectTo:'blog',pathMatch:'full'}, Building the Angular-Scully App After all those configurations, we need to build our project with Angular, build with Scully then serve the built project on the Scully server but first, let's restart the Angular server.Build the project by running ng build Then we build with scully using npx scully We can also modify the command in our so that it will run the two previous commands. build package.json "build": ng build && npm run scully -- --scanRoutes Now we can use to achieve the same thing. After those two commands, a folder is created in the root directory of our project. This folder contains the two built versions of our site, The folder named is the one built by Angular while the one named contains the static pages generated by scully. Now, we can start the scully server using the command: npm run build dist angular-blog static npx scully serve After the server starts successfully, navigate to to see the angular app running, then in a separate tab, open this link to see the static site. You browser should show a white page with the text .To check our actual blog post (created by the schematic) go to the markdown file in the folder and copy the value of the property in the frontmatter. http://localhost:4200/blog http://localhost:1668/blog blog-list works! init:blog blog slugs ---
title: 2022-04-29-blog
description: 'blog description'
published: false
slugs:
    - ___UNPUBLISHED___l2kp8pyl_z4RfUZ7hSOMdOfldi8yqeZcOKuebIId2
--- That is the current path(generated by scully) to the blog post when . It's a private route to your blog post when it's still in draft version so you can share with anyone to get an article review before publishing. When you are ready to publish the post, you can set and remove the property which will allow scully use the file name(without the extension) as its path when it generates the static pages. published: false published: true slugs Go to address bar of the tab serving the static site and paste the slug after then press enter. You should see the content of the blog post. Now, we have confirmed that our blog feature is fully functional so next up is to add more blog posts. http://localhost:1668/blog/ Creating Blog Posts We can create a blog post with the command below. The option takes the name of your post. name ng generate @scullyio/init:post --name="Post 1" This creates a markdown file in the folder. When we open the newly created markdown file, we see this blog ---
title: Post 1
description: blog description
published: false
---

# Post 1 As you now know, the content between the three dashes is the frontmatter and below the frontmatter is the blog content.The frontmatter is where we can add information about the post such as metadata, SEO e.t.c. Let's update this markdown file to look like this ---
title: Post 1
description: blog description
published: true
image: /assets/images/enigma.jpg
seo: {
metaDescription: First post for my angular scully blog,
metaTitle: First post
},
---

# Post 1 I have added an image in the corresponding directory which I'll render in post. When we're satisfied with our markdown file, we can build with the command. npx scully A Tip on Knowing Which to Build With is only needed when you modified something in your angular app. The scully config file, plugins, and eventual markdown files are not part of your Angular app. Although this may seem evident, if this is your first time using Scully it is easy to rebuild Angular even if it is not needed. When writing Scully plugins OR modifying your blog's markdown files, you DO NOT need to ng build the app each time you re-run Scully. Again, ng build Angular only if the Angular app changes ng build Showing All Blog Posts Let's head over to to work out the logic that handles data for the component. In this component, we will inject the as a dependency which will give us access to the blog posts routes. blog-list.component.ts ScullyRoutesService import { Component, OnInit } from '@angular/core';
import {ScullyRoute, ScullyRoutesService} from "@scullyio/ng-lib";
import {Observable} from "rxjs";

@Component({
  selector: 'app-blog-list',
  templateUrl: './blog-list.component.html',
  styleUrls: ['./blog-list.component.scss']
})
export class BlogListComponent implements OnInit {
  links$: Observable<ScullyRoute[]> = this.scully.available$;

  constructor(private scully: ScullyRoutesService) { }

  ngOnInit(): void {
    this.getPublishedPosts();
  }

  getPublishedPosts() {
    this.links$ = this.links$.pipe(tap(val) => console.log(val))
  }
} What we want to render are the published posts, that's why we get the published routes from the property on the .In the we can build the template that shows all blog posts. We'll work with the code below for now. available$ ScullyRoutesService blog-list.component.html <div>
  <ul>
    <li *ngFor="let post of links$ | async">
    <a [href]="post.route">{{post.title}}</a>
    </li>
  </ul>
</div> After you save, you should see an array of two routes in the console. We can't see any blog posts route yet because we haven't built with scully after changing the property to .Let's ensure that the property in our markdown files are set to then build with scully to update our published routes. Now when we reload, we should see an array of 4 routes in the console. However, since we only want blog posts routes, we'll need to transform our data with some rxjs. Let's update the function published true published true getPublishedPosts getPublishedPosts() {
    this.links$ = this.links$.pipe(map((links) => links.filter((link) =>
      link.route.startsWith('/blog/'))),tap((val) => console.log(val)));
  } To ensure the scully version of our site is updated, let's run the command: npm run build Now we should have our page like this. You can click on the links to see that they show the corresponding posts. Accessing the Data in the Blog Post Page We can get the route data of a particular page we navigate to with the help of the by subscribing to the observable returned by the method. Add the code below to the ScullyRoutesService getCurrent() blog-post.component.ts import {Component, OnDestroy, OnInit} from '@angular/core';
import {ScullyRoute, ScullyRoutesService} from "@scullyio/ng-lib";
import {Subject, takeUntil} from "rxjs";
import {tap} from "rxjs/operators";

@Component({
  selector: 'app-blog-post',
  templateUrl: './blog-post.component.html',
  styleUrls: ['./blog-post.component.scss']
})
export class BlogPostComponent implements OnInit, OnDestroy {
  currentRoute: ScullyRoute = {} as ScullyRoute;
  onDestroy$ = new Subject<void>();

  constructor(private scully: ScullyRoutesService) {
  }

  ngOnInit(): void {
    this.getCurrentPost()
  }

  getCurrentPost() {
    this.scully.getCurrent()
      .pipe(takeUntil(this.onDestroy$))
      .subscribe((routeData: ScullyRoute) => {
        this.currentRoute = routeData;
      });
  }

  ngOnDestroy() {
    this.onDestroy$.next();
    this.onDestroy$.complete();
  }
} Details of our current route is assigned to property and this allows us use the route data for that particular post the way we want. this.currentRoute Styling Our Blog Firstly, we need to create another component which will be our reusable component for the blog cards. Use the command: ng generate component blog/blog-list/blog-card Open the and place the code below inside it blog-card.component.html <li *ngFor="let post of links$ | async">
    <a [href]="post.route">{{post.title}}</a>
</li> Then we make use of this component in our via the selector in this way blog-list.component.html app-blog-card <div>
  <ul>
    <app-blog-card [post]="post" *ngFor="let post of links$ | async"></app-blog-card>
  </ul>
</div> We are also passing each route object in the array as through the component therefore, we will need to receive this data from the parent component( ) in our child component ( ) using the decorator. Let's do that by putting the code below in the post app-blog-card blog list blog card Input() blog-card.component.ts import {Component, Input, OnInit} from '@angular/core';
import {ScullyRoute} from "@scullyio/ng-lib";

@Component({
  selector: 'app-blog-card',
  templateUrl: './blog-card.component.html',
  styleUrls: ['./blog-card.component.scss']
})
export class BlogCardComponent implements OnInit {
  @Input() post: Partial<ScullyRoute> = {};

  constructor() { }

  ngOnInit(): void {
  }
} Finally, Some Styling You can use any styling format you want. I'll be using tailwind. Let's use the straightforward to configure it in our project. After the configuration is done, we'll need to restart the angular server. Update the with the new template below tailwind documentation blog-card.component.html <li class="h-full">
  <a [href]="post.route" class="h-full w-full lg:max-w-full lg:flex hover:bg-gray-100">
    <div
      class="h-48 lg:h-auto lg:w-48 flex-none bg-cover rounded-t lg:rounded-t-none lg:rounded-l text-center overflow-hidden"
      [style.background-image]="'url(' + (post['image'] || 'https://images.unsplash.com/photo-1496494118863-9cf5d1e70cd6?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=870&q=80') + ')'"
      title="Mountain">
    </div>
    <div
      class="w-full border-r border-b border-l border-gray-400 lg:border-l-0 lg:border-t lg:border-gray-400  rounded-b lg:rounded-b-none lg:rounded-r p-4 flex flex-col justify-between leading-normal">
      <div class="mb-8">
        <div class="text-gray-900 font-bold text-xl mb-2">{{post.title}}</div>
        <p class="text-gray-700 text-base">{{post['seo']?.metaDescription || post['description']}}</p>
      </div>
    </div>
  </a>
</li> Also update the blog-list.component.html <div>
  <ul class="p-10 grid grid-cols-1 sm:grid-cols-1 md:grid-cols-1 lg:grid-cols-1 xl:grid-cols-3 gap-5">
    <app-blog-card [post]="post" *ngFor="let post of links$ | async"></app-blog-card>
  </ul>
</div> The code below adds a header to our site. Add it in app.component.html <nav class="flex flex-wrap items-center justify-between bg-gray-800 p-6 w-full">
  <div>
    <a class="text-white no-underline hover:text-white hover:no-underline" routerLink="/">
      <span class="text-2xl">Angular scully blog</span>
    </a>
  </div>
  <ul class="list-reset flex justify-end flex-1 items-center">
    <li class="mr-3">
      <a class="inline-block text-white no-underline hover:text-gray-200 hover:text-underline py-2 px-4"
         routerLinkActive="" routerLink="/blog">blog</a>
    </li>
  </ul>
</nav>
<router-outlet></router-outlet> Now we have a nice user interface that shows all blog post Let's add the code below for the blog post user interface( ) blog-post.component.html <main class="mx-auto max-w-screen-sm max-w-screen-lg">
   <img [src]="currentRoute['image'] || 'https://cdn.mos.cms.futurecdn.net/4uiRZ5nNAgpHSifSjaKwcC-970-80.jpg.webp'"
      alt="nft"/>
   <h3>ScullyIo content</h3>
   <hr>
   
   <scully-content></scully-content>
   <hr>
   <h4>End of content</h4>
</main> Finally, use the command to build the project and checkout the scully static version in your browser. npm run build Pushing to Github Create a repository on and then copy the remote url ( ) so that we can add it for our project using the command below: Github https://github.com/<github-username>/<repository-name>.git git remote add origin https://github.com/<github-username>/<repository-name>.git Rename the branch to with the command below: main git branch -M main Push to github with the command below: git push origin main Here's a link to the . repository for this article demo Deploying to Netlify After pushing our Angular Scully blog to github, we are ready to deploy on Netlify. If you do not have an account yet, you can or go ahead and log in to your account if you have one.Choose import from git Select Github Connect the repository you want to deploy. You may need to configure netlify for your github account if it has not been setup. This is needed for netlify to have access to the repository Provide the path to the folder where the scully generated static pages are as well as the build command Click the button and watch as netlify builds your project. Congratulations on making it to the end and have fun personalising your site as you like. signup here Deploy site Here's a link to the deployed site Conclusion I do hope this article has been helpful in guiding you through creating your blog site with Angular and scully from scratch. You can leave questions or suggestions in the comments or reach out to me on twitter @BrunoElo if you like. Thanks for reading! Also published . here

Creating an Angular Blog With Scully and Deploying on Netlify

So you have your own personal website hosted on Netlify, but want to start writing like I am and create a blog using Hashnode? How does one do that and is it possible to set up a custom subdomain with Hashnode? The answer is yes. Login in to your Netlify account and click on the domain app you want to set up a subdomain. I am choosing . martinpatino.com Click on button Domain Settings 3.Under Domains and click on ** Go to DNS Panel** on the domain you want to target. Next just click on "Add a New Record" and enter the following DNS Settings and in the fields available just fill out the following Record Type: CNAME

Name: blog or any subdomain of your choice

Value: hashnode.network Result: That is pretty much it for Netlify so congrats on this part. Now all that is left is complete the set up on the Hashnode side. Under Domains in the dashboard settings, you will just add a custom domain such as . The DNS propagation can take up to 24 hours to complete. blog.martinpatino.com You can see now hosting Hashnode custom subdomain blog ☕ blog.martinpatino.com

Intro Guide to Setting up a Custom Hashnode Blog Sub Domain on Netlify

Spoiler alert: I learned nothing. Every interviewer was nice and friendly. But most of the interviews had these awkward silences that I assume are normal(?). As an introvert, I never know how to fill these gaps in the conversation. During and after each interview I felt like a fraud. And each rejection email was the confirmation of that thought. The week after a rejection email is tough. My brain recreates the interview looking for mistakes and inserting thoughts that I will never be good enough to work in those places. But thankfully, after the first week or so, I get a motivation boost where a lot of new fresh ideas come to mind. Ideas of how to get better, what topics should I learn or what startups should I launch next. So I never have to go through an interview process again. Perhaps I did learn something. Instead of avoiding feeling like an impostor speed up the process and embrace it. Embrace that at some levels we are all impostors. This is good since it means that we are aware of things that we don’t know yet. So use this as a motivation to go and learn those things. Follow me on as I continue trying to get better. Twitter

What I learned from interviewing at Twitter, Webflow, Netlify, and Shopify 

Split testing is a feature you aren’t using enough. It’s a great way to test changes with your visitors without minimizing risk. In this tutorial, we’ll learn what split testing is, why you need it, and how to set it up with . Netlify What is Split Testing? Split testing is the idea of creating another copy of your website that you can send users to, so you can test new features. Let’s say you have a new design you want to try out. Rather than push that new design to production where everyone can see it, you can test it with a few people. Here I have redesigned my awesome Vue blog. But I don’t want to dump the new design on everyone. I want to test it out. Here are the options I can do with split testing: I will keep the main production site with the current (light colored design). Then I can: Only send people I invite to the (private) beta site Have folks “opt in” to the beta site Push a certain amount of (public traffic) to the beta site These are all ways I can test the design without fully committing. If there are major problems with the site, I’ll find them and fix them before sees it. everyone Enable Split testing The first thing I have to do is enable split testing with Netlify. To do that, I must: Create a new branch in git with the new design Enable in Netlify branch subdomains Once you have created a new branch (name it whatever you like) you can push the new design to that branch. I have mine setup at staging.jeremymorgan.tech. If you enable branch subdomains, you’ll see a split testing tab in Netlify: Option 1: Invite Only (Private Beta) You enable invite only once you’ve enabled branch subdomains. Your main traffic goes to your production site: jeremymorgan.tech: And you can send testers to the branch subdomain: staging.jeremymorgan.tech Easy stuff. You gather feedback, make changes and when your site is ready to go, you merge the branch. Option 2: Opt In (Semi Private Beta) Let’s say you want to make so folks can opt in to a beta if they want to, and if not they stay on your production site. To do that, you create a split test, and set of your traffic to production, and to the new beta site: 100% 0% Now, to route people to the beta site, they will need a cookie set. Netlify uses the cookie. If the nf_ab cookie is set to the name of the subdomain, Netlify will route the user to that branch subdomain: nf_ab So as long as the cookie is present, they will see the version of the website (available on the staging subdomain). For example, in my Vue App, I added a button: new Click here to try our BETA version < > h3 < = = > a href "#" v-on:click "gobeta" </ > a </ > h3 Which calls this method: gobeta: {
    alert( );
    VueCookies.set(‘nf_ab’, , );
} ( ) function "We are going beta!" "staging" "24h" This code sets the cookie for anyone wanting to “try out” the beta version of the site. The “opt in” model is great for your website visitors who are feeling adventurous and want to try out your new site. You leave the production site intact for everyone else. Option 3: Split Traffic (Public Beta) So if you’ve created a new design or new features, and you want to “ease into” deploying them, this is the way to go. In the Netlify split testing panel, simply choose a number of people to send to the new site: In this example, we’re sending 19% of the total public traffic to the new website. This is random, and it could be anyone. Netlify will send a percentage of your visitors to your new site and the rest to your old or “production” site. No need to worry about visitors getting a new site one day and the old one the next. Netlify will use the cookie again to route users to the original site they visited. This is an excellent way to push out some fresh changes, look for feedback, and react. You can even set up a with this. nf_ab Blue-Green Deployment Try Out Split Testing For Yourself! Split testing is an excellent way to test out new features without rolling the dice on a full deployment. Sometimes you want to test a new design, a new feature, or do some A/B testing for advertising. These are all possible with Netlify’s split testing feature. The best part is, it’s easy to set up. You create a new branch, point a subdomain to it, and start tinkering. Netlify makes this testing simple and easy to implement. Check it out! Questions, comments? Let me know! Previously published at https://www.jeremymorgan.com/tutorials/javascript/jamstack-split-testing-netlify/

How To Setup Split Testing With Netlify

Intro For this blog post, I am going to go over how I built my blog site with Strapi and React. I'm going to keep this as short and simple as possible. I followed along with the tutorial from Strapi themselves but there were hiccups along the way that I will address. Also, the tutorial only goes over how to make the blog locally. In this post, I'll explain what I did to deploy it out to the worldwide web. Here is to the Strapi blog post that I followed along with. Overall it was great. It clearly described every step of the process and explained why things were done the way they were. the link Initial hurdles The first small issue I noticed was in their instructions. One of the first commands you have to run is . Before this command is run in the terminal you must ensure you are in the correct directory. Make sure to in your terminal. You make this backend folder in the step before this, they just don't tell you to navigate to the newly created folder before the next step. If you don't do this you will install graphql in the root folder of the project and your backend for the blog will not work. yarn strapi install graphql cd backend Another problem I ran into was how to organize the project for version control. I use VSCode's built-in source control almost 100% of the time for my projects. The way this tutorial gets setup (I'm starting to learn many projects are set up this way), you'll end up with two separate directories for your frontend and backend code. Since the backend was largely already set up for me by Strapi I only committed my frontend code to GitHub. My backend directory also has version control but it is managed through the Heroku CLI. I'm sure there is a better way to manage this, but at the time I was too lazy to look into other options. Especially, when my current setup was working perfectly fine. Lastly, I ran into an issue that I couldn't quite understand while running the frontend locally. Here was the error: Could not find "client" in the context or passed in as an option. Wrap the root component in an <apolloprovider>, or pass an ApolloClient instance in via options Luckily a couple of users had already solved this problem and put it in the comments. Link to comment here. Everything else in the tutorial was pretty self-explanatory though! If I did have any confusion on something Strapi was so kind to add a video to the tutorial which also guided people through the process of creating the blog. I was able to have the blog finished and running locally on my machine pretty quickly. The next step was deploying the blog out to Heroku and Netlify. Deploying to Heroku and Netlify If you haven't used this stack with other projects before, from what I've gathered, Heroku is used to host your backend server and Netlify is used to host the frontend (at least that is what the tutorial recommended). Heroku Strapi has great documentation on how to deploy their backend to Heroku. Quick note, I created a Heroku project for this blog while I was still going through the tutorial. Pro tip: don't do that. The Strapi documentation shows you how to create the Heroku project in your backend folder which is so much easier. But if you took the same route I did, make sure to skip those create Heroku project steps (step 6) in the Strapi Heroku docs and connect to your existing project. Here is the link to that. I used PostgreSQL for this. They also give you an option to use MongoDB. I'm sure both are great, but seemed like the PostgreSQL route was simpler. Other than that the Heroku backend set up was pretty straight forward. Let's get to deploying the frontend. Netlify I think the Netlify set up might have been the easiest part of the project. Like I mentioned above, I had already pushed up my frontend directory to GitHub. All I had to do was make a Netlify account and connect my GitHub repo to my Netlify server (they step you through this process when you make a Netlify account). Just like that my frontend code was being hosted on Netlify, but there was one problem. My Heroku backend wasn't connected to my Netlify frontend. That issue can easily be solved in your file in your frontend directory. Originally, your backend is set to your localhost URL. I think by default in the Strapi tutorial it is . You'll need to change that to the link of your Heroku app you just created. Pro tip: Make sure there is no trailing slash in the URL. For example, your file should have this one line in it: . .env https://localhost:1337 .env REACT_APP_BACKEND_URL="https://*your-app-name*.herokuapp.com" There we go! Now you should have your blog uploaded to the internet for the whole world to see. Next, I'll go over what I'll call an "optional issue". Image upload with Cloudinary Figuring out how to upload an image for a blog post was a real pain. What is the issue you may ask? Here is the answer straight from the Strapi docs: Heroku's file system doesn't support local uploading of files as they will be wiped when Heroku "Cycles" the dyno. This type of file system is called ephemeral, which means the file system only lasts until the dyno is restarted (with Heroku this happens any time you redeploy or during their regular restart which can happen every few hours or every day). Due to Heroku's file system, you will need to use an upload provider such as AWS S3, Cloudinary, or Rackspace. One very easy way to get around this is to simply not add any pictures to your blog posts (this is why I consider this an optional issue). If you do go this route, make sure an image is not a required field in the Strapi admin portal (it was by default when I created my Articles content type). I decided to use Cloudinary, but in hindsight, I think AWS would have been easier. I'm not giving Cloudinary enough credit though. It really wasn't that hard. I was just being stupid. First, you want to head over to the npm package page. This page will show you how to add the Cloudinary provider to your Strapi blog. Strapi Provider for Cloudinary Second, I set up my configuration differently than they recommended. Before I get into what I did, I should disclose that this is probably not a best practice. Instead of using an file for the Cloudinary config variables I just put them in the file statically as strings. Yes, I know. For some reason when I was trying to use environment variables Cloudinary wasn't getting hooked up correctly. Here is a code example of what I did in my file: .env plugins.js backend/config/plugins.js .exports = ({ upload: { : , : { : , : , : ,
    },
  }, }); module ( ) => { env } // ... provider "cloudinary" providerOptions cloud_name "add_cloudinary_name_here" api_key "add_api_key_here" api_secret "add_api_secret_here" // ... Definitely not the best way to solve that problem but it indeed worked. Conclusion See it live here: https://teamtyry.netlify.app/article/2 Overall this was a really fun project. If you're new to coding, this tutorial (along with the video) walks you through the process very well. There may be a couple of hiccups to figure out, but hopefully, this article solves most of them. Like always, peace ✌️ and happy coding!

How to Build a Blog with Strapi, Netlify, and React 👨‍💻

Hey Hackers! Here's the tech stack I use to serve up without paying a dime. If you're starting out and don't want to commit to paying monthly server/database costs, some of these resources might be of use to you! The Hive Index Please note that although the website is dynamic in the sense that I update the data source & redeploy frequently, it doesn't have any functionality where the visitors create data. For an application that has user authentication, CRUD resources, or more complex functionality, you might actually need webservers or a "real" database. - Gatsby is a frontend framework for creating static frontend applications (like blogs, documentation sites, portfolio pages). It's based on React, but optimized for runtime performance because the bulk of the work (querying from your database) happens once when you deploy it. Spinning up a website with gatsby is super simple, and they have several that you can clone and modify to make your own. Framework gatsby.js starter projects - Google Sheets My data source is google sheets, which gives me the ability to expand my data source easily, and add fields by simply adding a column in the sheet. It's super easy to work with and you can use to pull data from your private spreadsheet to make the contents of your application. Just note that to update your website, you need to trigger a redeploy of the gatsby application, simply adding a row into the spreadsheet won't update the data on your site. Data Source this plugin - Netlify is a hosting service for static websites. To deploy your site is as simple as pushing up to your github repository, or triggering a build from the Netlify UI. They have a generous free tier, but after a certain amount of deploy minutes or bandwidth of serving your site, you need to pay. In my case, I'm usually at <1% of bandwidth capacity for the month, so until you have a ton of traffic (champagne problems) you don't need to even put in your credit card. Hosting Netlify - My site has a search component, so I'm serving up dynamic content based on the user's search query. This is a bit of a shift from the gatsby way of doing things, which is optimized for knowing the content of your site at buildtime, not runtime. Thankfully, Algolia has a that indexes your site's contents during buildtime, and you can use the algolia frontend client in your react app to serve up the content on your search page. Search Algolia gatsby plugin This has been a nice tech stack that works for me for this particular style of website. For applications that have many more dynamic features I use a different stack (might write a post about that later). Hope this post is useful for you as you spin up your ventures.

Gatsby, Sheets, Netlify, and Algolia - That's All You Need To Host Your Website for Free

After getting up and running I recently decided to add to it, to understand what content people were most interested in. At first this was amazing as I could see which blog posts were getting the most traction, but after a while it became a bit of a pain to log into my Google Analytics dashboard when all I wanted was to quickly see the page view count of a blog post. my blog Google Analytics Wouldn't it be easier to just go to my site and see the page view count displayed on each blog post? It most certainly would, and so that's what I set out to build. Since Google Analytics has a powerful API, all I really needed to do was call that API and retrieve my information, but ideally I wouldn't want to be making that call directly from this blog as that would mean exposing my API key and any other sensitive information to anyone who knows hows how to press F12. TL;DR Here is the GitHub repository for the serverless function that I wrote for retrieving Google Analytics page views. Since this blog is setup to be completely free (aside from the domain name), leveraging for the hosting, for images and for the content management system, I definitely wouldn't want to pay for running a back-end (especially one that was simply fetching stats from Google Analytics). And that's where Netlify functions come in. Netlify has a very generous free plan that allows 125k function executions and 100 hours execution time, a quota that this blog would never reach within 1 month, and this seemed like a perfect fit for what I needed. Netlify Cloudinary Ghost So let's dive into creating the serverless function for retrieving Google Analytics metrics. Building the Google Analytics Serverless Function As one does, I googled how to setup a Netlify function and came across this amazing blog post on the official Netlify blog which described . how to run Express.js apps with Netlify functions Described in the above post is how AWS Lambda functions work at a high level, which is important since Netlify functions seems to be built ontop of that infrastructure. It also describes how the npm package translates between the function and object of Lambda functions to the and objects used in Express, allowing you to easily run Express.js apps as serverless functions. In fact , the guidance given should apply to any web framework built upon Node.js's module. serverless-http callback event req res http Google Analytics authentication In order to get access to your Google Analytics data you will need to authenticate when using the API. In order to do this, you will need to do the following: Create a new Google API Project. Enable the Google Analytics Reporting API. Create authentication credentials (Service account key) and generate a JSON key file. Add the created service account user to your Google Analytics instance in the User Management section. Retrieve the for your website on Google Analytics. View ID The following blog posts have detailed descriptions on and . how to authenticate with google analytics interacting with google analytics Once you've setup your Google API project with the correct permissions you can simply create a JWT object and call authorize on it, like this: jwt = google.auth.JWT(process.env.GA_CLIENT_EMAIL, , process.env.GA_PRIVATE_KEY, ); jwt.authorize() //create jwt object const new null 'https://www.googleapis.com/auth/analytics.readonly' //authorize using jwt object await Fetching Google Analytics page views As I said in the beginning of this post, Google Analytics has a powerful API exposing a vast array of metrics and dimensions which you can view . here After identifying the metric and dimension you would like to extract from Google Analytics, you can use the npm package to retrieve the data you want. Google API's { defaults = { : jwt, : + process.env.GA_VIEW_ID,
  } jwt.authorize() metricRequestOptions = {
    ...defaults, : startDate, : , : , : }; (pagePath)
    metricRequestOptions.filters = result = google.analytics( ).data.ga.get(metricRequestOptions) result.data.rows;
} /**
 * Retrieves unique page views from Google Analytics
 * @param {*} pagePath the path to filter from results
 */ async ( ) function getUniquePageViews pagePath const 'auth' 'ids' 'ga:' await const 'start-date' 'end-date' 'today' 'metrics' 'ga:uniquePageviews' 'dimensions' 'ga:pagePath' if `ga:pagePath== ` ${pagePath} const await 'v3' return Executing the above request should return the page paths along with the number of unique page views [
    [ , ],
    [ , ],
    ...
] "/continuous-monitoring-using-flood-element-and-azure-devops/" "46" "/securing-traefik-dashboard-with-azure-ad/" "80" Once your serverless function is working correctly, you can then easily deploy it to Netlify. The full source code can be found here Using this, I was able to get the unique page views to simply show up on my blog instead of having to go to the Google Analytics dashboard every time. Endless possibilities In this blog post we've gone through a very simple use case of how Netlify functions can be leveraged but the possibilities are truly endless. How do you use serverless functions currently? Leave a comment and share your thoughts. Previously published at https://javaadpatel.com/get-page-views-from-google-analytics-using-a-netlify-serverless-function/

Stories, News & Mentions about NETLIFY

Netlify’s Stories on HackerNoon

Netlify's News & Mentions