DEV Community: Sazardev

I finally built the Go project generator I always wanted: Goca (Beta)

Sazardev — Wed, 29 Oct 2025 14:24:14 +0000

Hey Devs!, I wanted to share a side project I’ve been pouring time into lately: Goca.

If you’re like me, you’re tired of writing the same 20 files just to start a new Go service following Clean Architecture. The layers, the interfaces, the DI config—it’s necessary, but it’s pure boilerplate.

That’s where Goca comes in. It’s a CLI tool that generates a full, production-ready Go feature (entity, use case, repository, HTTP handler) in seconds, all while strictly enforcing Uncle Bob’s Clean Architecture rules. It’s essentially my way of cutting out the setup tax.

Heads up: This is still very much in beta. It’s working great for my own projects, but there are definitely rough edges, and I’m still figuring out the best ways to handle database migrations and multi-protocol setups.

It’s open source (MIT licensed), and I’m genuinely looking for feedback from people who actually build production Go apps. If you hate boilerplate as much as I do, please check out the documentation and let me know where it breaks for you.

Link to the docs:https://sazardev.github.io/goca/

Transform Business Productivity with DevOps Culture

Sazardev — Mon, 15 Sep 2025 17:56:18 +0000

When someone hears the term "DevOps", they often think of a branch of software engineering that sounds complex and very technical, and that only concerns system engineers. How naive people can be sometimes.

DevOps is much more than a fancy-sounding job title; it is a culture, a work philosophy that every company wanting to be competitive in today's market should have. This is because DevOps has a very precise philosophy: "Automate everything that can be automated and measure everything that can be measured."

I have seen hundreds of times people, teams, departments, and even companies fall into overengineering, creating unnecessary processes and procedures, generating bureaucracy and paperwork that add no value to the product or service being offered. This is, absolutely, the death of productivity and efficiency.

Imagine (or not, if this has happened to you) that you need to book a meeting room. The first thing they'll ask you to do is fill out a form, then send it to your boss for approval, then the boss sends it to HR for their approval, then HR manually checks a calendar of rooms and confirms if the room is available, then you get a confirmation email, and finally, you go to the room to book it physically. All of this must be notified to everyone involved.

After so much bureaucratic process, guess what happened: someone in HR forgot to book the room and, when you arrived, it was occupied by another meeting.

This is a clear example of overengineering and bureaucracy that adds no value to the process of booking a room. If an automated system had been implemented for booking rooms, all this bureaucracy would have been avoided, saving time and effort for everyone involved. Also, a motto to remember when talking about DevOps is:

"If something can go wrong, it will go wrong" - Murphy's Law

It's inevitable, and you may think it's a bit pessimistic, but it's reality. Humans are prone to making mistakes, no matter how careful they are. That's why it's important to automate everything that can be automated and measure everything that can be measured, to minimize the human factor in a company's processes and procedures. It's important to note that automation is not just for technical processes, but also for administrative and business processes. The DevOps culture should permeate the entire company, from the CEO to the last employee. Stop thinking it's something that only concerns system engineers and start thinking about how you can implement the DevOps culture in your company to be more efficient and competitive in today's market.

Now that it's clear that DevOps is a culture that should permeate the entire company, it's important to understand how to implement it. Here are some steps to implement the DevOps culture in a company:

