DEV Community: Natalia Venditto

Lightweight, portable and secure Wasm runtimes and their use cases.

Natalia Venditto — Fri, 15 Dec 2023 14:11:04 +0000

Why is JavaScript so popular?

With 16 million developers estimated, JavaScript is a pretty popular language. We sometimes attribute that to its high-level nature, and the fact that you just need a browser and a text editor, and you can write a small program or a lengthy app, and see the result right away.

The so-called feedback loop is immediate; we can see the results of code execution right away.

There is no need to compile it -or at least you don't need to intervene in the compilation as a developer-. Of course, modern frontend setups and build tools come equipped with transpilation systems, bundling and packaging, and a lot of ahead of time processes like static analysis, but in essence, you can run JavaScript from a text file with a browser only.

JavaScript needs no compilation...but, does it?

For a program written in JavaScript to run, each instruction goes through the following JIT (just in time) flow.

the parser or JS engine generates an Abstract Syntax Tree (AST), which is a hyerarchy of nodes,
which the interpreter reads and
generates high-level binary code or byte code from, for
the compiler to finally generate the machine code -or low level binary- that may be optimised as instructions for a specific CPU architecture.

This cycle of execution, uses the client's (be it desktop or mobile) resources.

Client-side dynamics

Until very recently, and ever since libraries like jQuery and JavaScript frameworks like AngularJS, Ember, Backbone emerged and became so popular, around 2009, almost everything dynamic happened on the client-side. In addition to the interpretation of JavaScript during execution, to offer good performance, the stars had to align: the requested data had to be distributed -served from the cache of a CDN- to avoid high latency, the user connection had to be fast, and they needed to be on a high-end, high-capacity terminal.

In reality, we don’t know the user’s system capacity at any time. And that’s a hindrance.

We try to prevent exhausting end-user terminal resources

In theory, if we ran lower level code, we would be using less resources. That's more than a theory. Go to this video where I demonstrate Pagefind, written in Rust and compiled to Wasm as target, as a static app that ingests and indexes HTML documents and runs super efficient search queries, all client-side.

Portable, secure, and lightweight: Wasm runtimes and their use-cases by Natalia Venditto - YouTube

WebAssembly, a super lightweight binary compilation target has been around for a while. But it's only now taking off, amidst additional enhancements, like WA...

youtube.com

Going lower, to reach higher

That's Wasm. A (web) standard binary instructions compilation target that runs on the browser, implementing a system of imports and exports.

You literally write the code in the language you prefer, and given the toolchain is in place -and it's in (experimental or preview) place for JavaScript, with teams working on it, like for example JCO- you can compile with Wasm as target.

Learn more about Wasm

At the edge of the cloud

We have seen how we can run Wasm on the browser to attain a high level of performance with low bandwidth cost, client-side. But what about server-side or in an isomorphic way?

Cloud technologies -and emerging JavaScript meta-frameworks- allow us to render, cache, and then rehydrate dynamic parts of a (server rendered) static page based on rules, cookies or headers and other composability strategies.

This allows us to build dynamic experiences with a backend for frontend approach, preventing the execution of JavaScript to happen client-side, with the unavoidable performance degradation.

And where does this compute or execution run?

On serverless functions, we can run it on Node.js as runtime on a host built specifically for that purpose. Yet this serverless environments that run at the heart of data-centers, have some drawbacks. They experience something known as cold-start: a mix of the time necessary for the runtime to start, load dependencies, execute the function, and the latency imposed by the physical distance between the server and the end-user terminal.

Lighter runtimes

How can we spin lighter runtimes in the cloud, at the edge of the network? Intuitively we know that edge means we're closer to the user, and we can reduce latency. But how do we run lower level code, which is faster and more lightweight, and hence more performant, on a non-browser environment?

We can do that also server-side, -or on non-browser environments- with WASI enabled Wasm. If WebAssembly is a compilation target that uses a system of imports and exports to enable access to APIs from the Web Platform using the browser as execution engine-, WASI is a POSIX compatible system interface that enables that imports and exports strategy to exist where the browser is not part of the host.

This enables the ultimate level of portability of a sandboxed runtime, from frontend to backend, to a myriad of systems and devices.

Don't read me say it, see me at it!

Portable, secure, and lightweight: Wasm runtimes and their use-cases by Natalia Venditto - YouTube

WebAssembly, a super lightweight binary compilation target has been around for a while. But it's only now taking off, amidst additional enhancements, like WA...

youtube.com

Here are the slides for the conference talk I based this article on, https://slides.com/anfibiacreativa/wasm-runtimes-portable-secure-lightweight/fullscreen

Micro-frontends and beyond: composable frontend applications

Natalia Venditto — Tue, 25 Apr 2023 10:12:34 +0000

Hi folks! It's been a while I don't post here, and there is a reason why. Besides being quite busy with work, back in December last year I decided to use part of my vacation to start a website to publish all I've learned over the years about web development, cloud development and architecture. You can visit it at microfrontend.dev

My journey with micro-frontends

I started experimenting with optimized and performant patterns and architectures to ship enhanced frontend applications, when I was a frontend technical lead for a large enterprise platform operating globally. We were maintaining its legacy version, and at some point, we decided to migrate. That's when I started my transition from developer and lead developer to architect. There was a lot going on: we were also moving from on-prem to the cloud. We were shipping a new platform to a new market. The team was growing from 10 to over a hundred. We were maintaining 3 legacy and a brand new code base, dozens of projects mapping to respective business units, and hundreds of localized websites, and we wanted to do it in the most efficient way for the stakeholders, the developers involved, and overall, the end-users. We also had external teams collaborating. It was not an easy endeavour, and I shared part of that adventure in a post that's been one of the most popular I've written in this platform Micro frontends: my lessons learned.

The motivation to build a website about micro-frontends

I spent most of 2020 and 2021 writing and doing public speaking online and on-site, about micro-frontend architectures, and later on, when I joined MongoDB as an architect, about data and how to connect the dots between data sources and the application layer, in the cloud. I visited multiple podcasts, too, and tried to spread as much of my knowledge, gained through experience designing, building and shipping to production, composable architectures in the cloud over serverless and event-driven components.

You can access some of that content here, under Content created by me

But that wasn't enough. I wanted to write a book.

I thought that writing a book would be beneficial for my career. I realized -and still think that it is the case- only published authors are somewhat taken seriously. Especially if you're a woman, it takes you a lot more effort to get visibility and for your opinions and research to be taken seriously.

But writing a book demands you subscribe to a publishers schedule. And I was already plenty busy and meeting deadlines at work; it didn't appear to be feasible. Especially after joining Microsoft to lead the e2e DX for JavaScript on Azure.

This is when I decided to publish a website.

If I don't have time for a book, I'll make it a website

And that's how microfrontend.dev was born. Not before my good friend Wassim bought a domain for me.

Shipping my knowledge and opinions as a website makes them accessible to everyone. And I do believe that's a good thing.

I have debated open-sourcing it, but I would like for the backlog to be completed first. I can't believe it went live for the first time on the 6th of January, and we're already almost in May.

Ever since, it has been visited by people from over 70 countries and hundreds of cities. I hope it's helping folks get a better understanding of some of the technologies, patterns, mechanisms and frameworks explored. I have a lot of pending topics to address, and I hope I find time soon to continue to develop it, improve it and expand on those topics and more.

If you find it useful, please visit it, share it with others, leave a comment here. Do you have topics you would love for me to add? Let me know!

For publishers: I may still be interested in writing that book. Especially now I have most of it put together ;)

More on the subject of composable architectures

If you visit my website and want to know more, I will be speaking at the O'Reilly Architecture Superstream on the 31st of May, precisely on this subject.

As a woman in technologies and a web software architect who's always been interested in innovating, disrupting, finding new ways to architect frontend applications with performance and user experience in mind, and bring professional frontend development closer to everyone, it was very exciting to get an invitation to participate and share my ideas at such a prestigious event.

I wish you all a great week, and hope to hear from you soon!

