La historia del nacimiento de un servicio de búsqueda y reserva en línea para viajes con derechos de autor en todo el mundo: una palabra del desarrollador

Como empezó todo
Tormento ideal
Tecnologías y cómo no son únicas
¿Cómo almacenar y dónde?
No solo para almacenar, sino también para buscar
Esto es SEO críptico
CDN nuestro todo
Para resumir

Como empezó todo

Quiero compartir nuestra historia de medio año de crear un servicio en línea para buscar y reservar viajes con derechos de autor en todo el mundo. Al crear este artículo, el objetivo era hablar sobre la experiencia de crear nuestras propias soluciones desde cero y los problemas y desafíos que encontramos en el camino, por lo que no juzgue estrictamente.

Para empezar, qué tipo de servicio es y por qué fue necesario crearlo. Durante mucho tiempo, nuestro equipo trabajó en varios proyectos grandes para clientes comerciales. Estos son portales para bancos, empresas, grandes participaciones, así como sistemas de gestión de documentos. Naturalmente, trabajar con ese segmento implica la satisfacción de un círculo estrecho de empleados interesados ​​y no siempre termina con un uso prolongado y exitoso.

Hay varias razones para esto: una falta de comprensión del proyecto en la etapa inicial, un deseo de ahorrar dinero y obtener el equipo más completo, cambios en los requisitos en la etapa final sin ninguna revisión de los términos y presupuestos. Como puede ver, la satisfacción del proyecto en ambos lados, después de tales condiciones, es muy difícil de lograr.

Entonces, después de toda esta experiencia, decidimos probarnos en el mercado, donde los comentarios del cliente son rápidos, usted comprende el interés en el producto lo más rápido posible y ve el uso de su servicio todos los días.
Al final resultó que, nuestros días tranquilos habían terminado!

Tormento ideal

Lo primero que había que hacer era tener la idea de lo que queremos ofrecer de manera tan útil que no esté en el mercado y que sea percibido y esperado. Tuvimos varias de esas muestras y durante los primeros dos meses nos dedicamos a experimentos para encontrar el futuro. Como puede comprender, también hubo un problema con las tecnologías, ya que es necesario realizar maquetas funcionales en el menor tiempo posible, verificar su operatividad y mejorarlas o rehacerlas constantemente.

Al principio, el bagaje de tecnologías que teníamos no era muy jQuery y C # (que utilizamos en nuestros proyectos anteriores). Estas herramientas no nos permitieron enfrentar los desafíos de manera rápida y flexible. Afortunadamente, ya hemos considerado nuevos enfoques para el desarrollo tanto del cliente como del servidor. Nuestra elección recayó en Angular 2 y Node.js. Esta solución nos permitió formar rápidamente componentes y módulos que podríamos modificar en el menor tiempo posible (el día podríamos rehacerlos dos o tres veces).

Llegamos a la conclusión de que cada componente debe ser lo más pequeño posible e integrable en otros componentes y módulos. Por lo tanto, en el proceso de experimentos, acumulamos suficientes plantillas a partir de las cuales fue posible ensamblar varios diseños de trabajo.

Pero si descubrimos las herramientas lo suficientemente rápido y en la batalla aumentamos nuestras habilidades cada vez más (notare inmediatamente que Google te ayuda, pero no te olvides de los tutoriales en video), entonces surgió otra pregunta sobre dónde almacenar los datos. Pero hablaré sobre esto un poco más tarde, y ahora volviendo a la idea misma.

El principal vector de nuestro servicio que buscamos para organizar viajes, inmediatamente dirá que en nuestro tiempo hay un montón de sitios y servicios para viajes, además del mismo grupo de agencias de viajes y estoy de acuerdo con usted. Pero, la pregunta es cómo cambiar la actitud del turista promedio para descansar y darle la oportunidad de obtener el máximo conjunto de impresiones y sentir un acercamiento individual a su amado.
Entendimos que estos planes ambiciosos no pueden resolverse con un solo servicio o con una única solución, pero siempre debemos comenzar por algún lado. Y ahora, habiéndonos establecido con el objetivo principal, comenzamos a buscar ese primer ladrillo, que servirá como la base de nuestra solución futura. Después de una larga búsqueda, se nos ocurrió la idea de un servicio, del que ahora quiero hablar.

Que es esto