Automate everything that can be automated: Identify the processes and procedures that can be automated and look for tools and technologies to do so. This includes everything from technical processes to administrative and business processes. (People usually think that a certain process can't be automated, but if you think a bit, there's always a way, so don't give up so easily, think outside the box).
Measure everything that can be measured: Identify key performance indicators (KPIs) that can be measured and set up monitoring and reporting systems to do so (it doesn't have to be something extremely complex, it can even be with notes). This allows you to identify bottlenecks and areas for improvement in the company's processes and procedures.
Encourage collaboration and communication between teams: Break down silos between teams and encourage collaboration and communication among them. This allows for a better understanding of the company's processes and procedures and makes it easier to identify areas for improvement. Just because something is automated doesn't mean communication between teams is lost; on the contrary, it should be more fluid and problem detection should be faster.
Foster a culture of continuous improvement: Create an environment that encourages continuous improvement and innovation. This includes everything from training and skill development to implementing new technologies and tools. Don't get stuck with what you already know; there's always something new to learn and improve. Especially in the automation process, there are always new tools and technologies that can make work easier.
Committed leadership: It's essential that company leadership is committed to implementing the DevOps culture. This includes everything from allocating resources to communicating the company's vision and objectives. If leadership is not committed, it's very likely that the implementation of the DevOps culture will fail. It must be a mindset change throughout the company, and this is only achieved with committed and visionary leadership. If someone is not committed, it's better they are not in the company (it's a tough process, but many companies have failed by trying to keep those who don't want to change, and this only generates friction and resistance where change is needed).

With these steps, it may be possible to implement the DevOps culture in a company and be more efficient, but following a few steps is not everything: it's a continuous process that requires commitment and dedication from the entire company. That's why I want to dedicate a special section to the hardest part of this whole process: The mindset change.

Understand that implementing the DevOps culture in a company is not just a change of processes and procedures, it's a radical change of mindset. Many times, people and teams are used to working a certain way and may resist this change, especially those who have survived various company transformations, and it's understandable: change is scary, but it's necessary to be competitive in today's market. Some may think they will lose power, their job, or become obsolete, and that's understandable, but it's important to communicate that implementing the DevOps culture is not about eliminating jobs, but about making them more efficient and productive. It's important to communicate that automation is not to eliminate jobs, but to eliminate repetitive and tedious tasks that add no value to the product or service being offered.

In the end, what most companies want is to deliver a product, and many employees need to start understanding that what gives value to the company is the product or service being offered, not the processes and procedures used to do so. Many employees believe that by doing many things they are being productive, but just because you do a lot doesn't mean you're being productive; if those things don't add value to the product or service being offered, then they're not productive. So, you must change the mindset to focus on the product or service being offered, not the processes and procedures used to do so. Employees will no longer be tied to repetitive and tedious tasks, but will be focused on delivering a quality product or service, being much happier (due to less work) and more productive.

Don't feel bad or be afraid of the resistance to change that may exist in your company. It's normal, and it's part of the process. Many other companies have experienced this resistance to change. A clear case was Nokia, they had a very entrenched culture and established processes, and when they tried to implement the DevOps culture, there was too much resistance, different departments fought each other for power, and decisions weren't made. In the end, the company couldn't adapt to change and was brutally overtaken by the competition. Nokia is the clear example that it didn't fall because of its technology, it fell because of its culture and resistance to change.

"It is not the strongest species that survives, nor the most intelligent, but the one that best responds to change" - Charles Darwin

Thank you for reading this far. I hope this article has been useful and has given you a new perspective on implementing the DevOps culture in a company, whether you are in a company that wants to implement it, or in a company that has already implemented it and wants to improve it. Remember that implementing the DevOps culture is a continuous process that requires commitment and dedication from the entire company, but the benefits are enormous, from improved efficiency and productivity to improved quality of the product or service being offered.

"Change is the only constant in life" - Heraclitus

Del Caos al Control: La Filosofía de Flutter BLoC para un Estado Predecible

Sazardev — Thu, 12 Jun 2025 14:40:17 +0000

La Motivación: ¿Por Qué Nació BLoC?

Imagina que estás construyendo una casa. La interfaz de usuario (UI) son las paredes, los muebles, los cuadros; todo lo que ves y con lo que interactúas. La lógica de negocio es la plomería, el sistema eléctrico, la calefacción; todo lo que hace que la casa funcione por detrás.

En una aplicación pequeña, podrías tener los cables y las tuberías a la vista, mezclados con los muebles. Al principio no es un gran problema. Pero, ¿qué pasa cuando la casa se vuelve una mansión? Si un enchufe deja de funcionar, tendrías que romper paredes y mover muebles solo para encontrar el cable defectuoso. Si quieres cambiar la calefacción, podrías dañar el sistema de agua sin querer. Es un caos.

Esto mismo sucedía en las primeras etapas de Flutter. Los desarrolladores a menudo mezclaban la lógica (qué hacer con los datos, cómo interactuar con una base de datos, etc.) directamente en los widgets de la UI. Esto provocaba varios problemas graves:

Código Espagueti: La lógica estaba tan entrelazada con la UI que era imposible saber dónde empezaba una y terminaba la otra.
Difícil de Testear: ¿Cómo pruebas la lógica de un pago si está dentro de un botón? Tendrías que simular un clic en el botón en lugar de simplemente probar la función de "pagar".
Reutilización Imposible: Si querías usar la misma lógica de "iniciar sesión" en otra parte de la app, tenías que copiar y pegar un montón de código de UI junto con la lógica.
Estado Inmanejable: A medida que la app crecía, era increíblemente difícil saber por qué la pantalla se actualizaba o de dónde venían los datos que se mostraban.

La solución era clara: necesitábamos un arquitecto. Un patrón que nos obligara a instalar la plomería y la electricidad (la lógica) en una sala de máquinas central, completamente separada de las habitaciones (la UI).

Aquí es donde nace BLoC. Su motivación principal es imponer una separación estricta y clara entre la presentación (UI) y la lógica de negocio.

La Filosofía y Lógica Central: El Flujo Reactivo

La filosofía de BLoC se basa en una idea muy simple pero poderosa: La UI notifica al BLoC sobre eventos del usuario, y el BLoC notifica a la UI sobre cambios de estado.

Pensemos en una analogía: una cafetería ☕.

Tú (El Usuario): Llegas al mostrador.
El Mostrador (La UI): Es donde interactúas. Ves los botones: "Pedir Espresso", "Pedir Latte".
Tu Pedido (El Evento): Cuando presionas "Pedir Latte", creas un Evento. El evento es una simple descripción de lo que quieres: PedidoDeLatte. No preparas el café, solo comunicas tu intención.
El Barista (El BLoC): El barista toma tu pedido (el Evento PedidoDeLatte). Él es el único que sabe cómo preparar el café. Tiene la máquina, el conocimiento y los ingredientes. Esta es la lógica de negocio. No hablas directamente con la máquina de café; hablas con el barista.
El Proceso (La Lógica dentro del BLoC): El barista muele el grano, calienta la leche, extrae el espresso... realiza una serie de pasos.
La Pantalla de Pedidos (El Estado): Mientras esperas, miras una pantalla. Primero dice PedidoRecibido. Luego cambia a PreparandoCafe. Finalmente, cambia a PedidoListo(tuLatte). Estos son los Estados. El barista va actualizando esta pantalla para que sepas qué está pasando.
Recoges tu Café (La UI Reacciona al Estado): Cuando ves el estado PedidoListo, tu parte de la UI (tu vista) se actualiza: ahora tienes un café en la mano.

Esta es la esencia de BLoC:

Eventos (Events): Objetos inmutables que representan las intenciones del usuario o del sistema (ej: BotonDeLoginPresionado, DatosSolicitados).
BLoC (Business Logic Component): La clase que recibe los Eventos, procesa la lógica correspondiente (hacer una llamada a una API, calcular algo) y emite nuevos Estados.
Estados (States): Objetos inmutables que representan una parte del estado de tu aplicación (ej: Cargando, Exitoso, Error). La UI simplemente escucha estos estados y se redibuja a sí misma según corresponda.

Este flujo es reactivo y predecible. La UI solo puede cambiar en respuesta a un nuevo estado emitido por el BLoC. Y el BLoC solo cambia su estado en respuesta a un evento. Sabes exactamente cómo fluye la información, lo que hace que depurar sea infinitamente más fácil.

¿Qué Soluciona y Qué Hace Exactamente?

BLoC soluciona el problema de la gestión del estado de una manera escalable y organizada.

¿Qué hace?

Centraliza tu lógica de negocio: Todo el "cerebro" de una funcionalidad (autenticación, carrito de compras, perfil de usuario) vive en un solo lugar: su BLoC.
Desacopla la UI de la lógica: Tu UI se vuelve "tonta". No sabe cómo iniciar sesión, solo sabe que hay un estado Cargando y debe mostrar un spinner, y un estado Autenticado y debe navegar a la pantalla principal.
Facilita las pruebas: Puedes probar tu lógica de inicio de sesión (el AuthBloc) de forma aislada. Le das un evento LoginEvent y verificas que emita los estados LoadingState y luego AuthenticatedState, todo sin renderizar un solo píxel en la pantalla.
Hace tu estado predecible: Al restringir el flujo a Evento -> BLoC -> Estado, siempre puedes rastrear por qué algo cambió. La librería bloc incluso viene con un BlocObserver que te permite imprimir cada transición de estado en la consola.

¿Qué NO hace?

Esto es igualmente importante para entenderlo bien.

No realiza la inyección de dependencias: BLoC no sabe cómo ser "provisto" a la UI. Para esto, se apoya en otra librería, flutter_bloc, que usa provider por debajo para inyectar eficientemente tus BLoCs en el árbol de widgets.
No es un framework de navegación: BLoC puede emitir un estado que desencadene una navegación (usando un BlocListener), pero la lógica de navegación en sí misma (usando Navigator.push o GoRouter) está fuera de su responsabilidad.
No hace las llamadas a la API directamente: Tu BLoC orquestará la llamada, pero la implementación real de la llamada (el código que usa http.get o dio.get) debería estar en una capa separada, comúnmente llamada Repositorio o Proveedor de Datos. El BLoC llama al repositorio, y el repositorio obtiene los datos.

¿Cuándo Usarlo y Cuándo NO? (El Dilema del BLoC vs. Cubit)

No necesitas un BLoC para todo. Usar BLoC para manejar el estado de un simple checkbox es como usar un tráiler para llevar una bolsa del supermercado.

Cubit: El Hermano Menor y Simplificado

El equipo de BLoC creó Cubit, una versión más ligera y simple. La diferencia clave es:

BLoC: Usa Eventos (add(LoginEvent())). Es más verboso pero más trazable. Sabes exactamente qué causó el cambio de estado.
Cubit: Expone funciones públicas (login()). Es más directo y requiere menos código.

Analogía:

BLoC (El Restaurante Formal): Das una orden formal (Evento) al mesero, y no sabes exactamente qué pasa en la cocina, solo esperas el resultado (Estado). Es bueno para procesos complejos y para tener un registro claro de cada orden.
Cubit (El Puesto de Tacos): Le dices directamente al taquero: "¡Dame dos al pastor!" (llamas a una función dameTacos(2)). Es rápido, directo y eficiente para tareas simples.

Reglas de Oro:

Usa Cubit cuando:
- La lógica es simple. Por ejemplo, manejar el tema de la app (oscuro/claro), controlar el índice de un BottomNavigationBar, o manejar un formulario simple.
- Los cambios de estado son el resultado de llamadas a funciones directas, no de una cadena compleja de eventos.
- Quieres escribir menos código para una funcionalidad sencilla.
Usa BLoC cuando:
- La lógica de negocio es compleja y tiene múltiples pasos. Un proceso de pago, por ejemplo: ValidarFormulario -> ProcesarPagoConAPI -> CrearOrdenEnBD -> EnviarEmailDeConfirmacion.
- Necesitas trazabilidad. Quieres saber la secuencia exacta de eventos que llevaron a un estado de error. Esto es invaluable para la depuración.
- Los eventos pueden venir de múltiples fuentes: clics del usuario, respuestas de un WebSocket, notificaciones push, etc.
- Estás trabajando en un equipo grande y quieres que la lógica sea explícita y fácil de entender para todos.

Conclusión: Empieza con un Cubit. Si tu lógica empieza a volverse compleja y te encuentras poniendo demasiada inteligencia dentro de una sola función, es una señal de que necesitas refactorizar a un BLoC para manejar esa complejidad con eventos más granulares.

Rendimiento: ¿Cómo Evitar Reconstrucciones Innecesarias?

Una preocupación común con cualquier gestor de estado es el rendimiento. ¿Se reconstruirá toda mi pantalla cada vez que cambie un pequeño detalle del estado? Con BLoC, la respuesta es no, si lo usas correctamente.

La librería flutter_bloc te da herramientas precisas para controlar qué se reconstruye y cuándo:

BlocBuilder: Es el widget más común. Se reconstruye cada vez que el BLoC emite un nuevo estado. Por defecto, es bastante inteligente y no se reconstruirá si el estado emitido es idéntico al anterior.
buildWhen: Este es el superpoder de BlocBuilder. Es una condición opcional que te permite especificar exactamente cuándo debe reconstruirse el widget.

  * **Ejemplo:** En una pantalla de login, podrías tener un estado `LoginState` con propiedades `(email, password, status, errorMessage)`. Si el usuario solo está escribiendo en el campo de texto del email, no necesitas reconstruir el botón de login. Con `buildWhen`, puedes decirle que solo se reconstruya si el `status` (ej: `Loading`, `Success`, `Failure`) cambia.

<!-- end list -->

```dart
BlocBuilder<LoginBloc, LoginState>(
  buildWhen: (previous, current) {
    // Solo reconstruye el widget si el estado de la petición cambia,
    // no si solo cambia el texto del email o la contraseña.
    return previous.status != current.status;
  },
  builder: (context, state) {
    // UI que muestra un spinner o un mensaje de error
    if (state.status == LoginStatus.loading) {
      return CircularProgressIndicator();
    }
    return ElevatedButton(onPressed: ..., child: Text('Login'));
  },
)
```

BlocSelector: Es aún más granular. Te permite escuchar cambios en una pequeña parte del estado.

  * **Ejemplo:** Imagina un `UserState` con `(name, age, profileImageUrl)`. Si solo quieres reconstruir el widget del nombre cuando el nombre cambie, `BlocSelector` es perfecto. Evita reconstruir el widget de la imagen de perfil innecesariamente.

BlocListener: Este widget es para efectos secundarios. No reconstruye ninguna UI. Su propósito es ejecutar una acción una sola vez en respuesta a un cambio de estado.

  * **Usos perfectos:** Mostrar un `SnackBar` ("Usuario guardado con éxito"), un diálogo de error, o para la **navegación** (`Navigator.push(...)` cuando el estado sea `LoginSuccess`).

Equatable: Para que buildWhen y el comportamiento por defecto de BlocBuilder funcionen correctamente, tus objetos de estado deben poder compararse. La librería equatable te ayuda a hacer esto fácilmente, simplemente listando las propiedades que definen la identidad del objeto.

La Implementación Ideal: Paso a Paso

Vamos a construir un ejemplo práctico: una pantalla que carga una lista de usuarios desde una API.

1. Estructura de Carpetas

Una buena organización es clave. Para una funcionalidad de "usuarios", tendrías algo así:

lib/
└── features/
    └── users/
        ├── bloc/
        │   ├── user_event.dart
        │   ├── user_state.dart
        │   └── user_bloc.dart
        ├── data/
        │   ├── user_repository.dart
        │   └── user_model.dart
        └── presentation/
            └── user_screen.dart

2. Definir los Estados (State)

El estado representa todo lo que la UI necesita saber. ¿Qué estados puede tener nuestra pantalla de usuarios?

UserInitial: El estado inicial, antes de que hagamos nada.
UserLoading: Estamos cargando los usuarios. La UI debería mostrar un spinner.
UserSuccess: Tuvimos éxito. El estado contendrá la lista de usuarios.
UserError: Algo salió mal. El estado contendrá un mensaje de error.

user_state.dart:

part of 'user_bloc.dart';

// Clase base abstracta para todos los estados
abstract class UserState extends Equatable {
  const UserState();

  @override
  List<Object> get props => [];
}

class UserInitial extends UserState {}

class UserLoading extends UserState {}

class UserSuccess extends UserState {
  final List<User> users; // Los datos que la UI necesita

  const UserSuccess(this.users);

  @override
  List<Object> get props => [users];
}

class UserError extends UserState {
  final String message; // El mensaje de error para la UI

  const UserError(this.message);

  @override
  List<Object> get props => [message];
}

3. Definir los Eventos (Event)

El evento es lo que la UI envía al BLoC para desencadenar una acción.

FetchUsers: Un evento para solicitar la carga de los usuarios.

user_event.dart:

part of 'user_bloc.dart';

abstract class UserEvent extends Equatable {
  const UserEvent();

  @override
  List<Object> get props => [];
}

// Único evento que necesitamos por ahora
class FetchUsers extends UserEvent {}

4. Crear el BLoC

Aquí es donde vive la magia. El BLoC escucha eventos y emite estados.

user_bloc.dart:

import 'package:bloc/bloc.dart';
import 'package:equatable/equatable.dart';

// Importamos nuestro repositorio y modelo
import '../data/user_model.dart';
import '../data/user_repository.dart';

part 'user_event.dart';
part 'user_state.dart';

class UserBloc extends Bloc<UserEvent, UserState> {
  final UserRepository userRepository;

  UserBloc({required this.userRepository}) : super(UserInitial()) {
    // Aquí registramos el manejador para nuestro evento
    on<FetchUsers>(_onFetchUsers);
  }

  // El manejador de eventos es una función asíncrona
  Future<void> _onFetchUsers(FetchUsers event, Emitter<UserState> emit) async {
    // 1. Emitimos el estado de carga inmediatamente
    emit(UserLoading());
    try {
      // 2. Llamamos al repositorio para obtener los datos
      final users = await userRepository.getUsers();
      // 3. Si todo va bien, emitimos el estado de éxito con los datos
      emit(UserSuccess(users));
    } catch (e) {
      // 4. Si hay un error, emitimos el estado de error
      emit(UserError('Failed to fetch users: ${e.toString()}'));
    }
  }
}

Observa la separación de responsabilidades: el BLoC no sabe *cómo se obtienen los usuarios (HTTP, base de datos...), solo llama a userRepository.getUsers(). El repositorio es el que se encarga de eso.*

5. Integrar con la UI

Finalmente, conectamos todo en la pantalla.

user_screen.dart:

import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';

// Importamos todo lo necesario
import '../bloc/user_bloc.dart';
import '../data/user_repository.dart';

class UsersScreen extends StatelessWidget {
  const UsersScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Users')),
      // 1. Proveemos el BLoC al árbol de widgets.
      // BlocProvider crea la instancia del BLoC y se asegura de cerrarla (dispose) correctamente.
      body: BlocProvider(
        create: (context) => UserBloc(
          // Normalmente inyectarías el repositorio con get_it o provider
          userRepository: RepositoryProvider.of<UserRepository>(context),
        )..add(FetchUsers()), // Añadimos el evento inicial para que cargue los datos al entrar.
        child: const UserView(),
      ),
    );
  }
}

