DEV Community: Jorge Arraga

✨ Introducing data2ui | turn any JSON into a clear, navigable UI

Jorge Arraga — Sun, 30 Nov 2025 15:55:58 +0000

data2ui is a small tool that lets you paste or load any JSON and immediately explore it through a clean UI. No setup, no accounts required. Just open the app, drop your data, and browse it in a way that’s easier than scrolling through raw text.

You can use it entirely locally in your browser, or switch to the cloud version if you want to keep your files online and share them with your team in read-only mode.

The project is built and maintained by one developer, and new features are already on the way:

📁 Folder support
🧩 New UI components
🔌 A full REST API to manipulate files
📴 Offline support
…and many more enhancements already in progress

If your JSON changes as you work, data2ui lets you see how the structure evolves in real time. And if you’re collaborating, you can just send someone a share link and they’ll see exactly what you see.

https://data2ui.jarraga.dev

Try it in VS Code — you’ll love it!

Thanks for testing the app and giving it a try. Feedback is always welcome.

env-literal [node.js]

Jorge Arraga — Mon, 11 Oct 2021 21:45:46 +0000

This package iterates the variables of the process.env object, and parses them as if it were a literal javascript string, and injects them back into the same object

For example:

BASE_URL=http://localhost:3000
API=${BASE_URL}/api

In this case, the API variable will have the value http://localhost:3000/api

Unlike dotenv or dotenv-expand, variables are read directly from the system environment and not from an .env file

Usage: as soon as possible, run the function:

const envLiteral = require("@jarraga/env-literal");

if (process.env.NODE_ENV === "production") {
  envLiteral(); // call envLiteral(true) for debugging
}

Link to NPM

DOM 3D view | Edge devTools

Jorge Arraga — Fri, 23 Apr 2021 21:24:27 +0000

I discovered this functionality a couple of days ago and wanted to share it here

To test it, enter a page or the same page that you are reading with Microsoft Edge, then open the console with F12, go to the three points > More tools > 3D view

You can view the position of a particular element, or the entire DOM

It can also be accessed by clicking the icon next to the z-index property in the styles section of devTools

Let you the official docs:

Microsoft docs

Prevent app crash Node JS

Jorge Arraga — Fri, 16 Apr 2021 00:42:54 +0000

There are two main reasons why our node application crashes, uncaught exceptions, and unhandled rejections

While the correct way to fix this problem would be to handle all these exceptions and rejections, sometimes our application crashes due to a error in one part of the code, and this causes the entire app flow to not be able to continue

I show you how to prevent this behavior

The trick is add two listeners in the top of app, for the unhandled exceptions and rejections, this way:

process.on('uncaughtException', (error, origin) => {
    console.log('----- Uncaught exception -----')
    console.log(error)
    console.log('----- Exception origin -----')
    console.log(origin)
})

process.on('unhandledRejection', (reason, promise) => {
    console.log('----- Unhandled Rejection at -----')
    console.log(promise)
    console.log('----- Reason -----')
    console.log(reason)
})

To demonstrate that works, I add a setInterval function next to the listeners

setInterval(() => {
    console.log('app still running')
}, 1000)

And to make app crash, I call a function that doesn't exists

nonExistingFunction()

As we can see, the uncaughtException runs, and app continues its execution

----- Uncaught exception -----
ReferenceError: nonExistingFunction is not defined
    at Object.<anonymous> (C:\Users\Jorge\Desktop\test\t.js:19:1)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47
----- Exception origin -----
uncaughtException
app still running
app still running
app still running

I let you official node JS documentation:

Uncaught exception

Warning: Using 'uncaughtException' correctly

Unhandled rejection

Multiple fetches + params

Jorge Arraga — Wed, 10 Mar 2021 19:02:02 +0000

Suppose we need get data from multiple endpoints and proccess all toghether when all requests are finished.
Together with the request we need to pass other parameters to identify them or do something else.

In order to make a requests adding parameters, we'll create our own function that will contain the fetch.

const ownFetch = async (url, params) => {

    const res = await fetch(url)
    const data = await res.json()

    return { data, params }
}

Now we can create an empty array of requests (promises), I'll use jsonplaceholder to get fake info and test code.
Suppose we want to take somethings todos, and each todo has its respective id and thus its own endpoint.

let requests = []
let todos = [1, 3, 5, 10]

