L'histoire de la naissance d'un service de recherche et de réservation en ligne pour les voyages protégés par le droit d'auteur à travers le monde: le mot du développeur

Comment tout a commencé
Tourment idéal
Technologies et comment elles ne sont pas uniques
Comment stocker et où?
Non seulement pour stocker, mais aussi pour rechercher
C'est un SEO cryptique
Cdn notre tout
Pour résumer

Comment tout a commencé

Je veux partager notre histoire semestrielle de création d'un service en ligne pour rechercher et réserver des voyages protégés par le droit d'auteur à travers le monde. Lors de la création de cet article, l'objectif était de parler de l'expérience de création de nos propres solutions à partir de zéro et des problèmes et défis que nous avons rencontrés en cours de route, alors ne jugez pas strictement.

Pour commencer, de quel type de service s'agit-il et pourquoi il était nécessaire de le créer. Pendant longtemps, notre équipe a travaillé sur divers grands projets pour des clients commerciaux. Ce sont des portails pour les banques, les entreprises, les grandes exploitations, ainsi que les systèmes de gestion des documents. Naturellement, travailler avec un tel segment implique la satisfaction d'un cercle restreint d'employés intéressés et ne se termine pas toujours par une utilisation longue et réussie.

Il y a plusieurs raisons à cela: un manque de compréhension du projet au stade initial, un désir d'économiser de l'argent et d'obtenir l'équipement le plus complet, des exigences changeantes au stade final sans aucune révision des termes et des budgets. Comme vous pouvez le voir, la satisfaction du projet des deux côtés, après de telles conditions, est très difficile à atteindre.

Ainsi, après toute cette expérience, nous avons décidé de nous essayer sur le marché, où les retours du client sont rapides comme l'éclair, vous comprenez l'intérêt pour le produit le plus rapidement possible et voyez l'utilisation de votre service au quotidien.
Il s'est avéré que nos journées calmes étaient terminées!

Tourment idéal

La première chose qui devait être faite était de trouver l'idée de ce que nous voulons fournir si utile qui n'est pas sur le marché et qui sera perçu et attendu. Nous avons eu plusieurs de ces échantillons et au cours des deux premiers mois, nous avons entrepris des expériences pour trouver l'avenir. Comme vous pouvez le comprendre, il y avait aussi un problème avec les technologies, car il est nécessaire de faire des maquettes fonctionnelles dans les plus brefs délais, de vérifier leur opérabilité et de les améliorer ou de les refaire constamment.

Au départ, le bagage de technologies que nous avions n'était pas très jQuery et C # (que nous utilisions dans nos précédents projets). Ces outils ne nous ont pas permis de relever les défis de manière rapide et flexible. Heureusement, nous avons déjà envisagé de nouvelles approches pour le développement client et serveur. Notre choix s'est porté sur Angular 2 et Node.js. Cette solution nous a permis de former rapidement des composants et modules que nous pourrions modifier dans les plus brefs délais (le jour nous pourrions les refaire deux ou trois fois).

Nous sommes arrivés à la conclusion que chaque composant devait être aussi petit que possible et intégrable dans d'autres composants et modules. Ainsi, au cours des expériences, nous avons accumulé suffisamment de modèles à partir desquels il a été possible d'assembler différentes dispositions de travail.