class UserView extends StatelessWidget {
  const UserView({super.key});

  @override
  Widget build(BuildContext context) {
    // 2. Usamos BlocBuilder para escuchar los cambios de estado y construir la UI.
    return BlocBuilder<UserBloc, UserState>(
      builder: (context, state) {
        // 3. Renderizamos diferentes widgets basados en el estado actual.
        if (state is UserLoading) {
          return const Center(child: CircularProgressIndicator());
        }
        if (state is UserSuccess) {
          return ListView.builder(
            itemCount: state.users.length,
            itemBuilder: (context, index) {
              final user = state.users[index];
              return ListTile(
                title: Text(user.name),
                subtitle: Text(user.email),
              );
            },
          );
        }
        if (state is UserError) {
          return Center(child: Text(state.message));
        }
        // Estado inicial o por defecto
        return const Center(child: Text('Press a button to fetch users.'));
      },
    );
  }
}

¡Y eso es todo! Hemos creado una funcionalidad robusta, testeable y desacoplada. La UserView es completamente "tonta", simplemente refleja el estado que le da el UserBloc. Si mañana necesitas cambiar la fuente de datos de una API REST a Firebase, solo modificas el UserRepository, y ni el BLoC ni la UI se enterarán del cambio. Ese es el verdadero poder de BLoC.

WebSockets Unplugged: A Developer's Guide to Real-Time Magic

Sazardev — Wed, 11 Jun 2025 15:31:50 +0000

Have you ever wondered how chat apps deliver messages instantly? Or how collaborative editing tools update in real-time? Behind this magic is a technology called WebSockets – and it's not as complicated as you might think!

The Problem: Why HTTP Wasn't Enough

Imagine you're at a restaurant (the browser) trying to talk to the kitchen (the server):

Traditional HTTP (REST API): You ask the waiter a question, they go to the kitchen for an answer, return with a response, then leave. Every. Single. Time. Want to know if your food is ready? New waiter trip. Want to modify your order? Another waiter trip.

