Oh My GHaaD: Git Hosting as a Database

Hola a todos. Mi nombre es Chris Griffin, y hoy voy a hablar sobre un proyecto paralelo que hice llamado Oh My God, que es Git Hosting como una Base de Datos. Ahora, puede que no entiendas lo que eso significa todavía, pero al final de esto, podría tener un poco más de sentido. Y el objetivo de esto no es que uses mi proyecto. Es más para hacerte pensar fuera de la caja y pensar en algunos proyectos divertidos que podrías hacer que reimaginen lo que podría ser un backend y cómo se pueden construir las aplicaciones.

Así que primero, un poco sobre mí. He sido desarrollador de software durante unos diez años. Soy defensor de desarrolladores en GitKraken, y soy un streamer de programación en Twitch. Transmito demasiado en Twitch. Si quieres conectarte conmigo en las redes sociales, solo escanea este código QR. Está pregrabado, así que puedes simplemente rebobinar esto cuando finalmente se publique. Pero, sí, conéctate conmigo y charlemos. Pero vamos a ello.

No tengo mucho tiempo. Primero, ¿qué es un backend? Va a ser importante reconocer qué hace que un backend funcione en nuestras aplicaciones, porque entonces podemos empezar a reimaginar dónde puede vivir ese backend. Así que realmente, tu backend es solo datos, autenticación y autorización. Realmente son solo esas tres cosas. Los datos pueden ser tu base de datos MySQL o una base de datos Postgres. Incluso podría estar en Mongo o CouchDB o DynamoDB o en todo tipo de lugares en NoSQL. Pero cada vez más en estos días, vemos que los datos pueden estar basados en archivos. Puedes simplemente tener archivos viviendo en S3 y consultarlos con Athena. También puedes consultar archivos con Presto o Hive.

Incluso hay formas de consultar archivos parket con, creo, Snowflake o cosas como esa. No estoy muy versado en esas cosas. Pero la idea de simplemente consultar archivos que viven en algún lugar en lugar de consultar esta base de datos de conexión en vivo a la que puedes escribir y hacer todo tipo de cosas, sí, las bases de datos basadas en archivos son cada vez más comunes, y esa fue mi inspiración para construir Oh My God.

La autenticación es básicamente decirle al servidor quién eres, ¿verdad? Podría estar en una cookie o un token, pero es solo una forma de autenticarte con el servidor y que constantemente sepa quién está haciendo esta solicitud para que sepa qué hacer y todo eso. Así que realmente, bastante simple. Y luego la autorización es lo que puedes hacer con esa cookie o token. Así que eso podría ser tus permisos de lectura, tus permisos de escritura, tu capacidad para hacer cosas de administrador. Todo esto es algo separado de la parte de autenticación, pero van de la mano. Y cuando combinas todas esas cosas juntas, ¿verdad?

, si entrecierras los ojos y desenfocas tu visión un poco, podrías ver a través de este ojo mágico, y con un poco de ayuda, porque siempre fui malo en estos, con un poco de ayuda, podrías empezar a ver algo como GitHub. Así que piensa en eso, ¿verdad? Usé Oh My God como un marco. Construí una aplicación con esta arquitectura similar antes, pero decidí que quería construir algo que fuera un marco que pudiera usar para construir otras aplicaciones más pequeñas en el futuro, y fue simplemente un poco divertido Fue buen contenido de transmisión en mi transmisión de Twitch. Pensemos en GitHub, GitLab y Bitbucket. ¿Cómo podrían ser un backend? Bueno, los datos pueden ser simplemente JSON en un repositorio. La autenticación puede ser simplemente OAuth, ¿verdad? Es solo, ya sabes, iniciar sesión con GitHub y estás autenticado con OAuth, y luego tienes acceso a todos tus repositorios, incluso repositorios privados, etc. de tu organización. Y finalmente, la autorización, bueno, sí, todos tenemos formas de invitar a colaboradores y darles permisos específicos de solo lectura o solo escritura o incluso acceso a nivel de administrador.

