Extending Directus for an Online Art Gallery - London Meetup

Speaker 0: Alright. Hi. My name's David. I'm gonna tell you a little bit about, extending directors to build a beautiful online art gallery. Can everyone hear me okay?

If you can't, please, like, wave at me, shout at me, be like, Can't hear you. And then I'll speak up, we'll move this. A quick show of hands just so I can gauge, who here has used Directus on a project? Great. Good start.

Who has used it for more than one project? Just because I'm curious. Nice. Who has, when they've been working on a director's project, you've used an extension as part of that? Alright.

Starting to shrink. Great. Who has written a custom extension? Okay. Great.

Phew. Otherwise, I was worried that I was going to be like, hey, you guys tell me how to write an extension. All right. Before I start, a little bit about me. I'm David.

I'm head of engineering at Pixilabs. We are a digital product development agency. That means that we design and develop digital products, everything from internal platforms for FTSE 100 companies to manage smart home device installations, helping funded startups launch their product, all the way down to we once made a typewriter type by itself when you tweeted at it. And that was part of a digital art installation for Twitter, which was really fun. Basically, if we can code it, we will do our best to do that.

And, actually, most of the time we build, like, full stack web applications in Ruby on Rails. But sometimes, we need a headless CMS and sometimes, we often turn to directors. So that's what I wanna talk to you about, not the Ruby on Rails apps. Just because I thought it would be interesting, like, if I was here, I would wanna know what are people what are other people making with Directus. Right?

So I thought I'd show you a couple of things that we've made at Pixielabs. The first one, is a company called Blackwing 7. They make bespoke cinematography lenses for film, TV, music videos, things like that. This is kinda what you maybe a site that you would traditionally expect for a headless CMS. Right?

So, we actually took this over from another agency. It was all completely static, and the client wanted to be able to edit little bits of it, make some of it interactive, and things like that. And so that was something that we kind of turned to Directus to build. Something maybe a bit more unusual, thinking about that kind of, like, not just a headless CMS kind of vibe. This was a for good project called Red Flags.

You can kind of think of it as like hazard perception but for consent. If any of you have taken your driving test and you've done the hazard perception, you know, you're watching a video of someone driving, usually through Wales, and you click a button every time there's a sheep on the road. Basically, that, but, but, yeah, for for consent. So there's, like, a video that you watch of someone going on a first date and you click a button every time you see, a, you know, an issue to do with consent. This was a campaign around that.

And at the end, you get a score of how many you spotted or how many you missed, and you get to submit some details about you to sort of help their campaign, help understand who is engaging with this. And that's particularly interesting because that was where we were kind of using that ability. You know, Directus is ultimately just a wrapper around a database. Right? And so we could use that to store those results that were being submitted alongside the content that was part of the website as well.

So really acting as more like a basic kind of app data store there than just a headless CMS. You kind of maybe something you might use Firebase for as well maybe is kind of like a sort of point of comparison. Kind of interesting. I'm gonna talk about a different project, for a client called Depuri that we worked on. I'm gonna tell you a little bit about that project, why we picked Directus, the extension that we had to build.

That's the meat of it. And some tips as well for building your own extension if you, you know, are sort of wondering about how you'd go about doing that. Hopefully, by the end, you're gonna know some pitfalls to avoid if you do go about building an extension, how to get started as well, and, also, you're gonna hopefully know the best, in my opinion, way to, progressively load images on a website if you wanna do it in, like, a really, kind of optimum way because that's the extension that we built. So the project was, to build this kind of beautiful online art gallery, for a new brand, of online art curation and auctions called De Pury. We did a whole kind of tech stack evaluation and architecture process for this, and we recognized a couple of things.

We knew that we wanted a bespoke front end so that we could wield all of our front end power, and we wanted a layer there that could, you know, we could kind of do whatever we wanted to do. So, we knew that the designs were gonna be you know, they wanted it to feel luxurious and feel sophisticated and expensive, and so we knew that we needed to be able to kind of tweak it a lot. And we recognized early on we needed a CMS because we did not want to have to edit all the content by hand. We wanted the client to do that. So we recognized pretty quickly that we needed a headless CMS.

So Directus ended up being a good fit for a few reasons, actually. First of all, the image handling in Directus, if you've not explored that a bit, is really cool. We knew we were gonna need to be able to do resizing for different devices. We potentially thought we might have to do sort of interesting transformations of images. Maybe we wanted to make them grayscale or blur them or anything like that as part of the designs.