The HTTP Problem:

Each request needs a new connection
The server can't talk to you unless you ask first
Constantly asking "Is it ready yet?" wastes resources (polling)

Enter WebSockets: The Direct Phone Line

WebSockets are like installing a direct phone line between you and the kitchen:

With WebSockets:

You establish a connection ONCE
Both sides can talk whenever they want
The connection stays open until either side hangs up
Messages flow freely in both directions

How WebSockets Work: The Handshake Dance

Let's break down how WebSockets actually connect:

It's like going to a secret club:

You knock on the door (HTTP request)
You whisper the secret password ("Upgrade: websocket")
The bouncer checks your ID (handshake)
Once inside, you're a member until you leave!

Real-World Analogies for WebSockets

The Walkie-Talkie Analogy

Traditional HTTP is like sending letters through mail. WebSockets are like walkie-talkies - always on, instant communication!

The Party Line Analogy

Remember old telephone party lines? WebSockets are similar - everyone on the line can hear and speak without hanging up and dialing again.

The News Subscription Analogy

HTTP: Walking to the newsstand every 5 minutes to check for a new edition
WebSockets: The newspaper being delivered the moment it's printed

When Would You Use WebSockets?

Perfect for:

Chat applications
Live sports updates
Collaborative editing tools
Real-time dashboards
Multiplayer games
Stock tickers
Notifications

Not great for:

Simple content websites
Data that changes infrequently
One-time data transfers

A Typical WebSocket Scenario: The Chat App

Here is how a basic chat app might use WebSockets:

The beauty is that Bob doesn't need to keep asking, "Did Alice send me a message?" The server pushes messages to Bob the moment Alice sends them!

What About WebSockets Under the Hood?

Without getting too technical:

Initial handshake uses HTTP
After upgrade, it's a different protocol (ws:// or wss://)
Messages are framed differently than HTTP
Can send text or binary data
Includes built-in ping/pong to keep connections alive

Benefits of WebSockets

Efficiency: No need to send HTTP headers with every message
Speed: No connection setup/teardown overhead
Real-time: True bidirectional communication
Less server load: No polling with hundreds of requests
Better user experience: Instant updates!

Practical Tips from a Developer's POV

Use Secure WebSockets: Always use wss:// (not ws://) in production
Handle disconnections: Networks are flaky, always implement reconnection logic
Be message-size aware: Some proxies limit message sizes
Consider a fallback: Some environments might block WebSockets
Remember mobile: Mobile connections can drop and reconnect often

So When Should You NOT Use WebSockets?

WebSockets are not always the answer:

Simple websites: Regular HTTP is simpler and more than adequate
RESTful services: If you are just requesting data occasionally
When HTTP caching helps: WebSockets bypass the HTTP caching system
When you need simple horizontal scaling: WebSockets maintain state, making scaling more complex

Conclusion

WebSockets bring the magic of real-time communication to the web. They solve the problem of bidirectional communication in an elegant way that allows for rich, interactive experiences.

Next time you are building an app that needs instant updates or real-time interaction, remember our kitchen phone line! WebSockets might be exactly what you need to create that magical experience where things just happen instantly.

Have you used WebSockets in your projects? What challenges did you face? Let's chat in the comments below!

Surviving Extreme Programming: A Developer's Wild Ride

Sazardev — Tue, 10 Jun 2025 15:07:04 +0000

Surviving Extreme Programming: A Developer's Wild Ride

Have you ever wanted to strap your coding practices to a rocket and send them to the moon? That is what Extreme Programming (XP) does to traditional software development. As a developer who has been through the XP wringer, I am here to tell you it is both terrifying and exhilarating - like riding a rollercoaster built by the same people who review your pull requests.

What the Heck is Extreme Programming Anyway?

Extreme Programming is like regular programming, but after it's chugged five espressos. It takes good engineering practices and cranks them up to eleven.

Think of it this way: If traditional development is like carefully planning a road trip with maps and hotel reservations, XP is more like deciding to drive cross-country with only a compass, a full tank of gas, and the willingness to change direction every time someone in the backseat spots something interesting.

Pair Programming: Two Keyboards, One Brain

Imagine having someone watching over your shoulder while you code... ALL. THE. TIME. That's pair programming, and yes, it's as awkward as it sounds at first.

*Real-life example: * Last month, I was pairing with Alex on a particularly nasty authentication bug. I was driving (typing), and Alex was navigating (directing).

Me: confidently typing "This should fix it."
Alex: "You just created three new bugs in two lines of code."
Me: "...talent."

But here is the weird part - it works! After a few weeks of pair programming:

My code quality improved dramatically
I stopped making silly mistakes (goodbye, infinite loops!)
I learned tricks I never would have discovered on my own
My ability to explain my thinking improved

It is like having a real-time code review, brainstorming session, and therapy appointment all at once.

Test-Driven Development: Write Tests, Fail Tests, Question Life Choices

TDD is like building a safety net before attempting a trapeze act. It feels like a waste of time until you're falling through the air screaming.

*In practice: *

Write a test for a feature that does not exist yet
Watch it fail (duh)
Write just enough code to make it pass
Refactor until it is not embarrassing
Repeat until you have built something that works

*Real-world example: * Our team was building a payment processing system. Instead of diving straight into code, we wrote tests for every scenario: successful payments, failed payments, expired cards, zombie apocalypse, etc.

When we finally wrote the actual code, we discovered we had forgotten to manage timeouts. But guess what? Our test caught it before it ever hit production. No late-night emergency calls, no angry customers, no sad developers.

Continuous Integration: Commit Early, Commit Often, Commit Therapy

In XP, we commit code to the main branch multiple times a day. It is like ripping off a band-aid repeatedly until you get used to the pain.

Before XP, my commits looked like:

git commit -m "Massive changes to everything after 2 weeks of work"

After XP:

git commit -m "Changed button color to blue"
git commit -m "Made button 2px wider"
git commit -m "Button now does the thing when clicked"

This approach is like keeping your room clean by putting things away at once instead of waiting until your floor disappears under a pile of laundry and pizza boxes.

The Customer Is Always... Right There. Always.

In XP, customers (or their representatives) are part of the team. They do not just drop requirements from the mountaintop and disappear - they are right there in the trenches with you.

*Example: * We were building a dashboard for financial analysts. Instead of guessing what they needed, we had Sarah from the finance team sitting with us three days a week.

Me: "Would you prefer the reports in a table or chart format?"
Sarah: "Actually, can we have both with a toggle switch?"
Me: thinking "That's... actually a great idea I never would have thought of."

It's like cooking dinner with someone instead of trying to guess what they want to eat.

The Velocity Paradox: Going Slow to Go Fast

XP feels slower at first. Writing tests takes time. Pairing takes time. Planning takes time. It is like packing properly for a trip instead of just throwing random stuff in a suitcase and hoping for the best.

But then something magical happens - you stop wasting time on:

Fixing bugs that could have been prevented
Building features nobody wants
Massive refactoring because the code became unmaintainable
Emergency hotfixes at 2 AM

*Personal story: * Our team spent an entire sprint refactoring and adding tests to a legacy module. Management was nervous about the "lack of new features." Three months later, every other team was still putting out fires while we were consistently delivering new features every week.

Is XP Right for You? A Handy Quiz

The XP Developer Survival Kit

If you're about to dive into an XP project, here is what you will need:

A thick skin - Your code will be reviewed constantly
An open mind - Some practices will feel weird before they feel right
Comfortable headphones - For when you need a break from pairing
The ability to say "I don't know" - XP values honesty over heroics
A sense of humor - Because sometimes your tests will fail in spectacular ways

Conclusion: The Extremely Good Parts

After years of practicing XP, I cannot imagine going back. Yes, it is extreme. Yes, it can be uncomfortable. But it is also incredibly effective.

Have you tried Extreme Programming practices in your work? Which ones worked for you and which ones didn't? Let me know in the comments!

Why Developers Are Just Doctors for Computers

Sazardev — Mon, 09 Jun 2025 12:43:48 +0000

Ever wondered why your dev friend always looks so tired? They're basically running a 24/7 emergency room for code.

The Similarities Are Uncanny 🤔

Debugging = Medical Diagnosis

