DEV Community: Tito Candra

I Almost Used Nuxt Content for My Blog, but I Chose a Database Instead

Tito Candra — Sun, 11 Oct 2026 13:49:28 +0000

When I started building my personal blog with Nuxt, one of the first decisions I had to make was how to store my content.

At first, Nuxt Content seemed like a good option. Writing articles in Markdown sounded simple, and I wouldn't need to worry too much about database setup.

But there was one thing I needed: a custom admin panel where I could manage my articles, categories, and tags.

That made me reconsider my choice.

Why I Didn't Choose Nuxt Content

Nuxt Content is a great option for projects where content lives in files, such as Markdown documents stored in a Git repository.

However, my blog needed a different workflow.

I wanted to create and edit articles directly from my admin panel. Since I also planned to deploy the application to a serverless environment, writing Markdown files at runtime wasn't a reliable approach for my setup.

I didn't want to build my content management system around a storage method that didn't fit how I planned to use the application.

So, I decided to use a database instead.

My Choice: PostgreSQL and Drizzle ORM

I chose PostgreSQL for storing my blog data and Drizzle ORM for working with the database.

My initial schema included tables for:

Articles — titles, content, slugs, publication status, and SEO information.
Categories — separating tech articles from personal posts.
Tags — organizing articles by topic.
Users — storing user information for authentication and administration.
Comments — leaving room for future discussions.

I also used a many-to-many relationship between articles and tags, since one article can have multiple tags and one tag can belong to multiple articles.

This approach gave me more control over how my content was organized and managed.

Of course, it also meant taking responsibility for database schemas, relationships, migrations, and queries.

It Was a Trade-Off, Not a Perfect Solution

Choosing a database didn't automatically make everything easier.

I had more things to configure and maintain than I would have with a file-based content solution. I also needed to think carefully about my data model before building more features.

But for my use case, that extra work made sense.

I wanted a blog that could grow beyond publishing Markdown files. I wanted an admin panel, structured content, authentication, and room for features I might add later.

Using a database gave me the flexibility I needed for that direction.

That doesn't mean Nuxt Content is the wrong choice. If your website mainly contains static articles and you enjoy managing content through Git, it may be exactly what you need.

For my project, though, a database was a better fit.

What I Learned

This decision taught me something simple: the best technology isn't always the one with the easiest setup. It's the one that fits the project you're actually building.

Before choosing a tool, I now try to think beyond the first feature I want to implement.

How will I manage the content? Where will the application run? What might I need to add later?

These questions helped me make a decision that felt right for my project, rather than choosing a tool just because it was convenient at the beginning.

I'm still building and improving this blog, so I expect to revisit some of these decisions as the project grows.

For now, PostgreSQL and Drizzle ORM are working well for the direction I want to take.

What about you? When building a blog with Nuxt, would you choose Nuxt Content or a database? I'd love to hear your reasoning.

This article is part of my Database Series, where I share what I learn about data modeling, database decisions, and building real applications.

I Integrated Better Auth into Nuxt, and the Session Bugs Taught Me More Than I Expected

Tito Candra — Sat, 10 Oct 2026 09:08:20 +0000

When I started building my blog with Nuxt, I wanted to keep things simple. I needed an authentication system for the admin panel, so I could manage articles, categories, and other content without exposing those features to everyone.

After looking at my options, I decided to use Better Auth.

At first, the integration seemed straightforward. I could configure the authentication client, create a login page, and connect it to my admin panel.

But as I started working with authentication across different pages and layouts, I ran into problems I didn't expect.

The login request could succeed, but parts of the application still behaved as if I wasn't logged in.

That was when I realized that getting authentication to work and keeping authentication state consistent across a Nuxt application were two different challenges.

The Login Worked, but Something Still Felt Wrong

One of the most confusing problems I encountered was session synchronization.

Imagine logging into your admin panel successfully. You expect the application to recognize that you're authenticated everywhere, right?

In my case, that wasn't always what happened.

The login process could succeed, but another layout or component could still show the old authentication state. In some cases, the UI behaved as if the user hadn't logged in yet.

Naturally, my first thought was that something was wrong with Better Auth itself.

I started looking at the authentication flow, checking how the session was retrieved, and investigating why different parts of the application didn't seem to agree about the current user.

What made this problem tricky was that not everything was actually broken.

Sometimes, the session existed, but the UI was still using outdated data.

That distinction changed how I approached the problem.

I Started Looking at Nuxt Instead of Just the Authentication Library

Before this experience, I tended to think of authentication as something relatively isolated: send credentials, receive a response, and update the UI.

Working with Better Auth in Nuxt made me pay more attention to how the framework manages data and application state.

Nuxt has server-side rendering (SSR), which means parts of the application can run on the server before the resulting HTML reaches the browser.

It also has its own data-fetching utilities, such as useFetch, which can reuse cached data.

These features are useful, but they introduce details that I needed to understand.

For example, when session data is fetched through Nuxt's data-fetching system, that data doesn't automatically become synchronized across every separate place where I request it.

If multiple layouts and pages manage their session data independently, they can end up working with different states.

