Home on Buro notes

The proper use of useEffect

Wed, 21 Oct 2026 16:01:56 +0200

The proper use of useEffect

useEffect is for side effects: stepping outside React to sync a component with an external system (network, timers, subscriptions, browser APIs). The typical case is async work: a promise whose result arrives after the render.

Ref: Synchronizing with Effects

The standard shape

It’s literally the first page of the official useEffect documentation.

useEffect(() => {
 // 1. setup: start the side effect
 const controller = new AbortController();

 fetch(`/api/users/${userId}`, { signal: controller.signal })
 .then((res) => {
 if (!res.ok) throw new Error(`HTTP ${res.status}`);
 return res.json();
 })
 .then(setUser)
 .catch((err) => {
 if (err.name !== 'AbortError') setError(err);
 });

 // 2. cleanup: stop or neutralize it
 return () => controller.abort();
}, [userId]); // 3. dependencies: re-run when they change

fetch rejects only on network errors: an HTTP error (4xx, 5xx) still resolves, so check res.ok and throw. All the examples below do it.

Docker containers management

Wed, 21 Oct 2026 00:29:59 +0200

Docker containers management

Why

Label everything, so you can:

filter metrics (Prometheus) and logs (Loki) by service, env, version
track the full chain: log/metric → container → image → git commit → code

Labels

Use Docker labels for all the metadata.
Build labels: use the OCI standard keys, already understood by registries, scanners, Renovate, GitHub, …
Run labels: define your own prefix to avoid collisions with other tools’ labels (e.g. acme_).

Label	Set at	Example
`org.opencontainers.image.source` (git repo)	build	`https://github.com/acme/orders`
`org.opencontainers.image.revision` (git commit)	build	`3f9c2a1`
`org.opencontainers.image.version` (image tag)	build	`1.4.0`
`org.opencontainers.image.created` (build date)	build	`2026-10-21T10:00:00Z`
`acme_release_date`	run	`2026-10-22T08:30:00Z`
`acme_env`	run	`production`
`acme_service`	run	`orders`
`acme_host`	run	`node-1`

Image labels are inherited by the containers, so every container carries both build and run labels.

SQL optimization

Wed, 21 Oct 2026 00:03:01 +0200

SQL optimization

Two goals:

reduce roundtrips between the caller (e.g. the BE) and the DB
optimize the queries

Measure first

Don’t guess, find what is actually slow: slow query log, pg_stat_statements, EXPLAIN ANALYZE (runs the query and shows real timings, unlike plain EXPLAIN).

Reading

Ensure indexes on the columns used in WHERE, JOIN and ORDER BY.
- Indexes are not free: they slow down writes and take space. Index what your queries use, not everything.
- Composite indexes: column order matters, put equality filters before range filters.
- Covering indexes: include the selected columns so the DB doesn’t need to read the table.
Check how you wrote the query: select only the columns you need, avoid functions on indexed columns.
Avoid N+1 (classic with ORMs): fetch related rows for the whole batch at once with eager loading or WHERE id IN (...).

CREATE INDEX idx_orders_customer_created ON orders (customer_id, created_at) INCLUDE (total);

EXPLAIN ANALYZE
SELECT id, total FROM orders
WHERE customer_id = 42 AND created_at > '2026-01-01';

Reading many rows

Use pagination: never load the whole table at once.
Load in batches (e.g. 500 rows per call), process them, then write the results in batch (see below).

Prefer keyset pagination over OFFSET, it stays fast on big tables:

Me

Sat, 21 Sep 2024 13:13:56 +0200

Me

Who am I?

what is this

Sat, 21 Sep 2024 13:13:56 +0200

What is this

This is not a blog. This is a collection of notes that I update when I want by adding, removing or changing stuff.
My ideas change, I change, I have new experences, so these notes will change accordly without warning and without the need for consistency.

These are my notes, they don’t claim to be right or wrong, just my notes.

Hope these notes could help someone.

who I am

Sat, 21 Sep 2024 13:13:56 +0200

Who I am

I’m Buro.