In this episode of Debugging Dan, I share my latest milestone: integrating video recordings into my podcasts and live streaming for the first time. Inspired by a friend, I decided to jump in despite not having a perfect setup. I provide an update on my recent GitHub activities and discuss how the accountability page on my website is helping me stay on track. I also delve deep into my tech stack, explaining the tools and frameworks I use, like Preact, Express, Svelte, and more. Additionally, I discuss my deployment strategy using Docker, managing servers, and how I handle different applications and projects like Teletron. Whether you're a seasoned developer or just curious about tech stacks, this episode provides an in-depth look at my approach and experiences.
Welcome to episode 13 of the Debugging Dan podcast. Today, I'm again recording a video for YouTube, but also the audio goes to the different podcast platforms out there. And today, I made a tiny leap. I'm sharing my screen, but I'm also going to be recording some video. For me, that's a big step. I've never done that before for public streams. It's not that advanced yet. I don't have my green screen. I just use my laptop camera.
But this week, I saw a friend of mine, Jordy Bruin. He did an iOS app building live stream, and he just did it using his webcam, and he just went for it. So I decided I'm also going to go for it. I'm not going for a full screen video because I don't have my background set up, and I had some problems with OBS. Recording that video because I'm trying to do that, and just the entire image. But when I'm streaming my desktop, I created a small circle around my webcam, put it in the lower right corner, but somehow the live stream version or the full screen version did not move anymore. So I just figured I'm going to go for it. Let's do this.
And what I also wanted to add was a little item before I really start with the topic of the podcast. So for this one, that's my text tag, is to give a short update on how it's going. And how it's going can be pretty well visualized by this GitHub commit graph. So I changed my GitHub username. That's what you see in the bottom there. I just placed my face in front of it, but you can see it. So, before a few months ago, I didn't use GitHub as my primary Git platform. I only used it for my open source projects. But a few months ago, I started just using GitHub and no longer shelf hosting Git. And you see here that July was a pretty slow month. I was on holidays and the past two weeks I was back, but then I wasn't really able to sit down and focus and do some stuff.
But on the accountability part, that's helping. So I made a good progress in the last week. All those small to-do items, I made progress on those. So I'm pretty happy about that. If you want to see the updates to the accountability, I have a page for that. Just go to debuggingden.com slash accountability, and you'll see the post that update the progress on the accountability. And next week will be a podcast. Reflecting on the current accountability tasks and setting up new ones. So I'm pretty happy about that here in the Netherlands. School is about to begin tomorrow. That's Monday. That will also be the day that this podcast will go live. I'm recording this on Sunday morning. And then we will, at least here at the family, we'll go back to a more regular schedule with school. And that's nice that something external helps you in getting into a rhythm. I have my day job on Monday until Thursday.
So that's for me, that's a rhythm. But then we will again have a rhythm with the entire family. So that's nice. I updated the slide template and created more of a debuggingden thing. So I copied the green background. And yeah. So let's dive into the topic of today. So my tech stack, it's something that I created myself mostly. So I don't really use frameworks like Next.js or other things. I sometimes use Seltkit. I'll get into that. And so I use Preact for frontend. So I built single page applications. And I just realized I forgot to include Node.js in this picture. So Node.js is the core on which the entire stack is running.
But I'm using Preact, which is a low weight version of React. And I have a better vibe with that. So React is a very large ecosystem and it could be very heavy. And Preact just focuses, says we focus on being light, but the API is still React compatible to a certain level. And moving away from the React framework, but you can also use React libraries. Most of them work anyways. So I'm not running into problems there. And I have a good vibe with that. And the HTTP part, so I do that in Express, which is a web server. It's a package that's very well known and it's been around for a long time. I have years of experience with it. So I know how to use it. And it's pretty dated. So it doesn't really have proper async await support.
But I work around around that. And I found my own way of working with it that fits me. So I don't really have any needs or requirements to move away from that since it's working for me. And sometimes I switch out Preact with Svelte or even Express with SvelteKit. So for todo.debuggingdan.com, I used SvelteKit. So there was one HTTP route and I figured I can do it within the same project. And I use SvelteKit because earlier when working on some SDK stuff, I figured that Svelte might be more lightweight than using Preact. And Preact is, since it's not a very big project, it doesn't really get updates regularly. And for Svelte, I had worked with that for something else. And I really enjoyed it.
So some projects I now do in Svelte if it fits. But my boilerplate in which I create most of my applications, I just still have Preact and Express in a mono repo. And I'm built with that. For styling, I use booma.io, which is a CSS library that I like using. I know Tailwind exists, and a lot of people use Tailwind. But for me, that doesn't really fit yet. So I got to learn to work with booma and I don't really have any requirement to use something else. Maybe I'm getting old, maybe I'm not learning everything as fast as I used to, but I like booma. And it recently got updated to version 1.0, now has a dark mode. It has CSS variables, so it's also easier to customize. Because of that, you don't really have to do the entire sauce pipeline. So that's also, it was a very enjoyable experience.
I created my own open source database, which I called SuperSafe, which is a wrapper around SQLite or MySQL currently. And it's not really an ORM. It's a very simple way of querying data without having to think about table structure and things like that. SuperSafe takes that away. And it also, as a bonus, adds a automatic API endpoint for every table or collection that you add, if you want to. And I created a authentication library on top of that. And the downside is it's not super efficient. So what it does, it creates a table. It has an ID column and a contents column. And in the contents column, it dumps the entire object that you're trying to save as JSON. And based on the indexes that you've defined, it adds some additional columns and it updates those values as you write data.
And that works perfectly for small projects without a high load, which is what I have. I think a pretty big load needs to come around for it to really start to buckle under the weight. And for me, it's something I'm really proficient with. Since I built it myself, I can also customize it if I want, but it is usable by everybody. You can check it out on NPM. And the last thing in my stack is an open API specification. So what I do, I have a mono repo setup with a backend and a web component. And in the backend, I write an open API specification in JSON, and I'm able to generate TypeScript types and automatic validation with AGV from that. And because of that, I have validation and types from the same file, so I only need to change them once.
And also as an added bonus, I can reuse the backend types in the front end when I'm querying data, doing JSON requests, or HTTP request, XHR, AJAX, whatever you want to call it. And then I already have the typing there. And because it's a mono repo, I can refer to the name of the backend package, and then I do slash types, and then the name of the type. And it really allows me to use the typing. And it's not really a convenient or simple way of working, but it's something that I've grown into, I've set up, and I can really, I can build application with that pretty fast. So that's why I use this. So this is my software stack. And I have a self-hosted server, Contavo in Germany. And on that server, I run all my applications, and I run them with Docker.
So as a web server, I have Caddy, and Caddy takes care of the SSL, and it uses Let's Encrypt to generate the SSL templates. No, not the templates, the certificates. I have a MySQL server running there, and I have Docker. So on my local machine, I build a Docker image of the application, and I pull that on the server itself, and I set some environment variables, and then I configure it to run on a specific port, and then I start the application. And I point Caddy to that specific port, and basically that's when it runs. So I don't need to copy a lot of files or do a lot of management. I just set up the site. I set up a user for the site. I pull the Docker image, and I have a script that creates the Docker image. It just restarts when it fails.
And I add some monitoring with Uptime Robot with a free account on the domain name to see if it still runs. And that's how I run my different applications. So whether I'm using Preact, Express, or SvelteKit, I just make sure there's a Docker image that listens to a port, and all I need to do is point Caddy to that port. And that's how I use observerize, and what I do with Datastore, with Teletron, with all the other applications that I'm building. They all work and are hosted in the same strategy. And the server is like 12 euros a month. I only have one. I make sure that the MySQL server is backuped. I also wrote a script for that. All the files are copied remotely to a backup location. And for me, this works. It's running on Ubuntu and Linux. I just SSH into the machine, and I manage it.
And I've been doing software engineering for 20 years. And in the time, I picked up a lot of skills with Linux. And so I'm able to do this pretty proficiently. And I'm happy about that. For me, again, same as with the software state. It might not be everybody's choice, but for me, it works. And the odd one out here is the Teletron project. So Teletron is a platform in which you can create a dashboard, like for example, a magic mirror, or having a browser open a webpage where you show information at the clock, or the weather, or other things. And it works a little bit different there, because for every user, I create a different Docker container. So those are, if you're looking at YouTube, there are three containers here, for example, at the bottom. And they are called TT from Teletron www. And every user has their own container there.
So what I did here is in teletron.me, I built an integration with the Docker daemon on the host. So Teletron really needs to run on Docker. And when a new user registers, it spin-ups a new container, it creates a volume, it stores the data, and you can rebuild the Docker container from the management API. You can upgrade it to a different container version. And it all runs with Docker, and it's all pretty straightforward. And also here, I have a second instance of caddy running, because for everybody gets a unique subdomain at teletron.me. So in this case, I set up the original caddy here at the top of the image, if you're looking at the image. So caddy handles the incoming requests. So that's an external caddy, not within Docker, that does the SSO of loading.
And there I created the, with the Cloudflare plugin, star or asterisk dot teletron.me, I'll point to this caddy that is part of the teletron platform. And that caddy takes care of offloading the information to the person or container of that person. So teletron.me also has an integration via an API with that specific caddy instance to add or remove routes based on whether there are containers created or removed. And, well, that's my tech stack. And I'm going to sound like a broken record, but for me this works. I can understand that if you're less experienced, if you've always been doing things differently your entire life, you're like, wait, why is he doing it like this? Let me know if you have different suggestions or different feelings about what I'm doing. Let me know. For me it works and I'd like to get this out there and just share it with the people listening, with the people watching. And I'm curious to hear what you think.
So that was my tech stack. And it might evolve. So in the past months it evolved because I added Svelte there in the mix. But it could be that in a couple of years I'm doing things very differently. It could also be that I'm still doing it the same. Alright, I'll speak to you in the next one. Bye. If you're looking at the camera you can see my hand. Bye.