That helped explain why one part of my application could recognize a successful login while another part still showed the previous state.

The problem wasn't necessarily the login request. It was how the application handled the session after that request.

A Composable Error Taught Me Something Important

I also encountered another issue while integrating Better Auth.

I initially tried to initialize the authentication client in a regular utility file and access Nuxt's runtime configuration from there.

Something like this looked reasonable to me:

const config = useRuntimeConfig()

However, Nuxt composables such as useRuntimeConfig() and useNuxtApp() need the appropriate Nuxt context.

Calling them at the top level of a regular module doesn't guarantee that this context will be available.

The result was an error telling me that a composable requiring access to the Nuxt instance had been called outside that context.

At first, this felt like one of those framework-specific issues that was difficult to understand without spending time reading and experimenting.

Eventually, I learned to think differently about where application code should be initialized.

A regular utility function, a Nuxt composable, and a Nuxt plugin might all contain TypeScript code, but they don't necessarily run in the same context.

Moving the authentication client initialization into a Nuxt plugin gave it the appropriate place to access runtime configuration and expose the client to the rest of the application.

It was a small change in code organization, but it helped me understand Nuxt's conventions much better.

I also became more careful about which code should run on the server and which code should run in the browser.

The Biggest Lesson: One Source of Truth Matters

The session synchronization issue eventually led me to reconsider how I managed authentication state.

Instead of treating every layout and page as an independent place to retrieve the session, I started thinking about authentication as shared application state.

Nuxt provides useState() for sharing reactive state in an SSR-friendly way.

For my case, the idea was simple: keep the session in one shared state, let the relevant components read from it, and update that state when authentication changes.

After a successful sign-in or sign-out, the session needs to be refreshed so the rest of the application can reflect the new state.

This approach made more sense to me than allowing each component to maintain its own potentially outdated version of the session.

There was still an important detail to consider: shared state doesn't automatically guarantee that the session is initialized correctly. The initial session needs to be resolved at the appropriate time, especially when server-side rendering is involved.

But the overall design became clearer once I stopped treating session data as something every component should independently figure out.

It wasn't just about making the login page work anymore. It was about deciding which part of the application should own the authentication state and how other parts should consume it.

SSR Added Another Layer to the Problem

Another thing I learned was that server-side rendering changes how I think about requests and authentication.

When a user visits a page, Nuxt may render that page on the server. That server-side code can make its own requests, but it doesn't automatically behave exactly like code running in the user's browser.

For example, browser cookies are important when checking an existing session. When handling an internal server-side request, I needed to pay attention to whether the relevant cookie headers were being forwarded.

I also had to think about the authentication client's base URL. A relative URL that works naturally in the browser might not be sufficient in a server-side context.

These details were easy to overlook when I was focused only on the sign-in form.

They also helped me understand why authentication problems in SSR applications can be confusing: the browser, the server, the authentication library, and Nuxt's data-fetching system all play different roles.

Once I started separating those responsibilities, debugging became more systematic.

Instead of immediately changing the authentication configuration, I could ask more specific questions.

Was the login request successful? Was the session cookie present? Was the server receiving the expected headers? Was the session actually stale, or was the UI simply showing outdated data?

Those questions gave me a much better starting point.

What I Took Away From This Experience

I didn't expect authentication to teach me so much about how Nuxt works internally.

Looking back, the most useful lessons weren't about memorizing a particular Better Auth configuration.

They were about understanding the environment in which my code runs and how application state moves through the system.

Here are a few things I'm taking forward into my next projects:

Successful requests don't always mean the UI is up to date. I need to distinguish between a backend problem and a frontend state synchronization problem.
Nuxt composables need the right context. Where code is initialized matters, especially when working with runtime configuration and third-party libraries.
SSR introduces responsibilities that browser-only applications may not have. Cookies, request headers, and server-side URLs deserve more attention.
Shared state needs a clear owner. When several components depend on the same authentication session, they should not become disconnected sources of truth.
Debugging gets easier when I investigate one layer at a time. Checking the request, cookie, server response, and UI state separately is more useful than assuming everything is an authentication failure.

I'm still learning Nuxt, and I know there are more details to explore. But this experience gave me a better mental model of how authentication and SSR interact.

More importantly, it reminded me that integrating a library into a framework is about more than getting the initial setup right. I also need to understand how that library fits into the framework's existing lifecycle, state management, and rendering behavior.

Final Thoughts

Building this blog has been a useful way to learn Nuxt beyond the basics.

I could have studied plugins, useState(), SSR, and data fetching separately. But encountering a real problem made the connections between them much easier to understand.

The authentication bugs were frustrating at first, but they pushed me to look beyond the login form and think about how the application behaved as a whole.

That's something I want to keep doing as I learn new technologies: build something real, pay attention when things don't work as expected, and share what I learn along the way.

I'm curious how other Nuxt developers handle authentication state across layouts and pages, especially in applications that rely heavily on SSR.

Do you prefer a shared session composable, or do you use a different approach?

I'd love to hear what has worked for you.

This article is part of my journey of learning Nuxt by building a real project and sharing the lessons I discover along the way.