Y veamos un poco sobre cómo he juntado esto y cómo está arquitectado, porque pensé que era algo divertido. Así que antes de llegar a esa parte, pensemos en algunas de las características interesantes de poner tu backend en un repositorio Git. Bueno, número uno, las copias de seguridad son fáciles. Es solo un Git clone. Estamos copiando los archivos. Es serverless. Y no quiero decir que no haya un servidor, ¿verdad? GitHub se ejecuta en servidores. Pero no nos importa dónde están los servidores, y eso es realmente lo que se supone que significa serverless.

Serverless es solo una idea de que no me importa dónde está alojado esto, y no me preocupo por la escalabilidad, ese es el problema de otra persona. El problema de otra persona es uno de los mejores camuflajes del mundo. Y una cosa que quiero aclarar es que con GitHub, no es completamente serverless. Necesitas un endpoint de backend para hacer el intercambio de tokens debido a la implementación de OAuth que utilizan. En GitLab, puedes hacer totalmente una aplicación del lado del cliente y obtener el token directamente de ellos.

Y finalmente, sí, repositorios públicos y privados. No tienes que exponer tus datos en un repositorio al mundo con GitHub, GitLab, Bitbucket. Puedes hacer un repositorio privado que esté disponible solo para ti y tu organización o el equipo con el que trabajas, lo cual es bastante poderoso. Así que profundicemos en algunos de los conceptos centrales que componen este marco de aplicación, o como quieras llamarlo. Tenemos colecciones, tenemos adaptadores, tenemos motor e integraciones. Y el motor es lo principal, pero vamos a pasar por el proceso un poco, pero tengo que tener cuidado con el tiempo.

Una colección es solo el modelo de tu aplicación. Así que en la aplicación que voy a mostrarte aquí como una demostración rápida de mi framework en acción, tenemos conferencias. Así que estoy usando una aplicación para rastrear las conferencias a las que he aplicado. Y puedo rastrear las charlas que he dado para ellas, si han sido aceptadas o no. Y es algo que puedo usar para asegurarme de rastrear esto. Hay aplicaciones como Sessionize y algunas otras que rastrean estas cosas, pero no todas las conferencias pasan por Sessionize. Así que sí, echemos un vistazo. Tenemos el esquema de la conferencia para que podamos validar estas cosas porque los formularios son importantes, ¿verdad? Tenemos esta colección de conferencias que tiene el ID de la colección. Tenemos la función ID que le pasamos para que podamos crear nuevas conferencias que tengan sus propios IDs únicos. Y luego tenemos los nombres que podemos referenciar dentro de nuestra aplicación. Y finalmente, adjuntamos el validador para que podamos conectar cosas como React hook form.

El adaptador es una de las partes más importantes porque es lo que hace que esto sea realmente adaptable a los diferentes proveedores, ¿verdad? Así que GitHub y GitLab son adaptadores que ya he hecho. Pero si alguien quisiera hacer un adaptador de Bitbucket, todo lo que tendrían que hacer es seguir esta interfaz a la derecha. Tendrían que implementar el método fetch repositories, fetch file, fetch file history, create commit, create file, update file, y delete file. Solo crud básico. Ahora, la razón por la que necesitamos este adaptador es porque no todas estas APIs funcionan exactamente de la misma manera, y vamos a profundizar en una forma en que son ligeramente diferentes en un momento. Aquí, vemos el adaptador de GitHub. Y en la API de GitHub, solo tienen un único endpoint llamado put, y esto va a poner el contenido de la ruta en tu repo. Y luego usamos ese método put dentro de nuestro create file y update file, porque esos son los dos métodos de nivel superior que son realmente utilizados por el motor para hacer cosas. Pero luego, cuando miramos GitLab, hacemos algo ligeramente diferente. GitLab no tiene poner el contenido de un archivo. Tienen crear un commit, porque nuevamente, está basado en Git. Pero cuando crean el commit, es ya sea creando un archivo, ¿verdad?, con la acción que vemos en el medio allí, o está actualizando un archivo con una acción ligeramente diferente. Ahora, esos tienen que estar en los dos métodos separados que tenemos, create file y update file, pero vamos a ver eventualmente si miramos Bitbucket y otras plataformas, que tal vez difieran en alguna manera muy pequeña.

