ApolloServer, AzureFunctions and local debugging

I wanted to jog down some notes that’ll help with local debugging of Apollo Server with Azure Functions.

Firstly, due to changes to Azure API routing - specifically x-ms-privatelink-id having strange invalid characters - we need to expand the function handler and blank out the x-ms-privatelink-id property.

https://github.com/Azure/azure-functions-host/issues/6013

Now to get local debug happening - we must configure CORS.

Add the cors settings - origin can be ‘true’ for every url, or ‘http://localhost:4200’ if only for your local build.

Additionally, copy the access-control-request-headers to Access-Control-Request-Headers because ApolloServer applyMiddleWare is case sensitive.

https://github.com/apollographql/apollo-server/issues/4178

const graphqlHandler = server.createHandler({
    cors:{
        origin: true,
        credentials: true,
    }
});
export default (context: Context, req: HttpRequest) => {
    // https://github.com/Azure/azure-functions-host/issues/6013
    req.headers['x-ms-privatelink-id'] = '';
    // apollo-server only reads this specific string
    req.headers['Access-Control-Request-Headers'] = req.headers['Access-Control-Request-Headers'] || req.headers['access-control-request-headers'];
    return graphqlHandler(context, req);
}

These changes by itself isn’t enough, we also need to make sure the Azure Functions runtime is forwarding the options method correctly to our Apollo Server. Make sure ‘methods’ contains ‘options’ otherwise the Azure Functions local runtime will not accept the browser pre-flight request.

(this second one was the one that got me for a while - why wasn’t Apollo Server options being called?!)

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post",
        "options"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ],
  "scriptFile": "../dist/graphql/index.js"
}

Building modern public sites (JAM Stack) with Microsoft Flow

Web technologies evolve, and we are on the edge of a new stack, it is called JAMStack.

  • Javascript

  • API

  • Markup

In the world of JAM Stack, we create serverless public sites by hosting them directly from a CDN.

Now there are plenty of frameworks that will move to help developers to create this type of applications right now and next.

What I’m writing about is how citizen developers can take advantage of the same pattern to build public websites

Episode 0

  • Define JAM Stack

  • Set up data source (SharePoint)

  • Set up API (Flow)

  • Set up Storage (Azure Storage)

  • Set up CDN (Cloud Flare)

  • Set up dynamic trigger


Whether you are a Professional Developer or a Citizen Developer - you need to understand the basics of this stack. This will save you a LOT of money.

How we can use Microsoft Flow (Power Automate) to build public websites. This is a how-to video that involves defining the JAM Stack, Microsoft Flow, Azure B...

Hot-patching our dependencies with patch-package

lego-644x450.jpg

This is also a quick blog post.

Let me tell you the tale of patch-package. Not many people have heard the tale of patch-package. Many prefer to walk the path forked.

Well, the path of patch-package works like this.

About patch-package

Your favourite NPM library has a problem. You need to hot fix it. You send in a PR and it’s stuck in review hell. The poor maintainer is on stress leave and you really don’t want to trouble her/him - they are in Finland, don’t wear shoes, and can’t possibly scale any further.

This is the patch-package path https://www.npmjs.com/package/patch-package

  1. yarn / npm lock the dependency on that specific version so our entire team and the build pipeline gets the same version

  2. npm install patch-package --save-dev

  3. make changes in node_modules against that library, e.g. “package-banana”

  4. npx patch-package “package-banana” - this creates a folder
    /patches/package-banana-version.patch

  5. add “postinstall": "patch-package" to scripts section in package.json

  6. check in / commit everything. Package.json and /patches/package-banana-*.patch

Now when anyone get latest and run npm install, the build chain will automatically grab that version of the library package-banana and apply your patch.

Then it will build as normal. This works great on Azure DevOps (VSTS) too.

When the library package-banana is finally fixed - update the library version and the patch file won’t work against newer versions.

Bad JavaScript. Expected '(' in our webpack eval chunk

This is a quick blog post for resolving an issue this morning from webpack uglified/minified JavaScript. The error happens in IE and Edge, it simply says:

Expected ‘(‘

This was happening in the middle of a webpack minified chunk so the entire block was wrapped inside eval(““)

Steps

  1. Navigate to the end of the webpack chunk, which will tell us the source of this chunk. Scroll past the sourcemap section to the end of the chunk (not the end of the file).

  2. Find the original file that the chunk was created from - now run ESLint over it.
    I didn’t have this handy in the build chain, so I ran it online https://eslint.org/demo/

  3. The error was spotted as there was a catch{} statement - in plain JavaScript - catch has to collect an argument. So the first syntax is incorrect. It must be the second syntax.

try {
    // do something
}
catch {
    // incorrect  
}
  
try {
    // do something
}
catch(e) {
    // correct, even if we don't use e  
}


Modern browsers are more lenient so this error did not appear on all browsers.

JSON cheatsheet for Microsoft Flow

I have a big blog post in the works for a significant dive in Microsoft Flow functionality.  But I realized that before we get there, we need to GET GOOD at doing JSON in Microsoft Flow.

So this is the cheat sheet.  With all the caveats.  Enjoy!

Update: added a compound JSON object construction.

This is the part of the cheatsheet series on Microsoft Flow.

  1. JSON cheatsheet for Microsoft Flow (this article)
  2. Nested-Flow / Reusable-Function cheatsheet for Microsoft Flow
  3. Building non-JSON webservices with Flow
  4. One Connection to Proxy Them All - Microsoft Flow with Azure Functions Proxies
  5. Building Binary output service with Microsoft Flow

var X = { "x": 1 }

{ "x": 1 }

And this is the running results

X = JSON.parse("{ 'x': 1 }")

Flow-2.png
"@json('{\"x\": 2}')"

X is updated.  But the run result panel for Set variable shows incorrect INPUTS value of X

{ ...X, { 'y': 2 } }
jQuery.extend( X, { 'y': 2 } )

"@union(variables('X'), json('{\"y\":2}'))"

Union is great - it'll let you add properties to existing objects easily.


var Y = { ...X, { 'y': 2 } }

Flow-4a.png

Use union to set variable

if ( Y.x != null )

sometimes, you need to check if an object contains a property

sometimes, you suddenly don't need the " double quotes for conditional statements. 
sometimes I feel this is a bug.

Flow-5.png

 

The UX can get quite silly.  It forgets how to render the basic view after you save.

(Y.x || Y.y)

"@coalesce(variables('Y').x, variables('Y').y )"

 

Use Coalesce to pick the first non-null value.  If the property doesn't exist this will error.  Protect the check with contains

X = Y

And we end this cheat sheet on a simple one.  Assigning variables to another.

Note you can't currently use the variable in setting the variable itself.

This would have been REALLY useful...  Because this would have let us keep appending to existing variable.

 

Finally, object composition
var Z = { z: Y }

"@json( concat( '{ \"z\": ', variables('Y'), ' }'  ))"

The result, see how a compound JSON object has been constructed.