Construye un Clon de Postman con Tim Corey

Visión general del curso y propósito

Tim comienza explicando que esta lección trata sobre la configuración de la estructura inicial necesaria para construir un clon de Postman. Él establece claramente que el enfoque no está en hacer solicitudes de API o manejar respuestas JSON aún, sino en crear los proyectos, configurarlos correctamente y tener todo listo para funcionar.

Él explica que este curso está diseñado para ayudar a los usuarios a entender cómo una herramienta del mundo real como Postman podría construirse como una simple aplicación de Windows. Aunque la aplicación final no reemplazará a Postman, demostrará conceptos clave como solicitudes REST, respuestas y diseño de interfaz de usuario. Tim también explica que aunque este proyecto puede inspirar trabajo de portafolio, los usuarios no deben copiarlo directamente. En su lugar, deberían mejorarlo y modificarlo para crear algo único.

Creación de la biblioteca de clases para el clon de Postman

En este punto, Tim abre Visual Studio 2022 y comienza el proceso de configuración. Él explica que está usando la última versión disponible en el momento de la grabación y comienza creando un nuevo proyecto. Para esta lección, elige crear primero la biblioteca de clases.

Tim explica que esta biblioteca de clases eventualmente contendrá código compartido al que la interfaz de usuario hará referencia. Este enfoque ayuda a separar las preocupaciones y mantiene la aplicación organizada. Él también explica que, aunque el orden de creación de proyectos no suele importar, comenzar con la biblioteca le permite demostrar un problema común que los desarrolladores pueden enfrentar durante la configuración.

Él busca una biblioteca de clases C# y enfatiza que debe ser un proyecto moderno de .NET, no el antiguo .NET Framework. Tim selecciona una biblioteca de clases de .NET 8, señalando que versiones más nuevas como .NET 9 o posteriores también pueden funcionar. Él explica que las diferencias entre versiones son una parte normal del desarrollo y que aprender a adaptarse es una habilidad importante.

Nombrando la solución y los proyectos correctamente

Tim dedica tiempo a explicar cómo nombra la solución y los proyectos. Él nombra la solución como la aplicación de clon de Postman y la biblioteca como la biblioteca de clon de Postman. Él explica que incluir la palabra "Biblioteca" hace muy claro qué proyecto contiene la lógica compartida y cuál contiene la interfaz de usuario.

Este enfoque de nomenclatura ayuda al trabajar con referencias más adelante. Tim explica que las referencias siempre deben fluir de la interfaz de usuario a la biblioteca, nunca al revés. Esta decisión de diseño soporta un código más limpio y un mejor proceso de desarrollo a largo plazo.

Él también explica por qué no coloca la solución y el proyecto en el mismo directorio. Dado que esta aplicación contendrá múltiples proyectos, separarlos facilita la navegación y evita la confusión a medida que la solución crece.

Agregando el proyecto de UI de Windows Forms

Una vez que la biblioteca está creada, Tim agrega un segundo proyecto a la solución. Esta vez, selecciona una aplicación de Windows Forms. Él explica que este proyecto servirá como la interfaz de usuario para el clon de Postman y eventualmente permitirá a los usuarios ingresar URLs, parámetros de consulta y ver respuestas.

Él nombra el proyecto UI de clon de Postman y nuevamente confirma que está utilizando .NET 8. Tim menciona brevemente un mensaje relacionado con DPI causado por la escala de pantalla. Él explica que esto no es importante para esta lección y que el manejo de DPI puede explorarse más tarde si es necesario.

En esta etapa, la solución ahora contiene dos proyectos: una biblioteca y una interfaz de usuario de Windows Forms. Esta estructura establece la base para construir una herramienta al estilo Postman en Windows.

Corrigiendo el problema del proyecto de inicio

Tim demuestra un problema que ocurre porque se creó la biblioteca de clases primero. Cuando intenta ejecutar la solución, Visual Studio muestra un error que indica que una biblioteca de clases no puede iniciarse directamente.

Tim explica que este es un problema común de configuración y enfatiza la importancia de leer cuidadosamente los mensajes de error. Él explica que los mensajes de error a menudo te dicen exactamente qué está mal y cómo corregirlo.

Él muestra dos formas de resolver el problema: estableciendo el proyecto de interfaz de usuario como el proyecto de inicio usando el menú contextual, o seleccionándolo del menú desplegable de proyectos de inicio cerca del botón Ejecutar. Una vez hecho esto, la interfaz de usuario de Windows Forms se lanza correctamente.