Pero solo quería mostrar que los adaptadores están ahí para suavizar las diferencias entre las APIs REST. Finalmente, está el motor, y esto hace la mayor parte del trabajo real. Esto está llamando al adaptador para muchas cosas. Está configurando mucho del estado, y cuando estás construyendo una aplicación usando este framework, probablemente vas a estar interactuando con el motor la mayor parte del tiempo. Por último, pero no menos importante, tenemos la idea de las integraciones, y las integraciones son solo lo que conectamos a nuestro framework frontend.

lo que luego permite que nuestros componentes o nuestras rutas vuelvan a activar un renderizado. Así que solo podrías tener una integración para cualquier otro framework, pero esta es una conferencia de React, así que no vamos a profundizar en cómo podríamos hacer eso con Vue o Svelte o lo que sea. Entonces, ¿qué puedes construir con esto? Así que muy rápido, voy a pasarlo por alto tan rápido como pueda. Construí un rastreador de CFP para conferencias, y podemos ver que estoy conectado a getcrackin slash CFPs. Esto es para el trabajo, y podemos ver todas las conferencias a las que apliqué específicamente para cosas de trabajo. Tengo aquí mis conferencias, las charlas que se propusieron, si fui aceptado o no. Tengo las charlas que luego puedo asociar con esas conferencias. Es realmente bastante genial, pero por cuestiones de tiempo, tengo que pasarlo por alto, y vamos a volver a las cosas. Y solo piensa en lo que podrías construir que sea una aplicación pequeña y agradable que podrías usar con este framework. Y esto es lo que uno de los repos, tal vez no ese exacto, se ve así.

Son solo archivos JSON en un repo. Bastante simple. Así que advertencia, sin embargo, hay algunas advertencias. Número uno, vas a encontrar limitaciones de tasa en varias plataformas. GitHub, GitLab, Bitbucket tienen varias cantidades de limitación de tasa, y no estoy seguro si es específicamente para tu token o si es para la aplicación que has tenido que conectar a través de su backend. Pero encontrarás límites de tasa, así que no querrás construir algo mayormente escalable. No vas a lanzar el próximo Facebook usando Oh My Gut. Pero es todavía una idea bastante genial para micro-aplicaciones. Permisos. Sí, tienes que invitar a colaboradores. No es automático. Gestionar eso puede ser un poco molesto. Tienes que ir al proveedor y configurar estas cosas, porque no es algo para lo que queramos pedir permisos desde el nivel del framework. Y luego permisos a nivel de organización, ¿verdad? Bueno, tal vez podrías hacer que todos en tu organización obtengan acceso, pero ¿quién de nosotros realmente tiene la capacidad de hacer eso, de modificar eso a nivel de organización? ¿Y es realmente una buena idea? ¿Hay otras advertencias? Probablemente.

Pero no he usado esto lo suficiente como para saber realmente. Fue solo un experimento de pensamiento divertido. Entonces, ¿cuáles son las conclusiones clave que quiero que tengas de esto? Bueno, número uno, ¿deberías usar Oh My Gut para todo? Probablemente no. Pero espero que esto haya sido una buena inspiración para que pienses fuera de lo que hace que una aplicación funcione y cómo puede funcionar. Porque no tengo ningún backend. Estoy dejando que GitHub sea el backend. Estoy dejando que GitLab sea el backend. Todo lo que estoy haciendo es construir una aplicación del lado del cliente que puedo alojar básicamente en cualquier lugar, lo cual es bastante poderoso. Así que sé que estoy un poco pasado de tiempo por aproximadamente un minuto. Solo quiero agradecer por darme la oportunidad de hablar sobre esto y simplemente hablar sobre un proyecto paralelo divertido en el que trabajé, porque simplemente me gusta construir cosas en mi transmisión de Twitch. Y como dije, si quieres conectarte conmigo en las redes sociales, aquí está mi código QR y me encantaría charlar más.