todos.forEach((id, i) => {
    requests.push(ownFetch(`https://jsonplaceholder.typicode.com/todos/${id}`, `Request #${i+1}`))
})

The final step is to run all the requests through the Promise.all() function and get results:

const run = async () => {
    const results = await Promise.all(requests)
    results.forEach(result => {
        console.log(result)
    })
}

The result:

{
    data: {
        userId: 1,
        id: 1,
        title: 'delectus aut autem',
        completed: false
    },
    params: 'Request #0'
}
{
    data: {
        userId: 1,
        id: 3,
        title: 'fugiat veniam minus',
        completed: false
    },
    params: 'Request #1'
}
{
    data: {
        userId: 1,
        id: 5,
        title: 'laboriosam mollitia...',
        completed: false
    },
    params: 'Request #2'
}
{
    data: {
        userId: 1,
        id: 10,
        title: 'illo est ratione...',
        completed: true
    },
    params: 'Request #3'
}

You can use Promise.allSettled() instead of Promise.all(), the differences is explained by Victor in this post:

🤝 Promise.allSettled() VS Promise.all() in JavaScript 🍭

Victor de la Fouchardière ・ Aug 16 '20

#javascript #node #webdev #beginners

I leave you the complete code:

const ownFetch = async (url, params) => {
    const res = await fetch(url)
    const data = await res.json()
    return { data, params }
}

let requests = []
let todos = [1, 3, 5, 10]

todos.forEach((id, i) => {
    requests.push(ownFetch(`https://jsonplaceholder.typicode.com/todos/${id}`, `Request #${i}`))
})

const run = async () => {
    const results = await Promise.all(requests)
    results.forEach(result => {
        console.log(result)
    })
}

run()

👋🏽

Vite.js + Vue 3 + router + vuex + tailwindcss template

Jorge Arraga — Sun, 07 Mar 2021 17:23:01 +0000

Github CLI usage

If you don't use github CLI to manage yours repositories I recommend that you do it. Install here

gh auth login

Then you can create a repo using this code as a template, the command will create your repo directory.

gh repo create <ownRepoName> --private --template jarraga/vite-vue3-template

? This will create the "<ownRepoName>" repository on Github, Continue? (Y/n) -> YES

? Create a local project directory for "<ownRepoName>"? (Y/n) -> YES

Ok, you have new repository created on Github and local files to start coding.
Let's install dependencies and run dev server.

cd <ownRepoName>
npm i
npm run dev

And that's it, open folder with your code editor and start make changes.

Recomended plugins if you're using visual studio code:

vetur

tailwind

Thing to keep in mind for tailwindcss

If you want to make components using dynamic tailwind classes, you have to literal write the entire classes in an object and acces to it, instead of use something like bg-${color}-300
Simon explain this in detail in this video:

https://youtu.be/HZn2LtBT59w?t=509

I hope you find it useful! 👋🏽

Mercadopago | Checkout PRO (postman, no library)

Jorge Arraga — Wed, 17 Feb 2021 15:01:02 +0000

Hace unos días tuve la oportunidad de certificarme como Certified Developer para la integración del checkout pro, muy buen producto de mercadopago.

En este post quiero dejarles el paso a paso para probar el funcionamiento de la API ya que, a pesar de la documentación y los ejemplos, hay cosas que no quedan del todo claras.

Para realizar este proyecto no vamos a utilizar ninguna librería externa o tecnología en particular, sino que vamos a hacer las consultas HTTP utilizando postman, y luego podremos exportarlas en formato de código.

Para quienes no conocen postman es una herramienta que permite crear solicitudes HTTP con todos los datos necesarios, utilizar diferentes entornos, y que luego se pueden exportar a una variedad de códigos para usar en los desarrollos.
A continuación les dejo un link a la colección de requests pública que cree para este ejercicio, y explico cómo usarla para que todo funcione correctamente.

Postman

Postman collection

Con el enlace anterior podemos bajar el json de una colección de Postman, vamos a utilizar dos secciones para hacer las pruebas.

Environments

Variables de entorno. Utilizaremos 3 tipos:

Globals: variables que están siempre disponibles, como por ejemplo la url base que es 'https://api.mercadopago.com'
DEV_ENVIRONMENT: variables para realizar pruebas con dinero ficticio.
PROD_ENVIRONMENT: variables para realizar operaciones en producción con dinero real.

Es mandatorio que seleccionemos el entorno correspondiente en cada consulta, de lo contrario las solicitudes no van a funcionar.

