web development

Apollo getCacheKey() with TypeScript

I’m currently working on the front end of an app that uses React + Apollo (via apollo-boost) + TypeScript. I’m to the point where I’m retrieving items from the cache in my resolvers using fragments1, which means I need to use getCacheKey() to search for the item's cache key using its ID field. (In this app, it would probably work to just assume the cache key is TypeName:UUID, but you never know, so we should probably do things properly.)

Unfortunately, I have not been able to find the correct typings for getCacheKey(). When passing in cache as an argument to a resolver, one can import NormalizedCacheObject for the typings, like so:

import { ApolloCache } from 'apollo-cache'
import { NormalizedCacheObject } from 'apollo-boost'


Mutation: {
  resolveSomeStuff: (
    _: undefined,
    { itemId, itemOptions }: { itemId: string; itemOptions: Array<string> },
    { cache }: { cache: ApolloCache<NormalizedCacheObject> }
  ) => {
  /* Now we resolve everything. Global warming, world
  hunger, over- and under-population.... */

Inside my resolver, the Apollo docs tell me to get an item's cacheKey like this:

const cacheKey = cache.getCacheKey({ __typename: 'Item', id: itemId})

Unfortunately, if I use this formulation, tslint will yell at me:

"Property 'getCacheKey' does not exist on type 'ApolloCache'."


Half an hour of Googling was unhelpful. But eventually I found someone reporting a similar-sounding problem as an issue over at the apollo devtools repo. I adopted his workaround, and it was effective for me. So here is the code inside my resolver:

const cacheKey = cache['config'].dataIdFromObject({
  __typename: 'Item',
  id: itemId

This essentially does an end run around the problem by not calling getCacheKey() at all. I don't know enough about the inner workings of the Apollo client to understand why this works, but I kind of don't care.

If you don’t know what some or all of that means, this post probably isn’t for you.↩︎

Website UX

I’m currently building a website for a new business I’m starting, and I keep being surprised at the user-interface challenges posed by designing a way for people to give you money.

Hitherto, most of my web development experience has been about presenting information, which just means doing a specialized kind of graphic design. Self-critical as I might be about my graphic design skills, this limits the number and kind of choices I have to make.

In this case I’m using the much-vaunted (and so far not over-sold) Squarespace for the design and hosting. I went with one of their lovely templates for the site because I didn’t want to spend forever on the coding part of the process.

This works as advertised. What Squarespace can’t do for me is make decisions. Which page should contain this or that idea? How do I want to describe the services I offer? Will people just click a button to go the payment page directly, or should I first take them to another informational page so they know exactly what they’re getting into?

It all needs to fit together in a way that makes people feel confident about what they’re buying, and that’s challenging. I know how my brain works, but it may not be the way the masses’ brains work.

I guess this is just another way that everything takes longer and gets more complicated than you imagined when you started.

Entrepreneurial Trials

One of the drawbacks (or perks, depending on what kind of person you are and how much time you have on your hands) of trying to work for yourself or be an independent artist is having to do many things yourself that most people would probably just pay someone else to do.

I designed this website myself. It runs on the well-regarded Movable Type platform, which is basically the same kind of thing as the much-more-popular WordPress. Movable Type is written in Perl, which I know almost nothing about except that its syntax is difficult to follow and that it used to be referred to as “the duct tape of the internet”.

I’ve already lost 80% of you by this point.

This week I decided that I wanted my blog to auto-post to Twitter, like some other popular blogging platforms. I figured (correctly) that this would probably just involve some googling and the subsequent download and installation of a Movable Type plugin.

Boy, that word “just” does a lot of heavy lifting, doesn’t it?

I did find the plugin, Twitter Tools, by MT-Hacks, a well-known Movable Type plugin developer. His installation instructions were pretty clear, so I whipped through them, navigated to the Movable Type Content Management System interface, and instead of seeing the login screen, received a mangled error message something like this:

can&#039;t use string (&quot;TwitterShortEntryURL&quot;) as a HASH ref while &quot;strict refs&quot; in use


Lest I lose the remaining 2% of you still reading by this point, I will not chronicle all the steps I went through to solve this issue. I’m only pretty sure what ultimately ended up working, anyway. I’ll just mention two things:

1) Installing a Movable Type plugin is not like installing desktop software; it’s basically just copying a bunch of text files to various locations in your web host. While doing this, I took a couple of shortcuts by replacing entire folders instead of replacing the individual files in them one by one. I ended up having to manually revert to previous versions of all those folders before redoing it the way I should have done it in the first place. Lesson learned: when doing things you only barely understand, follow the instructions slavishly; do not interpret.

2) The thing that I think fixed the issue was updating to the newest version of the LWP Perl module (oh my goodness, seriously… no one’s reading this now). I decided to do this because the plugin author said, right there on the Twitter Tools web page, that this was something you might have to do. I feel like this is the same lesson as Lesson One, above.

Anyway, good web-dev times. When you have more time than money, you end up doing things like this (or whatever the equivalent is for you)–chores that you would almost certainly be better off paying a professional person to do, were it not for that pesking time-money imbalance.

This is the first post I’ve made since installing Twitter Tools; now to see if it works!

Update: It does.

Too Many Chores

Pre-production, as it turns out, is all about time management and task-prioritizing.

Here is a rough list of things I have to do right now, in no particular order:

  1. Send several emails
  2. Fill out insurance applications
  3. Build a website for the film
  4. Post things on the website
  5. Record a video podcast. Every week.
  6. Draw stick-figure storyboards for the entire film.
  7. Do an inventory of the gear we have at our disposal
  8. Get bios and photographs of the crew
  9. Write sides to hand out at auditions
  10. Make the production schedule
  11. Read two books on directing actors
  12. Watch several movies for inspiration
  13. This blog post
  14. About 20 more things I can’t remember right now.

Figuring out which of those things to spend my time on is probably the biggest challenge. Nearly all of them are easy to do, or at least close. That’s not the problem.

Cheap, fast or good. You can have any two of those three.

I’m trying to leave out “fast,” but even that is turning out to be hard.

Watch the Reel. Because.

Because it took me so long to figure out, that’s why.

This is how publishing your own website is. It takes you fifteen minutes to make some minor changes to your reel, then another two hours to figure out how to do HTML5 video while also supporting certain backward browsers built by companies who disdain plebeian things like innovation.

And don’t get me started on Ogg Theora.

Anyway, the reel is up; I hope you love it.

Edit. The Reel is now no more.