Pippe mentali finite, stavolta ho trovato l'architettura perfetta:

1. client chiama API endpoint per ottenere un signed url

2. il server crea document Asset con un field "processed: false", e ritorna il signed url

3. client utilizza il signed url per effettuare l'upload direttamente da browser, cosa molto veloce ed efficiente

4. una cloud function è triggerata al seguito dell'upload, che effettuerà post-processing. Essendo questa funzione nella stessa rete di gcs ottenere i bytes degli asset è efficientissimo. Sarà responsabile di normalizzare file, ad esempio di convertire tutti i video in .mp4, tutti gli audio in .mp3, di effettuare la compressione e via dicendo

5. la cloud function salverà il file processato nella posizione permanente, eliminerà il temporaneo e aggiornerà il document asset mettendo "processed: true" e l'url con cui sarà possibile accedere all'asset

6. nel frattempo che la cloud function è in esecuzione il client guarderà il documento asset aspettando che processed sia true

Caso immagini:

7. quando processed diventa true il documento asset conterrà un url valido

8. Il client mostrerà questo url, così che le possiate incollare in un post come avete fatto finora

Caso audio, video:

7. il client attenderà che processed diventi true e basta

8. il client salverà l'assetId nei parametri di creazione del post

9. l'API responsabile della creazione di un post prenderà questo assetId, controllerà che il relativo document asset è stato processato. Se si prenderà l'url e lo allegherà nel post. Altrimenti panicherà ritornando un errore

Poi, per la gestione degli asset orfani:

Quando un asset viene pubblicato, aggiornerò il document asset con un parametro "hintId", rappresentante il post in cui è stato pubblicato. Aggiungerò un TTL che eliminerà asset che non hanno quesdto parametro dopo tot di tempo.