Para utilizar estas variables, podemos escribirlas donde queramos con la sintaxis {{variable}}

Collections

Colección de solicitudes GET, POST, que vamos a necesitar para ir probando la integración. Estas ya están preparadas con las variables de entorno, por lo que luego de configurarlas ya se las puede ejecutar.

Pueden observar en cada una de las peticiones los valores de url, headers, body.

Exportar código

La parte más útil de esto, es que cambiando las variables de entorno y seleccionando el entorno adecuado, puedan hacer sus propias pruebas y también exportar las consultas al lenguaje con el que trabajen.
Para esto, deben presionar el botón </> que se encuentra en la barra lateral derecha, seleccionar el lenguaje y copiar el código.

En este ejemplo se puede ver el código generado para utilizar fetch en javascript para el navegador, lo cual no podríamos hacer porque este código debe ser ejecutado del lado del servidor, pero yo utilizo node.js y la librería node-fetch con lo cual el código es muy parecido.

Documentación oficial

A lo largo del tutorial voy a ir dejando los links a la documentación oficial.

Integración checkout pro

Referencia a la API

En la referencia a la API, los ejemplos de consulta estan escritos en cURL, les dejo una web app que parsea cURL a fetch, para poder copiar mejor los datos si quieren agregar consultas a postman luego.

Web app para parsear peticiones cURL a feth

Comencemos

En este proceso vamos a utilizar 3 cuentas diferentes de mercadopago, por lo que debemos tener en claro cual estamos usando en cada momento, voy a indicarlo pero hay que prestar especial atención.

Las 3 cuentas son las siguiente:

Cuenta REAL: es nuestra propia cuenta de MP, donde vamos a recibir los pagos una vez que pongamos la aplicación en producción.
Cuenta VENDEDOR, es una cuenta de prueba, de la cual vamos a tomar las credenciales para testear la API.
Cuenta COMPRADOR, es una cuenta de prueba, con la que vamos a estar logueados para efectuar la compra a la cuenta vendedor.

Para utilizar los diferentes usuarios podemos tener varios navegadores como chrome, edge, firefox, o utilizar los modos incógnitos, de manera de no tener que entrar y salir de las cuentas constantemente.

1 Crear usuarios de prueba

Lo primero que tenemos que hacer es crear el usuario VENDEDOR y COMPRADOR.
Para esto, debemos acceder a las credenciales de nuestra cuenta REAL.
En todas las cuentas vamos a encontrar que tenemos dos tipos de credenciales, de PRUEBA y de PRODUCCIÓN.

Vamos a ingresar a las credenciales de PRUEBA de la cuenta REAL, y tomar el valor de Access Token.
Para esto, debemos estar logueados con nuestro usuario real a la hora de ir al siguiente enlace:

Credenciales usuario REAL

En postman, asignamos este string a la variable de entorno devAccessToken en la sección Globals

Con esto ya podemos crear los usuarios de prueba ejecutando la solicitud "Generar usuarios de prueba" en la lista de la colección, vamos a obtener un resultado como este:

Debemos ejecutar la consulta dos veces para obtener el usuario VENDEDOR y COMPRADOR.
Anotamos bien los datos en algún lugar ya que no lo podremos consultar luego.
Mercadopago permite crear hasta 10 usuarios de prueba, y estos caducan después de 60 días de inactividad.
Cualquiera de los 2 usuarios creados puede ser el vendedor o comprador, lo importante es que ambas partes sean de prueba.

2 Obtener credenciales del usuario VENDEDOR

Para continuar vamos a tomar las credenciales de PRODUCCIÓN del usuario VENDEDOR.
Para esto, debemos loguearnos con el usuario de prueba que hayamos elegido como vendedor, podemos hacerlo en otro explorador, o en una pestaña de incógnito (para no desloguearnos con nuestro usuario real)

Credenciales usuario VENDEDOR

Siguiendo el link anterior, podrán acceder a las credenciales de producción, tomamos el valor de Access Token y lo asignamos a la variable de entorno accessToken en DEV_ENVIRONMENT

Ya podemos probar la API ejecutando la consulta "Tipos de documento" del listado en postman, seleccionando primero como entorno DEV_ENVIRONMENT y ver el resultado.

3 Crear una preferencia de pago

Una preferencia de pago es un documento en formato JSON que representa todas las partes de una operación, como ser datos del comprador, vendedor, ítems, cantidades, precios, urls de estado, etc.

