DEV Community: Dedaldino Daniel

Nexus API: Why I'm Going Back to Native Node.js in the Age of AI

Dedaldino Daniel — Tue, 15 Sep 2026 13:03:02 +0000

AI has completely changed the way we build software.

Today, I can describe a feature in natural language and, within seconds, have generated code, tests, an API structure, and even architectural suggestions.

That's incredible.

But there is a question I've been asking myself more and more:

Are we becoming better programmers, or simply better at writing prompts?

That question is one of the reasons I started building Nexus API.

🔗 Source code: GitHub Repository — Nexus API

Nexus API is a personal laboratory where I'm exploring Node.js using mostly its native capabilities, without relying on frameworks to hide what happens underneath.

The goal isn't to build the most sophisticated API in the world.

The goal is to understand what is actually happening underneath the abstractions.

The problem isn't using AI

I'm not against AI tools.

Quite the opposite.

I use AI to explore ideas, compare solutions, find problems, automate repetitive tasks, and even learn new concepts.

The problem starts when developers stop understanding what AI is producing.

There is a huge difference between:

"AI generated this code and it works."

and:

"I understand why this code works, what its limitations are, and how to change it when the requirements change."

The first approach can produce fast results.

The second produces better engineers.

Nexus API

Nexus API is a personal project I'm using as a laboratory to explore Node.js more deeply, relying heavily on Node's native capabilities instead of frameworks that abstract away much of the runtime.

The goal isn't to build the most sophisticated API in the world.

The goal is to understand what is actually happening underneath.

I'm working primarily with native Node.js capabilities such as:

→ http
→ url
→ fs
→ path
→ crypto
→ events
→ stream
→ buffer
→ node:test
→ assert
→ process
→ Node's built-in modules
→ HTTP request/response
→ header parsing
→ routing
→ error handling
→ manual dependency injection
→ unit testing
→ integration testing
→ end-to-end testing

Instead of simply writing:

app.get('/users', controller.getAll)

I want to understand what exists behind that abstraction.

How does an HTTP request reach the process?

How does Node represent request and response?

How are headers processed?

How is the request body received?

How do streams work?

How can we build routing without a framework?

How should controllers, services, and repositories be separated?

How can dependency injection be implemented without a container?

How should each layer be tested?

These questions are more valuable to me than simply getting an API running as quickly as possible.

What I'm trying to learn

The project forces me to deal with problems that are usually hidden behind frameworks.

For example, I'm building an architecture similar to:

src/
├── modules/
│ └── users/
│ ├── users.routes.js
│ ├── users.controller.js
│ ├── users.service.js
│ ├── users.repository.js
│ └── users.test.js
│
├── core/
│ ├── http/
│ ├── errors/
│ └── middleware.js
│
├── app.js
└── server.js

It looks simple.

And that's exactly the point.

When you remove abstractions, you start noticing how many decisions a framework normally makes for you.

HTTP stops being "magic"

When using Express, Fastify, or NestJS, we can create a route in a few lines.

That's great for productivity.

But if we never learn what exists underneath those abstractions, we may eventually depend on them to solve problems that should be part of our foundation.

In Nexus API, I'm exploring things like:

const server = http.createServer((req, res) => {
// routing
// headers
// body
// authentication
// controller
// response
});

Not because I want to replace Fastify or NestJS.

I want to understand what these tools are doing for me.

Once you understand the abstraction, using it becomes a conscious decision.

Where does AI fit into this?

This is the interesting part.

I'm using AI while building the project.

But I'm trying to reverse the relationship.

Instead of:

Prompt → code → copy → run

I want:

Concept → attempt → failure → investigation → implementation → AI as support

Sometimes I implement something manually first.

Then I ask AI to critique it.

Other times, I ask for different approaches to a problem.

Then I compare the solutions.

I also use AI to generate test cases, find edge cases, and challenge architectural decisions.

AI becomes a kind of pair programmer.

Not the programmer.

The danger of learning only through prompts

There is a trend that concerns me.

As AI tools become more powerful, some people are starting to question whether learning programming deeply is still worth it.

The reasoning is:

"If AI writes the code, why should I learn how to program?"

I think the question is backwards.

The more powerful AI becomes, the more important programming knowledge becomes.

Someone still needs to evaluate the result.

Someone needs to recognize when the solution is wrong.

Someone needs to understand performance.

Someone needs to identify a race condition.

Someone needs to recognize a security problem.

