What's it all about, Alfie?

Over the weekend, I had a problem with a project at work that was using PostGraphile and I was having an issue with the Postgres URL that I was feeding to the configuration of PostGraphile:

    postgraphile(
      process.env.PLATTER_POSTGRES_URL,
      'public',
      {
        watchPg: false,
        graphiql: true,
        enhanceGraphiql: true,
        graphqlRoute: '/graphql/v2',
        graphiqlRoute: '/graphiql/v2',
        eventStreamRoute: '/graphql/v2/stream',
        appendPlugins: [
          require('@graphile-contrib/pg-simplify-inflector'),
          require('postgraphile/plugins').TagsFilePlugin,
        ]
      }
    )

The process.env.PLATTER_POSTGRES_URL was generated by a call to the Platter service, and it turned out to be cached, and stale, and as the source is Let's Encrypt, it needs to be updated monthly. The cache had been running for more than a month, and that left an old, expired, certificate for the site, in memory.

It was easy enough to have them restart the cache, getting to that point... well... 🙂 that was a little more involved. The first issue was that with PostGraphile, used as a Library, had the feature that if it could not generate the initial schema for the GraphQL engine, it would exit the process, and effectively crash the service.

I wanted to protect the service, so the first order of business was to update the way I was using PostGraphile to allow me to capture the failure, and just disable the GraphQL engine until we could get this problem figured out. Thankfully, that was as easy as adding a function to the retryOnInitFail option:

    postgraphile(
      process.env.PLATTER_POSTGRES_URL,
      'public',
      {
        watchPg: false,
        graphiql: true,
        enhanceGraphiql: true,
        graphqlRoute: '/graphql/v2',
        graphiqlRoute: '/graphiql/v2',
        eventStreamRoute: '/graphql/v2/stream',
        appendPlugins: [
          require('@graphile-contrib/pg-simplify-inflector'),
          require('postgraphile/plugins').TagsFilePlugin,
        ],
        retryOnInitFail: (err, att) => {
          log.error(`[PostGraphQL] Error on initialization: '${err}' with ${att}
                     attempts. Bailing out on PostGraphQL.`)
          return false
        }
      }
    )

At this point, we had time to figure out what the issue was. I was going to dig into the PostGraphile code, and Alex, at Platter, was going to look at it from his end. Which brings me to the point... the PostGraphile TypeScript code is very nice. Yes, there are a lot of packages/modules, and the organization is clean, but I'd have done it the same way - easy separation of responsibilities. The code is exceptionally clean... well considered and implemented. The more I dug into it, the more impressed I was with it as a project.

I thought it might be an issue with their code - an asset they are loading that has an expired certificate, so I filed that on GitHub, and had a wonderful exchange with the maintainer of the project. As I dug in more, and worked to repeat the issue on a much more limited basis, the back and forth with the maintainer was very helpful... just exactly what you'd hope to encounter - but often don't.

It was the most unexpected, wonderful, experience I'd had in months. It renewed my faith in Open Source again. 🙂

This morning I was looking to visualize some time-series data from a Plaid Asset Report, in preparation for some work at The Shop, and I thought that it would be a perfect opportunity to use the xkcd Chart package. I like the way it's clearly trying to be a little less serious, and it seems like just the thing to try out for this visualization.

The data from the endpoint I created is returned as a sequence of tuples:

{
  accounts: {
    'Checking': [
      [ '2021-09-05', 115.4 ],
      [ '2021-09-06', 115.4 ],
      [ '2021-09-07', 110 ],
      [ '2021-09-08', 110 ],
      [ '2021-09-09', 110 ],
      [ '2021-09-10', 110 ],
      [ '2021-09-11', 110 ],
      [ '2021-09-12', 110 ],
    ],
    ...
  }
}

these are really the closing balances for each date for the account, and I just wanted to be able to visualize them so that any calculations can be validated by looking at the data.

The graph turned out pretty well:

This is just exactly what I'd hoped for. 🙂

A friend pointed out Cloudflare Workers to me as a near-Heroku style deployment and run-time platform for Node/JS projects. It's really more turn-key than Heroku - it's targeted at the folks that don't want to maintain servers, or worry about global data centers, or anything like that. Just make a Node/JS project, deploy it, and pay for what you use.

There are a lot of reasons to like something like this - it's what someone would need if they just wanted to write the code and leave all the other details to someone else. It's got a nice "Free Plan", for little hobby projects - much like Heroku, but it doesn't provide all the services that Heroku does in it's Store... but again, if this is a simple Node/JS app, you are probably set up with your own database and Cloud Services, so that's not necessarily a bad thing.

I haven't really used it on a project - yet, but I can imagine trying one - from my iPad and play.js... it might be interesting to see how it all might work in a non-laptop mode... 🙂

This morning, play.js had an update the allows for real-time collaboration through Code Sandbox, and I have to say, it's a very interesting development, for the development I'd like to be doing on the iPad. I have really been hoping to move more development to the iPad, and play.js is an amazing tool that I've just started to experiment with, and the idea of the collaborative sessions would be very nice to have as a teaching and support tool.