Agregando el proyecto a Git y GitHub

Con la estructura de solución en su lugar, Tim pasa al control de versiones. Él abre la ventana de cambios de Git y explica que el control de versiones aún no se ha habilitado. Él crea un repositorio de Git directamente desde Visual Studio.

Tim explica el propósito del archivo .gitignore, afirmando que las salidas de compilación como archivos compilados no deben incluirse en el control de versiones. Dado que estos archivos pueden recrearse, no pertenecen a un repositorio de GitHub.

Él también discute la concesión de licencias y explica que elegir no tener licencia significa retener todos los derechos sobre el código. Tim agrega un archivo README y explica lo importante que es para explicar el proyecto, especialmente si se va a compartir o usar como parte de un portafolio.

Tim nombra el repositorio de GitHub, agrega una descripción clara explicando que esta es una recreación de Forms de Windows de Postman, y elige mantener el repositorio privado para que los usuarios se centren en aprender en lugar de copiar código.

Comprendiendo los indicadores de control de versiones

Después de enviar el código a GitHub, Tim explica los iconos de candado que aparecen en el Explorador de soluciones. Estos iconos indican que los archivos están controlados por control de versiones y no han sido modificados.

Él explica cómo cambian estos indicadores cuando se agregan o actualizan archivos, ayudando a los desarrolladores a entender qué cambios serán confirmados. Este feedback visual se vuelve muy útil a medida que el proyecto crece y se agregan más funciones.

Manteniendo Class1 y agregando una referencia

Tim explica por qué el archivo por defecto Class1 se deja en la biblioteca por ahora. Sin al menos una clase, la biblioteca no tendría un espacio de nombres, lo que haría imposible hacer referencia desde la interfaz de usuario.

Él luego agrega la biblioteca como una dependencia del proyecto de interfaz de usuario. Tim demuestra tanto arrastrar la biblioteca en las dependencias de la interfaz de usuario como usar la opción Añadir referencia de proyecto. Este paso permite a la interfaz de usuario acceder al código compartido, lo cual es esencial para construir un clon estructurado de Postman.

Renombrando Form1 a Dashboard

Tim renombra el Form1 por defecto a Dashboard, explicando que este formulario representa la pantalla principal de la aplicación. Cuando este formulario se cierra, la aplicación también se cierra.

Él asegura que todas las referencias se actualicen correctamente, incluyendo el archivo de código detrás y Program.cs. Tim también convierte el espacio de nombres en Program.cs a un espacio de nombres de alcance de archivo, explicando que esto proporciona más espacio y un formato más limpio para futuros cambios.

Ajustando propiedades de la UI y configuraciones de fuente

Tim abre el formulario Dashboard y se enfoca en la ventana de Propiedades. Él explica cómo los desarrolladores pueden reposicionar ventanas dentro de Visual Studio para adaptar su flujo de trabajo.

Él cambia el título del formulario para identificar claramente la aplicación como un clon de Postman y aumenta el tamaño de fuente predeterminado de 9 a 18. Tim explica que ajustar el tamaño de fuente temprano asegura un tamaño consistente para todos los controles futuros agregados a la UI.

Cometiendo la configuración inicial

Con todos los cambios de configuración completos, Tim pone en escena los archivos modificados y crea un commit. Él explica que el mensaje del commit no necesita ser perfecto, pero debe describir claramente los cambios de configuración.

Él confirma y sincroniza el código con GitHub, asegurando que el repositorio esté completamente actualizado y listo para desarrollo continuo.

Preparándose para el siguiente paso en la construcción del clon de Postman

Para concluir el video, Tim explica que la configuración del proyecto ahora está completa. En la próxima lección, el enfoque cambiará a construir la interfaz de usuario y crear una forma sencilla de enviar solicitudes GET a una API y mostrar respuestas.

Él anima a los espectadores a intentar el siguiente paso por su cuenta antes de ver el siguiente video. El objetivo es crear una interfaz simple que pueda enviar solicitudes, recibir datos y mostrar respuestas JSON formateadas. Este enfoque ayuda a los usuarios a comprender mejor el proceso y los prepara para mejorar la aplicación con el tiempo.

Tim cierra recordando a los espectadores que este proyecto está destinado a crecer. Comenzar con una configuración simple permite a los desarrolladores construir confianza, entender el flujo de trabajo y gradualmente convertir el proyecto en una herramienta significativa al estilo Postman.