Someone needs to choose between a simple architecture and unnecessary complexity.

Someone needs to understand trade-offs.

And most importantly:

someone needs to know what to ask for.

A good prompt doesn't replace knowledge.

Knowledge makes the prompt better.

Fundamentals still matter

Frameworks change.

Libraries change.

AI tools change.

Models change.

But some fundamentals remain.

HTTP.

TCP/IP.

JavaScript.

Runtime behavior.

Memory.

Processes.

Streams.

Concurrency.

The event loop.

Data structures.

Algorithms.

Databases.

Distributed systems.

Testing.

Architecture.

These concepts remain useful regardless of which tools we use.

If a completely different framework appears tomorrow, the knowledge stays with us.

Programming better, not just faster

AI has made code generation extremely cheap.

That changes the value of software development.

Writing 500 lines of code is no longer necessarily an achievement.

The challenge becomes knowing:

which 500 lines should exist?

Or even better:

do we need those 500 lines at all?

This is where fundamentals, experience, and reasoning become even more valuable.

A strong developer isn't necessarily the person who writes the most code.

It's the person who can solve complex problems with the minimum necessary complexity.

The goal of Nexus API

Ultimately, Nexus API is less about building an API and more about rebuilding my understanding of Node.js.

I want to reach the point where, whenever I use a framework, I can think:

"I know what this abstraction is doing underneath."

That completely changes your relationship with the tool.

You stop being dependent on it.

You start choosing to use it.

And that difference matters.

AI + fundamentals

I don't think we have to choose between learning programming and using AI.

I believe in the opposite:

Learn the fundamentals deeply and use AI to increase your capabilities.

Use AI.

Generate code.

Automate tasks.

Experiment.

But also open the code.

Read it.

Break it.

Test it.

Reimplement it.

Question it.

And sometimes, turn off the abstraction and build something from scratch.

That's exactly what I'm doing with Nexus API.

Not to prove that frameworks are bad.

But to understand what exists underneath them.

And, most importantly, to remain a programmer — not just someone who knows how to ask AI for code.

The project

I'm keeping Nexus API on GitHub as an open learning laboratory for Node.js.

The project will continue evolving as I explore:

Node.js internals
HTTP
streams
event loop
architecture
dependency injection
testing
performance
security
API design
design patterns
software engineering practices

If you're also trying to deepen your Node.js fundamentals, feel free to follow the project, explore the code, or contribute.

Code first. Abstractions second. AI as an accelerator — not a replacement for knowledge.

The Problem With “AI Specialists” Created by Trends

Dedaldino Daniel — Mon, 11 May 2026 15:02:15 +0000

The AI industry is growing fast.
Maybe too fast.

And with this growth, something has started bothering me:

Today, many developers complete a short course, use a few AI models, and suddenly start calling themselves “AI Specialists”.

No real-world projects.
No technical depth.
No understanding of architecture, embeddings, RAG pipelines, evaluation systems, agents, context handling, AI security, or production scalability.

Just hype.
Just trends.
Just excitement.

Using AI ≠ Understanding AI

Using ChatGPT or Claude does not automatically make someone an AI Engineer.

Just like using VS Code does not make someone a Software Engineer.

There is a huge difference between:

consuming AI tools
and engineering AI solutions

Real AI work involves:

system design
model limitations
prompt engineering
context management
vector databases
performance optimization
security
cost efficiency
product thinking
UX integration
production reliability

Most people only see the interface.

They never study what happens underneath.

The Industry Needs More Builders

The tech industry does not need more fake gurus posting recycled AI content every day.

It needs:

engineers
researchers
builders
problem solvers

People capable of creating products that actually improve businesses and users’ lives.

Because in the end, the difference always appears:

in the product quality
in scalability
in technical decisions
in performance
in reliability
and in real impact
Trends Fade. Competence Stays.

AI is not magic.

And the people who will truly stand out in the next years are not those chasing trends for attention.

They are the ones building real things consistently.

What’s your opinion about the current “AI expert” wave in tech?

Understanding Pipes in NestJS: What They Are, Benefits, and How to Use Them

Dedaldino Daniel — Wed, 22 Oct 2025 15:25:11 +0000

🧩What Are Pipes in NestJS?

In NestJS, Pipes are classes that are used to transform or validate incoming data before it reaches your controller’s method.

They work like internal middleware, processing and sanitizing data automatically.

In short:

Validation: Ensures that incoming data meets certain rules.
Transformation: Converts data types (e.g., from string to number).