While I'd love it if there were similar iPad tools for ObjC, and Clojure, I can't complain because it's really a nice set of tools for the majority of the Node/JS and Typescript work that I do. Sure... there are npx commands that don't work because they are compiled, and so not everything is going to work today on the iPad, but quite a lot will, and the collaboration features are a nice move in that direction as well.

On the heels of the Notarize Node Client, we took the time to create a Node Client for the PostGrid service - where they will use regular Postal Delivery for PDFs, and HTML pages, and we needed that at The Shop. It was easy enough to build on the previous client, and just update the different domain elements, and handle the data interfaces. Not bad at all.

One thing I did have a few issues with was the handling of the Form Data for the posts to the service. There were endpoints that could accept application/json data, and some that required multipart MIME data from a FormData element. Thankfully, I'd had to work with this for some additions we made to the HelloSign Node Client, but that was a lot easier because the basic client was written by the HelloSign engineers, and we just had to add the ability to post PDF documents provided as Buffer objects.

In all, it wasn't all that bad, and now I have a core TypeScript library for building almost any client for a restful service with either JSON or Form Data. That's a nice place to be. 🙂

This morning I saw a tweet that a new version of Sublime Text 4 is out - and given the few little issues I've seen, I was quick to upgrade and see what the release notes said. What I read was that there were significant speed improvements, along with improvements in the OpenGL rendering, and several fixes in the specifics of the UI rendering. There was only one Mac-specific issue, and that was related to the Dark/Light scheme, which is fine, but doesn't worry me.

When I started using it, I was pleased to see that I didn't see any of the problems I'd seen before, and the editor seemed zippy - so what's not to like? 🙂 I have a new TypeScript project I'm about to start, so we'll see how it handles that load as well.

Several weeks ago, The Shop made the decision to implement CI/CD on the code repositories at GitHub using GitHub Actions. And it has been an amazing success. The ability to set up individual responses to GitHub actions like push, and so on. It's also very nice that it's all done in parallel, which is very nice for speed.

One of the things I have really enjoyed about the Actions is that GitHub gives each project quite a lot of free compute minutes for the execution of the Actions. This means that if you have a relatively static project, this is likely something you will be able to use for free. And if it's a business, you could prove out that this will work for you before having to invest in more tooling.

When you do run up against the limits of the free plan, the only thing that will happen is that the Actions will all fail. This is completely understandable, and a very reasonable fall-back position for projects. Add a billing source, and you're back in business. Very nicely done.

This morning I pulled up play.js on my iPad Pro to run a simple project I built to hit a MLB stats site and extracts some data, and format it into a simple JSON output. It's nothing, really... a simple Express/NodeJS site that I used in learning Express... but it is just an amazing tool for writing Node services - with front-ends, or not.

It's really pretty nice - includes a full git client, and complete dependency searching and incorporation... it's all you'd really need if you had a Node service back-end, and a static assets front-end. I know it can do even more on the front-end, but I'm quite happy with the ability to use HTML/CSS/JavaScript to build the front-end - I typically don't build elaborate front-ends to validate the back-end service.

The one wrinkle I've seen with some Node dependencies that include non-JavaScript components - like downloaded commands. These are not going to run in play.js's environment. It has to be 100% Node and JavaScript. So... there are some limitations on the projects it can handle... but not many.

Today I was able to publish my first Open Source TypeScript npm library for using the Notarize service. Their docs are good, but the only client they offer is really just the docs on the REST endpoints for the service, which are nice, but it's really nice to have a good client that makes accessing the functions of the service easy. So at The Shop, we decided to make a Client, and then give it to the Notarize folks so that they can give it to other clients looking for a simpler access interface.

This was a nice foray into TypeScript, because the interfaces are easy to define, the domain components of the service are nicely separable, and things generally worked out quite nicely. The tests didn't seem to fit into a simple CI/CD pipeline, but that's something that we can work on - if needed, and now that it's out in the wild, we will see how it's used, and if we get requests for additions.

All in all, it was fun to get this out. And it made working with the service much nicer. 🙂

This morning I did a little security updating on a project at The Shop - a few OWASP issues for dependencies. One had risen to a high level, so it seemed like a good time to dig into the updating process.

In the past, for Java and Clojure projects, I've had to go and look up the recent versions of each library and see if they correct the security issue, and if they do, are there other updates that I have to do in order to handle any changes from these security-related updates? It was often times a very tedious process, and doing it for Java Spring projects was almost something like Black Magic.

Imagine my surprise when I find that Node/JS already has this covered. Simply run:

  $ npm audit

and not only will it list all the OWASP security vulnerabilities, but it will also provide you with the specific npm commands to update (aka install) the specific package, and how far down the nesting tree that package sits.

Run the commands specified by the npm audit command, and you'll update just what's needed, and not have to go through the process manually. What a refreshing change to my previous encounters with fixing OWASP vulnerabilities. 🙂