readme

README.md

@@ -0,0 +1,52 @@
+### Feature che vorremmo avere
+
+* da una persona vogliamo vedere le nostre interazioni passate con questo
+	* quindi dobbiamo mettere tra gli "streammati" anche gli utenti del servizio
+* sto interagendo con un tot, capire chi è che "conta di più" tra di loro
+	* versione semplice: dato un tot di persone guardo metadati  e, in una storia recente, retweet tra di essi
+		* i metadati si possono prendere con le API
+		* i retweet probabilmente solo con il crawler
+* ricerca frasi: "il primo che l'ha detto"
+
+
+Esistono degli "utenti": essi possono accedere alle nostre API per vedere un "twitter aumentato"
+
+### Architettura proposta
+
+#### Schema generale
+
+Lo schema è complesso, è vero, però abbiamo evitato di usare software troppo strani o di basarci su feature avveniristiche. Il tutto dovrebbe rimanere relativamente semplice da capire/interagirci.
+
+Abbiamo UN database mongodb;  un frontend scritto in Go; dei crawler in linguaggi vari ed eventuali ma con interfacce HTTP ben definite; un Inseritore/Validatore che riceve messaggi dai crawler e li mette su mongo. In realtà i crawler possono anche vivere "dentro" il frontend quando sono particolarmente semplici.
+Il frontend accede a Mongo in sola lettura. Il browser/client dell'utente parla SOLO col frontend. Il frontend dovra' quindi ricevere sia richieste che sono semplici interrogazioni, sia richieste che implicheranno la partenza di uno o più crawler. Questi crawler produrranno dei dati. Li passano all'inseritore, che li mette dentro mongo.
+
+Tutte le interazioni tra programmi diversi avvengono in HTTP. Questo permette di usare  librerie semplici; di contattare crawler su altre macchine. La cosa di parlare tra diverse macchine è comoda perché ad esempio si possono mettere più crawler che escono da più IP.
+
+
+#### Inseritore
+L'inseritore esiste per "mediare" le scritture su mongo. Il vantaggio di passarli all'inseritore invece di mettere direttamente i dati dentro mongo, è che così possiamo:
+
+1. validare! possiamo controllare che i dati ci sembrino corretti
+2. "riformattare". In particolare volevamo aggiungere un campo "generator" in cui scrivere *quale* crawler ha inserito il dato. In questo modo, in caso di errori di programmazione che comportano l'inquinamento della base dati, li si può ritrovare/cancellare/correggere più facilmente
+3. evitare che i crawler abbiano il supporto di libreria a mongodb
+
+
+
+#### Frontend
+
+Il frontend contiene un po' di logica; tipo se l'utente gli chiede "dammi delle informazioni sommarie su Mario" lui allora magari fa partire una query su mongo per vedere cosa sa su mario; vedendo che non c'è molto fa partire 3 crawler, uno per i metadati, uno per gli ultimi 30 tweet, uno boh.
+Sarà scritto in Go perché dovrà tenere traccia di queste cose asincrone con un minimo di ordine che in Python ci verrebbe difficile. In altri linguaggi non siamo boni.
+
+#### Crawler
+
+I crawler devono essere quindi degli oggetti asincroni, in grado di ricevere richieste HTTP mentre crawlano. Siccome puo' darsi che noi vorremo riciclare programmini di merda, allora facciamo un wrapperino che:
+
+* fa partire un server web
+* quando riceve una richiesta POST, fa partire un programma che prende i dati della POST come stdin
+	* finche' il programma non termina, mette tutto in coda senza far partire altro
+	* se il programma termina con exit code 0 allora bene, toglie dalla coda, e prosegue lanciandone un altro
+	* se il programma termina con exit code non-zero allora rimette in coda e ci riprova tra un po'
+* dice al frontend che ha finito
+
+
+Chiaramente si può pure fare che i crawler capiscono l'HTTP da soli; questo è meglio perché il rate limit si può impostare meglio.