Tiny edit: if you want to get more tech content from me around JavaScript, TypeScript, VSCode, Azure... 🙏 me on twitter (I still don't have a BlueSky...) https://twitter.com/AnfibiaCreativa

Bases de datos: operar con la base de datos - parte 2

Natalia Venditto — Thu, 25 Aug 2022 11:54:06 +0000

En la entrada anterior aprendimos cómo crear una base de datos y una colección, y también empezamos a trabajar con la base de datos usando las operaciones CRUD para crear documentos.

Al final de la entrada, les recomendé utilizar el comando mongoimport de las herramientas de base de datos, para importar un set o conjunto de datos más extenso, y así poder trabajar con MQL de manera más compleja.

Si no lo hicieron, les recomiendo ir a la entrada 3 y seguir las instrucciones.

Operaciones CRUD para leer documentos

Hoy vamos a aprender a usar MQL, el lenguaje de consultas de MongoDB para, justamente, consultar nuestra base de datos de redtatuaje.

Como aprendimos en la entrada anterior, vamos a usar la terminal para conectar a nuestro servidor local, y usar la base de datos deseada y colección, deseadas.

Operación CRUD findOne()

Lo primero que vamos a hacer es inspeccionar cualquier documento de la base de datos, de manera aleatoria, solo para ver qué estructura tiene un documento.

Lo haremos ejecutando primero, como aprendimos antes, show collections para ver qué colecciones tenemos disponibles y asegurarnos que hemos importado correctamente los datos, para poder seguir las indicaciones de esta entrada.

y luego ejecutando

db.artistas.findOne()

findOne() devuelve el primer documento que encuentra, que satisface un determinado criterio de consulta, es decir, el primero a partir del orden natural en el que se encuentran los documentos. Si la colección tiene un límite de algún tipo (generalmente en MB), entonces el orden natural corresponde al orden de inserción. En este caso vemos que devuelve el correspondiente al artist_id: 743 correspondiente al name: "Alex Holt".

Parámetros opcionales de `findOne()`

El método findOne() acepta que se le pasen dos argumentos opcionales para determinar ese criterio. Por ejemplo, podemos decir

db.artistas.findOne(query, projection)

la consulta en sí, y una condición de proyección.

Si vemos la imagen anterior, podemos comprobar que para el artista de id 743, la propiedad owns_studio, tiene el valor Yes. Podemos pedir a MongoDB que nos devuelva el primero por orden natural, para que ese valor sea No.

db.artistas.findOne({ "owns_studio": "No"})

En cuyo caso, como podemos ver, el id de artista es ahora 701, correspondiente a la artista de name: "Sue King".

Proyección de consultas (Projection)

Pero hemos dicho que este método además aceptaba un segundo parámetro adicional, de proyección. ¿Qué significa eso?

MongoDB siempre va a devolver los campos de un documento que se encuentran proyectados. Por defecto, todos los campos están proyectados, o sea tienen el valor de proyección a 1 o true.

1 u otros valores diferentes de 0 y true, especifican inclusión en la proyección

Sin embargo, si explícitamente proyectamos un campo, solo se devolverá ese campo junto con el valor del _id, que solo se excluye si se pone su valor de proyección explícitamente a 0 o false.

Veamos un ejemplo

db.artistas.findOne({ "owns_studio": "No"}, {"owns_studio": 1, "name": 1})

Si queremos omitir el valor del campo _id, le tenemos que pasar 0 explícitamente (o false)

db.artistas.findOne({ "owns_studio": "No"}, {"owns_studio": 1, "name": 1, "_id": 0})

Vamos a ver a estudiar Projection más adelante en la serie con más profundidad, ya que hay muchísimas más formas de proyectar, y formas especiales para datos más complejos, como los datos anidados, o los arreglos.

Operación CRUD find()

Hasta ahora, como pedíamos MongoDB encontrar uno, o findOne(), siempre devolvía solo uno...Pero, ¿qué pasa cuando queremos una lista?

Entonces debemos ejecutar

db.artistas.find()

Pero espera...¿Qué ha pasado? ¿Nos ha devuelto los 1000 documentos que habíamos importado a la colección?

No. Este método devuelve un cursor, que es una referencia a un conjunto de resultados que devuelve una consulta, y que se pueden iterar. Es decir, podemos ver más de lo que hay en el cursor y luego acceder al documento que deseamos.

Por defecto el cursor para find() nos muestra 101 resultados siempre que no se exceda el máximo tamaño de documento, que es de 16MB (como ya vimos en la entrada 1 de la serie) y una de las formas de obtener más es ejecutando it, como vemos en la imagen.

También podemos asignar el cursor a una variable (¡recordemos que estamos en un REPL completamente funcional!) y utilizar algunos de sus métodos. Por ejemplo.

let tatuadores = db.artistas.find({ "owns_studio": "Yes" });

while (tatuadores.hasNext()) { 
  printjson(tatuadores.next());
}

Aquí estamos usando los métodos hasNext() que evalúa si hay más documentos que satisfagan la consulta, en el cursor, y utilizamos el método next(), para iterarlos mientras hasNext() devuelva true.

Otros métodos del cursor son forEach(), toArray() y objsLeftInBatch(), que nos dice cuántos objetos hay en el batch, después de ejecutar una iteración (o conjunto) devuelto.

Podemos también utilizar el método isExhausted() para comprobar que realmente no existen más objetos o documentos, en el cursor.

Recordemos que cada documento mapea a un objeto.

Una lista completa de métodos del cursor, se pueden encontrar aquí

Cuando se usaba find() con las versiones anteriores de la consola, se solía concatenar el método pretty(), para que los resultados en el cursor se mostrasen formateados. En mongosh, pretty() se ejecuta por defecto.

Veamos un ejemplo de usar forEach():

let tatuadores = db.artistas.find({ "owns_studio": "Yes" });

tatuadores.forEach((tatuador) => { 
  if (tatuador.payment_method === "Credit Card Only") { 
    printjson(tatuador);
  }
});

Limitar el cursor a una cantidad específica de resultados en el batch

En una base de datos muy grande, con documentos de tamaño muy pequeño, podríamos tener demasiada cantidad de objetos devueltos. Si queremos limitarlos de manera explicita para aumentar el rendimiento, podemos usar el método limit(), de esta manera.

db.artistas.find({"payment_method" : "Credit Card Only"}).limit(5)

Más información sobre el método limit() se encuentra aquí.

Parámetros opcionales de `find()`

Find también acepta la configuración de dos parámetros opcionales: la consulta y la proyección.

Consultas complejas con operadores de consulta

Vamos a empezar a realizar consultas más complejas, utilizando los operadores de comparación. En otras entradas exploraremos los lógicos, de elemento, de evaluación, de array y geoespaciales. Y por supuesto, haremos una entrada específica sobre proyección.

¡Empecemos!

Encontrar un valor equivalente al pasado en la consulta: operador `$eq`

Este operador nos permite consultar la base de datos para encontrar todos los documentos que tienen un valor especifico que equivale al que se pasa. Por ejemplo, vamos a buscar todos los artistas que no tienen estudio propio.

Vamos a limitar las consultas siempre a 5 para reducir el tiempo de respuesta, pero eso no es un requerimiento.

db.artistas.find({ "owns_studio": { $eq: "No" } }).limit(5)

El formato de la consulta es:

{ <campo>: { $eq: <valor> } }

Podemos decir que esto es equivalente a realizar esta consulta

db.artistas.find({ "owns_studio": "No" }).limit(5)

sin embargo, al usar operadores, los podemos combinar o usar operadores lógicos, para consultas más complejas, como veremos mientras progresemos.

Encontrar un valor más grande que el valor pasado: operador `$gt`

Este operador nos permite encontrar los documentos para los cuales el valor del campo pasado, es más grande que el especificado. En este caso, todos los artistas con un identificador más grande que 500

db.artistas.find({ "artist_id": { $gt: 500 } }).limit(5)

El formato de la consulta es:

{ <campo>: { $gt: <valor> } }

Igualmente podemos encontrar valores más grandes o iguales al valor pasado, con $gte, más pequeños con $lt, o más pequeños o iguales al valor pasado, con $lte. La sintaxis es la misma.

Encontrar todos los valores diferentes a: operador `$ne`

ne vendría a significar not equal, o no igual. Lo usamos para encontrar todos los documentos cuyo valor no es igual al pasado.

db.artistas.find({ "artist_id": { $ne: 500 } }).limit(5)

Por supuesto que no necesariamente estamos haciendo comparaciones numéricas. Estamos comparando valores literales. Por lo cual, podemos pasar cualquier tipo.

db.artistas.find({ "name": { $ne: "Cordelia Swanson" } }).limit(5)

Y esto es cierto para las comparaciones de arriba, también. Por ejemplo:

db.artistas.find({ "country": { $lt: "PE" } }).limit(5)

Donde devolverá todos los valores más pequeños que "PE" como código de país, en orden alfabético.

Comparar fechas con operadores de comparación

También los podemos usar para las fechas. Por ejemplo, si queremos encontrar a todos los artistas que se unieron a la plataforma hace un año o más, lo haríamos así:

db.artistas.find({ "joined_network": { $lte: new Date("2021-08-12") } }).limit(5)

Excluir resultados que contengan un valor en un campo array: operador `$nin`

Este operador not in, nos permite excluir objetos del cursor, sí contienen un cierto valor en un campo de tipo arreglo.

Por ejemplo, supongamos que queremos filtrar a todos los artistas que se dedican a los estilos geometric y realism, de nuestro cursor de resultados.

db.artistas.find({ "styles": { $nin: ["geometric", "realism"] } }).limit(10)

$nin también puede usarse para excluir del cursor los documentos que no contienen un cierto campo.

Más información sobre este operador de condición, se encuentra en la documentación

MQL en el mongosh vs. operar con un driver

No se debe confundir los métodos de operación de MQL en la consola de MongoDB, con los métodos que provean los diferentes drivers cuando se está escribiendo una aplicación.

Muchos de estos drivers (o software intermedio) crean capas de abstracción para simplificar la combinación de operadores, y es posible que ofrezcan diferentes métodos para operar con la base de datos.

En la próxima entrada, vamos a usar operadores lógicos. ¡Hasta entonces!

Gracias especiales a @wassimchegham que siempre me revisa los screenshots y a @dfreniche al que le pedí peer review, y me contesto "RIGHT NAO!" <3

Bases de datos: operar con la base de datos - parte 1

Natalia Venditto — Wed, 03 Aug 2022 17:58:36 +0000

En las entradas anteriores hablamos del modelo de documento y del particionamiento de bases de datos distribuidas, que corresponden a ese modelo. ¡Llegó el momento de trabajar un poco con las mismas!

Pre-requisitos

Para poder experimentar deberán tener instalado MongoDB Community Server y las herramientas de terminal y extensiones necesarias. Pueden ir a la primera entrada de esta serie, para encontrar indicaciones. También pueden instalar Compass, la herramienta gratuita de Interfaz Gráfica Visual de MongoDB.

Crear una base de datos MongoDB desde la terminal

Vamos a empezar trabajando con la Mongo Shell. Una vez está instalada, la arrancamos así



mongosh

Eso nos conecta directamente a nuestro servidor local, lo cual podemos apreciar en la imagen, ya que al ejecutarlo se inicia una conexión a 127.0.0.1:27017 o sea a la IP de bucle invertido, o localhost en el puerto 27017 que es el puerto que usa mongod (o sea el proceso mongo daemon del que hablamos en la primera entrada de la serie) por defecto. Además inicializa el entorno REPL JavaScript (read-evaluation-print loop o bucle de lectura, evaluación y salida).

Más adelante conectaremos a un despliegue remoto, para lo que necesitaremos usar una cadena de conexión pero por ahora trabajaremos en local.

Mostrar las bases de datos existentes: `show dbs`

Para ver las bases de datos que existen en nuestro servidor vamos a usar el comando show. Simplemente escribimos en la terminal show dbs.

Cuando se instala un servidor, MongoDB crea algunas bases de datos que utiliza el sistema para operar, como admin, config y local.

Nota: No se recomienda manipular las bases de datos por defecto, ya que puede alterar el correcto funcionamiento del sistema.

El comando `use`

Para cambiarnos de base de datos usamos el comando use, al que le pasamos el nombre de la base de datos que queremos utilizar.

En mi caso ya tengo una base datos adicional que se llama Items de modo que si ejecuto



use Items

el sistema va a usar esa base de datos, como se ve en la captura.

Pero...qué pasa si ejecuto use, con una base de datos que no existe. Vamos a verlo...



use Item

En este caso el sistema creará una referencia a una base de datos de ese nombre.

¡Pero cuidado! Mientras esa base de datos esté vacía, no será listada, como podemos ver en la siguiente captura

Hay que tener cuidado con la puntuación, entonces, porque si estamos trabajando con la base de datos Items y nos equivocamos y escribimos Item, estaremos creando esa base de datos nueva. ¡Con las colecciones, pasa lo mismo! Esto es el comportamiento por diseño de MongoDB y por eso, para evitar operar con una base de datos o colección incorrecta cuando usamos los drivers desde una aplicación, hay que seguir buenas prácticas que nos eviten dolores de cabeza, como por ejemplo asignar esos nombres a constantes.

Cuando usamos use, entonces, lo que hacemos es asignar un valor al objeto db que ahora apuntará a una base de datos en concreto. Si simplemente ejecutamos db, nos dirá cuál es ese base de datos.

`show collections` para mostrar colecciones

Para saber qué colecciones existen en una base de datos una vez que la estamos usando, ejecutamos show collections en la misma.



show collections

Dado que Item no tiene ninguna colección, no devuelve nada. Así que vamos a crear una colección. Podemos usar el método createCollection() del objeto db.



db.createCollection("items")

Nota: métodos adicionales se pueden encontrar en la documentación oficial

Podemos ver que al ejecutar show collections, nos muestra la colección items que existe en nuestra base de datos activa.

También podemos ejecutar



db.[nombre_de_collección]

Por ejemplo

¡A prestar atención! Porque hemos escrito item como nombre de colección. Dado que no existe, MongoDB la creará.

Operaciones CRUD para operar con documentos

Para demostrar este último concepto, vamos a utilizar nuestro primer operaciones CRUD, a nivel colección. Podemos encontrar un listado completo de los mismos en la documentación

Hasta ahora tenemos una colección llamada items. Cuando ejecutamos show collections, es la única que aparece. Pero si ejecutamos



db.item.insertOne({})

y luego ejecutamos show collections, veremos que ahora que hemos insertado un documento vacío, entonces aparecen ambas colecciones.

Lo importante a tener en cuenta, es que por diseño MongoDB creará una base de datos o colección que no existe, si se opera con las mismas.

Hemos por fin ejecutado nuestra primera operación CRUD para crear un documento nuevo. Dado que le hemos pasado un objeto vacío {} al método, el documento está vacío a excepción del identificador de tipo ObjectId que MongoDB asigna automáticamente a todos los documentos. Más adelante en la serie cuando hablemos de indexes (indíces) explicaremos más sobre el campo _id y cómo puede customizarse según las necesidades de nuestra aplicación, ya que este campo siempre se indexa como clave primaria de una colección.

El campo automático _id o identificador único de documento, de tipo ObjectId se auto-indexa y es clave primaria de cada colección.

Si ahora ejecutamos el método findOne(), podemos ver la estructura del documento.

Operaciones CRUD

Las operaciones CRUD (create, read, update, delete en Inglés) nos permiten operar con la base de datos para crear, leer, actualizar y borrar datos o documentos, en la base de datos.

Cuando operamos con la base de datos, generalmente usamos una o una combinación de éstas operaciones convencionales.

Vamos a empezar con las operaciones que crean documentos.

Creación de documentos

Como ya pudimos observar anteriormente, podemos crear un documento a través del método insertOne( {<documento>} ), al que pasamos un objeto que representa el documento. Si no pasamos ninguna propiedad, se creará un documento vacío, con un identificador único.



db.[nombre-de-colección].insertOne({ "nombre": "Documento1", "estaEscrito": true })

Además de insertOne() al que pasamos un solo objeto, podemos utilizar insertMany() para insertar múltiples documentos en la base de datos por medio de un arreglo.

Para probarlo, vamos a ejecutar



db.item.insertMany([{},{},{}])

Tengan en cuenta que obviamente, los identificadores que se generarán en la ejecución de ustedes, serán otros.

Ahora vamos a actualizar uno de estos documentos de la colección, utilizando updateOne(). Este método espera recibir una condición para filtrar el documento deseado (en nuestro caso sólo podemos pasarle el _id, y un objeto con el campo que se va a modificar, que se pasa al método $set, así:



db.item.updateOne({ "_id": ObjectId("62e7f362b654003b0ba25e4a")}, // esto es el filtro que encuentra el documento a actualizar {$set: {"campo_nuevo": true}} // $set le agregará el campo_nuevo, o lo actualizará si existiera)

Por cierto, cuando hablamos en la jerga de MongoDB en inglés, los métodos que tienen un $ antes del nombre, se suelen decir como dollar-nombre. En este caso, se leerá dollar-set.

También podemos pasar upsert como parámetro adicional del objeto options que recibe opcionalmente este método, lo que garantizará que si el filtro no encuentra ninguna correspondencia, se creará el documento. Para demostrarlo, le cambiamos los 4 últimos dígitos a cualquiera de los ids que nos devuelva por 0000(¡a menos que ya exista uno que termine con 0000! Entonces elegiremos 4 cifras que no existan. 😅)



db.item.updateOne({ "_id": ObjectId("62e7f362b654003b0ba20000")}, {$set:{"campo_nuevo": true}},{ upsert: true })

Otras opciones que recibe este método, se pueden aprender aquí

Más métodos que crean documentos

Otros métodos que crean documentos cuando se les pasa la opción upsert a true, se especifican en está página, y más métodos adicionales de actualización, se explican aquí

¿Documentos con estructura diferente?

Se dieron cuenta, ¿verdad? Al haber actualizado un par de los documentos, existen documentos en una misma colección, con una estructura distinta. Esto es perfectamente posible en MongoDB y el modelo documento, porque aunque se puede implementar un schema y proceder a la validación de datos a través del mismo, no es obligatorio tenerlo. Sin embargo, no es recomendable desde el punto de vista funcional que los documentos de una misma colección tengan campos totalmente diferentes, aunque está cualidad permite agregar campos a ciertos documentos de la colección, sin tener que nulificar (o para no inventarme términos raros, dar un valor null) al mismo campo en aquellos documentos para los que no existe el valor -o la propiedad no aplica-. Esto puede ser útil para ciertos casos de uso, en el modelado de datos.

Existen documentos en esta colección con una estructura distinta. Esto es perfectamente posible en MongoDB y el modelo documento, porque aunque se puede implementar un schema y proceder a la validación de datos a través del mismo, no es obligatorio tenerlo.

Utilizar `mongoimport` para importar datos a una base de datos MongoDB

Para poder hacer uso de esta utilidad, tendremos que haber instalado las herramientas de base de datos como se indica en este documento

Además, pueden forkear (me encanta escribir entradas en español y darme cuenta que no tengo ni idea de cómo traducir algunas operaciones de GIT. ¡Espero no ofender a nadie!) este repo. Básicamente lo que van a necesitar hacer es importar este archivo que es un listado de artistas de tatuaje (¡que no existen! los generé con mgeneratejs).

Antes que nada, vamos a poner en uso algunos de los conceptos que aprendimos antes para crear una base de datos que se llame redtatuaje y una colección que se llame artistas.

A la misma le vamos a importar este archivo abriendo una nueva pestaña de la terminal (o ventana, según el caso -ojo! no mongosh o mongo, sino bash/zsh, etc) y ejecutando



mongoimport --uri mongodb://localhost:27017 --db redtatuaje --collection artistas --file [ruta-al-archivo]/artists.json

El comando anterior asume que el servidor está corriendo en el puerto por defecto 27017. Recuerden que si no crearon la base de datos y colección con anterioridad, o si la escriben de manera diferente (intencionalmente o por error), se crearán.

Conectando a una base de datos remota

mongoimport y el resto de utilidades, se pueden usar también para operar con bases de datos remotas. Por ejemplo supongamos que tenemos un servidor Cosmos DB que creamos para usar con MongoDB API. Lo podemos crear directamente desde VS Code, con la extensión de Azure Tools, o desde el portal de Azure.

Una vez creado, podemos obtener la cadena de conexión desde la extensión de VS Code directamente, haciendo click con el botón derecho del ratón para desplegar el menú, y luego haciendo click en Copy connection string(obtener cadena de conexión)

o yendo a la página de configuración del recurso y copiando o pegando la cadena de lectura + escritura, en este caso, ya que vamos a crear documentos.

Más sobre la cadena de conexión MongoDB

Una cadena de conexión es precisamente una concatenación de argumentos que nos permiten establecer la conexión, y que en el caso de la de MongoDB, se compone del protocolo, que en el caso de MongoDB puede ser mongodb o mongodb + srv, el dominio de servidor (o IP) que se corresponde al parámetro host, con su respectivo puerto, el nombre de usuario o cuenta, la contraseña y algunos parámetros adicionales de configuración, como por ejemplo si utilizaremos ssl, el nombre del conjunto de réplicas y si se intentará reescribir en caso de errores de conexión o retardos.

La cadena de conexión es la concatenación de argumentos que nos permiten establecer la conexión con la base de datos, a la vez que configuramos ciertos aspectos de la misma.

Lo que vamos a hacer es copiar exactamente el comando de arriba, y reemplazar el valor de la opción --uri que ahora apunta a localhost, por la cadena de conexión tal cual la obtuvimos del portal o la extensión de VS Code, puesta entre comillas.



mongoimport --uri "[cadena-de-conexión]" --db redtatuaje --collection artistas --file [ruta-al-archivo]/artists.json

Eso nos permitirá importar los datos desde el archivo en nuestro ordenador local, para poder trabajar con los mismos en remoto.

Más información sobre la cadena de conexión, la podemos leer aquí

Ahora ya tenemos todo listo para consultar documentos locales o remotos de manera eficiente con MQL. ¡Nos vemos en la próxima entrada donde vamos a aprender a hacerlo!

¡Hasta la próxima!

Bases de datos distribuidas: sharding.

Natalia Venditto — Fri, 15 Jul 2022 12:30:38 +0000

En el post anterior hablé de algunos conceptos básicos para entender el modelo de documento. Básicamente, el modelo de documento surgió de una necesidad real por parte de los desarrolladores de tener un sistema más idiomático de representar datos y sus relaciones, que se pudiera mapear a los objetos que típicamente creamos cuando usamos patrones de programación orientados a los mismos, OOP.

Básicamente, el modelo de documento surgió de una necesidad real por parte de los desarrolladores de tener un sistema más idiomático de representar datos y sus relaciones, que se pudiera mapear a los objetos

Es preciso recordar que las primeras bases de datos relacionales de modelo tabular, surgieron en los 70. Es decir, cuando el uso que se le daba a los sistemas computacionales era diferente del de ahora (¡no comprendía la web, por ejemplo!), y los mismos se desplegaban y servían de manera centralizada. No existía ni una necesidad, ni una infraestructura, ni una governanza que requiriera que las bases de datos se distribuyeran a través de diversas ubicaciones.

Las primeras bases de datos relacionales de modelo tabular, surgieron en la década de 1970. Es decir, cuando el uso que se le daba a los sistemas computacionales era bastante diferente, y los mismos se desplegaban y servían de manera centralizada

Pero los tiempos cambiaron y la necesidad vino determinada por la globalización producto del acceso masivo a los mismos productos, servicios y aplicaciones, por parte de los usuarios de internet a nivel mundial. Esta globalización exacerbó problemas ya existentes, pero menos relevantes, como la latencia. La latencia determina cuánto tiempo pasa desde que se inicia una petición hasta que se recibe una respuesta, en un modelo cliente servidor.

Antes de que las nubes públicas y sus proveedores entraran en escena, los despliegues se hacían 'en premisas', es decir en las mismas premisas donde las empresas y organizaciones operaban sus negocios o en un centro de datos cercano. (Recordemos que todavía hay un enorme porcentaje de organizaciones que por motivos de seguridad o retraso en la adopción de sistemas en la nube, siguen operando en premisas o como se conoce en inglés 'on-prem(ise)'). Más adelante, los centros de datos que se dedicaban a proveer y mantener infraestructuras y las redes necesarias, fueron creciendo y distribuyéndose. Finalmente, el requerimiento de un mejor rendimiento, menos latencia, y de los controles de privacidad en forma de soberanía de datos por parte de países y regiones (como puede ser GDPR en la Unión Europea), definieron la descentralización y los modernos sistemas de distribución de datos.

Pero muchas veces, aunque estos sistemas cachean datos en diversas regiones del globo (es decir, guardan una copia para servir más eficientemente a puntos distribuidos lo que se conoce como CDN), siguen teniendo su nodo transaccional en un único punto.

¿Qué es el sharding?

Sharding es simplemente ese proceso de dividir grandes volumenes de datos en partes más pequeñas, que se guardan generalmente en particiones físicas o virtuales diferentes. Cualquier base de datos se puede dividir así, pero es un proceso complicado, que requiere toda una refactorización y reconfiguración de acuerdo a la nueva distribución.

Partir modelos tabulares de modo que podamos desplegar parte de la base de datos en una región de la nube, por ejemplo, y otra parte en otra región, exige un diseño de sistema y una infraestructura realmente complejos. Particularmente por cómo está diseñado el modelo relacional, para desacoplar datos a los que se accede de manera frecuente, pero deben seguir relativos a otro (u otros) grupos de datos para conformar una entidad.

Partir modelos tabulares de modo que podamos desplegar parte de la misma base de datos en una región de la nube, por ejemplo, y otra parte en otra región, exige un diseño de sistema y una infraestructura, realmente complejos.

El modelo de documento simplifica la distribución de datos

Sin embargo, el modelo documento propuso que todos los datos a los que se accede juntos, se guardan juntos, en un único documento. Y aunque existen muchas excepciones a esa regla, y formas de relacionar documentos en distintas colecciones a través de ciertos patrones de diseño, es muy importante tener esta definición en cuenta, a la hora de diseñar bases de datos de modelo de documento.

Una de las ventajas es que es mucho más simple 'dividir' bases de datos en conjuntos de datos completamente diferentes, siguiendo una estrategia de particionamiento si respetamos ese precepto.

En el caso de MongoDB además, el proceso de sharding es nativo y se puede automatizar, interviniendo en él otros procesos como el enrutado, el auto-balanceo, etc.

Sharding si, sharding no

El sharding de MongoDB no es en lo absoluto un proceso simple. Es un proceso complejo que necesita una estrategia bien meditada para ser exitoso. Una de las preguntas más importantes que debemos hacernos (como con todos los procesos que implican una re-estructuración de la arquitectura, con un coste elevado) es si realmente lo necesitamos.

Es importante tener en cuenta que en Cosmos DB, por ejemplo, el sistema está particionado por defecto, en particiones pequeñas. Hablaremos de esto en el siguiente post.

Para empezar, es importante saber que el sharding en una base de datos MongoDB se recomienda solamente para volúmenes muy grandes de datos. Pensemos en varios TB's de los mismos. Generalmente el volumen recomendado estará ligado a la infraestructura donde corre el software y su capacidad del hardware, que determina el rendimiento del motor a nivel escaneado, compresión y cacheado. Pero eso es tema para otro blog post. Así que prosigamos.

Incluso si nuestro volumen de datos comprimido está por encima de los TB's recomendados en ese momento, la primera pregunta que hay que hacerse antes de habilitar sharding, tendrá que ver con la arquitectura de nuestros datos, y las politicas de retención de los mismos. Es decir...¿realmente necesitamos tener en caliente, todos los datos que guardamos?.

Datos fríos y datos calientes

Una de las definiciones más importantes que tiene que hacer una empresa en el momento en que empieza a brindar un servicio a usuarios a través de una aplicación, es la política de retención de datos.

A nivel estrategia de negocio siempre será más barato, y por ende más ventajoso para nuestra empresa, el definir claramente las expectativas y acuerdos de acceso a los datos por parte de nuestros usuarios. Es decir, imaginemos que somos una start-up que recabamos datos a los que los usuarios acceden a través de nuestra aplicación o plataforma, podemos definir que los usuarios tendrán acceso inmediato a los datos de menos de 12 meses de edad en la base de datos, y que deben esperar un poco más tiempo para obtener datos más antiguos. Por un poco más de tiempo, me refiero a algunos segundos en vez de nano o milisegundos.

Ese tipo de términos de uso son generalmente aceptados como normales por los usuarios, y nos permiten mantener datos en caliente por menos tiempo (es decir, en un cluster de acceso inmediato) mientras que los más antiguos de guardan en almacenamiento frío, por ejemplo un data lake (lago de datos? Nunca lo he escuchado en español, pero eso sería literalmente el nombre!). Los data lakes son almacenamientos en máquinas menos potentes, y por lo tanto son más baratos y admiten volúmenes enormes de datos.

Múltiples clusters como alternativa al sharding

Otra alternativa para volúmenes grandes de datos que deben estar en caliente, de más fácil implementación y mantenimiento particularmente cuando se debe observar la soberanía de datos, es la de desplegar bases de datos a través de diferentes clusters, en vez de recurrir al sharding.

Qué pasa en nuestra base de datos, cuando la particionamos?

Ahora que ya hemos hablado de volúmenes mínimos de datos, y de políticas de datos que nos permitan mover datos a almacenamientos más baratos, y que ya hemos establecido que el sharding es un proceso caro a nivel complejidad de la implementación y mantenimiento, hablemos del mecanismo de sharding en si.

El sharding es un proceso que reconfigura al driver para que la aplicación ignore que se está comunicando con múltiples instancias de la base de datos, y ejecuta un balanceo de cargas que mueve datos automáticamente entre las mismas.

El sharding es un proceso que reconfigura al driver para que la aplicación ignore que se está comunicando con múltiples instancias de la base de datos, y ejecuta un balanceo de cargas que mueve datos automáticamente entre las mismas, de acuerdo a una estrategia predefinida.

Así como enfatizamos en que la replicación es una copia del mismo conjunto de datos que permite la redundancia de los mismos en varios nodos, es importante recordar que cada shard o partición, es (si se siguen buenas prácticas) un conjunto de réplicas en si.

Cada shard o partición, es un conjunto de réplicas en sí. Técnicamente es posible que cada shard sea un nodo único standalone, pero recordemos que eso no es lo recomendado

En un momento hablaremos de las estrategias de sharding, que dependen de su clave de sharding. La clave de sharding o sharding key es básicamente el campo que define cómo se separarán los datos, y cómo se indexarán. Antiguamente, una vez se elegía una clave, no se podía cambiar, pero desde la versión 5.0 de MongoDB se puede cambiar con un proceso de resharding.

Componentes de la arquitectura de `sharding`

Una de las razones por las que el sharding es más caro de mantener, es que requiere varios nodos adicionales al standalone o a las réplicas (en el caso de que cada shard sea un conjunto de réplicas, como se recomienda).

Vamos a suponer que tenemos 3 shards de arquitectura PSS. Uno de los 3 shards va a ser el primario. Además, necesitaremos un nodo adicional que corra el proceso mongos. También necesitaremos un servidor de configuración, que también es un conjunto de réplicas. ¡Con esta configuración y usando buenas practicas, tenemos nada menos que 13 nodos corriendo!

El proceso Mongos

Este proceso es un proceso de enrutado (un router) que mantiene una tabla de contenido de la base de datos que dirige las peticiones del cliente hacia el shard correcto, y actúa como intermediario entre la aplicación y la base de datos particionada. La arquitectura acabará siendo como se ilustra en el diagrama anterior.

Cuando habilitamos sharding en una base de datos, para una o varias colecciones, debemos elegir la clave de shard, que como decíamos, no es más que un campo indexado de la colección en cuestión. Voy a dedicar una entrada de blog a los índices (indexes en la jerga de MongoDB, no sé por qué, pero el plural en este contexto es así 🤷‍♀️). La indexación es uno de los temas más complejos y difíciles de entender, en lo que a MongoDB respecta.

Shards

Cuando se inicia el proceso de sharding, que por cierto es un proceso paulatino y asíncrono que puede tardar días y hasta semanas en completarse (dependiendo del volumen de datos), pero que no interfiere con el funcionamiento de la base de datos (es decir, se puede ejecutar en sistemas en producción, sin problemas), los datos de las colecciones afectadas se irán distribuyendo en forma de chunks del tamaño predeterminado, a través de la cantidad de shards configurada.

Un cluster particionado siempre tiene además un shard primario que es el que guarda las colecciones que no están sujetas a partición.

Chunks

Durante este proceso, el sistema particionará los datos en chunks o cachos(muy gracioso, pero no encuentro mejor traducción!) y los irá distribuyendo y redistribuyendo de manera balanceada, a través de los shards.

Estos chunks deben de tener, por convención, un tamaño mínimo de 64MB. No tiene sentido tener chunks de menos tamaño. Recordar que el tamaño máximo de un documento MongoDB es 16MB.

El sharding es un proceso paulatino y asíncrono que puede tardar días y hasta semanas en completarse, dependiendo del volumen de datos, y no interfiere con el funcionamiento de la base de datos; se puede ejecutar en sistemas en producción.

Consultas (queries)

Las consultas que ejecutamos contra un sistema particionado son de dos tipos:

targeted queries, vendría a ser como consultas objetivas, y son las que contienen la clave de sharding, y que pueden ser dirigidas por mongos al shard que contiene los datos relevantes.

Por otro lados las consultas que no contienen la clave, se deben de mandar a todos los shards y se conocen como broadcast o scatter-and-gather, (algo así como desparramar-reunir), ya que son consultas que se lanzan o desparraman entre todos los shards para finalmente reunir los resultados.

Habilitando un sistema de `sharding`

Mientras que el sharding se habilita a nivel base de datos es importante entender que el mismo se ejecuta a nivel de colección. Más abajo describo algunos métodos.

Podemos utilizar la clase ShardingTest del servidor de MongoDB que instalamos con la versión Community, para crear un cluster de prueba. Es una clase que se usa internamente, para hacer pruebas de sharding, pero que está expuesta para uso externo. Podemos ver la implementación, aquí.

Nota: Es importante saber que esto está disponible solo para la versión anterior de la herramienta de linea de comandos mongo y no para mongosh. Intentaré para el siguiente post encontrar tiempo de cargar los scripts y snippets de compatibilidad para la clase y jstest, pero no prometo nada!)

Lo primero que hacemos es inicializar la consola de mongo



mongo --nodb --norc

con los parametros --nodb y --norc para no inicializar una base de datos ni la evaluación de JavaScript.

Luego podemos crear un par de shards de test así



testdesharding = ShardingTest({
  name: "TestdeSharding",
  shards: 2,
  chunkSize: 1
});

Nota: Si esta clase nos da un error de boost relativo a la no existencia de la ruta data/db, se la podemos pasar al task runner así

MongoRunner.datapath = 'mi-ruta/es-tu-ruta/data/path';
(hay gente que va a entender la referencia y otra que no...jaja)

Hay muchísimas más opciones de configuración que podemos pasar a la hora de crear nuestro cluster de test, que están descritas a partir de la línea 8 del script. Entre ellas encontramos:

name (nombre del cluster)
shards (número de shards)
rs (al que podemos pasar un objeto de configuración para cada conjunto de replica, como cantidad de nodos y tamaño del oplog)
mongos (número de mongos que se correrán)
chunkSize (el tamaño de cada chunk)
enableBalancer (si habilitamos el load balancer por defecto)
enableAutoSplit (si habilitamos la auto partición)

etc

Cuando ejecutamos esta clase de test, creamos un cluster y se inicializan los procesos necesarios, incluyendo mongos y los conjuntos de réplica configurados, así como el servidor de configuración.

Una vez creado el cluster, podemos probar los métodos de sharding, que se describen en la documentación oficial del software. También podremos experimentar con las diversas estrategias de sharding. Por defecto el proceso mongos corre en el puerto 20009, pero se puede reconfigurar.

Para experimentar, abrimos otra ventana o pestaña de la terminal donde podemos crear una base de datos e importar o crear algunos datos, para poder experimentar.

Esto es solamente para hacer pruebas y aprender. Si fuéramos a habilitar un sistema de sharding de MongoDB real, deberíamos seguir el proceso que se describe aquí.

Básicamente deberíamos inicializar todos los nodos por separados, primero que nada un conjunto de réplicas para el servidor de configuración, que se inicializa con el parámetro --configsvr (siempre antes que el proceso mongos). Otro nodo para mongos que se inicializa con el comando mongos y el parámetro --configdb (al que se pasan los datos de los servidores de configuración) Finalmente conectamos al que será el shard primario, asígnandole el rol a cada miembro con la opción --shardsvr, lo que deberemos repetir con cuantos nodos decidamos tener para los conjuntos de réplicas que conformaran cada shard.

Una vez tenemos todos los nodos activos, se pueden agregar al cluster de sharding manualmente con el comando

sh.addShard(//réplica set path + puerto);

al que pasamos cada réplica set individualmente.

Habilitar el proceso de distribución de datos

Una vez tenemos todo configurado, debemos habilitar manualmente el sharding para la base de datos.

sh.enableSharding("nombre_base_de_datos");

y seguidamente, particionamos las colecciones que decidamos

sh.shardCollection("nombre_base_de_datos.nombre_colección", {"clave_de_partición": 1})

donde clave_de_partición es la clave elegida, o sea un campo indexado de la colección.

Estrategias de `sharding`

Como comentaba anteriormente, la forma más eficiente de distribuir nuestros datos a través de múltiples shards, va a determinarse por medio de una estrategia de partición.

La estrategia de hash

La estrategia de hashing es la más eficiente a la hora de distribuir datos de manera balanceada. Los datos se distribuyen de manera aleatoria, asegurándose que hay el mismo volumen de datos en cada partición. Es la estrategia ideal cuando la intención es liberar espacio de disco y asegurarnos que los datos se distribuyen de manera equitativa.

La estrategia de rango

Esta estrategia es la más eficiente para distribuir datos de acuerdo a ciertos rangos. Por ejemplo, si estamos distribuyendo usuarios, los podemos distribuir en el rango de la A a la I, de la J a la Q y de la R a la Z, de acuerdo con la primera letra de su apellido.

Una desventaja de la distribución por rango, es la baja cardinalidad (hablaremos de cardinalidad cuando hablemos de indices) pero básicamente, como habrán muchos apellidos con ciertas letras, y muy pocos con otras, será difícil garantizar el buen balance.

La estrategia de zonas

Finalmente, podemos segmentar los datos ya distribuidos, por zonas. Las zonas pueden venir determinadas por el data locale, lo que permitiría distribuir geográficamente, o por otra variable. En el caso de usar la estrategia para distribuir geográficamente, un shard que se encuentre desplegado en cierta región del mundo guardará los datos de los usuarios que pertenecen a esa región. Esta estrategia nos ayuda a cumplir con políticas de protección de datos, por ejemplo, pero al igual que la estrategia de rangos, puede incurrir en un desequilibrio de las particiones.

En el próximo post

La próxima entrada será más corta e intentaré explicar sobre todo,

Sharding en Producción
Particionamiento en CosmosDB y como difiere con MongoDB

A prestar atención!

Bases de datos y el modelo de documento

Natalia Venditto — Mon, 25 Apr 2022 19:45:05 +0000

No sé si un blog en español va a funcionar en esta plataforma...pero, por qué no? En diciembre del año pasado dejé mi puesto como arquitecta de soluciones con MongoDB, para irme a Microsoft, a trabajar en experiencia y herramientas de desarrollo, para desarrolladores JavaScript en Azure. Una de las cosas que me apenó bastante, era que me había comprometido a escribir sobre MongoDB en español, y no había encontrado tiempo. Sé que suena como una excusa terrible, pero realmente estoy más ocupada de lo que me gusta admitir.

Sin embargo, no quería dejar de hacer esto. Sobre todo mientras la información está fresca en mi cabeza. ¿Por qué? Bueno, realmente soy una fan del modelo documento y ahora mismo, uso la API de MongoDB con CosmosDB, constantemente. Inicialmente iba a hacer videos, pero llevan una cantidad de tiempo increíble, y era realmente inviable.

Advierto que la información es bastante y seguramente no va a caber toda en un post único. Intentaré no demorar mucho entre post y post, pero no puedo prometer nada.

Empecemos por el modelo.

MongoDB como base de datos, fue concebida realmente para solucionar un problema que sus creadores venían experimentando ellos mismos, y que era obvio era general a toda la industria. Las bases de datos SQL eran cada vez menos compatibles con nuevos casos de uso, eran (y son) difíciles de escalar, necesitan capas intermedias entre la base de datos y la de la aplicación (conocidas como ORM u Object Relational Mapping) y además, son poco idiomáticas. Con esto quiero decir que cuando escribimos aplicaciones, generalmente creamos entidades que se describen como objetos con ciertas propiedades o atributos, métodos, etc. Representar esos objetos y la relación de los mismos con otros objetos, mediante tablas, no es precisamente fácil para aplicaciones complejas.

...las bases de datos SQL eran cada vez menos compatibles con nuevos casos de uso, son difíciles de escalar, y necesitan capas intermedias entre la base de datos y la de la aplicación, conocidas como Object Relational Mapping

Y no sólo eso. Las aplicaciones modernas generalmente hacen peticiones a través de APIs (mayoritariamente REST) que típicamente devuelven los datos en formato JSON. JSON es verdaderamente el estándar abierto de intercambio de información, más utilizado en redes. Así que...¿por qué no crear un tipo de base de datos que utilizara el mismo formato? Pues los creadores se abocaron a ello, y así nació MongoDB (que es una abreviación de la palabra en inglés 'humongous', que quiere decir algo así como 'enorme', porque realmente MongoDB siempre estuvo pensada para alojar grandes volúmenes de datos y para poder escalar de manera simple).

...MongoDB siempre estuvo pensada para poder escalar de manera simple y alojar grandes volúmenes de datos

Pero, como casi todas las soluciones, habían algunos problemas. A pesar de que JSON era idiomático y fácil de entender para todos los desarrolladores, y de que los documentos eran fáciles de crear y modificar, se podían anidar subdocumentos para establecer relaciones, (hablaremos más de relaciones y consistencia cuando hablemos de patrones de diseño), y otras ventajas a nivel flexibilidad, JSON no ofrece demasiadas opciones en lo que se refiere a tipos de datos. Por lo tanto, si bien a nivel humano es fácil de escribir y entender, no es eficiente a la hora de guardar los datos en sí.

JSON es rápido a la hora de leerse y su tamaño es bastante pequeño, pero no ofrece demasiadas opciones en lo que se refiere a tipos de datos. Por lo tanto, si bien a nivel humano es fácil de escribir y entender, no es eficiente a la hora de compilar o guardar los datos en sí

BSON como estándar abierto, para guardar otros tipos de datos

Y así se creó BSON (Binary encoded JavaScript Object Notation), como una manera de codificar JSON, para extender los tipos nativos de JSON: además de tener cadena (string), boleano (boolean), numérico (number), arreglo (array), objeto (object) y null, BSON ofrece tipos binarios, decimales de 128 bits, fecha (date), id de objeto (objectId), etc.

BSON puede compararse con otros Protobuffs, o protocolos de buffer, que se usan para serializar y deserializar datos* estructurados, pero a diferencia de los mismos, no exige un schema, lo que se traduce en una mayor flexibilidad a la hora de guardar datos.

(*) El proceso de serialización es el de codificar un objeto (y el de deserialización, el de decodificarlo), para que se encuentre en un formato más adecuado ya sea para su transmisión a través de una red, lectura por parte de un sistema informático o un humano, o su almacenaje.

La diferencia más significativa es que BSON tiene más tipos de datos, y es más rápido de escribir y compilar en la base de datos, mientras que JSON es más fácil de leer para humanos y computadoras, además de tener un tamaño más pequeño

Podemos ir a la documentación de MongoDB, para obtener una comparativa entre los dos estándares.

Comparativa (o contraste) entre una base de datos SQL o relacional, y una base de datos de modelo de documento

A pesar de las diferencias, una base de datos es...bueno, eso. Es un software que opera sobre un sistema informático, para almacenar datos. Y todas las bases de datos tienen, a pesar de sus diferencias, muchas cosas en común. Por ejemplo, si queremos comparar MongoDB con una base de datos relacional clásica, el mapeo de terminología y conceptos, sería el siguiente:

Modelo Relacional	Base de datos	Tabla	Fila	Columna	Clave	Valor	Vista
Modelo de Documento	Base de datos	Colección	Documento	Campo	Campo	Valor	Vista

Vamos a ver más equivalencias, a medida que progresemos.

Anatomía de un documento

Ahora que entendemos un poco más sobre datos, vamos a enfocarnos en los documentos en sí. Un documento del modelo documento (valga la redundancia), tiene estás características en su formato JSON.

{ 
   "field1" : "valor (string)",
   "field2" : "valor (boolean)",
   "field3": [valor(number), valor(number), valor(number)],
   "field4": { "valor": "string" } // (object) -> también conocido como subdocumento, si tiene su propio identificador
   //etc
}

Donde podemos decir que el nombre del campo se corresponde a una clave o key en una base de datos relacional, y el valor corresponde al valor, que tiene un tipo. Cuando necesitamos convertir un valor a un tipo no soportado por JSON, pero soportado por BSON, generalmente efectuamos un "casting", ya sea a nivel driver (o aplicación) o durante el formateo del documento. Por ejemplo, todos los documentos guardados en una base de datos MongoDB, necesitan un identificador único, del tipo ObjectId. Al deserializar, la base de datos mostrará ese valor como un objeto anidado con esta estructura:

{
   "_id": {"$oid":"61bf540215c38f38aff7f352"}
}

Cuando creamos un documento en MongoDB, sin guardar ningún tipo de datos en él, por ejemplo con el comando

db.[collection].insertOne({})

la base de datos le asignará un campo "_id", con un valor aleatorio y único, de manera automática.

Ese comando es parte de las operaciones CRUD de la API de MongoDB. No importa que ahora no entiendas lo que hace ese comando. Hablaremos de las operaciones CRUD, más adelante.

Bases de datos distribuidas y la consistencia eventual

Además de ser diseñada para grandes cantidades de datos, (y quizás por esa misma razón) MongoDB fue diseñada como una base de datos distribuida. Es decir, a diferencia de las bases de datos tabulares, que son difíciles de distribuir de manera optimizada, MongoDB fue creada específicamente con la distribución en mente.

Para entender cómo funciona MongoDB a nivel distribución y consistencia, hay que tener en mente el Teorema de CAP. En resumen, este teorema propone que cualquier almacenamiento de datos distribuido solo puede ofrecer dos de las siguientes tres garantías:

Consistencia - cada petición va a obtener la escritura más reciente o un error.
Disponibilidad - cada petición va a obtener una respuesta y nunca un error, pero sin la garantía de que esta contiene la escritura más reciente
Tolerancia a la partición - El sistema va a continuar operando a pesar de que algunos mensajes entre nodos se pierdan o se descarten. En caso de fallos el sistema debe decidir entre disminuir la disponibilidad (cancelando la operación) o mantener la disponibilidad, sacrificando así la consistencia.

MongoDB es un sistema particionado, con lo cual continúa operando, y por defecto da más prioridad a la consistencia que a la disponibilidad, ya que todas las lecturas y escrituras se realizan por defecto al nodo primario. Sin embargo esto se puede reconfigurar cambiando lo que se conoce como write/read concerns volviéndose así la base de datos eventualmente consistente.

MongoDB y la alta disponibilidad

La alta disponibilidad es realmente necesaria para satisfacer la mayoría de casos de uso de las aplicaciones modernas, sobre todo en un mundo donde el alto rendimiento y la inmediatez son lo mínimo que un usuario medio espera.

¿Y cómo resuelve MongoDB este requisito, a pesar de estar diseñada para distribuir nodos a través de diferentes centros de datos e incluso proveedores de nube? Bueno, vamos a empezar por un ejemplo donde NO estamos distribuyendo un sistema, sino que lo inicializamos localmente.

Para eso, vamos a instalar MongoDB en nuestros ordenadores. Lamentablemente la documentación de MongoDB está solo en inglés y no tengo capacidad para traducir las instrucciones de instalación para cada sistema operativo, pero les dirijo a la página:

https://www.mongodb.com/docs/manual/administration/install-community/
https://www.mongodb.com/products/shell
https://docs.mongodb.com/database-tools/?_ga=2.100697729.1601885193.1650825625-818649307.1634902066

Lo que vamos a estar instalando es la versión community, o gratuita, la herramienta de línea de comandos y las utilidades.

Yo voy a utilizar además la extensión oficial de MongoDB para VS Code, para cualquier operación sobre las bases de datos y para trabajar con documentos.

Trabajando con la terminal (Mongo Shell)

Como ya mencioné antes, no voy a explicar cómo instalar MongoDB. Aunque la documentación oficial está en inglés solamente, hay bastante información en la internet al respecto como para que lo puedan lograr sin problemas. Sin embargo, si por alguna razón encuentran problemas, por favor comenten abajo. Seguro que alguien de la comunidad les ayuda.

Cuando instalamos MongoDB localmente, y luego de configurarla, lo que estamos instalando es el servidor que va a correr el proceso mongod.

Si ya saben lo que es un proceso y especialmente un proceso daemon, se pueden saltar esta parte. Esto es para quienes no lo tienen tan claro.

El proceso mongod

MongoDB corre varios procesos y uno de ellos es mongod, el proceso daemon primario del servidor, que se encarga de todas las peticiones, el manejo y procesamiento de datos, el acceso, además de -como todo daemon- correr operaciones en una capa profunda de fondo. Es una buena práctica denominar a los procesos daemon con una d al final, que facilita su identificación como tal.

Cuando ejecutamos mongod en la Mongo Shell, incializamos el proceso con los valores por defecto, es decir el puerto será 27017 los datos se almacenarán en /data/db. Estos valores por defecto (así como todos los demás) son reconfigurables. Por ejemplo, si queremos inicializar el servidor en otro puerto TCP y guardar los datos en otra ubicación, podemos ejecutar mongod con las siguientes opciones

mongod --dbpath /mi/ruta/elegida/ --port 28001

El proceso se puede parar en cualquier momento, como cualquier otro proceso, típicamente con ctrl+C o mongod --shutdown. Hay métodos adicionales en otros contextos, que exploraremos más delante.

MongoDB standalone o nodo único

Cuando nosotros inicializamos mongod como proceso, estamos inicializando un proceso, es decir, un nodo único. Este nodo es un nodo primario, con todas las capacidades del nodo primario de un conjunto de réplicas, excepto, la de mudarse a otro nodo, en el caso de un fallo de sistema.

Esto lo podemos verificar, ejecutando rs.status() en la terminal. Cuando lo hacemos, obtendremos esta información, que básicamente nos dice que no estamos ejecutando un sistema de conjunto de réplicas.

No te preocupes si no has entendido nada. Lo explicaremos. Antes de describir el proceso de instalación y lo que es mongod, estábamos hablando de alta disponibilidad. Alta disponibilidad, en lo que refiere a sistemas en la nube, se refiere a la capacidad de un sistema de recuperarse ante un fallo, eliminando los puntos potenciales de fallo único. Y para eso, hay que implementar lo que se conoce como redundancia.

Alta disponibilidad, en lo que refiere a sistemas en la nube, se refiere a la capacidad de un sistema de recuperarse ante un fallo, eliminando los puntos potenciales de fallo único, a través de la redundancia.

Redundancia y replicación

La redundancia implica tener varias copias de un sistema, en un estado idéntico, de manera que siempre exista una copia disponible. En MongoDB, eso se logra a través del sistema de replicación y los conjuntos de réplicas.

Si bien cuando por defecto inicializamos un proceso mongod, estamos inicializando un nodo único y primario (es decir un nodo único que recibe todas las lecturas, efectúa todas las escrituras, y todos los procesos alternativos), las buenas prácticas con MongoDB, especialmente cuando pensamos en sistemas distribuidos geográficamente y a través de varios centros de datos, exigen que optemos por una arquitectura -como mínimo- PSS, que se entiende como Primary, Secondary, Secondary.

Esta arquitectura describe una instalación de MongoDB, donde encontramos un nodo Primario, que por defecto recibe todas las lecturas, y efectúa todas las escrituras, y las replica a dos nodos Secundarios, que van a tener una copia exacta del primario.

Es decir, no hay que confundir replicación con particionamiento de datos. La replicación es el sistema fundamental que soporta la alta disponibilidad, mientras que el particionamiento de datos (tener diferentes sets or conjuntos de datos distribuidos entre diferentes máquinas -ya sean físicas o virtuales, y lo que en MongoDB (y otros sistemas) se conoce como sharding, son dos conceptos con aplicaciones y requerimientos diferentes).

El requerimiento de Alta Disponibilidad se satisface en MongoDB con la Replicación, que es igual a redundancia, o a tener copias idénticas de un conjunto de datos único, en un conjunto de varios nodos.

Las arquitecturas de los conjuntos de réplica, admiten desde 3 hasta 50 nodos, con una recomendación de al menos 3, 5 o 7 (dependiendo del volumen y del tipo de distribución), donde un máximo de 7 nodos participarán del proceso de recuperación a través de una elección del nodo primario, en caso de que este falle.

El proceso de replicación

El proceso de replicación es un proceso asíncrono, en el que los nodos secundarios replican los datos del primario. Existe una sincronización inicial, donde el primario vuelca todos sus datos a los sencundarios. Posteriormente la replicación continúa en un proceso mediante el cual los secundarios van leyendo y reescribiendo en su propio oplog el oplog del primario, y luego efectuando los cambios en disco.

Cada vez que (y solamente cuando! Pregunta de examen!) se modifican datos, el primario escribe una entrada en su oplog, que luego se copia al oplog de cada secundario para que este pueda sincronizarse, siempre y cuando el secundario no sea del subtipo árbitro.

Subtipos de secundarios

Existen subtipos de secundarios.

secundario de prioridad != 0 - No es propiamente un subtipo, pero es el por defecto. La prioridad establece qué tan probable sea que este secundario se convierta en nuevo primario, en el evento de un fallo del primario.
secundario de prioridad 0 - Cuando creamos un secundario y le damos una prioridad diferente de 0, este guarda datos y puede recibir peticiones de lectura, pero nunca podrá ser elegido nuevo primario.
secundario árbitro (arbiter) - este secundario no puede escribir datos ni recibe peticiones de lectura, ni tampoco ser primario, solamente se usa para desempatar la votación en el caso de elecciones.
secundario escondido (hidden) - este secundario está escondido a la aplicación. mantiene una copia del primario y puede votar, pero no puede volverse primario. Se suele usar para workloads o tareas específicas, como procesamiento de análisis de datos.
secundario con retraso (delayed) - este secundario se debe mantener escondido y con prioridad 0, para que no se vuelva un primario, ya que es un secundario que mantiene una sincronización con un cierto tiempo de retraso con respecto del primario. Se suele usar como estrategia de respaldo.

Fallo del primario y elecciones

Hemos dicho que una arquitectura MongoDB que sigue buenas prácticas, va a ser al menos PSS, es decir va a contar con 3 nodos. Pero ahora que conocemos los subtipos, tenemos que tener en cuenta que cuando decimos 3 nodos, nos referimos a 3 nodos con la capacidad de votar y ser elegidos primarios. Hemos dicho que podemos tener hasta 50 nodos, y que cuántos decidamos tener, va a depender de nuestros requerimientos. Otra vez, recordar que esos 50 nodos tienen todos exactamente la misma copia de los datos. Aunque puede ser que la latencia entre nodos afecte la replicación, en nanosegundos, milisegundos, segundos, o incluso minutos.

Sin embargo, lo habitual es tener 3, 5 o 7 nodos (que votan). La cantidad de nodos que votan, siempre tiene que ser impar, con un máximo de 7.

Tenemos que tener en cuenta que cuando decimos 3 nodos, nos referimos a 3 nodos con la capacidad de votar y con la capacidad de convertirse en primarios. La cantidad de nodos que votan, debe ser siempre impar, con un máximo de 7

¿Y por qué tiene que ser impar? Para prevenir empates si ocurre una elección.

El procesos de elección y la conmutación automática del primario

En el dibujo de arriba vemos unos corazoncitos. Estos representan un latido o heartbeat, que es el proceso que identifica el estado de cada nodo, en todo momento. La frecuencia es configurable y lo que ocurre en el caso de no detectar un latido es lo siguiente:

si el primario no detecta latidos de uno de los secundarios, de modo que no se pueda garantizar la mayoría, se convertirá automáticamente en secundario.
si un secundario no detecta el latido del primario, se auto-nominará primario. En ese momento, cualquier otro secundario votante de la réplica intentará conectar con el primario, para verificar que el secundario que se intenta promover no ha dejado de percibir latidos por un problema de conexión o de red.
Si este secundario comprueba que el primario realmente ha caído, entonces empezará un proceso de verificación del estado del secundario que se quiere promover, para validar su estado tanto de salud como de versión de datos, con respecto al oplog del primario que falla.
Una vez han terminado las comprobaciones, el secundario que se ha promovido, es votado y pasa a ser el primario, mientras que el primario que ha fallado, se vuelve secundario y comienza su proceso de auto-reparación.

Todo este proceso dura unos 4 segundos, en condiciones óptimas.

Evitar la perdida de escrituras durante una conmutación automática

Para evitar la pérdida de datos, en el momento de una conmutación, debemos haber habilitado los reintentos de escritura a nivel aplicación o driver, con la opción

retryWrites=true

Hay que tener en cuenta que los reintentos de escritura no son posibles para los concerns de escritura equivalentes a 0, ni a nivel individual durante una transacción (hablaremos de transacciones cuando hablemos de soporte ACID), ni en los sistema de un nodo (standalone).

Más sobre el Oplog

Hemos hablado de cómo los nodos de una réplica se sincronizan a través de la copia de operaciones que modifican los datos, que se registran en el oplog del primario, se copian a los oplogs de los secundarios, y finalmente se ejecutan a nivel de disco.

El oplog es una colección especial y capada (es decir, tiene un límite de bytes disponible) que define lo que se conoce como la ventana del oplog o retención de datos. Solo las operaciones que están dentro de la ventana son recuperables.

Para decidir el tamaño del oplog y de la ventana del oplog, hay que evaluar la intensidad y cantidad de operaciones que modifican el set de datos (inserts, updates, etc), en un determinado periodo de tiempo. El oplog se puede configurar por tamaño en bytes (generalmente MBs o GBs) o en horas. Para la configuración en bytes, se suele reservar 5% del espacio en disco para el oplog.

Para decidir el tamaño del oplog y de la ventana del oplog, hay que evaluar la intensidad y cantidad de operaciones que modifican el set de datos (inserts, updates, deletes, etc), en un determinado periodo de tiempo.

Las operaciones guardadas en el oplog, serán removidas siempre y cuando el oplog esté lleno o haya superado el tiempo ventana, first in, first out.

Write concerns (materia de escrituras)

La verificación de escrituras de un conjunto de réplicas, se determina por su definición de write concern.

Una configuración igual a w: "majority", establece que el reconocimiento de las escrituras, se debe haber propagado a una mayoría calculada en base al total de nodos que guardan datos y son votantes, antes de ser efectivas.

Si w: 1, entonces el reconocimiento del nodo primario es suficiente, para que la escritura sea efectiva. Un concern diferente de w: 1, conlleva degradación de rendimiento, pero aumenta la consistencia.

Un concern diferente de w: 1, conlleva degradación de rendimiento, pero aumenta la consistencia.

Crear y configuar un set de réplicas con la terminal

Lo primero que vamos a hacer es crear cada nodo del set de réplicas, de manera independiente.

Creamos tres nodos con la siguiente configuración

mongod --replSet nataliaRS --logpath "rsnode1.log" --dbpath rsnode1 --port 27017

mongod --replSet nataliaRS --logpath "rsnode2.log" --dbpath rsnode2 --port 27018

mongod --replSet nataliaRS --logpath "rsnode3.log" --dbpath rsnode3 --port 27019

Es decir, inicializamos tres procesos mongod, pasando la opción --replSet a la que en mi caso doy el valor nataliaRS que será el nombre del conjunto, le asignamos una ruta para el log y otra para los datos (ojo! que tiene que existir!), y a cada una un puerto.

Luego verificamos que los tres nodos están corriendo su proceso

Y ahora describimos la configuración con la que vamos a inicializar el conjunto de réplicas.

Primero inicializamos el REPL de la línea de comandos con el comando 'mongo'. Y luego creamos un objeto conf de la siguiente manera:

config = { 
  _id: "nataliaRS",
  members: [
     {_id: 0, host: "localhost:27017"},
     {_id: 1, host: "localhost:27018"},
     {_id: 2, host: "localhost:27019"} 
  ]
};

Este objeto se lo pasaremos luego al método de replicación rs.initiate() del la API de esta manera.

rs.initiate(config);

Si el objeto de respuesta tiene un valor 1 para el campo ok, podemos asumir que el conjunto de réplicas se ha creado correctamente. También podemos ejecutar rs.status() para obtener información sobre el estado del conjunto y sus miembros.

Se pueden agregar posteriormente más miembros al conjunto, usando

rs.add(server)

(donde server tiene que ser un proceso mongod)

Si necesitamos reconfigurar la réplica y sus miembros, podemos hacerlo de esta manera. Supongamos que queremos cambiar la prioridad del nodo secundario de _id = 1, que sabemos que está en el ínidice 1 del array members: lo podemos hacer especificando el _id o de esta manera.

Primero asignamos la configuración actual a una variable, en este caso la llamaremos cfg, que es una convención en la documentación.

cfg = rs.conf();

Y luego procedemos a reasignar el valor

cfg.members[1].priority = 3;
rs.reconfig(cfg);

Podemos ver que el conjunto de réplicas funciona correctamente, y crear una base de datos, una colección y un documento que después de la sincronización, serán accesibles desde cualquiera de los nodos de la réplica, que sean de escritura.

Podemos ver que el documento es accesible desde el nodo que corre el proceso en el puerto 27017, así como en el que corre el proceso en el 27018 ( y también lo será en el que lo corre en el 27019)

Más métodos replicación, se describen en la documentación

Buenas prácticas para conjuntos de replicas

Para terminar, hay que hacer incapié en que es importante seguir buenas prácticas al diseñar nuestras arquitecturas de conjuntos de réplicas, para poder garantizar la alta disponibilidad o la consistencia eventual, dependiendo del caso.

Es importante tener una buena política de retención de datos, que gobierne nuestras decisiones en cuanto al tamaño y ventana de oplog.

https://www.mongodb.com/docs/manual/reference/method/js-replication/ Si se distribuyen a través de varios centros de datos (regiones o zonas), es importante que hayan al menos dos nodos en el mismo centro, para impedir que las interrupciones de conexión o la latencia, nos den falsos positivos.

Es también importante habilitar los reintentos de escritura y, dentro de lo posible, no abusar de los nodos árbitros y utilizarlos de manera eficiente. Tener un árbitro, un secundario y un primario, no garantiza la alta disponibilidad del sistema.

En la medida de lo posible, los nodos dedicados a tareas exclusivas (isolated workflows), deben esconderse.

En los próximos blogs

Operaciones CRUD
Patrones de diseño
Marco de Agregado
Sharding
Wired Tiger y caching
CosmosDB para MongoDB API

y más...

Si te ha gustado el artículo, compártelo y dale like aquí en dev.to! Una versión en inglés de este artículo estará disponible pronto en GitHub, para ser traducida a otros idiomas.
Por favor, da crédito a https://www.github.com/anfibiacreativa si lo usas! <3

Cuídense mucho!

CSS z-index illustrated

Natalia Venditto — Tue, 27 Jul 2021 15:21:04 +0000

My followers know that I no longer work as a frontend developer, however, I worked as one for nearly 15 years and I was self-taught. I was lucky to have a background in architecture, CAD and graphic and 3d design, so grasping the more mathematical (or in this case geometrical) aspects of putting together a layout, was not difficult for me. However, I see that for self-taught developers coming from completely unrelated backgrounds, the z-index is a tough one to grasp.

This is my attempt at explaining it in an illustrated way.

Most people will be familiar with the concept of cartesian coordinates. They are used to define the location of a point in either a line (2d) or in space (3d). If you drive and use Google Maps, you are probably familiar with geospatial coordinates, or longitude and latitude; the points we use for locations on maps or Earth.

2d or two dimensional

In 2d, we have the y-axis, and the x-axis. From their convergence, the point (0,0), we can then specify where another point is located. Typically the y-axis defines the vertical location, and the x-axis the horizontal location of a point.

If we have several points that define a shape, like a box, then we can define its dimensions AND its location, using coordinates.

This is basically how we do layout with css, defining the dimensions and location of elements with respect to those two imaginary lines that come defined by the edge of the viewport.

We understand y=0 as the top of the browser viewport, and x=0 as the left edge (when left to right), so (0,0) would be the most top-left point as we load the page (considering it is not programmatically scrolling to another x,y location).

Layout and the box model

When we are adding new elements to the markup of a page, by default they're added to the default context (I will explain context later in the article). They will follow the document flow and be stacked on top of each other, in the same order they are added to the document.

So if we had 3 block elements like divs for example, added to a document like you see in the figure below, if we could see them from the side in terms of an imaginary vertical stack, they would be stacked in this way:

But what would happen if you added a child to div number 2, and give it a top margin to move it on top of div 3 in the y-axis? That "overlapping" bit would be hidden by div 3, and that's expected, since in terms of markup div 3 is coming after div 4 in the document flow.

z-index: 99999999999 !important will help...NOT

Many developers new to frontend will try to fix this using the z-index property, with a very high positive value (or maybe negative, supposign they wanted to completely hide the div 4). But that on its own, won't work.

EDIT: Originally I had written -> "If you don't create a new stacking context, z-index won't work, no matter how many 9's and !importants you add." ** I will address Temani Afif comments below, stressing this: the new stacking context is created when position is set to ‘fixed’, ‘sticky’ or ‘relative’ and z-index is set to anything other than ‘auto’. Position on its own removes the element from the document flow, which means it no longer follows the order in the markup as elements are painted. However, it remains in the same stacking context.

Understanding stacking contexts

Let's port that two-dimensional representation of cartesian coordinates, to a three-dimensional or spatial one. As you probably guessed, now we have 3 points that specify the location of a point: (x, y, z)

A stacking context is each new layer added to that z-axis, that you can now reorder, to bring elements on top or place them below the default context or other contexts.

The order comes defined by the index, that can be 0, a positive integer or a negative integer or auto.

I advise you now head to the official documentation on MDN, and read all you can about stacking contexts. But in a nutshell, you create a new stacking context by giving a container div the following properties and values:

you give it an opacity different than 0
you give it a position other than static, and a z-index other than auto
you give it display either flex or grid, and a z-index other than auto
you use transform, perspective, filter, clip-path or mask
or you use some of the brand new properties, such as isolate(with a value of isolate), will-change, or contain.

That's all folks! I hope you find it useful and don't have to struggle with z-index issues anymore! Also if this article has an error or you want to suggest an improvement, do it in the comments!

From developer to (solutions) architect. A simple guide.

Natalia Venditto — Wed, 21 Jul 2021 17:36:54 +0000

So you don't have formal CS education and have been doing development for some years, or you are a junior but your manager has already asked you where do you see yourself in tech in a few years. You want to become an Architect, but you are not sure of what it takes and you want to have a better idea of what you should focus on. You want to understand where are your technical gaps and what soft skills are required. This article is for you!

Architect is an umbrella term to designate a role that is focused on either designing or refining software solutions for the benefit of the customer. But it has different accountabilities, depending on the organization you work for.

Pre-Sales Solutions Architects

Pre-Sales Solutions Architects can also be called Customer Engineers or Sales Engineers, and are usually focused in making sure a technology they represent fits a customer's use case and their required capabilities, while they help them design a system to integrate it, or give pointers about the best application of it. They'll work on high-level diagrams, do discovery, work in scoping, and give support to Sales reps during technical alignments.

Post-Sales Solutions Architects

Some of the pre-sales Architects, also do post sales, meaning that after you're done with the sales process, and a deal is closed, you focus in helping with the actual implementation. They may just design the systems at a high level and overview the implementation, or be very hands on, and execute it together with the technical implementation team.

Software Architects

Software Architect is a very hands on role, architecting and oftentimes implementing a software solution. Software Architects are an equivalent of the Post-Sales, usually for a product or specific technology. Software Architects are not necessarily customer facing.

Again, it's important to clarify that the designation and accountabilities for each role, may vary across the industry.

The technical common ground

No matter what type of architect, the common ground is the technical one. Architects are technical by nature, from a perspective that allows them to connect tech specifications to complex security requirements, governance nuances and privacy compliance and sovereignty, and legal liabilities. They are not concerned with the nitty-gritty details of the implementation, rather the big picture. Deployment pipelines, layers of the stack, performance at a system level, user management, locality, infrastructure components...those are the things that really interest and occupy an architect.

Process phases a Solutions Architect participates of

I work now in the role of Solutions Architect, and will focus on this particular dimension, since Software Architects are involved in processes pertaining the software development cycle, which is much more complex to describe.

Solutions Architects are usually a customer facing role and participate of and are instrumental to a lot of conversations with them. Their main goal is to discover and scope a system's requirements and/or current technical state as much as drafting the desired state and deciding or advising on the most ideal solution.

Discovery

SA's (acronym for Solutions Architect) participate of discovery. These are the early stages of conversation with a client, where many questions are asked. An SA needs to understand everything about their client, their product or project, their goals, their problems, so they can map those to tangible solution suggestions.

The most important skills at a discovery meeting are not technical: Solutions Architects need to be able to

listen more than talk
make good assumptions and validate them with the client
do not propose a solution ahead of understanding well all the problems and requirements
be very objective

Contrary to what many people think, even those architects that represent a brand, are unlikely to push for a biased solution if they assess that's not what the client needs. Not only your reputation is at stake, most architects pride themselves in promoting the foundations of a solid system

Foundations of a solid system

Solid, well designed systems share certain identical features. They all aim to be scalable, robust, resilient, recoverable and secure, among other important characteristics. Architects also want their systems to be highly available and sometimes they have requirements for them to be globally distributed, which is less of a problem today when global provisioning is guaranteed in the cloud.

Scoping

Requirements are the documented capabilities used to measure a systems success, according to whether or not they're satisfied. They usually map to those foundational concepts. Like for example, it may be a requirement for the system to have an uptime of a certain percentage (usually 99.995% for mission critical applications, which is about 4s downtime daily - you can calculate that SLA here https://uptime.is/). That requirement maps to High Availability.

The process of putting requirements and capabilities in scope, is also done by the architect, and usually (technically) validated by the customer with business objectives in mind, at some point. Backlogs are oftentimes the result of generating user stories and functional requirements directly from the scoping exercise, together with the validation and priorization of capabilities, towards a release.

What technologies should I focus on?

That is a difficult question to answer, since it will very much depend on the type of system a software or solutions architect is designing or assessing, the technologies may vary greatly. I will focus on describing a list of technologies and areas of expertise you may want to check out, if your goal is to become an architect working in web oriented solutions.

The cloud landscape

This is not to say there aren't architects still working on premise in self managed environments, but if you're planning to join the forces, you probably want to have an idea of who are the 3 public cloud providers (AWS, Azure and GCP), and their offering and topology.

You may also want to learn about cloud-native technologies, and explore what's hot and trending.

Additionally it's very useful to know certain jargon and how some mechanisms work in the cloud. Concepts like

what is a cluster
scaling out vs. scaling up
what are distributed systems and how they work
what are the caching mechanisms and the best practices in the cloud

Infrastructure and infrastructure provisioning

Provisioning infrastructure is not really the architect domain and it is usually done by the system engineers, Ops or other roles (the name may vary, depending on the organization). However, architects may have to validate or analyse the deployment pipelines and infrastructure setup before it is executed or afterward, for several reasons:

costs assessment
compliance with architecture definitions (security, performance, technology definitions, etc)
risk evaluation
reconfiguration

Although infrastructure provisioning, especially in the cloud, is provider dependent, there are some concepts you need to know and understand.

Networking

You will need to understand well how the internet works and all the layers involved. Some important concepts and focus areas would be

the Networking Layer Model per type (TCP/IP, vLab, ISO/OSI)
TCP/UDP/HTTP Protocols
SSL, TLS and other Networking Security concepts (Firewalls, Keys, VPN's, VPC, Private Link, Network Peering, etc and the OWASP checklist)

A book I definitely recommend to read to catchup with a lot of these concepts, is Computer Networking, a Top-Down Approach I had to read it when I was taking credits in Software Engineering, and it's one of the best books on the subject.

I also recommend you download and install Wireshark for packet sniffing or TCP analysis, to learn more about segments, headers, and other networking concepts. There are more sophisticated tools, but this one is great to get going. It's open source, free and a consolidated tool.

Hardware

Yes, you need to know about hardware. This is particularly important at the time of deciding on infrastructure configuration and if you detect performance issues and must scale up or down/out or in and system, to decide on the specifications. Concepts like

CPU, (disk) SDD and HDD, (memory) RAM(ø)
IOPS
RAID architecture
ports -very important for hexagonal architectures-

and concepts like

big and little endianness

Unless you actually work at a data center and walk in between racks, you probably don't need to know about other components like power supplies. Just the necessary specifications to match a software requirement. Although I always advise that the more you know, the better! But you also need to know about:

operating systems(ø)
virtualization (most servers are actually virtual machines on top of physical servers)
containerization and containerization and orchestration software (like Docker and Kubernetes)

(ø)I am not going to provide links to content about physical components of computers because there are way too many sources, and you only need to run a quick google search and pick the one that interests you the most.

One important piece of advise I can give you, is that whatever operating system you love the most, you probably need to be familiar with Unix and Unix-like systems and architectures, and be proficient in the use of the shell since it's the preferred means of executing code remotely, deploying packages and code and accessing systems.

Databases

The task of storing and manipulating data becomes more and more important, as applications are more and more user-centric. Storing data is not only about the software used for it. It's a key part of the success of an application. And architects need to be well aware of the

different data models and database architecture
tabular vs document
graph databases
object storage
physical requirements of the database software
limitations of certain models in relation to scalability
security implications of data flows

You probably want to investigate what product corresponds to what provider, and want to learn concepts like transactions and ACID compliance

You may think I'm biased, but I recommend you head to the MongoDB free learning platform aka MonogDB University, where there are tons of information on all those subjects, and a lot of it is -contrary to what many may think- very objective.

Architecture models

Well obviously, an architect needs to know about architecture! And architecture is an evolving and dynamic ground!

microservices
hexagonal architectures
monoliths
event-driven architecture
serverless architecture
jam stack

You need to know those concepts by heart and when they're the approach to follow. I am inclined to think that a good architect, just like a good developer, is never biased, and will try to find the right solution to a problem, instead of finding a problem to implement a preferred solution.

All those paradigms have software and technologies associated, that you may want to explore and experiment with. For example:

docker (containerization/virtualization)
kubernetes (orchestration/management of containers)
kafka (event-streaming platform)
serverless functions (very much provider dependent, are a way to execute functions on triggers and avoid large backend implemetations)

Needless to say that the many providers will have tools and connectors, modules and best practices or guidelines, to implement each different type of pattern according to their infrastructure architecture and offering.

Deployment pipelines and release models

Architects are usually in charge of designing deployment pipelines, that tend to depend on the application release model. If you are working with a continuous integration pattern, you'll probably have to support it with CI/CD automation tools. And the following concepts should be familiar to you

Actions
Triggers/Events
Infra as code

together with relevant software (again, options may be conditioned by the cloud provider choice)

In the realms of automation you may also have to design means of performing test-automation for different areas, ranging from code sanity to performance, and have to know about the implementation and configuration of tools like

SonarQube (code quality)
SolarWinds (performance monitorization or observability) and the likes

Access control and governance

Architects are for sure in many cases responsible for software/platform security, if not for its implementation, for its design or assessment.

It is important for architects to understand the many means of controlling access to software code bases and data, and the services provided by the applications they architect.

Architects know well the meaning of

authorization
authentication http://www.bu.edu/tech/about/security-resources/bestpractice/auth/

and have to understand the different ways to implement them, at an application level and low level, too.

It is desirable for architects to understand what vectors of vulnerability their apps or platforms, or the software they work with may be exposed to, in order to mitigate risks.

Governance has many meanings and implications and it's so intersectional I can only map it to the different dimensions it may connect to.

For example, designing role based access depending on authorization granularity is part of governance policies for access, while software capabilities providing the ability to set those rules, guarantee legal compliance with standards like ISO27001 or GDPR.

The API and application layers

Most modern architecture patterns for web development are very heavily API dependent. It is very likely that the software or platform an architect is responsible for, does not only consume from dozens of API's but also exposes some of them.

Needless to say, 100% of the tools I mentioned through the article, are API based, and so are most of the services exposed by cloud providers.

For this reason, architects need to be skilled on API design and maintenance, and very familiar with concepts and patterns like

REST APIs and JSON standards
GraphQL
SOAP (although less used now, many legacy systems still consume or expose SOAP services)
And other API alternatives like Java Servlets

And before you complain about the age of some of the mentioned API architectures, remember that a lot of times Solutions Architects assist in migrating Legacy Systems, and for that, they need to know what they're facing!

In order to effectively design and maintain, or even assess in-place solutions, it is very useful for architects to be aware of and implement the Open API specification and Swagger

Architects need to design the connection and sometimes aggregation of data coming from all those API's. For that reason, they also need to understand well how to consume them and distribute them, and need to know concepts like

north-south bound (API gateway)
east-west bound(service-to-service or service mesh)
proxy and reverse proxy

In terms of app development, it may not be necessary for architects to know or understand implementation details of high level languages, but most architects do anyway, since at a great percentage architects used to be developers.

High-level diagrams, UML and other types of diagrams

Architects speak in diagrams. Believe me. Oftentimes they need to represent very complex systems and relationships, and the only way to do it is being proficient at representing entities with shapes and arrows.

This is why architects learn

UML
Crow's Foot Notation and other representation schemas

Architects usually conduct and lead calls with customers, and they need to have great public speaking and presentation skills: from putting together impressive slide decks, to expressing complex technical ideas in a language everyone can understand.

Sales

Some organizations hire architects to be part of their sales processes, and advise sales reps and clients from a technical perspective.

Those organizations are very likely to offer training in their sales process and methodologies used, as well as ramping up the architects in a particular technology or software.

Will all my coding skills go to waste?

Absolutely NOT! I can speak from personal experience that all I have learned as a software developer, helps me quickly understand systems and decisions, analyse existing code bases and configurations, and build rapport with other architects and developers. Some solutions architects are required to build PoC's on a regular basis, and your coding skills are not only helpful but necessary.

Conclusion

Well, I know this is already very long, and this is only the tip of the ice-berg! Software and Solutions Architecture is a very rewarding career path and one that many developers follow when they don't want to move to more administrative, project or account management positions, and want to continue to be part of the technical scene.

Disclaimer: I added links to resources from pretty reputable sites, but if you want to contribute with better ones, add them in the comments!

If you have more questions, hit me on twitter, share and like!

From Designer to Software Engineer to Solutions Architect: my journey

Natalia Venditto — Fri, 29 Jan 2021 13:19:17 +0000

I want to start this post with the regular disclaimer: this is my journey, and everything about it, is intrinsically bound to my nature as a person. A different person, under the same circumstances, may experience something totally different and get different results.

To explain how I got here, I have to go all the way back to when I was studying to be a draftswoman, and was supposedly going to continue my education as a (buildings) architect. Somewhere down the road I fell in love with CAD, with computers and graphic design, and even got a job at a printshop after a Photoshop, Quark and Freehand crash course.

In 2003 I moved to Spain. Immigrating is difficult, especially when you have to support yourself entirely. But when I did I was lucky to have over 5 years of experience as a graphic designer, and it was easy for me to get a job working for a small agency as soon as I moved here. We published a magazine focusing on real estate and after a few months I was promoted to Creative Director to be in charge of the magazine and the corporate image of a few clients. I had a couple of designers in my team, and it was fun.

Plot twist

One year later, it was evident all business was moving online. Youtube was about to be born, Facebook was in diapers, and everyone wanted to have online presence. I convinced the manager we should have a website, and we should try to build an online version of the magazine as a portal.

"We need a web developer for that" -he said. "I will be the web developer". I answered.

I started spending all my spare time learning Action Script. I was amazed at those full screen Flash websites, featuring gorgeous animations and graphics. I wanted to learn to do that. For the portal, I learned HTML, CSS, Javascript, PHP and mySQL. I was amongst the first avid consumers of online tutorials and web development books.

I experimented with Joomla, Wordpress, and finally Drupal.

And then the 2007 crisis hit us hard

We could keep the boat afloat selling websites, exclusively. I would be in charge of designing the websites, managing the databases, the hosting, setting DNS records, configuring htaccess, installing the CMS and plugins, developing frontend, and doing the maintenance. I was a true "webmaster" of the time. I loved it!

But in 2011, we hit rock bottom. Most of our clients were developers and real estate agents, that bursted together with the real estate bubble. They had to close business, and so did we. I started freelancing.

Being a freelance web developer, is a 24/7 job

If you're not working as a consultant for a much larger company and you have your own clients like I did, it's tough work. You're the sales person, the architect, the PM, the designer, the developer, the quality engineer, the tier 1 to 4 support person, the systems person, and the back office cashing the checks...you're it all. There are no evenings, no weekends...

Being a mom and a freelancer, was the most challenging thing I ever did. I breastfed my kid while patching 10 Drupal sites for heartbleed. I ran to school while holding a call with a client.

Getting a job in enterprise

So in 2014 I sent my CV to a consultant company (the same one I work for right now), with little hope. I had no CS degree, and all I had read around was I stood no chance to land a job in that league.

But I did land the job as a Frontend Developer for Adobe Experience Manager projects. I had to move to Barcelona, with my family. It was an immense bet. And you can say fortunately, it went well. Although it was not only fortune: there was always a lot of hard work involved.

It was not only fortune. There was always a lot of hard work and persistence involved.

The enterprise context has particularities, also. Working on enterprise you also learn a lot about politics, policies and processes. ;)

Getting acquainted with Adobe Experience Manager

Up until that day, Adobe was for me the company behind Photoshop, period. (Aaaand the company that had bought Macromedia and decommissioned my favorite ever vectors editor, Freehand ... :/ ) I had no idea they had also bought Day Software and had a CMS.

I was very comfortable with content management systems, and it did not take me too long to wrap my head around how it worked. Some frontend developers want to stick to frontend code only, and it's respectable. But I was coming from a different kind of dynamics (see the freelancer part!) and I was happy to traverse the whole stack.

My first role was as a Frontend Tech Lead for a very large platform being built from scratch. One year later, I was moved to a banking platform where I stayed for 6 months. Then I was assigned to a new account we had just gotten, as a tier 3 support and solutions engineer for a massive legacy platform. I was again in the role of Frontend Tech Lead, and I know a lot of people dislike working with legacy software, but I can promise you the amount of knowledge I was getting every single day working with it, was priceless.

The amount of knowledge I was getting every single day working with legacy code was priceless; the problems I had to solve were unique.

In my opinion, no other experience is better to understand coupling, dependencies, and acquire an overall overview of a system.

Plot twist, again

Apart from support, we were integrating new features, and at some point we decided we did not want the risk to build anymore on top of it, we wanted to go for cutting edge technologies. So a little bit more than a year later I got my first architect gig, working in the conceptualization and definitions of the 2.0 version for the same platform.

I fell in love with designing systems. It is a lot like building with legos. And I could apply principles learned while studying to be a buildings architect. After all, you want the same for your buildings than you want for your systems, for them to meet quality standards, to be resilient, secure and durable, amongst other things.

My first pre-sales experience was intense

In August 2017 I also attended my first RfP workshop. A global leading brand issued a RfP (request for proposal) for a very large enterprise project and I helped in putting together the whole DevOps strategy, and then travelled onsite, together with the Account Manager, a UX Engineer, and two C-levels, to defend our proposal.

I had to present the whole DevOps offer.

We won.

Conferences and public speaking and how they help me in being a better architect

Being an architect is a lot about communicating. You have to communicate your ideas and definitions or decisions to a team, other project leads and the clients. Translating those very technical concepts into simpler words and concepts any audience can understand demands highly developed communication skills. You need to be able to articulate and convey with simplicity, what sometimes are very abstract ideas.

Speaking at conferences and other technical events, has definitely helped me grow more comfortable into that presenter role. But I have to admit it is never the same talking to a crowd of peers or other developers, than to a customer.

The key is, no matter who you are addressing, you need to build rapport. And the most optimal way to build rapport is to identify with the more human side by providing structure to your narrative in a way that it becomes a story your audience can relate to.

Always, always put some work in your communication skills. Especially if you want to become an architect in the future.

Collaborating with sales teams

Typically, Solutions Architects have more of a backend/systems background. 4 years ago, it was already obvious to me that as the volume of frontend work was growing, the integrations were more complex, and there was a lot more to put together nicely. The role of a frontend expert during discovery phases was not only necessary, it was essential. I started paving the way to get there.

I joined a sales squad operating in northern Europe, in parallel to being a hybrid Tech Lead/Architect at the project I was assigned to (the one we won!).

As part of that team, I review code bases of potential clients/leads, join meetings to understand their problems and requirements, write architecture vision papers from infrastructure to tech stack, estimate and define timelines, estimate staffing needs, etc. Before COVID, I was traveling places to present those analysis or gather more information, or to build a connection with the clients, or to educate them on a certain subject.

Sometimes I would fly for the day only to Amsterdam or Copenhagen, sit in a meeting, and come back in the evening right on time to have dinner with my family. It was exciting, but also intense, and if you want that, you have to be prepared. On the way there, I was putting together slides and documentation for that meeting. On the flight back, I was reviewing PR's from my own project.(Thank you Norwegian and all the airlines that have wi-fi onboard!).

Leaving the tech lead role behind

At some point last year, we started working on a brand new concept that required a lot of high level definitions and I was officially anchored to the Solutions Architect pathway. In the context of the project I work at, I already had the architect role officially for 2 years, as part of our Holocracy organization.

Every company has their own role definitions and people energizing them are expected to deliver in different ways. At my current company, architects are definitely very hands-on. Our culture promotes and celebrates the intersection of architect and lead developer.

However, the domains where architects and tech leads work, although intersecting, are on opposite sides of the high-level design imaginary line. For those that are not familiar with the differences, this diagram may shed some light.

What does an architect do?

Architects are in charge of high level definitions of a system. They are the connecting point between the business vision and requirements, and the technical know-how. Even if they can, architects will not care about the nitty gritty details of the implementation.

Architects are the connecting point between the business vision and requirements, and the technical know-how

That is probably the part that is more difficult to detach yourself from, when you transition from being a tech lead. When you review a pull request, your input is not really so necessary in terms of "You could've used this method here, instead of this other one". Your concern is the big picture.

In fact, you will find yourself less and less in contact with other developers, and working more on your own or with other architects, requirement engineers, system engineers, and quality assurance leads. That is probably the hardest part of the transition.

Also if you come from a frontend technical lead position, you will be less in the spotlight. Work at a high-level is less tangible and visible, but equally important.

The day to day

As an architect, most of my (project) day is spent on client calls, team meetings to align the rest of the team on decisions made, partner calls, working on diagrams and documentation, and executing proof of concepts. I am more concerned about API design and integrations, data storage, security, performance, CD/CI pipelines, releases and rollouts. I care about my client's system being legally and standards compliant.

I am no longer part of the development sprint, and I don't deliver tasks in the scope of it. Do I miss it? I have to admit that I miss it less and less every time: for once, I really like what I do now. And I also enjoy tremendously the ability of delegating and seeing other people grow in the same direction I did.

My sales support day is spent supporting proposals and discovery, attending meetings with leads, writing architecture visions, reviewing concepts by other architects, and preparing educational material pre and post sales. So everything I used to do before COVID, minus the traveling.

The skills required to become a solutions architect

Let's map what I do, to the skills I find the most useful. The soft skills required to do a great architect job are:

Communication skills (ability to articulate but also to listen)
Presentation skills (put together great diagrams, and concise slide decks)
Diplomacy (you're at the front line with the client. It's all about business and especially in enterprise, you have to use a lot of patience and good manners)
Manoeuvring (because of working together with the client, you have to have the capacity to manoeuvre and respond fast)
Analytical skills (your job is all about solving abstract problems, designing or fixing systems that many not even exist yet)
Leadership skills (you have to lead your team and your client's team. You have to bring everyone onboard with what's best and the decisions made -which is a complex topic, sometimes, may not be the absolute best, but the most convenient in terms of parameters like time and budget-)
Ability to estimate and staff a project
Ability to prioritize

The technical knowledge is also different than the one you needed to have as a tech lead. Apart from mastering a programming language, right now in 2021 I recommend you specialize in

cloud providers and their offerings
concepts like horizontal and vertical scaling
concepts like replication and sharding
serverless computing
databases
API patterns and contracts
CD/CI and how to build your pipelines effectively
automation
containerization
orchestration
architecture trends (like micro-services)
design patterns
UML and different types of diagrams (flow, mindmaps)
security and protocols (networks)

If you have a frontend focus, you can check this mindmap of useful skills I put together a bit ago

https://twitter.com/AnfibiaCreativa/status/1331565865196777472/photo/1

Additionally, stay up to date! These are some of the architects I follow to keep myself informed on architectural trends. This list is relevant for me, you may need to find your own good sources ;)

Luca Mezzalira
Manfred Steyer
Martin Fowler
Dan Wahlin
Gabriel Walt

Do I feel like my coding skills are suffering?

Not for now, for sure. I spend a lot of time coding, and being a GDE and other community activities I do, help with that. I see myself coding for a very long time, and my new focus only adds value.

Finally

Another very important skill is the one of receiving feedback and acting upon it. If you want to become a great architect, find people that have been doing the job for a long time (this is valid for any profession, of course) and ask them for feedback and mentorship. Ask them to assign you tasks in areas where they see you're the weakest, so you have the chance to gain experience.

And...enjoy the ride!

PS: Thanks to Mario, Ina, Conrad, Tomasz, Andreas and Georg, who have been those mentors for me, from infrastructure, to architecture to soft-skills.

Can you become a successful software developer without a CS degree? My opinion

Natalia Venditto — Mon, 21 Dec 2020 07:56:38 +0000

Last week I read a few tweets that really caught my attention. Most of them targeted the 'anti-academia' movement.

It is not the first time I read some people are anything between skeptical to angry about those who say that you can have a successful career in tech without a CS degree, but these concrete tweets caught my attention because I never knew this particular 'anti-academia' movement existed, and I still have not come across a statement such as 'You should never go to the University!'.

Although maybe such statements exist and are public out there even as tweets, they never reached me in my feed. Or I never read them.

What I have read, unfortunately, are snark comments and dismissive remarks, ridiculing people who work in the tech industry without a CS degree, and saying things like "you can do websites, but cannot work on more complex stuff, like diagnose and disease detection software", or even remarks like "yeah, next thing is becoming a doctor without a CS degree. pffft!"

As a successful software architect without a CS degree, I finally felt like it was a good time to share my opinion.

After all, I have more than once encouraged people to transition from a different career background or no career background at all, to find new opportunities as developers. Just thinking that they may discouraged by a (sometimes) more privileged group of people for making a late-career choice, or for being unable to afford university education and deciding to get there following a different path, is heartbreaking to me.

Debunking some myths

First of all, I want to put things into perspective. People who become successful in tech, without a CS degree, are usually far from less intelligent, or too lazy to put the effort.

People who become successful in tech without a CS degree, usually

but not always, have completed university education in another field
always have spent an exponentially greater amount of time in self-teaching, including using online available resources and contributing to open-source communities, than those who do have a degree, before they get their first role in tech

People who have not attained a CS degree, but still have become successful in tech usually

but not always, have had to postpone or drop their education because of financial, health-related, or other personal reasons
but not always, would've loved and would still love to complete their education, even when they're consolidated professionals

I would say that in 90% of the cases if they would be given the chance, they would attempt at completing their university education and getting a CS degree, which is incompatible with being part of an 'anti-academia' movement.

How is it better to have a computer sciences degree than not?

Let me elaborate my opinion. People who do have a university degree in computer sciences, while still studying, usually

learn foundational or low-level concepts in a structured way, which is very important to understand high-level concepts
but not always, have access to a tutor or professor, to dissipate their doubts and help them apply the newly learned concepts
but not always, do not need to spend personal time finding the right learning resources, since they're provided

Also once they've attained their degree, they usually

almost always have more opportunities to be hired, since lots of companies have it as a hard-requirement
always are less prone to be immediately discarded by recruiters, upon sending their CV, for not meeting this particular requirement
almost always have more career progression opportunities
but not always, are paid more than their counterparts that do exactly the same job, but do not have the CS degree

Can we compare studying to be a doctor to studying to be a software engineer?

No. And why?

One of my siblings is a doctor, so my opinions are shaped by my experience of living with her, as she was studying. In Uruguay people don't go to Campuses. They stay home while they study, especially if they live in the capital city, Montevideo.

Let's talk about sources

The source of anatomy and pathologies knowledge for doctors, historically and from centuries, has always been actual, real, living and dead human bodies. I will not share details on how those doctors close to me dissected human parts on the same table I was having my meals. Well, ok, I guess that's enough detail. And yes, that happened. Those body-parts, unique and ultimate source of knowledge to understand anatomy and pathologies, were obviously provisioned by the university.

Let me begin by sharing with you my opinion that probably the doctors you would like being diagnosed and treated by if you had anything serious, are the ones that have the most amount of clinic practice and not those that are university professors, and rely almost only on theoretical knowledge.

Clinic practice is obviously not something you can teach on youtube. It would be unethical because you would have to disclose private information about a human being. It is unlikely anyone wants to visit a doctor that streams on Twitch as they perform you a colonoscopy or explores your naked body.

I know there are a couple of reality shows that feature this, but it is a very extreme exception.

Unlike the act of exploring a human patient, diagnosing them and treating them (which by the way also involves laboratories for analysis with expensive equipment not available to doctors at home while they Twitch, and prescriptions of law regulated medicines), building and diagnosing computer systems and programs in front of everyone else is a lot simpler, cheaper, and ethically acceptable.

Do I think a person could become a good, self-trained doctor if all the bibliography used by doctors was open-sourced, made available from online repositories, and doctors live-streamed their practice with patients (and body-parts) and people put the same amount of time they sometimes put to become developers? Possibly. But my guess is that, because of the ethical implications and obvious other legal issues, that will never happen.

However, even the most obscure and in-depth details about computer sciences, are available to everyone online, already.

Conclusion or tl;dr

Should you study at the University to learn computer sciences and get a degree? My humble opinion is that, if you can afford it, money-wise and time-wise, is: YES! Go for it!

But if you did not have the chance, or don't see that chance for you in the future, should you desist from the dream of being a successful, self-taught software developer? The answer is: NO! Go for it!

Micro frontends: my lessons learned

Natalia Venditto — Fri, 18 Dec 2020 15:26:14 +0000

Hello there!

For the past 6 months at work, I have been busy analyzing, experimenting, testing and sometimes suffering, while exploring the depths, the benefits, the cons of micro frontends as an architecture decision.

All I am going to describe, and all the opinions I will express, come from in depth-analysis and code that was shipped to production. I am not positioned in any place, with respect to micro frontends. Simply because it is my firm belief, that software architecture solutions are always good, when you have the problem they solve (hence, solution!) and always bad, when you don't and you're following trends for the mere wish to integrate innovations your software does not need.

The key is to use architecture patterns when really needed, and not to follow a trend or because the buzzword sounds good. There are very valid use cases for micro frontends, where they are probably the best solution.

This post is long, so grab a coffee, a tea or read it in parts.

When do micro frontends originate?

Micro frontends are the frontend analog to micro services in the backend.

Basically, a few years ago, with the explosion of digital transformation (enterprises, especially large organizations migrating to the web to operate their business), web software systems started growing larger and larger into huge monoliths that comprehended it all.

At some point, that architecture started bloating and smelling, and architects and developers came up with diverse approaches and strategies to break apart the code and the teams, and have dedicated release cycles.

Monoliths are not always necessarily bad, but sometimes they're hard to manage

When you have a very large system, and its pieces are very tightly coupled, meaning they're very inter-dependent, whatever change, upgrade, update, fix, etc you make to one part, however small it may be, requires you to release the whole monolith to a higher version. That affects also whatever depends on parts of your monolith, too, like sub-projects.

Even when using semantic versioning for dependencies, even when modularizing, and even if we were breaking teams apart to give them ownership of certain parts, developing an maintaining a large coupled system is a very challenging task.

Those are the fundamental reasons behind a micro-services architecture type: the wish to split apart large systems in a way that every component, and the team in charge, is independent in many areas

technologies
lifecycles
processes
operations

Especially in combination with event driven strategies, API first concepts and cloud platforms, micro-services have demonstrated to solve some of the afore mentioned problems, while introducing their own, due to the need for complex and well designed orchestration, for example.

Micro-services in the frontend

If splitting apart the backend was successful why not the frontend?

Actually the split in the backend, with dedicated teams to cover a feature or service, demanded we took our own measures in the frontend.

If we really wanted to make sure those components were completely independent, there was no other way around it, anyway. And that was the birth of micro frontends.

Micro applications

In all honestly, in enterprise, it is not something new. We have been doing this for years.

There are two ways in which we do this, we have a Single Page Application per hyperlink or url, or we embed a fully functional micro application in a page region, typically using an iframe.

The pros for this approach are

the team developing the app can be fully independent, choosing their own technologies and cycles
the app is fully encapsulated in the iframe, thus not interfering with the javascript or css of the host

The cons are

if there is more than one instance of micro-app initializing in a page (or route) the impact on performance can be really high, and there is likely a duplication of dependencies, since shared assets like styles or fonts, cannot be shared between the host and app
if the apps are integrated in the build system, there may be a chance to share certain dependencies, and even exercise some code-splitting/tree-shaking, however, but teams would lose independence, since they're bound to the cycles of the system where the build process is at
routing can become very complex, especially if the navigation tree is very deep
UX consolidation will be challenging. Aspects like localization, internationalization, and preservation of unified styles, will demand more efforts, alignments, or a very well documented style-guide
if integrated via an iframe, you will need additional code to handle iframe resize. because iframe is completely encapsulated, you won't be able to share any assets
if integrated via an iframe, additional measures for SEO and A11y will need to be taken

Does not change

if you're consuming a bundled app, you would still need to update your main system dependency version and that little change demands a release, before you could see any updates made by an independent team to a micro app

Web Components

Another popular, yet less proven(*) way of integrating micro frontends, are via the web components W3C Standard. For those that are new to web development or never heard about them, web components are a web standard that allows the generation of custom elements (as in custom HTML elements) that via the DOM, have properties either custom or inherited from the HTMLElement (or whatever element class extended) parent.

It is possible to bootstrap a javascript framework on top of the Web Component, as well. There are many libraries that support extended functionality and also provide the necessary polyfills to make sure the Web Components are supported across browsers. As you can imagine, like with any W3C specification, it gets fully supported overtime, and customElement, Shadow DOM API, etc, as part of Web Components, are only somewhat there.

() *When I say less proven, I mean that there are less records of this pattern successfully used in large enterprise production systems

The pros of web components

web components are more or less encapsulated depending on if Shadow DOM is used or not. That I have to say may be both a pro or a con, it depends on your use-case.
when less encapsulated, web components can leverage common assets, which makes it easier to achieve a more integrated user experience, and consistent look and feel, especially for corporate identity
having the ability to consume commons and shared code, reduces the amount of data shipped over the wire, and prevents duplicates, which enhances performance at runtime
SEO and Accessibility are treated as they are for any HTML subpart, so no additional efforts, there

Cons of web components

if you have to give support to very old browsers, expect having to ship additional code to polyfill them
if the teams behind each component are independent and they can make their own choices, can you foresee the impact on performance of bootstrapping and initializing multiple frameworks in a page?

Does not change

same as with micro apps

if you're consuming a bundled app, you would still need to update your main system dependency version and that little change demands a new build, release and deploy, before you could see any updates made by an independent team to the web component bundle

Orchestration, or bringing the whole micro parts together

It doesn't matter if your micro parts are standalone web components or micro applications, you will need to bring all that together, somehow.

That is only possible if you define a team in charge, exclusively, of what we will call 'the host'.

In large enterprise systems, the host is usually a CMS plus a large infrastructure, to support it. The team managing the host, should probably be in charge of the orchestration and composition, and make possible the following aspects

configuration for initialization (especially authored!)
routing
communication between components
state management
providing commons/shared code
availability of any other user-triggered event-based API's

Make it event-driven!

Does not matter if you're integrating micro frontends as micro apps in an iframe or web components, or even ES imports into a much larger application, a key part of preserving a good user experience is about making sure that all components can talk to each other. You can do that by using a publication/subscription mechanism strategy, like for example this one.

Publication/Subscription works in a very easy way. You publish a topic, and everyone listening or subscribed will react in any way you determine, to that publication. It is a great mechanism to use for micro frontends, because the publisher of the message or topic, does not need to know about the listeners. However, keep in mind that the subscribers, obviously do need to know the topic they need to subscribe to.

There are very, very light weight libraries to accomplish this and if we're bootstrapping a framework, it probably has its own preferred technology or recommended pattern.

But if you are bootstrapping different frameworks...

That's again when it gets messy! If you're bootstrapping different frameworks, all of which come with their own state management pattern and flavour, combining them may be especially challenging.

Each one will define its own store, and we will have to come up with ways to synchronise them. In my opinion, it defeats the purpose of a single source of truth, and I am not sure to buy into it. Even though we have effectively integrated Vuex and Redux store in very large applications, it is by no means an easy task.

Combining multiple state management patterns defeats the purpose of having a single source of truth, or unique store

This is something very important to keep in mind if you're stitching together multiple parts, and you're dealing with user authentication/authorization, etc.

Consistency in reactivity to browser native controls

This aspect is also essential. Having multiple micro parts behaving differently with respect to browser API's, like history, could confuse the user and lead to a very poor experience. It is very likely that each team should make sure every component posts their history state on state change.

Bookmarking may also become a challenge. Usually the user wants to bookmark a route, or the page in a specific state. If you're combining micro frontends in different technologies, this can become arduous.

Relying on Web API's will be helpful

Modern, evergreen browsers, offer a myriad of API's that you not only can but should leverage, in order to execute composition. Even when, again, not all browsers may support all API's, or some only offer partial support, they can be extremely useful in reducing development efforts and abstraction around composition, and using methods globally available.

Some of the most useful API's and interfaces for micro frontends composition, are these

Mutation Observer
Intersection Observer
History
Channel Messaging
Drag and Drop
Picture-in-Picture
Push API(^)
Service Workers and WebSockets

and of course, all the client-side storage mechanisms, and the Cache(^)

(^) These are still experimental and you can find them all here

The testing part

Testing a micro frontend component individually should be the responsibility of the team that owns it, that's clear. But if you're integrating it in a page, and again, you want it to communicate and sync state with other parts of that page, you also need to test that aggregation.

It is by no means easy to design automated tests for items that are in a black box to you. So expect that part to be, if not a problem, another challenge.

So you're not recommending micro frontends?

Again, no. That's not what I imply. I believe that micro frontends are the way to go, especially under these conditions:

you have to integrate development by teams that work in a different context (external repos, different organizations, etc)
each part has very different cycles (like feature A needs daily releases and feature B may get some maintenance), and you don't want to redeploy the whole system because of a stitch in a single (or several, yet minimal) feature(s)

And to make it possible you, need...

...at minimum

a very solid event driven strategy
a team in charge of the orchestration, routing, and commons
a very well documented and defined style-guide
a performance budget, and mechanisms in place to accelerate load (particularly perceived load).

And specifically in the enterprise world?

In my opinion, micro frontends architecture works extremely well for products.

Imagine you own an application with several different features. Let's imagine it's a search engine. You could break it down like this, into components, in the frontend:

the form elements (input, button, checkbox, radio-button, etc)
the atomic text elements (link, label, description)
image
teaser
pagination
lazy loading mechanism (for images and infinite scroll or load more)

You'd need a service in the backend to run the queries against an index, and return the results.

Of course there should be a (frontend) build system, a state management system or pub/sub module, a unified API/service to run queries from the frontend.

With them you could compose the search box, the facets or filters, the search results, the related results, the featured results, and even customized suggestions, combined with an analytics or target layer.

What I feel is the most important, is that everyone of those features map to a business capability or domain

You could easily form clusters and assign each one of those clusters to an independent team.

It is very likely you'd want the users to login, to save their queries. You'd have a team dealing with authentication and authorization, and they'd also use components from the other teams. (form elements, etc).

All those teams would still work with the guidance of a style system, to preserve UX and the identity of your product.

But what about the enterprise website context?

But enterprise sites are usually less of a product, and more of a composition of components to create web pages, to provide information of or acquire products and services.

Although you can very much assign each component to a different team that owns it, it is highly unlikely teams are configured in a way that allows for this. And that the business strategy backs up this split.

Usually teams working in enterprise sites are not that large that you could put together a fully cross-functional team in charge of smaller features. And even if they were, sometimes it would not make sense.

Oftentimes websites have a single business unit behind it. They advertise or commercialize a product or service, and all the components are tightly coupled, technically, and strategically.

There may be exceptions to the rule. And there are services that you can still break apart from the whole, and assign to independent teams to own, like we mentioned before, user management, or even the search mechanism as we suggested.

But it is more likely that enterprise platforms have a repository or library of components, used across many sites. And that the image component used in the search feature, is exactly the same than the one used in other places/components/modules/templates. All components are then equivalently important for the business stakeholder behind the site.

A really valid use case in enterprise

And that's the case when you have to integrate micro parts that are developed by remote teams. I don't want to use the term 'independent', because I still believe 100% independent is not going to help your UX and your performance. You will still want your corporate identity in the form of consistent UI/UX, to be preserved. You will still want state coherence and synchronization and communication between components of a page. You will still want to make sure you have a certain consolidation in the choice of technologies, to prevent collisions and performance degradation.

You will still want some decision matrix to rule and govern. As a Frontend Architect, concerned about performance, I wouldn't want to have Angular 9, 10 and 11, Vue 2 and 3 and React components initializing in a web page, requesting their myriad of accessories, and crashing the user experience (and the page!).

So the idea of having 100% independent, isolated teams, does not seem really feasible to me, in this context.

But the case of a team working in a really isolated feature, for sure merits independent release cycles, to avoid the need to rebuild and redeploy your whole monolith to pull a minor fix in a 3rd party component.

To use that commodity, you need to implement Module Federation. And to read what I have learned about Module Federation, you will need to wait until my next post.

Decisions, decisions...

These slides, from my talk at the HolyJS conference, offer a few graphics I created to aid with architecture decision making, based on the need for independent deploys or encapsulation, for example.

https://slides.com/anfibiacreativa/micro-frontends/fullscreen

being slides, 34, 35 and 52 to 56. If you're anywhere in the yellow areas, you may want to consider not using micro frontends.

Edit: You can compliment the reading, hearing me discuss the topic with John Papa, Ward Bell, Dan Wahlin and Craig Shoemaker at their podcast https://webrush.io/episodes/episode-113-micro-front-ends-with-natlia-venditto

Have a wonderful holiday season, folk!

Angular Schematics from 0 to publishing your own library (I)

Natalia Venditto — Sun, 16 Aug 2020 18:43:07 +0000

This is a series of posts, that, if you follow through, will help you acquire the necessary knowledge to write your first schematics and even publish them to npm with ng-add support!

Let's start!

What are schematics, you ask?

Schematics are code generators based on descriptive code. Basically, you write some descriptions of what you need and artifacts are generated. Those artifacts could be more code, templates, etc

What problems can I solve with schematics?

With Schematics you will be able to automate a lot of tasks across your projects or organization, allowing you to establish patterns and enforce best practices.

You will become more productive and reduce manual tasks, especially those around setup.

You won't need to write or read so much documentation!

Additionally, if you write a library, you will automate steps to have it working, which makes it more attractive to other developers, that do not need to perform them every time they install it.

In short, Schematics help with

structure standardization
enforcing patterns
enforcing best practices
enforcing naming conventions
reuse implementations
automate tasks

Main advantages of Schematics

So schematics as code and other artifacts generators help us setup and configure a new project (or parts of it) in a standardized and automated way, with the following advantages

they're extensible and atomic
they're safe and synchronous
they're implemented in debug mode by default

Extensible and atomic

Schematics are organized in collections and can be combined or chained, but apply transformations in an atomic way

Safe and synchronous

By being atomic, and because of their synchronous nature, Schematics are safe. They're executed one after another, which means errors are easily traceable.

Default debug mode

When executed from the Schematics CLI, they're dry-run, which means that bt default, none of the transformations is really applied to the file system.

Important vocabulary

It is difficult to learn Schematics without being familiar with its API and vocabulary first. Let's start with the vocabulary you will see in repeated over and over when we start the practical lessons.

Source, or ./files

The Tree or source is the VIRTUAL tree composed by a base (files that actually do exist, and are identical to our file system's content) and the staging area (where all transformations are applied), plus some metadata necessary to work with all.

For example, when we want our schematic to create new files in our system, we create a /files folder at the root of our schematic, with contents identical to what we want to be replicated.

We will call this folder files simply because by default, the ts compiler will ignore this folder and never transpile it. If we want to call it something else, we need to configure the tsconfig.json file, to know that and exclude that folder.

Rule{}

The Rule object defines a function that takes a tree as an argument and returns a new tree after all the transformations have been applied.

We can also use Observables, and return the Observable of a Tree.

index.ts

It's a Rule factory that acts as an entry point for our schematic. You find this file at the root of the schematic. It will always return a Rule.

It runs always in a context, that provides the metadata and utilities (ie: logging), necessary.

SchematicContext

This object represents the context in which the schematic runs, as explained before.

Action

Action is the most atomic transformation you can apply to a tree.

collection.json

A set of definitions for one or several schematics, where we find the declarations and values for the description, the path to the factory (or entry point for each schematic), the path to its validation schema (when it has one), and its aliases (when it has them)

Aliases

Aliases are as expected, an alternative string you can all the schematic with, to invoke its execution.

Each schematic may have one or several aliases.

"aliases": ["alias"]

schema.json

It's the validation schema for the schematic and its descriptor properties. It's optional, but recommended!

Options

Configuration options you can pass to the schematic, for example --name

Prompts

Prompts allow the schematic to interact with the user via the CLI. They're part of the schema.json

The virtual tree

The virtual tree is an abstraction of the file system of the project we want to transform, consisting of the base (the existing files), a staging area where the actions to applied (transformations) are applied, and the metadata derived of the context.

Important!

It is very important to understand that the transformations applied do not really modify the base directly! They're applied to the files in the staging area.

To understand this concept, you can think of git, and how every diff, every modification you do of a file, is not really effective unless you commit it to the index. And it does not really affect the upstream unless you push it and merge it!

In schematics, it works like this:

Actions

All transformations applied to a tree are essentially atomic actions.

These actions have four main types: CreateFileAction, DeleteFileAction, OverwriteFileAction, RenameFileAction

You can find the actual implementation for each action type, exploring

Implementación action.js

Until here, a bit of theory. We will dive a bit deeper in the API, in the next post!

EDIT: The rest of this series are being published in indepth.dev
Please go here to continue reading! -> https://indepth.dev/angular-schematics-from-0-to-publishing-your-own-library-i/

DEV Community: Natalia Venditto

Lightweight, portable and secure Wasm runtimes and their use cases.

Why is JavaScript so popular?

JavaScript needs no compilation...but, does it?

Client-side dynamics

We try to prevent exhausting end-user terminal resources

Portable, secure, and lightweight: Wasm runtimes and their use-cases by Natalia Venditto - YouTube

Going lower, to reach higher

At the edge of the cloud

And where does this compute or execution run?

Lighter runtimes

Portable, secure, and lightweight: Wasm runtimes and their use-cases by Natalia Venditto - YouTube

Micro-frontends and beyond: composable frontend applications

My journey with micro-frontends

The motivation to build a website about micro-frontends

If I don't have time for a book, I'll make it a website

More on the subject of composable architectures

Bases de datos: operar con la base de datos - parte 2

Operaciones CRUD para leer documentos

Operación CRUD findOne()

Parámetros opcionales de findOne()

Proyección de consultas (Projection)

Operación CRUD find()

Limitar el cursor a una cantidad específica de resultados en el batch

Parámetros opcionales de find()

Consultas complejas con operadores de consulta

Encontrar un valor equivalente al pasado en la consulta: operador $eq

Encontrar un valor más grande que el valor pasado: operador $gt

Encontrar todos los valores diferentes a: operador $ne

Comparar fechas con operadores de comparación

Excluir resultados que contengan un valor en un campo array: operador $nin

MQL en el mongosh vs. operar con un driver

Bases de datos: operar con la base de datos - parte 1

Pre-requisitos

Crear una base de datos MongoDB desde la terminal

Mostrar las bases de datos existentes: show dbs

El comando use

show collections para mostrar colecciones

Operaciones CRUD para operar con documentos

Operaciones CRUD

Creación de documentos

Más métodos que crean documentos

¿Documentos con estructura diferente?

Utilizar mongoimport para importar datos a una base de datos MongoDB

Conectando a una base de datos remota

Más sobre la cadena de conexión MongoDB

Bases de datos distribuidas: sharding.

¿Qué es el sharding?

El modelo de documento simplifica la distribución de datos

Sharding si, sharding no

Datos fríos y datos calientes

Múltiples clusters como alternativa al sharding

Qué pasa en nuestra base de datos, cuando la particionamos?

Componentes de la arquitectura de sharding

El proceso Mongos

Shards

Chunks

Consultas (queries)

Habilitando un sistema de sharding

Habilitar el proceso de distribución de datos

Estrategias de sharding

La estrategia de hash

La estrategia de rango

La estrategia de zonas

En el próximo post

Bases de datos y el modelo de documento

Empecemos por el modelo.

BSON como estándar abierto, para guardar otros tipos de datos

Comparativa (o contraste) entre una base de datos SQL o relacional, y una base de datos de modelo de documento

Anatomía de un documento

Bases de datos distribuidas y la consistencia eventual

MongoDB y la alta disponibilidad

Trabajando con la terminal (Mongo Shell)

El proceso mongod

MongoDB standalone o nodo único

Redundancia y replicación

El proceso de replicación

Subtipos de secundarios

Fallo del primario y elecciones

El procesos de elección y la conmutación automática del primario

Parámetros opcionales de `findOne()`

Parámetros opcionales de `find()`

Encontrar un valor equivalente al pasado en la consulta: operador `$eq`

Encontrar un valor más grande que el valor pasado: operador `$gt`

Encontrar todos los valores diferentes a: operador `$ne`

Excluir resultados que contengan un valor en un campo array: operador `$nin`

Mostrar las bases de datos existentes: `show dbs`

El comando `use`

`show collections` para mostrar colecciones

Utilizar `mongoimport` para importar datos a una base de datos MongoDB

Componentes de la arquitectura de `sharding`

Habilitando un sistema de `sharding`

Estrategias de `sharding`