And, Directus exposes the whole of the Sharp API. I don't know if anyone's a JavaScript dev. You might be familiar with Sharp. It's like ImageMagick or something like that. It's a really great package for manipulating images.

Directus just gives you that whole thing. You can just drive it via the API which is super cool. You can also configure it to cache forever and have no expiry on caching. Right? Which was useful for us.

We didn't want images randomly loading slow because Contentful had decided to delete some of our images from their cache or something like that. We really like the API. A lot of headless CMSs at GraphQL. I'm not really a huge fan of GraphQL. Really like that there's a REST API with Directus.

It's just quicker and easier to get up and running for a small project. Right? It's easy to deploy. Tapuri had some existing infrastructure on Amazon Web Services, and so it's just a Node. Js app.

You can deploy it somewhere. It'll align nicely with that. And lastly, we knew that we could extend it. Right? We felt comfort as we went into this project that we were like, well, if if there's something that directors can't do, we can at least write some JavaScript to make it do what we needed.

It turns out, we did need it. So direct us wasn't quite enough. Once we got going, and we were iterating, we identified a problem with the way that the images were loading. The website was full of these large, high quality images. They wanted to sort of full bleed, you know, images of the artwork, that was being curated.

And there were also just, like, galleries and it was just images. Right? Just thumbnails of images. And we wanted these to feel great, especially on mobile devices. The default approach, usually, is to do something like, low quality image placeholders.

Is anyone is anyone familiar with the concept of low quality image placeholders? If you're not, it's like where you basically request a really tiny image that's, like, 6 by 6 pixels, then you make it as big as you want it, and you add some kind of blur to it. Right? And then as the real image loads, you cross fade from one to the other. You get kind of a nice fade as the image loads rather than just, like, a gray box.

The problem is that that still takes time. Right? The page loads. We've got, like, 50 images that we wanna load. Now we're asking someone's web browser to load 50 images.

Still lots of requests and so we ended up in this situation, the client wasn't happy with it, where you've got a bunch of gray boxes that quickly change to these blurry versions of images and then they change again to the real image and it just didn't look great. Right? Fortunately, we had a solution in our back pocket that we'd used before which is called blur hash. Is anyone familiar with blur hash as a thing? Alright.

Great. Mostly shaking of heads, which is good. So Blahash, is a solution to this. It was made by a company called WALT, which is like a European Deliveroo competitor, which I hadn't heard of, I guess because we have Deliveroo. And they built a thing to to solve this problem.

I'll just show you it quickly. So it's kind of like a representation of a placeholder of an image. Right? So, imagine they had the same problem. Right?

They had this nice app and they just had these gray boxes and they were annoyed about it. What you basically do is you feed your image into the blur hash algorithm and you get, like, a very short representation of a blurry version of that image. Really, really short, like 10 to 20 characters, which you can then pass back to the blur hash library and it will generate a kind of blurry, smooshed version of the image. And what's cool about this over low quality image placeholders is that there's no extra request. You can include this, so when you're getting the data for your page, you're getting the data about your images, you can have the blur hash ready to go alongside the, like, URL, width, and height.

So there's no extra request. One request for everything and you've already got those placeholder images. Super useful for us. Alright. So we knew we wanted blur hash.

Directus doesn't have blur hash support by default, so so we needed to build an extension. Specifically, we built a hook extension, and I'll talk a little bit about different types of extensions but that, basically, is, like, custom JavaScript code that you can write and it will run at certain points defined by directors. Right? So, if you've ever written WordPress plugins, maybe, where you've got hooks, that'll feel really familiar or any kind of event based programming in JavaScript, you know, where you're like on this event, do this code. Basically, that.

So, in theory, we were like, well, this is pretty straightforward. We want to add a new field against all our images to store the blur hash. Then, when an image is created or modified using that hook, we want to use the blur hash library to calculate that string that you saw for the image and then save it into that new field. In reality, there were a few interesting gotchas which I'll tell you about, but in principle it was pretty straightforward. I'll just show you it quickly, what it looks like in reality.

So this was the site. Ignore my dev tools on the side here because I've got network throttling on to try and show you what it looks like. Please find the right button eventually. Hopefully, I've refreshed and cleared cache. Yeah.

So, you can see the effect where the blur hash is already there and then it crossfades to the image. As I scroll down, some of these are still even on a pretend 3 gs they're still loading in time. But, you can see the effect. There's no flicker from one to another. There's no gray, then color, then image.

It's just straight in. Some of the of course, they're now loading. You know, there we go. There's 1. We can go and look at this in Directus as well.