Mais si nous avons trouvé les outils assez rapidement et au cours de la bataille, nous avons augmenté nos compétences de plus en plus (je remarquerai immédiatement Google pour vous aider, mais n'oubliez pas les didacticiels vidéo), une autre question s'est posée: où stocker les données. Mais j'en parlerai un peu plus tard, et revenons maintenant à l'idée elle-même.

Le principal vecteur de notre service que nous visions à organiser les voyages, vous direz immédiatement qu'à notre époque il y a un tas de sites et de services pour le voyage, plus le même tas d'agences de voyage et je suis d'accord avec vous. Mais, la question est de savoir comment changer l'attitude du touriste moyen pour se reposer et lui donner l'opportunité d'obtenir le maximum d'impressions et de ressentir une approche individuelle de sa bien-aimée.
Nous avons compris que de tels plans ambitieux ne peuvent pas être résolus avec un seul service ou avec une seule solution, mais nous devons toujours commencer quelque part. Et maintenant, après nous être établis avec l'objectif principal, nous avons commencé à chercher cette première brique, qui servira de base à notre future solution. Après une longue recherche, nous avons eu l'idée d'un service, dont je veux maintenant parler.

Qu'est-ce que c'est?

En bref, c'est UBER pour les voyageurs. Imaginez que vous êtes un voyageur expérimenté qui a voyagé dans de nombreux endroits intéressants à travers le monde et qui veut vraiment partager son expérience et gagner de l'argent. Et d'autre part, un touriste qui en a assez des vacances turques avec s'allonger sur la plage et manger et boire. Et ces gens doivent être en quelque sorte unis. Nous avons donc décidé d'aider ces personnes à se retrouver.
Le service est un marché où les touristes expérimentés peuvent s'inscrire pour concevoir leurs circuits et les proposer à la masse des futurs voyageurs.

Technologies et comment elles ne sont pas uniques

Comment stocker et où?

Comme je l'ai déjà écrit, après avoir choisi les outils de création du service, la question s'est posée de choisir un entrepôt de données. Bien sûr, au fil des années, nous nous sommes habitués aux bases de données relationnelles et à SQL Server en particulier. Mais, une plate-forme était nécessaire pour une configuration minimale au départ et un minimum d'effort avec un support supplémentaire, ainsi que la capacité d'évolution dans le développement de notre service et la croissance des visiteurs.

Ainsi, dans le processus de recherche, une solution a été trouvée qui couvrait toutes nos exigences, c'était la base de données en temps réel Firebase. Ce service nous a aidés à résoudre les problèmes de stockage de données, d'hébergement, de service d'authentification, d'entreposage pour le stockage de données statiques. De plus, ce service est sous l'aile de Google, qui à son tour nous a donné de bons bonus, car il fournissait des bibliothèques séparées pour travailler avec Angular 2 et il était pratique et rapide. Mais la chose la plus cool que nous ayons est la base de données RealTime prête à l'emploi. Nos premières sensations étaient tout simplement fantastiques.

Maintenant, nous n'avions plus à constamment faire des demandes au service, à surveiller la pertinence des données sur le client, à attendre que les données arrivent au client (enfin, je note, Angular nous a également aidés). Nous avons configuré tout cela quelque part en une journée, puis nous avons commencé à créer directement notre service, sans être distraits par des problèmes d'infrastructure. Je dois dire tout de suite que pendant le processus de développement, nous n'avons pas dépensé un centime pour ce service, car la version de base est gratuite et elle suffit largement pour le développement, les tests et l'expérimentation.

Non seulement pour stocker, mais aussi pour rechercher

Et donc, dès que la première version bêta était prête, la question s'est posée de filtrer les données, et nous avons réalisé les premiers inconvénients de Firebase. Il s'est avéré que le processus d'échantillonnage des données pour un grand nombre de conditions n'est tout simplement pas pris en charge. Il est possible de sélectionner des données avec une seule condition, ou de collecter plusieurs valeurs dans un champ puis de les filtrer. Cette approche ne nous convenait pas et nous avons recommencé à chercher une solution.
Bien sûr, nous n'avons pas refusé Firebase, car celui-ci ne chevauchait pas la masse des avantages apportés par ce service. Heureusement, nous avions l'expérience de l'utilisation de Google Big Query, que nous avons obtenue au cours de nos recherches, et nous avons décidé de l'appliquer. Le premier avantage est que c'est Google, le second - les requêtes SQL natives et préférées et le faible coût de possession gratuite de 1 To de données par mois.

Encore une fois, tout est devenu clair et compréhensible, ils ont écrit un service d'envoi de données et l'ont vissé avec succès à Cloud Function. J'ai oublié de dire que Firebase s'est également occupé du backend, vous pouvez écrire vos propres déclencheurs sur Nodejs et les accrocher à n'importe quel événement de la base de données, ainsi qu'à une requête http.

Comme vous pouvez le voir, le processus de recherche de solutions et d'approches est devenu une tâche quotidienne pour nous, car presque chaque jour, nous étions confrontés à de nouveaux défis qui devaient être relevés rapidement.

Nous n'avons pas eu le temps de nous détendre et de continuer calmement à créer notre service lorsque les tests des groupes de discussion ont commencé, et nous avons réalisé que les utilisateurs sont habitués à changer de filtre très rapidement et veulent voir immédiatement le résultat de leur travail. Ces exigences nous ont obligés à abandonner Big Query et à chercher quelque chose de nouveau. Depuis Big Query nous a donné une vitesse de réponse d'un maximum de 2 secondes, et ce avec un minimum de données. Ici, bien sûr, il n'y a rien à leur reprocher, car ce service est destiné à traiter de gros volumes d'informations, et non à réagir rapidement à un tas de demandes consécutives.

En conséquence, nous avons opté pour la recherche élastique. Ce produit nous a permis de construire un moteur de recherche rapide, notre filtrage a commencé à répondre aux exigences de nos utilisateurs. Je ne dirai pas grand-chose ici, car ce produit a commencé à gagner en popularité et il y a suffisamment d'informations à ce sujet. La seule chose que je veux noter, c'est que pour ce produit, vous avez besoin d'une machine virtuelle qui doit être hébergée quelque part. Cette fonctionnalité fournit à la fois Google et Microsoft, vous avez donc le choix. Le configurer est tout aussi simple en utilisant la ressource bitnami. Nous avons choisi Azure pour nous-mêmes, ce choix n'était pas tant à cause de fonctionnalités technologiques, mais plutôt à cause de facteurs tiers).