Developer: "Hmm, the app is crashing. Let me check the logs..."
Doctor: "Hmm, you have a fever. Let me run some tests..."

Both involve a lot of console.log() statements and "turn it off and on again"

Code Reviews = Second Opinions

Developer: "Can you look at my PR? Something feels off..."
Doctor: "Can you review this case? Something doesn't add up..."

Both can save lives (or at least save you from production disasters)

Stack Traces = Medical Records

Long, confusing, full of technical jargon
Only make sense to professionals

Patients/Users: "Can you explain this in English?"

Hotfixes = Emergency Surgery

High pressure
No room for mistakes
Everyone's watching
Coffee is your best friend ☕

The Diagnosis Process 🔍

1. Patient/App shows symptoms
2. Ask questions nobody understands
3. Run mysterious tests
4. Stare at results for 20 minutes
5. Try the simplest solution first
6. If that fails, Google it
7. Blame it on lifestyle choices/user error

Common "Diseases" We Treat

Computer Disease	Human Equivalent
Memory leak	Chronic fatigue
Infinite loop	Insomnia
404 Error	Amnesia
Buffer overflow	Indigestion
Race condition	Multiple personality disorder
Deadlock	Paralysis

Famous Last Words 💀

Doctors: "This won't hurt a bit"

Developers: "This should work in production"

Both are usually wrong.

The Bedside Manner

Doctor: "Take two aspirin and call me in the morning"

Developer: "Clear your cache and restart your browser"

Patient: "But I already tried that..."

User: "But I already tried that..."

Both: "Try it again." 🤷‍♂️

The Real Truth

At 3 AM, both are:

Drinking way too much caffeine
Questioning their life choices
Saving someone's day/life
Wondering why they didn't become accountants

Remember: Always listen to your developer. They know when your system needs rest, updates, or a complete reboot. Just like doctors, but with less malpractice insurance.

What other job analogies describe developers perfectly? Drop them in the comments! 👇

*Posted by @sazardev

