Daniel Markow

I am maintaining several Next.js applications at the moment. The number of dependencies and the vulnerabilities they bring are astonishing. For a while, I have been searching for something simpler—I don't really use Next.js's features for what I do anyway. Usually, the start page is static, and the remaining pages are client components. Or, everything is static.

I tried numerous frameworks and languages. For example, Elixir and the Phoenix framework, Ruby on Rails, and .NET 10. While they were all okay, none of them worked well for me. You know that feeling? Sometimes you find a tool that just clicks with your brain, and working with it becomes a much more intuitive endeavor. None of them were that.

Until I started building with PHP. Not Laravel or Symfony (which are fine), but classic PHP applications where the majority of the PHP code lives in the markup. To me, PHP is like the C of the web development world. It forces you to think about HTTP again. There are no heavy abstractions, nothing to just "make your life easier." That's good. I want to understand what is happening. Yet, it provides convenience and abstraction where it makes sense (like for generating tokens).

Building with PHP in that way forces you to use JavaScript as it was meant to be used, which makes using JavaScript fun again. It is really cool to observe it change the markup. It makes it possible to build applications that don't have heavy dependencies—not thousands of npm packages with thousands of vulnerabilities that you think you can get under control with CI. But that's just throwing complexity on top of complexity. Applications built that way can just be thrown onto a standard webspace—which is cheap and GDPR compliant—and the application will just work.

If you would like to get into it, I can recommend this book.

Since there seem to be few people left building web applications this way, there aren't many maintained libraries for authentication anymore. And not wanting dependencies anyway, I did the unthinkable and wrote my own authentication setup—and had a great time doing so.

Trost ist der sichere Glaube an die Unrealität des Lebens hinter der vielleicht die wirkliche Wahrheit liegt. Und um sie zu finden, das heißt leben und sterben. Immer wieder aufs neue leben und sterben bis wir da angelangt sind, wo es keine Erfahrung mehr gibt nur noch absolutes Wissen. Je intensiver man zu sich selber kommt umso eher kommt man ihm oder dem Absoluten näher. Das ist das Ziel und der Trost.

​I have about 8 years of AWS under my belt. I still really don't like CloudWatch. The fact that someone at AWS thought it is a good idea to design a custom query language for logs is astonishing to me. And I know you can use SQL now or let AI generate the query for you - still it's not great. The UI is horrible. You get stuck with it however especially if budget is tight and custom solutions are out of the question. Or maybe you are using another AWS service like ECS Fargate to host your application. CloudWatch is deeply embedded in the AWS ecosystem. 

I do like DuckDB, though. It is a very capable file-based analytics database which just wants to plow through gigabytes of JSON logs on your laptop. Thus, I decided to make use of some of my free time and write my own command line tool cw-to-duck that exports CloudWatch logs directly into a DuckDB file. All you need to do is install AWS CLI, log in to your account with a role that has sufficient permissions to access your logs and run cw-to-duck. It also provides parsers for certain AWS services such that next to the logs_raw table the resulting DuckDB file will contain a handy logs_parsed table ready for analysis.