Static IBM Cloud Application

For my mum’s business, I run the website simplyfleece.co.uk. It has been through various incarnations but right now, it’s a simple website which I wrote in pure HTML and CSS (shocking!). Originally, when deploying to IBM Cloud, I was using Node JS and Express to serve the HTML. But this is overkill, especially when using Cloud Foundry.

Introducing the Static buildpack

IBM Cloud still allows users to deploy cloud applications with CloudFoundry, which I use for all of my applications. Normally I would use the NodeJS buildpack, but for simple HTML and CSS, I only need the Static Buildpack which allows simple HTML files to be served with very little config!

Simply create your website, and then create a Staticfile file, and push to IBM Cloud, and it’s ready to go!

index.html
styles.css
StaticFile
ibmcloud app push -k 64M -m 64M my-app

And that’s it! The static buildpack uses NGINX to serve the files, and if you need additional options, they go in the Staticfile and the options can be found here. For example, my SimplyFleece site has the following options for setting the file structure, and forcing HTTPS:

root: public
force_https: true
Written on August 1, 2018

GraphQL 101

title

Today in IBM Hursley I gave a quick introduction to GraphQL. We are using GraphQL in my current project at IBM Watson, with good success. While we as a team are still learning how to best use it, I can at least attest for its benefits compared to REST.

REST is not without issues, baked into its design. By describing only how to seek and modify data, servers and clients can be tightly coupled, which means it can be difficult to apply change to the API without causing a lot of work to update the client.

Another issue with REST is predicting what a client will request. Designing an API usually means designing how the client will need and utilise the data. If the client strays off the beaten path, it can result in underfetching an overfetching, meaning requiring additional API calls for more data, and discarding useless fields in payloads.

GraphQL aims to beat these issues, and more. By describing your data structures in a strongly typed schema, you define, and implement with resolvers, only the data itself. This means you aren’t enforcing a way of fetching data on your client, only providing whatever the client asks for.

The client then queries the graph of data, fetching all and only what it needs, saving time and bandwidth, in a single payload.

For more information, I recommend the GraphQL website and How to GraphQL.

Alternatively, read my slides that follow.

Written on July 12, 2018

New Blog!

I’ve created a whole new blog on my Github Pages site! Here it is!

Written on July 10, 2018