En resumen, esto es UBER para viajeros. Imagine que es un viajero experimentado que ha viajado a muchos lugares interesantes de todo el mundo y realmente quiere compartir su experiencia, bueno, y ganar algo de dinero. Y, por otro lado, un turista que está cansado de unas vacaciones turcas tumbado en la playa y comiendo y bebiendo. Y estas personas necesitan estar de alguna manera unidas. Entonces decidimos ayudar a estas personas a encontrarse.
El servicio es un mercado donde los turistas experimentados pueden registrarse para diseñar sus recorridos y proporcionarlos a las masas de futuros viajeros.

Tecnologías y cómo no son únicas

¿Cómo almacenar y dónde?

Como ya escribí, después de elegir las herramientas para crear el servicio, surgió la cuestión de elegir un almacén de datos. Por supuesto, a lo largo de los años nos hemos acostumbrado a las bases de datos relacionales y al SQL Server en particular. Sin embargo, se necesitaba una plataforma para una configuración mínima al inicio y un mínimo de esfuerzo con más soporte, así como la capacidad de escalar en el desarrollo de nuestro servicio y el crecimiento de visitantes.

Por lo tanto, en el proceso de búsqueda, se encontró una solución que cubría todos nuestros requisitos, era Firebase Realtime Database. Este servicio nos ayudó a resolver los problemas de almacenamiento de datos, alojamiento, servicio de autenticación, almacenamiento para almacenar datos estáticos. Además, este servicio está bajo el ala de Google, que a su vez nos dio bonificaciones, ya que proporcionó bibliotecas separadas para trabajar con Angular 2 y fue conveniente y rápido. Pero lo mejor que tenemos es la base de datos RealTime de fábrica. Nuestras primeras sensaciones fueron simplemente fantásticas.

Ahora no teníamos que hacer solicitudes constantemente al servicio, monitorear la relevancia de los datos en el cliente, esperar hasta que los datos lleguen al cliente (bueno, observo, Angular también nos ayudó). Configuramos todo esto en algún lugar en un día y luego comenzamos a crear directamente nuestro servicio, sin ser distraídos por problemas de infraestructura. Debo decir de inmediato que durante el proceso de desarrollo no gastamos ni un centavo en este servicio, ya que la versión básica es gratuita y es suficiente para el desarrollo, las pruebas y la experimentación.

No solo para almacenar, sino también para buscar

Y así, tan pronto como la primera versión beta estuvo lista, surgió la pregunta al filtrar los datos, y nos dimos cuenta de las primeras desventajas en Firebase. Al final resultó que, el proceso de muestreo de datos para una gran cantidad de condiciones simplemente no es compatible. Es posible seleccionar datos con una sola condición, o recopilar varios valores en un campo y luego filtrarlos. Este enfoque no nos convenía, y nuevamente comenzamos a buscar una solución.
Por supuesto, no rechazamos Firebase, ya que este menos no superpuso la masa de ventajas proporcionadas por este servicio. Afortunadamente, tuvimos la experiencia de usar Google Big Query, que obtuvimos en el proceso de nuestra investigación, y decidimos aplicarlo. La primera ventaja es que es Google, la segunda: consultas SQL nativas y favoritas y el bajo costo de poseer 1TB de datos por mes de forma gratuita.

Una vez más, todo se volvió claro y comprensible, escribieron un servicio de envío de datos y lo atornillaron con éxito a Cloud Function. Olvidé decir que Firebase también se encargó del backend, puede escribir sus propios disparadores en Nodejs y colgarlos en cualquier evento en la base de datos, así como en una solicitud http.

Como puede ver, el proceso de encontrar soluciones y enfoques se ha convertido en una tarea diaria para nosotros, ya que casi todos los días nos enfrentamos a nuevos desafíos que debían abordarse rápidamente.

No tuvimos tiempo de relajarnos y continuar tranquilamente creando nuestro servicio cuando comenzaron las pruebas de grupos focales, y nos dimos cuenta de que los usuarios están acostumbrados a cambiar los filtros muy rápidamente y desean ver de inmediato el resultado de su trabajo. Tales requisitos nos obligaron a abandonar Big Query y buscar algo nuevo. Dado que Big Query nos dio una velocidad de respuesta de un máximo de 2 segundos, y esto con una cantidad mínima de datos. Aquí, por supuesto, no hay nada de qué culparlos, ya que este servicio está destinado a procesar grandes volúmenes de información, y no a una reacción rápida a un montón de solicitudes consecutivas.