⚙️When Are Pipes Executed?

Pipes are executed after NestJS resolves the route parameters but before the controller method is invoked.
This allows you to intercept, validate, or modify the request data in a clean and structured way.

💡Benefits of Using Pipes

✅ Centralized validation — keeps validation logic out of your controllers.
✅ Reusable components — use the same pipe in multiple routes.
✅ Cleaner and more readable code.
✅ Perfect integration with class-validator and class-transformer.
✅ Improved data integrity and consistency across your entire app.

🔧 Example: Using the ValidationPipe

Let’s create a simple DTO and apply the built-in ValidationPipe to a controller method.

🚀 Conclusion

Pipes in NestJS are a clean and powerful way to handle data transformation and validation.
They make your backend code more maintainable, reusable, and consistent.

If you want to write scalable, enterprise-grade applications — mastering pipes is a must!

Additional Resources

Official Nestjs Documentation: Pipe

Use this template to create a backend with nodejs + express + prisma + typescript + tdd + S.O.L.I.D Principles

Dedaldino Daniel — Mon, 22 Jan 2024 12:38:03 +0000

Nowadays we don't want to waste so much time configuring so many things when starting an application, for nodejs backend devs this has been an annoying case for me, so this template is already configured and with a fantastic folder structure and ready to use.

Take a look at the technologies used in the project or template:

Nodejs
Express
Prisma
Typescript
Jest + Supertest
S.O.L.I.D Principles

See what the project folder structure looks like:

Here is the template link for you to use as you wish, you can contribute your ideas, as the project is open-source: Template

Porque usar o "TDD" no seu dia-dia ?

Dedaldino Daniel — Fri, 28 Apr 2023 14:03:29 +0000

Desenvolvimento Orientado a Testes é um processo que modifica o paradigma do desenvolvimento de softwares tradicional. Em vez de desenvolver, primeiramente, seu código e ajustá-lo de maneira retroativa para validá-lo, o TDD determina que os testes sejam escritos antes e que as adaptações sejam, só depois, aplicadas ao código até que o projeto atenda aos requisitos do teste já definido.

A maioria dos programadores não escreve códigos utilizando o Desenvolvimento Orientado a Testes, mas deveria. O desenvolvimento orientado a testes cria um código melhor e menos propenso a falhas. Por isso, esperamos que tenha entendido a filosofia do TDD com este texto e a incorpore nas suas práticas de desenvolvimento.

Estou muito animado para compartilhar com vocês meu mais recente projeto de código aberto no Github onde aplico o TDD e S.O.L.I.D! O projeto é uma api rest simples, mas poderosa, que pode ajudá-lo a embarcar no desenvolvimento orientado a testes e aumentar sua produtividade. O melhor de tudo é que você pode acessar e contribuir para o projeto gratuitamente no Github!

Link do projecto: Meu Projecto

O Github é uma plataforma incrível para desenvolvedores compartilharem seus projetos e colaborarem uns com os outros. É uma comunidade de desenvolvedores dedicados que estão sempre procurando maneiras de melhorar seus projetos e ajudar os outros.

Não perca a chance de conferir meu projeto no Github! Visite o link acima e experimente por si mesmo. Compartilhe suas ideias e feedback nos comentários abaixo.

Clone google homepage with next.js

Dedaldino Daniel — Thu, 20 Jan 2022 21:10:52 +0000

Simple project where I cloned google using the next.js framework, besides being able to see it in my github repository, you can see the deployment of this application on the Vercel platform.
Following the links listed below:

Github - https://github.com/dedaldinodov4/google-clone-nextjs
Application Deployment - https://google-clone-nextjs-delta.vercel.app/

Screenshot

Build RestFull API With Nodejs, Express and MongoDb!!

Dedaldino Daniel — Thu, 19 Aug 2021 11:03:06 +0000

This is a basic API skeleton written in JavaScript ES6+. Very useful to building a RESTful web APIs for your front-end platforms like Android, iOS or JavaScript frameworks (Angular, Reactjs, vuejs, etc).

This project will run on NodeJs using MongoDB as database. I had tried to maintain the code structure easy as any beginner can also adopt the flow and start building an API. Project is open for suggestions, Bug reports and pull requests.

Features

Basic Authentication (Register/Login /loginRequired with hashed password)
- JWT Tokens, make requests with a token after login with Authorization header with value Bearer yourToken where yourToken will be returned in Login response.
- Contact example with CRUD operations. Validations added.