Si bien se puede crear una preferencia con unos pocos campos obligatorios, es mejor proveer la mayor información posible en este paso, ya que mercadopago tiene un motor antifraude, el cual realiza comprobaciones internas cruzando algunos de los datos que le brindamos.

Preferencia completa

Veamos un ejemplo de preferencia y analicemos los campos:

{
    "items": [
        {
            "id": "1234",
            "title": "Smartphone",
            "currency_id": "ARS",
            "picture_url": "pics.com/sf.jpg",
            "description": "Dispositivo móvil",
            "category_id": "art",
            "quantity": 1,
            "unit_price": 30000
        }
    ],
    "payer": {
        "name": "Ricardo",
        "surname": "Alvarez",
        "email": "ralvarez@email.com",
        "phone": {
            "area_code": "11",
            "number": "22223333"
        },
        "identification": {
            "type": "DNI",
            "number": "12345678"
        },
        "address": {
            "street_name": "Calle",
            "street_number": 123,
            "zip_code": "1111"
        }
    },
    "back_urls": {
        "success": "myapp.com/success",
        "failure": "myapp.com/failure",
        "pending": "myapp.com/pending"
    },
    "auto_return": "approved",
    "payment_methods": {
        "excluded_payment_methods": [
            {
                "id": "amex"
            }
        ],
        "excluded_payment_types": [
            {
                "id": "atm"
            }
        ],
        "installments": 6
    },
    "notification_url": "myapp.com/webhook",
    "statement_descriptor": "Tienda eCommerce",
    "external_reference": "mlplesoj9b"
}

Veamos las partes:

items: array de productos en nuestro carro de compras.
payer: información del pagador, si tienen registrado al usuario en su sitio seguramente tengan ya algunos datos para completar.
back_urls: muy importante, urls a las que será redirigido tu usuario luego de haber completado una operación (sin cerrar el checkout) cualquiera sea el resultado, "success" si el pago fue aprobado, "failure" si rechazado, y "pending" si se utiliza medios de pagos físicos u otro que requiera una comprobación luego.
auto_return: si se deja en approved, el usuario es redirigido automáticamente al sitio de success que figura en las back_urls luego de 5 segundos (sin necesidad de que presione ningún botón). También puede tener el valor all, para que cualquiera sea el resultado se redirija automáticamente.
payment_methods: configuración de métodos de pago, se pueden excluir tipos y medios, y configurar la cantidad de cuotas para las tarjetas de crédito (installments). Para ver la información sobre los métodos de pago se puede ejecutar la consulta "Metodos de pago" en la colección de postman.
notification_url (webhook): muy importante, url a la que mercadopago hará una POST request informándonos de la creación o actualización de un pago, es necesario que tomemos estos datos, más abajo veremos cómo.
statement_descriptor: texto que aparecerá en el resumen de tarjeta de tu comprador.
external_reference: string interno de tu aplicación para corroborar la operación con información de tu base de datos.

Una vez completado nuestro JSON para crear la preferencia, podemos ejecutar la consulta "Crear preferencia" de postman (el ejemplo anterior se encuentra en el body de dicha solicitud)

Obtendremos como resultado un JSON bastante extenso, del cual vamos a utilizar la propiedad init_point, que es la url a la cual deberemos dirigir a nuestro usuario.
Se ve como este ejemplo:

"init_point": "https://www.mercadopago.com.ar/checkout/v1/redirect?pref_id=716087195-bcec52a0-1cae-4650-aa12-ae316f2f2674"

4 Iniciar flujo de pago

Una vez que hayamos obtenido nuestra url para comenzar el flujo de pago, deberemos redirigir a nuestro usuario a esta.

Para probar el flujo, debemos iniciar sesión con los datos de nuestro usuario de prueba COMPRADOR, y acceder al link.
Si por error accedemos al link con nuestro usuario REAL, o VENDEDOR, podemos obtener estos errores respectivamente:

Accediendo al link con nuestro usuario COMPRADOR entonces, veremos la siguiente pantalla:

Si elegimos pagar con efectivo, el resultado de la operación siempre será "pending".

Para probar los resultados "success" y "failure", podemos usar los datos de unas tarjetas de prueba que MP dispone para tal fin. Estas son las tarjetas:

Tarjetas de prueba