Como resultado, optamos por Elastic Search. Este producto nos permitió construir un motor de búsqueda rápido, nuestro filtrado comenzó a cumplir con los requisitos de nuestros usuarios. No diré mucho aquí, ya que este producto comenzó a ganar popularidad y hay suficiente información al respecto. Lo único que quiero señalar es que para este producto necesita una máquina virtual que deba alojarse en algún lugar. Esta función proporciona tanto Google como Microsoft, por lo que la elección es suya. Configurarlo es igual de fácil con el recurso bitnami. Elegimos Azure para nosotros, esta elección no se debió tanto a las características tecnológicas, sino más bien a factores de terceros).

Esto es SEO críptico

Y ahora el servicio se está ejecutando, las plataformas se están desarrollando y todo parece estar bien, estamos luchando por un futuro brillante. Pero, esto plantea el problema de promover nuestro servicio y el problema clave de SEO. Nunca pensé que esta pregunta podría no ser tan elaborada por los creadores de Angular. Al final resultó que, la aplicación de página única es muy débil para proporcionar esta función, y para ser honesto, no lo es en absoluto. Sí, puede coser datos estáticos en metaetiquetas y cuando omite el Crowl o cuando comparte proporciona la misma información, bueno, de alguna manera será incorrecto e ineficaz. Después de navegar por Internet, nos encontramos con un servicio tan maravilloso, que es parte de Angular 4, Angular Universal. Después de leer la descripción, nos dimos cuenta de que esto es lo que necesitamos y que en vano regañamos a los desarrolladores del marco.

Una epopeya comenzó con atornillar esta felicidad a nuestro proyecto, noto que en ese momento ya se habían escrito unos 10 módulos grandes y se utilizaron unos 12 paquetes npm de terceros. La primera configuración de un proyecto limpio fue perfecta, gracias a los manuales en Internet, y todo pareció comenzar. Además, torcimos la parte del servidor en la misma función de nube de Firebase. Bueno, ahora tenemos que probar el código de batalla, y luego hubo problemas. Primero, como resultó, todos los paquetes npm de terceros deberían ser compatibles con Angular 4, en el código del lado del servidor no se puede usar la ventana de variables, documentos, etc., bueno, depurar toda esta felicidad simplemente no es realista.

No describiré todos nuestros tormentos con este servicio, ya que fue mucho y doloroso. Diré una cosa, no lo superamos, no lo sé o no lo entendí completamente, o simplemente todavía está húmedo y no está listo para un uso productivo. En general, depende de usted decidir quién puede tener éxito, pero decidimos detenernos allí. Como resultado, se escribió un servicio que escucha todas las solicitudes http y devuelve una solicitud index.html, pero antes de eso, arroja las metaetiquetas necesarias. Como resultado, salió bien y durante 3 meses el vuelo ha sido normal. Por cierto, también lo alojamos en Azure para todos los mismos factores de terceros.

CDN nuestro todo

Y aquí de nuevo algún tiempo de estabilidad y trabajo relativamente tranquilo. Y nadie pensó que la sorpresa nos espera de Facebook. Un buen día resultó que compartir en FB no funciona. Al principio pensamos que esto se debía al endurecimiento de las políticas de seguridad en FB, luego con el bloqueo de IP, pero no encontramos la razón. Contactado en apoyo de FB y Firebase, pero cada uno pateó al otro.

Lo único que hemos determinado es que el problema está en las URL de las imágenes que almacenamos en la tienda de Firebase, y la URL, te digo de inmediato, es muy específica allí. Decidimos transferir todo el contenido estático a Azure también, y le diré que esta decisión fue correcta, ya que la velocidad de carga de fotos ha aumentado, y puede administrar todo esto de manera más flexible y transparente.

Para resumir

Por el momento, ya estamos en el tercer mes productivo, estamos mejorando y ampliando constantemente la funcionalidad. Para el control de versiones, por supuesto, usamos Git, automatizaremos gradualmente las compilaciones y la implementación. Recibimos alrededor de 450 nuevas visitas únicas por día, hay saltos de hasta 1000 usuarios. Y todo funciona.

Lo que me gustaría resumir de todo lo que se ha dicho:

1. No es necesario tratar de resolver todos los problemas que aparecen en sus proyectos debido a un servicio o una tecnología.
2. Intente desarrollar módulos universales para una mayor flexibilidad en el futuro.
3. La elección de un proveedor de servicios en la nube es un asunto puramente personal, ya que en general todos brindan el mismo conjunto de servicios. La pregunta permanece en el precio y sus preferencias.
4. Diseñe su solución para que pueda migrar entre diferentes proveedores de servicios y tecnologías, o al menos pensar en una estrategia para un posible movimiento.
5. Bueno, no tengas miedo de experimentar.