C'est un SEO cryptique

Et maintenant, le service fonctionne, les plateformes sont en cours de développement et tout semble aller bien, nous aspirons à un avenir radieux. Mais cela soulève la question de la promotion de notre service et le problème clé du référencement. Je n'ai jamais pensé que cette question pourrait ne pas être aussi élaborée par les créateurs d'Angular. Il s'est avéré que l'application Page unique offre très mal cette fonctionnalité, et pour être honnête - elle ne le fait pas. Oui, vous pouvez coudre des données statiques dans des balises META et lorsque vous contournez Crowl ou lorsque vous partagez les mêmes informations, eh bien, ce sera en quelque sorte faux et inefficace. Après avoir navigué sur Internet, nous sommes tombés sur un service aussi merveilleux, qui fait partie d'Angular 4, Angular Universal. Après avoir lu la description, nous avons réalisé que c'est ce dont nous avons besoin et qu'en vain nous avons réprimandé les développeurs du framework.

Une épopée a commencé en vissant ce bonheur à notre projet, je note qu'à ce moment, environ 10 grands modules avaient déjà été écrits et environ 12 packages npm tiers ont été utilisés. La première configuration d'un projet propre s'est parfaitement déroulée, grâce aux manuels sur Internet, et tout a semblé démarrer. De plus, nous avons tordu la partie serveur sur la même fonction cloud de Firebase. Eh bien, maintenant nous devons essayer le code de bataille, puis il y a eu des problèmes. Tout d'abord, il s'est avéré que tous les packages npm tiers devraient prendre en charge Angular 4, dans le code côté serveur, vous ne pouvez pas utiliser la fenêtre de variables, le document, etc., bien, le débogage de tout ce bonheur n'est tout simplement pas réaliste.

Je ne décrirai pas tous nos tourments avec ce service, car c'était beaucoup et douloureux. Je vais dire une chose, nous ne l'avons pas surmonté, je ne le sais pas ou ne le comprenais pas complètement, ou tout simplement il est encore humide et n'est pas prêt pour une utilisation productive. En général, c'est à vous de décider qui peut réussir, mais nous avons décidé de nous arrêter là. En conséquence, un service a été écrit qui écoute toutes les requêtes http et renvoie une requête index.html, mais avant cela, y jette les balises META nécessaires. En conséquence, cela s'est bien passé et pendant 3 mois, le vol a été normal. Soit dit en passant, nous hébergeons tout cela sur Azure également pour les mêmes facteurs tiers.

Cdn notre tout

Et là encore un peu de stabilité, et un travail relativement calme. Et personne ne pensait que la surprise nous attend de Facebook. Un beau jour, il s'est avéré que le partage dans FB ne fonctionnait pas. Au début, nous pensions que cela était dû au durcissement des politiques de sécurité dans FB, puis au blocage IP, mais nous n'en avons pas trouvé la raison. Contacté à l'appui de FB et de Firebase, mais chacun a donné un coup de pied à l'autre.

La seule chose que nous avons déterminée est que le problème est dans les URL des images que nous avons stockées dans le magasin Firebase, et l'URL, je vous le dis tout de suite, est très spécifique là-bas. Nous avons également décidé de transférer tout le contenu statique vers Azure, et je vous dirai que cette décision était juste, car la vitesse de téléchargement des photos a augmenté et vous pouvez gérer tout cela de manière plus flexible et transparente.

Pour résumer

Pour le moment, nous sommes déjà productifs au 3ème mois, nous améliorons et étendons constamment la fonctionnalité. Pour le contrôle de version, nous utilisons bien sûr Git, nous allons progressivement automatiser les builds et déployer. Nous recevons environ 450 nouvelles visites uniques par jour, il y a des sauts jusqu'à 1000 utilisateurs. Et tout fonctionne.

Ce que je voudrais résumer de tout ce qui a été dit:

1. Pas besoin d'essayer de résoudre tous les problèmes qui apparaissent dans vos projets en raison d'un service ou d'une technologie.
2. Essayez de développer des modules universels pour plus de flexibilité à l'avenir.
3. Le choix d'un fournisseur de services cloud est une affaire purement personnelle, car en général, ils fournissent tous le même ensemble de services. La question reste dans le prix et vos préférences.
4. Concevez votre solution de manière à pouvoir migrer entre différents fournisseurs de services et technologies, ou au moins réfléchir à une stratégie pour un éventuel déménagement.
5. Eh bien, n'ayez pas peur d'expérimenter.