Work upload functionality

[tmaxmax]

• [x] Accepts Google Docs, Word, and PDF or images
• [x] Normalizes text (abandoned, not required for the MVP):
  • [x] ensures consistent punctuation (quotation marks, dashes, commas etc.)
  • [x] replaces cedilla ş and ţ with their comma counterparts ș and ț
  • [x] removes extra blank characters
• [x] Provides input for the work's type and based on that type, the subject title/character of the work.
• [x] Allow student to request the review of an associated teacher
• [x] Post-upload:
  • [x] If the user is a student, put their work in the review queue (set the work status in the database to pending)
  • [x] If the user is a teacher, upload it instantly (set the work status in the database to approved)

Note: the aforementioned repartition happens post-upload conceptually. Implementation-side, it takes place when inserting the work into the database.

Technical:

• [x] Decode JWT in order to retrieve the user's role and ID, which will be used for the Hasura interactions
• [x] Fix GraphQL response decoding for both successful and failed requests
• [x] Handle errors gracefully
  • [x] remove code repetition
  • [x] use the correct HTTP response codes
  • [x] remove redundant response body data
  • [x] provide better, useful error messages (for GraphQL query errors use the error message in the response, for example)
• [ ] Return information about the inserted work (id)

Testing:

• [x] valid documents
• [x] invalid document
• [x] requested teacher

Note: to improve user experience, it should be checked if the user is registered and eligible for upload before even accessing the upload interface.

[mateitudose]

Vezi ca work upload si analiza de text/OCR sunt 2 issue-uri diferite

[tmaxmax]

Nu le văd ca două chestii diferite, pentru că au ca scop final încărcarea unei lucrări. Practic indiferent de ce variantă de încărcare vei alege, tot încarci lucrarea. Îi ca și cum ai avea mai multe "parsere" pentru o lucrare, selectându-l pe cel necesar în funcție de formatul încărcării. Dacă ar fi să fac o schematică, ar fi

        |-> (format .doc/x etc.) Procesare cu Tika ----|
Upload -|-> (format PDF, imagine) Procesare cu GCloud -|-> selectare tip, titlu/caracter -> post-încărcare
        |-> scrie-l pe site (momentan nu e în plan)

De aia zic că ține de upload, pentru că logica de încărcare va fi aceeași după extragerea textului, indiferent de format, nefiind nevoie de funcții diferite.

În termeni de Golang, ai avea mai multe funcții de tipul

type TextParser func (c *fiber.Ctx) (string, error)

care vor fi apelate în funcție de tipul de upload (sau chiar un query parameter dat la apelul funcției, de exemplu ?method=tika).

[mateitudose]

Mi se pare mai eficient sa spargi algoritmul in mai multe "subprograme": de upload, de analiza cu Tika, de analiza cu Vision AI etc.

[mateitudose]

Plus ca serverless e pentru chestii light nu si cu analiza asta cu Tika, merge cu Vision AI ca ala e un request la un API...

[tmaxmax]

Exact asta am făcut și eu, ideea este că nu e nevoie de mai multe funcții.

Pentru analiza cu Tika, e tot un request la un API. E chiar mai complext cu Vision AI, având în vedere că trebe stocat mai întâi în bucket, postat request-ul de analizare, iar apoi încă un request pentru obținerea textului extras, care trebuie făcut după un anumit timp.

Procedeul pentru operare cu Tika e în documentația pachetului.

[mateitudose]

Pai si poti face toate astea intr-o singura functie serverless? Nu ai nici suficient timp, nici resurse.

[tmaxmax]

Ai dreptate aici, cu Tika se poate face, însă nu se poate în cazul Cloud Vision. Ar trebui ca utilizatorul să primească o notificare atunci când este gata analizarea.

Ar fi mai sugestiv să denumesc issue-ul "Work upload functionality", nu "serverless function", având în vedere acest lucru.

[mateitudose]

Deci nu mai e serverless? Adica asta e server-side practic. OK. Nu e problema. Ideea e: spargem sau nu functia in mai multe parti, adica sa zicem ca ai putea sa combini upload+Tika, dar cand e nevoie de Vision AI, nu prea ai cum...

[tmaxmax]

Ba, e serverless, atâta că sunt două funcții în cazul Cloud Vision - una care returnează un ID pentru task-ul respectiv, introduce într-un tabel în baza de date task-ul respectiv, la care clientul dă subscribe cu GraphQL ca să primească notificare atunci când e gata. În acel moment, clientul continuă procedeul de încărcare, și a doua funcție este apelată, care introduce încărcarea în baza de date și face operațiunea necesară de post-încărcare.