u/Physical_Ruin_8024

Olá pessoal,

Stack: Node.js / Nuxt (Nitro) no backend, TypeScript, PostgreSQL. O schema do banco já está definido, então não preciso de feedback sobre isso — preciso de ajuda com a lógica de implementação no backend em si.

Contexto: app de finanças pessoais. Uma tabela `recurrences` guarda as regras (valor, frequência, dia de vencimento, total de parcelas quando aplicável, data de início). As transações reais ficam numa tabela `transactions` separada, com uma FK `recurrence_id` nula. As ocorrências futuras NÃO são pré-geradas no banco — elas devem ser calculadas sob demanda como projeções "virtuais" (ex: "me mostra todas as transações, reais + projetadas, de julho de 2026"), e só viram uma linha real quando a data chega ou o usuário confirma.

O que eu preciso de ajuda, especificamente:

1. Como vocês estruturariam a função/serviço que recebe uma regra de recorrência + um intervalo de datas e retorna a lista de ocorrências projetadas? Alguma abordagem concreta ou pseudocódigo.

2. Vocês usariam uma lib (date-fns, rrule.js, luxon) pra gerar as datas das ocorrências, ou fariam a matemática de datas na mão? Se usar lib, qual e por quê.

3. Como vocês mesclam transações reais e projeções virtuais numa única lista pro frontend sem confundir as duas (flags, formato de resposta separado, IDs)?

4. Quando uma projeção precisa virar uma linha real (a data chega, ou o usuário confirma), qual a forma mais limpa de fazer isso sem duplicar lógica entre o "calculador de projeção" e o "materializador"?

Não preciso de conselhos sobre banco de dados/schema — só a abordagem de implementação no backend. Pseudocódigo, padrões ou recomendações de lib são bem-vindos. Valeu!

Hi everyone,

Stack: Node.js / Nuxt (Nitro) backend, TypeScript, PostgreSQL. DB schema is already settled, so I'm not looking for feedback on that — I need help with the backend implementation logic itself.

Context: personal finance app. A `recurrences` table stores rules (amount, frequency, due day, total installments if applicable, start date). Real transactions live in a separate `transactions` table with a nullable `recurrence_id` FK. Future occurrences are NOT pre-generated in the DB — they should be calculated on demand as "virtual" projections (e.g. "show me all transactions, real + projected, for July 2026"), and only turned into a real row when the date arrives or the user confirms it.

What I need help with, specifically:

1. How would you structure the function/service that takes a recurrence rule + a date range and returns the list of projected occurrences? Any concrete approach or pseudocode.

2. Would you reach for a library (date-fns, rrule.js, luxon) to generate the occurrence dates, or roll your own date math? If a library, which one and why.

3. How do you merge real transactions and virtual projections into a single list for the frontend without confusing the two (flags, separate response shape, IDs)?

4. Once a projection needs to become a real row (date arrives, or user confirms), what's a clean way to do that without duplicating logic between the "projection calculator" and the "materializer"?

Not looking for database/schema advice — just the backend implementation approach. Any pseudocode, patterns, or library recommendations are welcome. Tha

Hi everyone,

Stack: Node.js / Nuxt (Nitro) backend, TypeScript, PostgreSQL. DB schema is already settled, so I'm not looking for feedback on that — I need help with the backend implementation logic itself.

Context: personal finance app. A `recurrences` table stores rules (amount, frequency, due day, total installments if applicable, start date). Real transactions live in a separate `transactions` table with a nullable `recurrence_id` FK. Future occurrences are NOT pre-generated in the DB — they should be calculated on demand as "virtual" projections (e.g. "show me all transactions, real + projected, for July 2026"), and only turned into a real row when the date arrives or the user confirms it.

What I need help with, specifically:

1. How would you structure the function/service that takes a recurrence rule + a date range and returns the list of projected occurrences? Any concrete approach or pseudocode.

2. Would you reach for a library (date-fns, rrule.js, luxon) to generate the occurrence dates, or roll your own date math? If a library, which one and why.