Como pueden observar dependiendo del "nombre" que completen, será el resultado y la razón de la operación.
En los campos de código de seguridad y DNI podemos poner cualquier número.

Por ejemplo, usando la Visa 4509 9535 6623 3704 y el nombre APRO, obtenemos como resultado un pago aprobado, y la redirección automática en 5 segundos:

O si ponemos por ejemplo FUND, nos rechaza por falta de fondos, y no redirige a menos que hagamos clic en "volver al sitio" o hayamos configurado auto_return: all:

Si vamos a la página principal de los usuarios VENDEDOR y COMPRADOR veremos sus respectivas actividades:

A continuación veremos como utilizar las back_urls

5 Hacer uso de las back_urls

Si nuestro usuario finaliza el flujo del checkout pro, es decir, si no cierra la página o pestaña antes de que termine, dependiendo del valor que hayamos pasado en la propiedad auto_return de la preferencia, sera redirigido automaticamente a la back_url que corresponda en base al resultado de la operación, o, al hacer clic en el botón "Volver al sitio".

Cualquiera sea el caso debemos redirigir al usuario a la dirección que corresponda y capturar los parámetros que mercadopago nos pasa en el query string de la url.
Tiene este formato:

https://myapp.com/?merchant_order_id=2334717960&merchant_account_id=null&processing_mode=aggregator&status=approved&collection_status=approved&payment_id=13710864554&payment_type=credit_card&site_id=MLA&external_reference=mlplesoj9b&collection_id=13710864554&preference_id=716087195-e9128a3b-f93e-40eb-8326-048cebbb1b1f

Podemos usar la herramienta query string splitter para parsear los parámetros de esta url, obteniendo los siguientes datos:

merchant_order_id: 2334717960
merchant_account_id: null
processing_mode: aggregator
status: approved
collection_status: approved
payment_id: 13710864554
payment_type: credit_card
site_id: MLA
external_reference: mlplesoj9b
collection_id: 13710864554
preference_id: 716087195-e9128a3b-f93e-40eb-8326-048cebbb1b1f

Con el valor de payment_id podremos consultar el estado del pago mediante la API, completando el valor paymentId en "DEV_ENVIRONMENT" y ejecutando la request "Consultar pago" de la colección de postman.
Obtendremos un JSON con toda la información del pago.
Los campos importantes a mirar acá son status y status_detail, si tienen los valores "approved" y "accredited" respectivamente, tenemos la seguridad de que el dinero ya se encuentra en nuestra cuenta.

{
    "status": "approved",
    "status_detail": "accredited"
}

En caso de que un pago pendiente veremos:

{
    "status": "pending",
    "status_detail": "pending_waiting_payment"
}

En caso de un pago rechazado por fondos por ejemplo veremos:

{
    "status": "rejected",
    "status_detail": "cc_rejected_insufficient_amount"
}

Ahora vamos a ver cómo obtener información de las operaciones sin depender de que el usuario vuelva a nuestro sitio o tener que consultar el payment desde los parámetros de las back urls.

6 Crear endpoint para el webhook o url de notificación

Cuando un pago se crea o actualiza, mercadopago hace un POST request a la dirección que hayamos configurado en la propiedad notification_url de nuestra preferencia.
Para informar a mercadopago que hemos recibido correctamente la información, debemos responderle con un STATUS 200 o 201 desde nuestro servidor.

En caso de que aún no hayamos creado el código para ejecutar del lado del servidor, podemos usar una herramienta muy útil para capturar estas solicitudes.
Se trata de Hookbin, esta web app nos permite crear una url a la que podemos apuntar, y se encarga de capturar todas las peticiones.
Ingresamos y presionamos "Create new endpoint"

Hookbin

Una vez generada nuestra nueva url, vamos a usarla para recibir el webhook.
Cambiemos la variable de entorno webHook en "DEV_ENVIRONMENT" por la url de hookin, y ejecutemos la request "Crear preferencia", no olvidemos de chequear que este seleccionado el entorno correcto.

Con esto obtendremos una nueva preferencia de pago, que tendrá como url de notificación la dirección de hookbin que le pasamos, y obtendremos el nuevo init_point para hacer nuestra prueba.

Accedemos al init_point con nuestro usuario COMPRADOR, y realizamos el proceso.
En este caso voy a mostrar una operación aprobada o "success".
Para ver la información recibida, nos vamos a la pestaña de hookbin y le damos actualizar o F5.
Podemos ver que hay un par de solicitudes recibidas, nos interesa la que tiene la propiedad "action": "payment.created", lo que la identifica como la creación de un pago, veremos que en el body trae algunos valores:

