Así es como lo hago:
El punto de partida será un método en código que hace algo. Digamos que es un acortador de URL: eso significa que voy a necesitar dos métodos: uno que transforma una cadena en otra cadena y un segundo que la transforma de nuevo. Es casi seguro que voy a hacer que la versión abreviada sea clave en un almacén de datos de algún tipo, porque la transformación seguramente destruirá la información. ( Podría escribir un algoritmo de compresión / descompresión, pero eso no acortará mucho las URL).
Así que ahora tengo un par de cosas en que pensar. ¿Qué algoritmo voy a usar para acortar una cadena? ¿Debo hacer que la salida se parezca a la entrada? (Nah, eso suena difícil.) ¿Está bien para mí simplemente trocear la cadena y convertir el valor de troceo en la base 36, de modo que el resultado sea una serie de caracteres en el rango [0–9A-Z]? ¿Puedo elegir una base más alta que 36 y usar más personajes? ¿Qué pasa con la codificación base64? Go tiene un paquete que hace esto. Preparo una prueba de esto (ver The Go Playground) y descubro que no, la codificación base64 produce resultados sensibles a mayúsculas y minúsculas, y eso no servirá para una URL. Entonces la base 36 es. Eso es tan simple como puedo hacerlo.
- ¿Una prueba de software se considera un trabajo sin salida? ¿Realmente no tiene perspectivas de futuro en términos de salario?
- ¿Por qué los ingenieros, programadores de software y profesionales de hardware y TI piensan que tienen respuestas a preguntas sobre las que no saben nada?
- Si un desarrollador de software no trabaja más de dos años en trabajos, ¿se ve mal en un currículum? ¿Cuánto tiempo debe permanecer en un trabajo?
- ¿Qué saben ahora los desarrolladores de software de 30 años o más que desearían haber sabido en sus 20 años?
- Como desarrollador, ¿cuál es el tipo de datos más interesante con el que ha trabajado y por qué? ¿Qué lenguaje / herramientas / marcos usaste?
Entonces, ¿dónde voy a mantener este almacén de datos para poder recuperarlo? ¿Debo usar una base de datos? ¿Puedo mantener la cadena en la memoria y escribirla en el disco cada vez que cambie? ¿Necesito usar MySQL? Digamos, ¿qué tal ese Cloud Firestore que acaba de ser anunciado ayer? No, hagamos que algo funcione.
Ahora puedo escribir mi código. El primer método toma una cadena, la divide en hash, convierte el hash en un número base 36, convierte * ese * número en una cadena y almacena la clave en un mapa en memoria (estoy usando Ir, por lo que la almacena como una cadena de mapa [cadena]). El segundo método busca una clave en la cadena del mapa [cadena] y devuelve el valor. Escribo pruebas unitarias para estos métodos. Hasta aquí todo bien.
También quiero que el mapa permanezca almacenado cada vez que cambie, y que se lea en la memoria cuando se inicie el programa, así que escribo métodos para hacer ambas cosas. Debido a que tengo experiencia y sé que voy a escribir un servidor web aquí, protejo la escritura con una sincronización. Mutex, para que dos escrituras simultáneas no corrompan el archivo. Y también protejo la actualización de la cadena del mapa [cadena] con una sincronización. Mutex por la misma razón. Como soy un poco arrogante, confío en esa sincronización. Mutex funcionará y no escribo pruebas para eso.
Ahora dirijo mi atención a la parte del servidor web. Afortunadamente, he hecho esto un millón de veces antes. Lo más simple es escribir un servicio REST, donde una URL GET en una ruta como / key llama a mi método de búsqueda y escribe el resultado como respuesta (o un 404 si no se encontró la clave) y una URL PUT en un ruta como /? url = convierte la URL y escribe la clave en la respuesta. Esto no me lleva mucho tiempo porque conozco bastante bien el paquete Go http, así que en diez o quince minutos tengo un servidor web ejecutándose en localhost: 5000 que acorta las URL.
Entonces creo que, digamos, nadie quiere obtener la URL acortada, lo que quieren es proporcionar la URL acortada y dirigirse al lugar correcto. Así que modifico mi método GET para devolver una redirección, después de buscar cómo funcionan las redirecciones en Wikipedia porque no recuerdo qué encabezados deben escribirse para que una redirección funcione. Ahora puedo acceder a mi servidor con una URL guardada y me dirige al sitio. ¡He escrito http://bit.ly! Ve a mi!
Por supuesto, en el mundo real nadie usará curl para hablar con un servidor como lo he estado haciendo, así que tengo que escribir un formulario HTML para hacer mi solicitud POST, y hacerlo para que mi servidor lo atienda cuando visite /. (Manteniéndolo simple, es simplemente HTML y parece el final de un perro. Voy a escribir un buen CSS para esto más tarde, como después de que esté muerto). Y eso significa que tengo que arreglarlo la URL de mi controlador GET, porque estaba sirviendo / clave. Tal vez lo haga lo suficientemente inteligente como para que si la URL es solo / sirve el formulario y si es / clave, redirige. Oye, eso incluso puede funcionar.
Así que ahora tengo una simple prueba de concepto. ¿Cuántas QPS resistirá? ¿Cuáles serán las fuentes de latencia? Bueno, escribir en el disco en cada solicitud será un cuello de botella bastante significativo si estoy sirviendo 50QPS, y el almacenamiento de todos los pares clave / valor en la memoria comenzará a descomponerse después de un tiempo (obtiene un sobre, lo entrega hacia atrás, agarra el bolígrafo, comienza a dividir 2 gb por 80 bytes … sí, eventualmente me preocuparé por la memoria).
Lo que realmente debería hacer es registrar la latencia de solicitud por método y escribir un programa que revise mis registros de vez en cuando y me avise si el servidor se está golpeando. Aquí dejé de ser programador y comencé a ser ingeniero. Pasé, “estoy bastante seguro de que esto funcionará”, y en “Necesito que me notifiquen si va a comenzar a fallar, para tener la oportunidad de mitigar la falla antes de que ocurra”. Una cosa inteligente sería registrar la memoria libre del servidor de vez en cuando.
En realidad, una cosa realmente inteligente sería encontrar un paquete de métricas de servidor que pueda integrar en mi servidor. Seguramente alguien ha escrito uno para Go. Parece que thoas / stats funcionará. Es simple incluir controladores en la colección de estadísticas y luego solo sirve esas estadísticas en otro puerto. Entonces puedo escribir un script bash que recopile esas estadísticas y … vaya, probablemente debería encontrar un sistema de monitoreo en lugar de escribir un montón de trabajos cron. Puedo decir que terminaré usando nagios para esto porque es lo que sé.
O espere, lo sé, fingiré que soy uno de mis propios clientes, lo trasladaré a GCE y usaré Stackdriver. Al menos, entonces ya sé dónde está el firewall para evitar que sirva mi puerto de estadísticas en Internet abierto.
De acuerdo, pero antes de que tenga que hacer algo así necesitaré usuarios, y si alguna vez tengo usuarios, la serialización JSON será lo que haga que el servidor se caiga. ¿Leer y escribir un archivo de 1 gb en cada solicitud? Eso no va a volar en ningún tipo de entorno de producción. Por lo tanto, necesitaré una base de datos o un almacén de valores clave, y tendré que integrar eso.
Por supuesto, la mayoría de mis proyectos son proyectos de pasatiempos que no voy a desatar en el mundo, así que sobre todo solo pienso en los últimos cuatro o cinco párrafos y nunca los hago. Pero los tengo en mi bolsillo trasero si quiero que esto sea real.
De todos modos, así es como lo haría. Probablemente me tomaría 2–3 veces más que escribir esta publicación, porque esto es todo lo que he hecho antes.