3. How do you merge real transactions and virtual projections into a single list for the frontend without confusing the two (flags, separate response shape, IDs)?

4. Once a projection needs to become a real row (date arrives, or user confirms), what's a clean way to do that without duplicating logic between the "projection calculator" and the "materializer"?

Not looking for database/schema advice — just the backend implementation approach. Any pseudocode, patterns, or library recommendations are welcome. Thanks!

Hi everyone!

I'm implementing a global HTTP error handler in my Nuxt 4 application and I'd like to properly handle HTTP 429 (Too Many Requests).

I understand what the status code means, but I'm not sure about the best way to implement it in practice.

Do you apply rate limiting only on authentication endpoints (login, register, forgot password), or on the entire API?

Do you return a Retry-After header?

How do you handle this on the frontend? Do you simply show a toast, disable the action temporarily, or implement an automatic retry?

I'd love to hear how you approach this in production applications.

Guys, here's the deal...

I've had a POCO F4 for about 4 years—it's a perfect phone in every way—but this morning it just started restarting on its own. I dug a little deeper and noticed that whenever I touch the fingerprint sensor, it starts acting totally haywire lol.

Like:

- Just running my finger over the sensor (without pressing) triggers Google Assistant.

- If I hold it for a bit, it gets stuck on the restart/power-off screen—even though that damn menu is supposed to activate only when you actually press the button + volume up. Like, what the hell?????? Is the reader faulty? If so, has anyone had this fixed? Could you share the cost and let me know if it actually works just as well afterwards?

I don't have the cash to replace the device right now, seeing as this phone is excellent for daily use.

Thanks for the help...

Good afternoon, everyone. I'm new to the Linux world and I need some help from you guys.

Here's the deal: I need to set up a home server to run my Docker containers, databases, and API, but I wanted to know if this PC I picked up will do the job.

My main concern is the RAM, as it only has 4GB of DDR3. Would that work for an Ubuntu server without a GUI?

My config:

Memory ram: 4gb

Motherboard: lga 775 biostar

Cpu: Pentium E5700

Will it work out?

I'm building a personal finance app from scratch — Node backend with PostgreSQL, Nuxt on the frontend. The core features are already working: accounts, categories, transactions and transfers. Now I need to implement what I consider the most important feature for my own use as a user: recurring and installment transactions.

Think of a monthly internet bill that repeats every month, or a purchase you split into 10 installments. That's exactly what I'm trying to model.

After researching quite a bit, I came up with this approach:

A separate recurrences table that stores the recurrence rule — type (fixed or installment), frequency, total installments when applicable, and whether it's still active. The existing transactions table would gain a single recurrence_id FK, null for one-time entries.

Records would be generated upfront — 12 months ahead for recurring, N records for installments, all linked by recurrence_id.

My main question is: does this schema make sense, or has anyone been down this road and found a better approach? Any criticism of the architecture is welcome.





I'm building a personal finance app from scratch — Node backend with PostgreSQL, Nuxt on the frontend. The core features are already working: accounts, categories, transactions and transfers. Now I need to implement what I consider the most important feature for my own use as a user: recurring and installment transactions.

Think of a monthly internet bill that repeats every month, or a purchase you split into 10 installments. That's exactly what I'm trying to model.

After researching quite a bit, I came up with this approach:

A separate recurrences table that stores the recurrence rule — type (fixed or installment), frequency, total installments when applicable, and whether it's still active. The existing transactions table would gain a single recurrence_id FK, null for one-time entries.

Records would be generated upfront — 12 months ahead for recurring, N records for installments, all linked by recurrence_id.

My main question is: does this schema make sense, or has anyone been down this road and found a better approach? Any criticism of the architecture is welcome.

I'm building a personal finance app and need to design a schema for recurring transactions (monthly income/expenses). Should I generate all future records upfront or use a parent record + cron job to generate lazily? What are the tradeoffs?