I made a project in Golang with no packages or libraries (also not ORM's)

Sazardev — Fri, 11 Apr 2025 18:44:15 +0000

The problem

Okay, may you are asking yourself, why you do a project in Golang with no packages or libraries? First, the project requires an highly optimized database, high concurrency and a lot of performance, a lot of files and a lot of data. So, I thought, why not do it in Golang?

The project it is about to make a conciliation with a different types of invoices reading XML in two differents ways. First, it is using an API (easy) the second it's in a dynamic database location (hard). The two ways give me only XML files, so I need to parse them and make a conciliation with the data. Also, when I get the conciliated invoices, that concilitation needs to be saved in a database. So, I need to make a lot of queries and a lot of data manipulation, and the hardest part is to make all this in a high performance way, when the data is conciliated the user will be able to sort and filter in the data.

The solution

That is the problem. Using Go was the best decission for this project, but why no packages? Not easy answer here, but I need to have a FULL control of the database, the querys, indexes, tables, and all the data. Even I need to control the database configuration. GORM do not let me to customize every aspect of a table or column.

Then another problem is a high concurrency with the two ways of getting data in different sources (And compress the XML because it is a HUGE amount of data) and then parse it. So, I need to make a lot of goroutines and channels to make the data flow.

Every pieces are on the table. Next lets see the structure project!

|-- src
| |-- config
| |-- controller
| |-- database
| |-- handlers
| |-- interfaces
| |-- middleware
| |-- models
| |-- routes
| |-- services
| |-- utils

Very simple, but very effective. I have a config folder to store all the configuration of the project, like the database connection, the API keys, etc. The controller folder as a bussiness logic headers, the database folder as the database connection and the queries, the handlers folder as the HTTP handlers, the interfaces folder as the interfaces declared for the petitions in others APIs, the middleware folder for CORS and , the models folder as the models for the database, the routes folder as the routes of the project, the services folder as the services of the project and finally the utils folder as a utility functions.

How the data is managed

Now, lets talk about my database configuration, but please, keep in mind, that this configuration only works in MY situation, and this is the best only in this case, may not be useful in another cases. And visualize that every table has indexes.

`listen_addresses = '*'`

Configures which IP addresses PostgreSQL listens on. Setting this to '*' allows connections from any IP address, making the database accessible from any network interface. Useful for servers that need to accept connections from multiple clients on different networks.

`shared_buffers = 256MB`

Determines the amount of memory dedicated to PostgreSQL for caching data. This is one of the most important parameters for performance, as it caches frequently accessed tables and indexes in RAM. 256MB is a moderate value that balances memory usage with improved query performance. For high-performance systems, this could be set to 25% of total system memory.

`work_mem = 16MB`

Specifies the memory allocated for sort operations and hash tables. Each query operation can use this amount of memory, so 16MB provides a reasonable balance. Setting this too high could lead to memory pressure if many queries run concurrently, while setting it too low forces PostgreSQL to use disk-based sorting.

`maintenance_work_mem = 128MB`

Defines memory dedicated to maintenance operations like VACUUM, CREATE INDEX, or ALTER TABLE. Higher values (like 128MB) accelerate these operations, especially on larger tables. This memory is only used during maintenance tasks, so it can safely be set higher than work_mem.

`wal_buffers = 16MB`

Controls the size of the buffer for Write-Ahead Log (WAL) data before writing to disk. 16MB is sufficient for most workloads and helps reduce I/O pressure by batching WAL writes.

`synchronous_commit = off`

Disables waiting for WAL writes to be confirmed as written to disk before reporting success to clients. This dramatically improves performance by allowing the server to continue processing transactions immediately, at the cost of a small risk of data loss in case of system failure (typically just a few recent transactions).

`checkpoint_timeout = 15min`

Sets the maximum time between automatic WAL checkpoints. A longer interval (15 minutes) reduces I/O load by spacing out checkpoint operations but may increase recovery time after a crash.

`max_wal_size = 1GB`

Defines the maximum size of WAL files before triggering a checkpoint. 1GB allows for efficient handling of large transaction volumes before forcing a disk write.

`min_wal_size = 80MB`

Sets the minimum size to shrink the WAL to during checkpoint operations. Keeping at least 80MB prevents excessive recycling of WAL files, which would cause unnecessary I/O.

`random_page_cost = 1.1`

An estimate of the cost of fetching a non-sequential disk page. The low value of 1.1 (close to 1.0) indicates the system is using SSDs or has excellent disk caching. This guides the query planner to prefer index scans over sequential scans.

`effective_cache_size = 512MB`

Tells the query planner how much memory is available for disk caching by the OS and PostgreSQL. 512MB indicates a moderate amount of system memory available for caching, influencing the planner to favor index scans.

`max_connections = 100`

Limits the number of simultaneous client connections. 100 connections is suitable for applications with moderate concurrency requirements while preventing resource exhaustion.

`max_worker_processes = 4`

Sets the maximum number of background worker processes the system can support. 4 workers allows parallel operations while preventing CPU oversubscription on smaller systems.

`max_parallel_workers_per_gather = 2`

Defines how many worker processes a single Gather operation can launch. Setting this to 2 enables moderate parallelism for individual queries.

`max_parallel_workers = 4`

Limits the total number of parallel workers that can be active at once. Matching this with max_worker_processes ensures all worker slots can be used for parallelism if needed.

`log_min_duration_statement = 200`

Logs any query that runs longer than 200 milliseconds. This helps identify slow-performing queries that might need optimization, while not logging faster queries that would create excessive log volume.

Table declarations

Obviusly I will not put here every table created and every column (Also the names are changed) but this is a general idea.

CREATE TABLE IF NOT EXISTS reconciliation (
    id SERIAL PRIMARY KEY,
    requester_id VARCHAR(13) NOT NULL,
    request_uuid VARCHAR(36) NOT NULL UNIQUE,
    company_id VARCHAR(13) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_reconciliation_request_uuid ON reconciliation(request_uuid);
CREATE INDEX IF NOT EXISTS idx_reconciliation_requester_id ON reconciliation(requester_id);
CREATE INDEX IF NOT EXISTS idx_reconciliation_company_id ON reconciliation(company_id);

CREATE TABLE IF NOT EXISTS reconciliation_invoice (
    id SERIAL PRIMARY KEY,
    -- Imagine 30 columns declarations...
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (reconciliation_id) REFERENCES reconciliation(id) ON DELETE CASCADE
);

CREATE INDEX IF NOT EXISTS idx_reconciliation_invoice_reconciliation_id ON reconciliation_invoice(reconciliation_id);
CREATE INDEX IF NOT EXISTS idx_reconciliation_invoice_source_uuid ON reconciliation_invoice(source_system_uuid);
CREATE INDEX IF NOT EXISTS idx_reconciliation_invoice_erp_uuid ON reconciliation_invoice(erp_system_uuid);
CREATE INDEX IF NOT EXISTS idx_reconciliation_invoice_reconciled ON reconciliation_invoice(reconciled);

CREATE TABLE IF NOT EXISTS reconciliation_stats (
    reconciliation_id INTEGER PRIMARY KEY REFERENCES reconciliation(id) ON DELETE CASCADE,
    -- ... A lot of more stats props
    document_type_stats JSONB NOT NULL,
    total_distribution JSONB NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_reconciliation_stats_reconciliation_id
ON reconciliation_stats(reconciliation_id);

Index Explanations

The schema includes several strategic indexes to optimize query performance:

Primary Key Indexes: Each table has a primary key that automatically creates an index for fast record retrieval by ID.
Foreign Key Indexes:

idx_reconciliation_invoice_reconciliation_id enables efficient joins between reconciliation and invoice tables
idx_reconciliation_stats_reconciliation_id optimizes queries joining stats to their parent reconciliation

Lookup Indexes:

idx_reconciliation_request_uuid for fast lookups by unique request identifier
idx_reconciliation_requester_id and idx_reconciliation_company_id optimize filtering by company or requester

Business Logic Indexes:
- idx_reconciliation_invoice_source_uuid and idx_reconciliation_invoice_erp_uuid improve performance when matching documents between systems
- idx_reconciliation_invoice_reconciled optimizes filtering by reconciliation status, which is likely a common query pattern

These indexes significantly improve performance for the typical query patterns in a reconciliation system, where you often need to filter by company, requester, or match status, while potentially handling large volumes of invoice data.

How I handle the XML

The KEY of why use Go it was by how EASY is to use XML in Go (I am really in love and save HOURS). Maybe you never see an XML, this is a fake example of an XML invoice:

<Invoice xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2"
...
</cac:OrderReference>
<cac:AccountingSupplierParty>
...
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
...
</cac:AccountingCustomerParty>
<cac:Delivery>
...
</cac:Delivery>
<cac:PaymentMeans>
...
</cac:PaymentMeans>
<cac:PaymentTerms>
...
</cac:PaymentTerms>
<cac:AllowanceCharge>
...
</cac:AllowanceCharge>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="GBP">17.50</cbc:TaxAmount>
<cbc:TaxEvidenceIndicator>true</cbc:TaxEvidenceIndicator>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="GBP">100.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="GBP">17.50</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>A</cbc:ID>
<cac:TaxScheme>
<cbc:ID>UK VAT</cbc:ID>
<cbc:TaxTypeCode>VAT</cbc:TaxTypeCode>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
...
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
...
</cac:InvoiceLine>
</Invoice>

In another language may can be PAINFUL to extract this data and more when the data have a child in a child in a child...

This is an interface example in Go:

type Invoice struct {
    ID              string `xml:"ID"`
    IssueDate       string `xml:"IssueDate"`
    SupplierParty   Party  `xml:"AccountingSupplierParty"`
    CustomerParty   Party  `xml:"AccountingCustomerParty"`
    TaxTotal        struct {
        TaxAmount         string      `xml:"TaxAmount"`
        EvidenceIndicator bool        `xml:"TaxEvidenceIndicator"`
        // Handling deeply nested elements
        Subtotals         []struct {
            TaxableAmount string `xml:"TaxableAmount"`
            TaxAmount     string `xml:"TaxAmount"`
            // Even deeper nesting
            Category      struct {
                ID        string `xml:"ID"`
                Scheme    struct {
                    ID        string `xml:"ID"`
                    TypeCode  string `xml:"TaxTypeCode"`
                } `xml:"TaxScheme"`
            } `xml:"TaxCategory"`
        } `xml:"TaxSubtotal"`
    } `xml:"TaxTotal"`
}

type Party struct {
    Name    string `xml:"Party>PartyName>Name"`
    TaxID   string `xml:"Party>PartyTaxScheme>CompanyID"`
    // Other fields omitted...
}

Very easy, right? With an interface we got everything ready to work extracting data and save from our APIs!

Concurrency

Another aspect of why go for Go is the concurrency. Why this project needs concurrency? Okay, lets see a diagram of how the data flow:

Imagine, if I process every package one by one, I will be waiting a lot of time to process all the data. So, its the perfect time to use goroutines and channels.

Conclusion

After completing this project with pure Go and no external dependencies, I can confidently say this approach was the right choice for this specific use case. The standard library proved to be remarkably capable, handling everything from complex XML parsing to high-throughput database operations.

The key advantages I gained were:

Complete control over performance optimization - By writing raw SQL queries and fine-tuning PostgreSQL configuration, I achieved performance levels that would be difficult with an ORM's abstractions.
No dependency management headaches - Zero external packages meant no version conflicts, security vulnerabilities from third-party code, or unexpected breaking changes.
Smaller binary size and reduced overhead - The resulting application was lean and efficient, with no unused code from large libraries.
Deep understanding of the system - Building everything from scratch forced me to understand each component thoroughly, making debugging and optimization much easier.
Perfect fit for Go's strengths - This approach leveraged Go's strongest features: concurrency with goroutines/channels, efficient XML handling, and a powerful standard library.

That said, this isn't the right approach for every project. The development time was longer than it would have been with established libraries and frameworks. For simpler applications or rapid prototyping, the convenience of packages like GORM or Echo would likely outweigh the benefits of going dependency-free.

However, for systems with strict performance requirements handling large volumes of data with complex processing needs, the control offered by this bare-bones approach proved invaluable. The reconciliation system now processes millions of invoices efficiently, with predictable performance characteristics and complete visibility into every aspect of its operation.

In the end, the most important lesson was knowing when to embrace libraries and when to rely on Go's powerful standard library - a decision that should always be driven by the specific requirements of your project rather than dogmatic principles about dependencies.

Is bad learning new programming languages?

Sazardev — Mon, 30 Sep 2024 22:20:27 +0000

When I was in high school, my teacher says that is truly unnecessary to learn new programming languages, because is better to be perfet in one language than to be average in many, and some other people think that this is a true fact, but for all that people that think that, I just can say that they are wrong.

Wrong in the sens that learning new programming languages is not just about learning a new syntax, is about learning a new way to think, a new way to solve problems, a new way to create things. It's about expanding your horizons, broadening your perspective, challenging your assumptions. It's about pushing yourself out of your comfort zone, stretching your limits, growing beyond your boundaries.

Also, if you're work requires Java, and you only know Java, you're limiting yourself to Java jobs, Java projects, Java opportunities. But if you know Java, Python, JavaScript, C++, you're opening yourself up to a world of possibilities, a world of opportunities, a world of challenges. You're making yourself more marketable, more versatile, more valuable. You're giving yourself the freedom to choose, the power to change, the confidence to succeed.

So, is bad learning new programming languages? No, it's not bad, it's good. I amply recommend to learn new programming languages, because it will make you a better developer, also in the book "The Pragmatic Programmer" says that you should learn at least one new programming language every year, and I think that's a good advice, because maybe you'll never use that language in your work but you can learn to think different, build different.

When I was using Flutter two years ago, I was so closed to use only Provider because is the most MVC pattern that I know, but then I learned React, with his hooks, and I was amazed by how easy is to use it, and how powerful is to use it, also a really easy to view and control the state, then when i check Riverpod in Flutter is like a mix of both, and I was so happy to learn it, because I can use the best of both worlds.

"The only way to learn a new programming language is by writing programs in it." - Dennis Ritchie

Provider en React con JavaScript

Sazardev — Tue, 10 Sep 2024 21:47:04 +0000

El patrón de comportamiento Provider es un patrón de diseño que se utiliza para proporcionar datos a otros componentes. Donde la idea principal es que un componente padre proporcione datos a sus componentes hijos a traves de un arbol de componentes e inyectar dependencias a los componentes hijos de otros Providers.

Provider es además aquel encargado de crear, almacenar y proporcionar los datos a los componentes hijos, donde la procedencia de esta información puede ser de una API, un archivo JSON, una base de datos, etc. Para un Provider le es indistinto la procedencia de la información, y es algo que no debe importarle, solo debe manejarla y asegurarse de que la información recibida sea la solicitada.

Componentes iniciales

Para la creación de un Provider se requiere plantear su estructura antes de utilizarlo, donde se necesita definir, a que modulo pertenece, con qué información se va a trabajar, y que funciones se van a utilizar para manipular la información. Por ende, necesitamos previamente un servicio que contenga comunicacion con la información, y un modelo que nos permita manipular la información.

Crear un Provider en React con JavaScript

Para crear un Provider escalable, mantenible y reutilizable, se debe seguir una estructura que permita la manipulación de la información de manera eficiente. Para React con JavaScript, es necesario crear alrededor de cinco archivos, donde estos comprenden: Contexto Global, Acciones, Reducer, Provider y Estado Inicial.

Estado Inicial

El Estado Inicial es el encargado de almacenar la información que se va a utilizar en los componentes hijos, y se encarga de proporcionar la información a los componentes hijos. Para crear un Estado Inicial se debe utilizar la siguiente estructura:

GlobalState.js

export const GlobalState = {
  // Informacion inicial
  // Aqui se extrae tambien la informacion local
  usuario: localStorage.getItem("usuario") || "",
};

Contexto Global

El Contexto Global es el encargado de almacenar la información que se va a utilizar en los componentes hijos, y se encarga de proporcionar la información a los componentes hijos. Para crear un Contexto Global se debe utilizar la siguiente estructura:

GlobalContext.js

import React, { createContext, useReducer } from "react";

const GlobalContext = createContext({
  state: GlobalState,
  dispatch: () => {},
  // Funciones extras
});

Acciones

Las Acciones son las funciones que se encargan de manipular la información del Estado Inicial, donde estas funciones se encargan de modificar la información del Estado Inicial. Para crear Acciones se debe utilizar la siguiente estructura:

GlobalActions.js

export const setUsuario = (dispatch, usuario) =>
  dispatch({ type: "SET_USUARIO", payload: usuario });

export const clearUsuario = (dispatch) => dispatch({ type: "CLEAR_USUARIO" });

Reducer

El Reducer es el encargado de modificar la información del Estado Inicial, donde este se encarga de recibir las Acciones y modificar la información del Estado Inicial. Para crear un Reducer se debe utilizar la siguiente estructura:

GlobalReducer.js

export const GlobalReducer = (state, action) => {
  switch (action.type) {
    case "SET_USUARIO":
      return { ...state, usuario: action.payload };
    case "CLEAR_USUARIO":
      return { ...state, usuario: "" };

    default:
      return state;
  }
};

Provider

El Provider es el encargado de proporcionar la información a los componentes hijos, donde este se encarga de almacenar la información del Estado Inicial y proporcionarla a los componentes hijos. Para crear un Provider se debe utilizar la siguiente estructura:

GlobalProvider.jsx

export const GlobalProvider = ({ children }) => {
  const [state, dispatch] = useReducer(GlobalReducer, GlobalState);

  return (
    <GlobalContext.Provider value={{ state, dispatch }}>
      {children}
    </GlobalContext.Provider>
  );
};

Colocación del Provider

Para que el Provider pueda ser utilizado en los componentes hijos, se debe colocar en donde es requerido, aunque sea tentador colocarlo en el componente raíz, no es recomendable, ya que puede causar problemas de rendimiento. Para colocar el Provider se debe plantear correctamente el alcance que deseas que tenga este Provider, así que antes de colocarlo, plantea si es necesario que TODOS los componentes van a requerir accesar a la información del Provider o solamente es un módulo aislado que solo requiere lo necesario para sí mismo.

App.js

import { GlobalProvider } from "./GlobalProvider";

function App() {
  return (
    <GlobalProvider>
      <Componente />
    </GlobalProvider>
  );
}

Consumir el Provider

Para consumir el Provider en los componentes hijos, se debe utilizar el Hook useContext que proporciona React. Para consumir el Provider se debe utilizar la siguiente estructura:

Componente.jsx

import { useContext } from "react";
import { GlobalContext } from "./GlobalContext";

const Componente = () => {
  const { state, dispatch } = useContext(GlobalContext);

  return (
    <div>
      <h1>{state.usuario}</h1>
    </div>
  );
};

Funciones personalizadas

A veces es necesario crear funciones personalizadas que no estén relacionadas con el Estado Inicial, para esto se puede agregar funciones extras al Contexto Global. Para agregar funciones extras al Contexto Global se debe utilizar la siguiente estructura:

GlobalContext.js

import React, { createContext, useReducer } from "react";

const GlobalContext = createContext({
  state: GlobalState,
  dispatch: () => {},
  // Funciones extras
  logoutAndRedirect: () => {},
});

GlobalProvider.jsx

export const GlobalProvider = ({ children }) => {
  const navigate = useNavigate();
  const [state, dispatch] = useReducer(GlobalReducer, GlobalState);

  const logoutAndRedirect = () => {
    dispatch({ type: "CLEAR_USUARIO" });
    navigate("/");
  };

  return (
    <GlobalContext.Provider value={{ state, dispatch, logoutAndRedirect }}>
      {children}
    </GlobalContext.Provider>
  );
};

Recomiendo altamente utilizar las funciones personalizadas cuando se requiere trabajar con el estado del Provider e involucra otros procesos o gestionamiento de muchos cambios en el estado. Esto con el fin de reducir la cantidad de codigo que puede llegar a involucrarse en el lado de la Vista, y mantener un orden en la estructura del Provider, promoviendo asi la reutilizacion de codigo y la escalabilidad del mismo.

How to setup a service in a SSH Server

Sazardev — Thu, 18 Jul 2024 19:56:16 +0000

You get a connection with ssh, and then you run your project or a command. You are innocent and just close the terminal assuming that your command will run forever in the SSH Server. If this was your case (Or you're just curios) let me help you to do a real Service in Linux for your SSH Server.

First of all we need to go to /etc in your SSH Server. So, if you are already logged in just put in the terminal:

cd /etc

/etc is where we have our system configuration files, it's like our nerve center of our system, so be careful of what you are touching here please. Also, that is why we are putting a service file right here. Let's dive into:

cd system/system

And here is where we create a new file called: [name of your service].service, in my case will be named deploy-frontend.service. So, in the terminal you will need to add:

vim deploy-frontend.service

And now we have a new file service! That is great but not all. Let me explain to you the syntax of the new file.

[Unit]
# Here we describe our service
Description=Serve run for frontend

[Service]
# Here we are going to detail the actions of our service
ExecStart={path_of_the_command} -s /home/dev/app/dist -l 5000
Restart=always
User={your_username}

[Install]
# And here we define what users had this service

And in my case my service looks like this:

[Unit]
Description=Serve run for frontend

[Service]
ExecStart=/usr/bin/serve -s /home/dev/app/dist -l 5000
Restart=always
User=dev

[Install]
WantedBy=multi-user.target

How to structure your files with VIPER Architecture

Sazardev — Tue, 16 Jul 2024 23:39:48 +0000

Maybe you already had the theory of how VIPER Architecture work but that's only the THEORY, in the real work can be painful implement a Software Architecture because you can have a lot of cases that you can't know how to implement correctly accordly VIPER Architecture (But this can happen when whatever Architecture).

I'll explain you how to implement correctly VIPER with a common cases, but if you have an especific scenario you can comment to discuss how VIPER can solvent correctly.

PhonebookApp (iOS)

A classic one. Let's supouse that you need to do a simple Phonebok application where stores contact.

PhonebookApp # Root directory of the application

├── Common # Shared code between features
│   ├── Models # Data models representing entities
│       ├── Contact.swift # Represents a single contact with its information
│       └── ContactGroup.swift # Represents a group of contacts
│   ├── Utils # Utility classes for common functionalities
│       ├── NetworkManager.swift # Handles communication with network services
│       └── StorageManager.swift # Handles data persistence and retrieval
│   └── ViewModels # View models for data presentation
│       ├── ContactDetailViewModel.swift # Prepares data for the contact detail view
│       ├── ContactGroupListViewModel.swift # Prepares data for the contact group list view
│       └── ContactListViewModel.swift # Prepares data for the contact list view
├── Features # Individual features of the application # Feature for managing a single contact
    ├── ContactDetail
        ├── Views # UI components for displaying the contact
        │   └── ContactDetailView.swift # Xcode Storyboard or SwiftUI view for contact details
        ├── Interactors # Business logic for contact data
        │   └── ContactDetailInteractor.swift # Fetches, updates, and deletes contact data
        ├── Presenters # Prepares data for the contact detail view
        │   └── ContactDetailPresenter.swift # Receives data from interactor and formats it for view
        └── Routers # Navigation logic for the contact detail screen
            └── ContactDetailRouter.swift # Handles navigation to other features from contact detail # Feature for managing contact groups
    ├── ContactGroupList
        ├── Views # UI components for displaying contact groups
        │   └── ContactGroupListView.swift # Xcode Storyboard or SwiftUI view for contact group list
        ├── Interactors # Business logic for contact group data
        │   └── ContactGroupListInteractor.swift # Fetches, updates, and manages contact groups
        ├── Presenters # Prepares data for the contact group list view
        │   └── ContactGroupListPresenter.swift # Receives data from interactor and formats it for view
        └── Routers # Navigation logic for the contact group list screen
            └── ContactGroupListRouter.swift # Handles navigation to other features from contact group list # Feature for managing the list of contacts
    └── ContactList
        ├── Views # UI components for displaying contacts
        │   └── ContactListView.swift # Xcode Storyboard or SwiftUI view for contact list
        ├── Interactors # Business logic for contact data
        │   └── ContactListInteractor.swift # Fetches, updates, and manages contacts
        ├── Presenters # Prepares data for the contact list view
        │   └── ContactListPresenter.swift # Receives data from interactor and formats it for view
        └── Routers # Navigation logic for the contact list screen
            └── ContactListRouter.swift # Handles navigation to other features from contact list
├── App # Entry point and core application logic
│   ├── AppDelegate.swift # Manages the application lifecycle
│   ├── SceneDelegate.swift # Manages window scene lifecycle and transitions on iOS 13+
│   └── MainCoordinator.swift # Coordinates navigation between features
├── Tests # Unit tests for application components
│   ├── CommonTests # Tests for shared code
│       ├── ModelsTests.swift # Unit tests for `Contact` and `ContactGroup` models
│       └── UtilsTests.swift # Unit tests for `NetworkManager` and `StorageManager`
│   ├── FeaturesTests # Tests for individual features
│       ├── ContactDetailTests.swift # Unit tests for contact detail functionality
│       ├── ContactGroupListTests.swift # Unit tests for contact group list functionality
│       └── ContactListTests.swift # Unit tests for contact list functionality
│   └── AppTests # Tests for application entry point
│       └── AppDelegateTests.swift # Unit tests for `AppDelegate`
└── Resources # Assets and configuration files
    ├── Images.xcassets # App icons and other images
    ├── LaunchScreen.storyboard # Storyboard for the launch screen
    └── Info.plist # Configuration file for the application

Shop App (Android)

ShopApp
├── app
│   ├── build.gradle
│   ├── src
│       ├── main
│           ├── AndroidManifest.xml
│           ├── assets
│           │   └── ... # app assets like images
│           ├── java
│               └── com.yourcompany.shop
│                   ├── data
│                       ├── model
│                           ├── Product.java # Represents a product with details
│                           └── ProductCategory.java # Represents a product category
│                   ├── network
│                       └── ApiManager.java # Handles network communication
│                   ├── persistence
│                       └── LocalStorage.java # Handles data persistence on device
│                   ├── repository
│                       └── ProductRepository.java # Provides access to product data
│                   ├── features
│                       ├── productdetail  # Feature for managing a single product detail
│                       │   ├── contract
│                       │   │   ├── ProductDetailContract.kt # Interface for VIPER communication
│                       │   │       ├── ProductDetailView.kt # Interface for View
│                       │   │       ├── ProductDetailInteractor.kt # Interface for Interactor
│                       │   │       ├── ProductDetailPresenter.kt # Interface for Presenter
│                       │   │       └── ProductDetailRouter.kt # Interface for Router
│                       │   ├── data
│                       │   │   └── ProductDetailRepositoryImpl.kt # Implementation of ProductRepository for product detail
│                       │   ├── presentation
│                       │   │   ├── ProductDetailPresenterImpl.kt # Implementation of ProductDetailPresenter
│                       │   ├── ui
│                       │   │   └── ProductDetailActivity.kt # Activity for displaying product details
│                       │   └── ... (other implementation classes)
│                       ├── productlist  # Feature for managing the product list
│                       │   ├── contract
│                       │   │   ├── ProductListContract.kt # Interface for VIPER communication
│                       │   │       ├── ProductListView.kt # Interface for View
│                       │   │       ├── ProductListInteractor.kt # Interface for Interactor
│                       │   │       ├── ProductListPresenter.kt # Interface for Presenter
│                       │   │       └── ProductListRouter.kt # Interface for Router
│                       │   ├── data
│                       │   │   └── ProductListRepositoryImpl.kt # Implementation of ProductRepository for product list
│                       │   ├── presentation
│                       │   │   ├── ProductListPresenterImpl.kt # Implementation of ProductListPresenter
│                       │   ├── ui
│                       │   │   └── ProductListActivity.kt # Activity for displaying product list
│                       │   └── ...
│                   ├── ...
│                   └── util
│                       └── ... # Utility classes
│   └── gradle.properties
│   └── gradlew.bat  # or gradlew (depending on OS)
├── build.gradle
├── gradle.properties
└── local.properties # Optional for local development configuration

VIPER Architecture

Sazardev — Mon, 15 Jul 2024 15:59:20 +0000

¿You're getting struggle writing your code for Mobile Applications? Let me present you with the VIPER Architecture, and why this is the BEST for mobile development.

V -> View
I -> Interactor
P -> Presenter
E -> Entity
R -> Router

View

The view layer handles everything related to what the user sees on his screen. This must be something like the Screen or the componentes in your application.

Interactor

Here is where you got the bussines logic of your application. Acts like a mediator between the controller of the screens that see our users and the data from an API, Database. But what is bussines logic? Here is EVERIYTHING related from the usability of our applications, this includes Data Transformation, Data Handling, Session Handling, and a large etc.

Just keep in mind that in the interactor you will put everything that includes an ACTION from the user, and you need to do the logic to correctly present the expected response to the user.

Presenter

We already got the bussines logic from the Interactor, so, what's Presenter? The presenter also has bussines logic, but he is the MEDIATOR between the View and Interactor, this was explained in the Interactor, but this layer is the responsibly to communicate with the UI. The classic flow from the Presenter is something like:

(View) User tap to "Posts" screen
(Presenter) Receive the action and start charging the loading component to the View, also start requesting to the Interactor for the data requested.
(Interactor) Talk to the data source and send it back to the Presenter.
(Presenter) Receive and clean the data and send it to the View
(View) The user is happy to see Karen posts.

Entity

Entities are the data models that stand for the application bussines object, can be something like User, Post, Comments. Here is where we represent the object data that will be used for every process in our VIPER Architecture. Also, it is important to keep in mind to not do anything too robust and too flexible, Entity is the core of our app, but like everything, our core needs to be adaptative to every situation.

Router

For some people this is not the most important, but for the user is MUST HAVE because they want a really powerful system of navigation, they want to have a powerful share and they friend go to the exact path they share, in mobile is a MUST you can't ignore this layer because you need to have to give an excellent experience.

But well, too much presentation, but what do the Router Layer? The router manages navigation between screens or modules, also manages the presentation and dismissing views or errors in the view, also this layer protects routes if is required (Like auth session), check the parameters routers. And most important, this is the most decoupled layer but the most responsable for the other layers.

Conclusion

And that is everything about VIPER Architecture, in personal I LOVE this architecture because I am and Flutter/Android developer, if you are a mobile developer consider using this Architecture above the Clean Architecture because is most simple, intuitive, and adaptable for the most Mobile Development cases.

Hope you enjoy reading and learn something new, please tell me what do you think about this architecture and why you will use it or not use it.

Thanks for reading!