2 posts tagged with "netlify"

Log Drains for function and CDN logs from Netlify, which have native SumoLogic collectors available, are included with Enterprise level subscriptions. However, there is a quantum jump in subscription costs between the Teams or Pro Editions of Netlify and the Enterprise Edition.

If you are deploying a JAMStack app in Netlify, the odds are each page will include an API call (using Netlify functions), and for authenticated pages, the request will include a Bearer Token.

Solution Overview​

Create a logging module that exports functions that can be used by any of your Netlify functions to log verbose data to the console (seen in the function log output in the Netlify app) and to push log events to a Hosted SumoLogic Collector Source. This will allow you to see verbose logs for each function call and CDN logs for each page load.

Steps​

Steps to deploy this solution are detailed here:

Step 1. Set up a Collector and Source​

Set up a Custom HTTP Collector and Source in SumoLogic (copy the source URL) using the SumoLogic web interface; see the documentation here: https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/HTTP-Source/Upload-Data-to-an-HTTP-Source.

Step 2. Create Netlify Environment Variable(s)​

Create a build time environment variable in Netlify for the Sumo Source URL you generated in Step 1 (in this case, I have called it SUMO_REQUEST_SOURCE_URL).

Step 3. Create a logging module​

Create your logging module (this example is in TypeScript, but you could implement the same logic in any other language/runtime). In this case, we will unpack the request event and send the fields to the collector source.

Step 4. Import and use the logging module​

Now import and use the logRequest function at the beginning of each Netlify function you deploy.

You will now get verbose logs (similar to CDN logs) to the Netlify console and to Sumo Logic!

You can implement similar functions for each request to log the jwtId and userInfo from the Bearer Token. This will allow you to see the user information for each request in SumoLogic.

headers: {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'Content-Type',
  ...
},

if you have enjoyed this post, please consider buying me a coffee ☕ to help me keep writing!

The Azure Static Web App feature is relatively new in the Azure estate which has recently become generally available, I thought I would take it for a test drive and discuss my findings.

I am a proponent of the JAMStack architecture for front end applications and a user of CD enabled CDN services like Netlify, so this Azure feature was naturally appealing to me.

Azure SWAs allow you to serve static assets (like JavaScript) without a origin server, meaning you don’t need a web server, are able to streamline content distribution and web app performance, and reduce the attack surface area of your application.

The major advantage to using is simplicity, no scaffolding or infra requirements and it is seamlessly integrated into your CI/CD processes (natively if you are using GitHub).

Deploying Static Web Apps in Azure​

Pretty simple to setup, aside from a name and a resource group, you just need to supply:

• a location (Azure region to be used for serverless back end APIs via Azure Function Apps) note that this is not a location where the static web is necessarily running
• a GitHub or GitLab repo URL
• the branch you wish to use to trigger production deployments (e.g. main)
• a path to your code within your app (e.g. where your package.json file is located)
• an output folder (e.g. dist) this should not exist in your repo
• a project or personal access token for your GitHub account (alternatively you can perform an interactive OAuth2.0 consent if using the portal)

An example is shown here:

GitHub Actions​

Using the consent provided (either using the OAuth flow or by providing a token), Azure Static Web Apps will automagically create the GitHub Actions workflow to deploy your application on a push or merge event to your repo. This includes providing scoped API credentials to Azure to allow access to the Static Web App resource using secrets in GitHub (which are created automagically as well). An example workflow is shown here:

Preview or Staging Releases​

Similar to the functionality in analogous services like Netlify, you can configure preview releases of your application to be deployed from specified branches on pull request events.

Routes and Authorization​

Routes (for SPAs) need to be provided to Azure by using a file named staticwebapp.config.json located in the application root of your repo (same level as you package.json file). You can also specify response codes and whether the rout requires authentication as shown here:

Pros​

• Globally distributed CDN
• Increased security posture, reduced attack surface area
• Simplified architecture and deployment
• No App Service Plan required – cost reduction
• Enables Continuous Deployment – incl preview/staging environments
• TLS and DNS can be easily configured for your app

Cons​

• Serverless API locations are limited
• Integration with other VCS/CI/CD systems like GitLab would need to be custom built (GitHub and Azure DevOps is integrated)

Overall, this is a good feature for deploying SPAs or PWAs in Azure.

if you have enjoyed this post, please consider buying me a coffee ☕ to help me keep writing!