Rahasia Laravel yang Bikin Kode Kamu Makin Ciamik – Pahami Trait Sekali, Langsung Ahli!

Tito Candra — Thu, 30 Oct 2025 06:14:04 +0000

Apa itu Trait di Laravel?
Trait bukan hal mistis, tapi sekadar cara cerdas di PHP untuk menghindari penulisan kode berulang. Trait adalah sekumpulan method yang bisa dibagikan ke beberapa kelas, bagaikan ‘paket fungsi’ yang bisa dipakai ulang kapan saja tanpa perlu turunan kelas yang ribet.

Kenapa Trait Berguna?

Kode reuse: trait memungkinkan kamu menulis satu set method sekali, dan gunakan lagi di banyak kelas - hematin waktu dan tenaga.
Menghindari keterbatasan pewarisan tunggal (single inheritance) PHP - tidak perlu extends berkali-kali.
Ibarat “ambil fungsi pakai trait” - langsung jadi tanpa ulang bikin ulang.

Cara Membuat dan Menggunakan Trait di Laravel (ramah untuk pemula)

Buat folder trait

Biasanya ditempatkan di: app/Traits atau app/Models/Traits.

Buat file trait

Contoh membuat trait ExampleTrait:

<?php
namespace App\Traits;

trait ExampleTrait {
    public function exampleMethod() {
        return 'Ini contoh method dari Trait!';
    }
}

Pakai trait di kelas lain

Misalnya di controller atau model:

<?php
namespace App\Http\Controllers;
use App\Traits\ExampleTrait;

class HomeController extends Controller {
    use ExampleTrait;

    public function index() {
        return $this->exampleMethod();
    }
}

Kalau kamu akses method tersebut, hasilnya: “Ini contoh method dari Trait!”

Tips Tambahan

Resolusi Konflik Nama Method

use TraitA, TraitB {
    TraitA::methodName insteadof TraitB;
}

Buat Trait dengan Fungsi Reusable

Contoh trait ResponseTrait untuk API:

trait ResponseTrait {
    public function successResponse($data = [], $message = 'success', $code = 200) {
        return response()->json(compact('data', 'message'), $code);
    }

    public function errorResponse($message, $code = 400) {
        return response()->json(compact('message'), $code);
    }
}

Trait di Eloquent Model

Trait bisa berisi relasi atau method yang sering dipakai di model. Contohnya:

HasRoles dari Spatie: trait yang memungkinkan model punya relasi roles().
HasTags: terasa seperti fitur tagging—attach, detach tag cukup panggil method di model yang sudah pakai trait.

Rangkuman Sederhana
Membuat Trait: Buat file di app/Traits, tulis trait NamaTrait { ... }
Gunakan: use NamaTrait; dalam kelas yang butuh method-nya
Pakai Lagi: Bisa di banyak kelas untuk fungsi sama
Kalau conflict: Atur dengan insteadof atau as agar tidak tabrakan method
Contoh Praktis: Response format, UUID auto_pk, relasi model, dll

Sumber Referensi:

Definisi dan konsep trait PHP: manual resmi PHP php.link
Penggunaan dasar trait di Laravel: Medium & DEV guides Medium+1DEV Community
Contoh trait di Eloquent (HasRoles & HasTags): Laravel Daily Laravel Daily
Trait otomatis UUID untuk model: David Carr Blog dcblog.dev

Rangkuman Sederhana

Gunakan di controller base agar semua controller turunannya punya format respons yang seragam.

Memperbaiki Error 0x0000011b Windows 10 Sharing Printer

Tito Candra — Sun, 06 Apr 2025 03:19:01 +0000

Hallo teman,
Disini saya akan share pengalaman pribadi saat troubleshooting printer yang mempunyai error 0x0000011b, error ini sering muncul saat ingin melakukan sharing printer pada Windows 10. Error tersebut disebabkan oleh update terbaru Windows 10 2021-09 Cumulative Update for Windows 10 Version 21H1 for x64-based Systems (KB5005565).

Terkadang update windows bisa menciptakan manfaat dan kerugian, dalam kasus yang saya alami adalah printer telah terinstall pada komputer Windows 10 kemudian printer tersebut di share ke semua pengguna lain. error ini muncul jika ada komputer client menggunakan Windows 7 yang mencoba melakukan koneksi dengan printer tadi, jika komputer client sama-sama menggunakan windows 10 mungkin error ini tidak akan muncul.

lalu bagaimana memperbaikinya, mudah sekali coba ikuti langkah-langkah dibawah ini:

Buka regedit pada komputer server printer atau pada Windows 10
Kemudian arahkan direktori ke HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
Kemudian buat DWORD-32 baru dengan nama RpcAuthnLevelPrivacyEnabled
Set Value Data menjadi 0
Kemudian Restart PC / Server

Setelah Komputer / Server menyala kembali, coba untuk menyambungkan ulang pada printer menggunakan komputer client yang menggunakan Windows 7.

Semoga membantu.
Terima Kasih

Referensi:

https://bptsi.unisayogya.ac.id/fix-error-kode-error-0x0000011b-windows-10-sharing-printer/