The hard choice we all face at least once a day. Any frontend dev will tell you.. wait they’ll just not tell you, they’ll just do a array.filter().filter().filter().map().map().reverse(). And like any backend dev will tell you.. ‘Why do they even need that?’.

The problem with sorting lists and transforming objects on the client is that your client has to do the work themselves. It is their computer that has to compute all your lousy n^5 algorithms. This might not be a problem on your dev server running 64 gigs of RAM, a brand new RTX 4090 and your 18 CPU-cores. But anyone with a parent that holds upwards of 50 tabs open at a time knows computers run slow. Even relatively new ones. Moving code execution to the server you could provision your own machines to do all that work your data model forced you to do. It’s not even your fault, it’s the product people. Why don’t they just know what the solution will be a couple years later? Pff..

We use Electron as a Javascript framework to create good-looking user interfaces. It runs as a desktopp app, which is exactly what we need. We don’t want an open browser in our MagicMirror. Since our solution lives 100% server-side, in the sense that it won’t run on a customers device, we still need to make use of the Client-Server architecture. We need to keep our asynchronous logic seperated from the frontend due to the architecture imposed on us by choosing to work with something open-source. Now, to stream videos, make API calls and the likes, we need to do this… vanilla! (yeah I’m talking vanilla javascript man it ain’t easy). So how can we make it easier for our selves? Well, we can leverage the websocket-connection between the somewhat-empty functionality of the DOM and the more powerful server side that can use node modules. Because our frontend and backend are sat up with a web socket we can transmit events with payloads in order to do compute and return the computed.

Our frontend can send events to our backend:

Our backend receives this message:

And do the necessary compute and return a new event:

Which our client can pick back up and do logic based off of:

Notice the updateDom function, which runs our conditional getDom function that in effect updates the document.

I remember learning about Elasticsearch for the first time. I still don’t know it.

But I do know how to make a algorithm. And I do know how to use OpenAI. I’ve made embeddings before, but never did I think to try and find an animal based on your own photo.

In our MagicMirror you can send your son or daughter when they start Hogwarts. Not sure which school animal they want to keep? No problem! We’ve got you covered. Evaluating you we can find the animal that will suit you best. But if you’re not happy, no worries! Our algorithm isn’t 100% deterministic, so let it do a second rating and see if you get the same or again or if you indeed should have been with another animal.

This is the part of our solution I am talking about right now. It is the part where you step into the mirror, some code is ran – and voilà – you have found your companion for the coming years.

What a way to search huh? Using your own image?

Where do we find the animals to pair you with?

Naturally, our solution can’t know of real(magical)-life animals. It can only know what we tell it exists. Therefore we have integrated with a database from https://harrypotter.fandom.com. It finds the animals, and we pair that data up with animal-illustrations coming from a wide range of websites (gifs). This way you can even see your own little one moving around the screen there with you.