De estos datos es importante que tomemos el valor de id, pero dentro del objeto data

{
   "data":{
       "id": 13711992133
   }
}

Con este id podremos consultar el estado del pago cambiando la variable de entorno paymentId y ejecutando "Consultar pago" como habíamos hecho anteriormente.
Si se trata de un pago en efectivo, podemos guardar este id en nuestra base de datos para consultarlo luego.

Si al consultar un pago nos encontramos con que esta pendiente, y el usuario realiza el pago luego (por ejemplo en pagofacil o rapipago), recibiremos otro hook con un action distinto "action": "payment.updated", lo que significa que la información del pago se actualizo, y podemos consultar nuevamente para ver si se aprobó o cual es su estado.

Recuerden que en la creación de la preferencia siempre podemos pasar un valor en external_reference para corroborar la operación con nuestra base de datos.

Documentación webhooks

7 Pasar a producción

Una vez realizadas todas estas pruebas con éxito podemos efectuar los pasos para pasar a producción.

Lo primero que debemos hacer es loguearnos con nuestro usuario REAL, y tomar el Acces Token de las credenciales de PRODUCCIÓN.
Mercadopago puede pedir algunas cosas adicionales al intentar activar las credenciales de producción, como verificación de DNI por ejemplo, solo seguir los pasos.
Colocamos este valor en la variable de entorno accessToken, pero esta vez en el entorno "PROD_ENVIRONMENT"

Credenciales producción

Una vez tengamos la dirección que finalmente vamos a usar para obtener los hooks deberemos asignarla a la variable de entorno webHook del "PROD_ENVIRONMENT".
Si queremos que todas nuestras preferencias tengan la misma url de notificación o webhook, podemos configurarlos y excluir la propiedad notificaion_url de la preferencia de pago.

Configurar webhook

Eso es todo, ahora podemos crear una referencia de pago utilizando el entorno "PROD_ENVIRONMENT" con un monto bajo, por ejemplo ARS 50, y pasarle el init_point a un compañero para que efectúe la compra, luego podemos hacerle la devolución desde la app de MP.

Conclusión

Hemos visto cómo probar la API para recibir pagos, sin embargo hay muchas otas funcionalidades que mercadopago ofrece y están todas asentadas en la documentación de la API, es cuestion de agregarlas a postman y probar.

Solo queda que pasen las consultas al código que usen para el backend, y subir la app a plataformas como heroku, vercel o su propio servidor.

Espero les sea de utilidad.
Saludos.

Recursos

Lista reproducción de mercadopago | Youtube

Mejora tus pagos

Video demostrativo

Github repo

Estoy acomodando algunos archivos cuando termine subo un repositorio que use para probar con vue y node.js

Local mp3 files to spotify playlist! (own app)

Jorge Arraga — Sun, 14 Feb 2021 15:52:20 +0000

For anxious people like me:

YouTube quick demonstration:
https://youtu.be/zv0ewC9OgdE

Link to app:
https://localtospotify.web.app

Github repository:
https://github.com/jarraga/local-to-spotify

Several years ago I uploaded all my photos taken with digital cameras to google photos, my personal files to the drive, and as a programmer I have my repositories saved in GitHub, it feels good to know that everything is safe in the cloud and available from any device.

But these days I was checking my hard drive and I still have about 35 GB of music in mp3 format, since that was the way to have music before, when we got it from some platforms, you know.

And although I wanted to erase them, I didn't want to lose all those songs that I had to work so hard to get, so I thought about making playlists on Spotify, since almost any song can be found in its catalog.

Seeing that this task would be very tedious, I started to investigate the Spotify API, and then I created this web app developed with Vue for the frontend, and node.js in the backend.

I tell you how it works:

You can select up to 100 mp3 files, the app reads the metadata and generates a table.
The name of the song and the artist can be edited, only the items that have both data will be searched, you can also play the song or copy the file name.

By pressing the search button, the Spotify API is consulted for each song and the most relevant result is displayed.
If no match is obtained, this screen allows you to modify the data and perform an individual search for each item.

Finally, you can choose the name of your new list and press the create button.
You can see the new list in the embedded preview, or on any of your devices with Spotify.

I hope you like it and it will be useful!
👋🏽