So if I come in here, this is the Directus instance for this site, this is for the home page. If I create a new block here, I'm gonna pretend like they're curating my own photos. So if I create this home page block, if I go back and look at that now and go and look and edit that image, we can see that the blur hash has been added. Right? So the extension's got that field in there.

It's generated it on save, and it's put it against the image. So now if I go and have a look, hopefully Imagine if it doesn't work out. Live demos was the worst. I tried to keep this one really simple. Yeah.

So you can see the blur hash loaded straightaway and then, on my simulated 3 gs, eventually, my image loads. Look at that. Oh, there was one other thing as well. We were talking about that nice REST API. So you can see here, right, this is the this is all the JSON for the homepage.

Single request to get the home page and get all of the related fields. Yeah? Sorry, can you carry on the flow? I'll ask when you're done. Okay.

Yeah. I've got space for questions at the end. Hold it hold it in your head if you can. Yeah. So you can see, you can see the blur hashes here being included in with the JSON.

Right? So they're all ready to go. Just drop it on. Cool. Alright.

The fun stuff. What did we learn? Quite a bit. First of all, there's a Director's extension SDK, which is super useful for getting started. It has a nice kind of, like, command line interface for getting set up.

It generates a kind of, like, directory depending on It asks you what kind of extension you wanna make, puts it all together for you, and kinda gets you started. There are lots of types of extensions, and that can be confusing. These are all the different types. Also, they're all kinda subtly different, in the way that they're, like, put together. At least when we were doing ours, hooks are are JavaScript and they're compiled using a thing called roll up, which I'll talk about in a sec.

But then app extensions are like ECMAScript modules, and they're loaded in a little bit differently and it's very confusing and it's moved around a little bit and, yeah, there's definitely some funkiness there to watch out for. When you build an extension, especially a hook extension, all of the internal API services are made available to you. They're, like, handed to your code. Like, Here you go. You can use all of this stuff.

There's no documentation for what any of that stuff is, Not even in the source code, there's not really comments for it. So you do have to kind of poke around to try and find what you need. I can actually show you an example where we've got our extension source code here. It's a little bit small, I know. But like this here, we're, like, calling the this asset service is coming from Directus.

Directus is giving it to us. Presumably, they want us to use it. But this get asset method, you've just gotta guess, what it's doing. Right? And it changes because it's an internal API and I did feel a little bit nervous putting it in here, I will admit.

But, hey, it works. So look over the source code. They are there to use. There's also no agreed way to embed a database migration in an extension. So you can write a migration as part of your as part of a director's extension.

But, like, if you wanna release an extension that does something to the database, there's no kind of agreed way of doing that. That made us a little bit nervous. I think there's a few different approaches. You can ask the user to put it in themselves. You can copy it in sneak.

Ly, which is what we do, or you can just do it at run time, which feels a little bit scary. Rollup, which is a tool that, at least for hook extensions is being used to kinda compile the extension. So you write your extension code and then Rollup builds it. Not webpack or anything like that. It's Rollup.

Kind of funky. It does some weird stuff if you want some dependencies. If you're including some dependencies for your extension, roll up's gonna do its best to try and push those all to your extension, and it can make a bit of a mess. And that kinda relates to this. Testing locally can be painful.

There is some stuff to help. The Director's, extension SDK has, like, a link tool that you can use to link your extension code into, like, a local Director. So while you're devbing and you're playing around, you can try stuff out That can mess with nodes, like dependency resolution, which can cause you trouble. So watch out for that. But, all that said, reading other extension code is super useful and there's 2 really great ways of doing that.

1 is that there's this awesome Directus on GitHub. Everyone loves an awesome something on GitHub, which has got a list of extensions. Super useful to go through and look and see how are other people doing this, how are people solving this problem. And, also, you can just go on to npm and search keywords directors extension because that SDK adds that by default to your package JSON. So if anyone who does that and then publishes it, it gets added as a keyword, which makes it super easy to search.

I think that was probably intentional so that they can find all the director's extensions, But useful as well if you're building your own. And hopefully, this doesn't I know there's a lot of negatives there, but it was kind of a, like, here's some stuff to watch out for. In general, it was actually pretty straightforward. The extension's only a 100 lines of code. There's not a lot to it.

Right? And it was very easy to get started. And I think, like, there's lots of opportunities to build stuff here. Right? Like, this is a community, it's open source, which actually Kevin is gonna talk about.

And it's hard to sell open source to clients, but it does sell well to us and to the team. Like, we believe quite strongly in open source as well. So being able to, like, do this and give back, is great. Yeah. Hopefully hopefully, that was useful and interesting.

Thanks for listening, if it wasn't.