---
term: 'Object storage gestito e distribuzione degli asset'
seoTitle: 'Object storage gestito: la distribuzione degli asset spiegata'
headline: 'Che cos''è l''object storage gestito e come funzionano le pipeline di distribuzione degli asset?'
slug: object-storage-gestito
category: cloud-architecture
shortDefinition: 'L''object storage gestito è un servizio BaaS che archivia i file caricati via SDK e li distribuisce tramite URL serviti da CDN, con controllo degli accessi.'
relatedTerms:
  - cdn-content-delivery-network
  - edge-computing-edge-functions
  - baas-vs-custom-backend
  - backend-sdk
contrastsWith:
  - cdn-content-delivery-network
faq:
  - question: 'Che cos''è l''object storage e in che cosa differisce da un file system?'
    answer: 'L''object storage conserva ogni file come oggetto autonomo – dati più metadati sotto una chiave univoca – in uno spazio dei nomi piatto, invece che in un file system gerarchico con directory e lock sui file. È questa piattezza a permettergli di scalare a miliardi di file e di esporre ogni oggetto come URL indirizzabile via HTTP, esattamente la forma di cui ha bisogno la distribuzione di asset web e mobile.'
  - question: 'Come funziona il caricamento di file in un BaaS?'
    answer: 'L''SDK client prende un file, lo trasmette in streaming all''endpoint dei file della piattaforma e riceve un URL stabile. La piattaforma scrive i byte attraverso un adattatore di storage nell''object storage e restituisce un riferimento da allegare a un oggetto del database. Non c''è alcun bucket da predisporre, alcuna richiesta di caricamento da firmare a mano, alcun server di upload da gestire – la pipeline è della piattaforma.'
  - question: 'Che cos''è un adattatore di storage in Parse Server?'
    answer: 'Il livello intercambiabile fra l''API dei file e lo storage fisico. Parse Server fornisce adattatori per GridFS (file dentro MongoDB, l''opzione predefinita), per il file system locale e per gli object store compatibili S3, e l''interfaccia resta aperta a backend personalizzati. Il codice client ignora l''adattatore – salvare un file, ottenere un URL – quindi il backend di storage può cambiare senza toccare l''app.'
  - question: 'Che ruolo ha un CDN nella distribuzione degli asset?'
    answer: 'L''object storage è l''origin; il CDN è il livello di distribuzione messo davanti. La prima richiesta di un file lo recupera dallo storage e lo mette in cache su un server edge vicino all''utente; le richieste successive sono servite da quella cache senza toccare l''origin. I caricamenti scrivono una sola volta nello storage, mentre le letture – enormemente più numerose delle scritture, per gli asset – vengono assorbite all''edge.'
  - question: 'Chi può leggere o scrivere file in un object storage gestito?'
    answer: 'I caricamenti richiedono una chiamata SDK autenticata, quindi l''accesso in scrittura segue il modello utenti dell''app. La protezione in lettura viene dall''oggetto che referenzia il file: proteggendo il record con le ACL, solo gli utenti autorizzati possono recuperare l''URL. L''avvertenza onesta: un URL di file, una volta noto, è di norma servito a chi lo richiede – la segretezza dell''URL va trattata come oscurità, e i download davvero sensibili vanno messi dietro endpoint autenticati.'
  - question: 'I file vanno archiviati nel database o nell''object storage?'
    answer: 'Metadati nel database, byte nell''object storage – il pattern del riferimento. Righe che trasportano blob di diversi megabyte gonfiano il database, rallentano query e backup e sprecano memoria di cache. Un BaaS impone automaticamente questa separazione sana: l''oggetto file vive nello storage, il database conserva un riferimento leggero più metadati interrogabili come proprietario, dimensione e tipo.'
  - question: 'Quali tipi e dimensioni di file può gestire un BaaS?'
    answer: 'Qualsiasi tipo di contenuto – immagini, video, audio, PDF, binari arbitrari – perché l''object storage è indifferente al contenuto. I limiti di dimensione sono fissati per piattaforma o per piano e coprono ampiamente immagini e documenti; i media molto grandi, come il video di lunga durata, meritano di solito una pipeline dedicata con caricamenti riprendibili e transcodifica. Tipo e dimensione vanno comunque validati lato server al caricamento.'
  - question: 'Come dovrebbero gestire le app mobile i caricamenti di file grandi in modo affidabile?'
    answer: 'Caricare in background fuori dal thread dell''interfaccia, mostrare l''avanzamento con i callback dell''SDK e ritentare alla perdita di connettività – sulle reti mobili il fallimento parziale è il caso normale. Comprimere o ridimensionare le immagini lato client prima del caricamento quando la piena risoluzione non serve: spedire una foto da 12 megapixel destinata a un avatar da 200 pixel spreca batteria, banda e spazio.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Object storage (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Object_storage'
  - name: 'Content delivery network (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Content_delivery_network'
  - name: 'HTTP caching (MDN)'
    url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching'
  - name: 'Parse Server documentation'
    url: 'https://docs.parseplatform.org/parse-server/guide/'
cta:
  title: 'Archiviazione e distribuzione dei file, già assemblate'
  text: 'Carica un file con una sola chiamata SDK e ottieni un URL servito da CDN – Back4app gestisce lo storage, il livello degli adattatori e la pipeline di distribuzione dietro di esso. Allega i file agli oggetti, proteggili con le ACL e salta del tutto il cantiere bucket-e-pipeline.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-23'
translationKey: managed-object-storage
---

**L'object storage gestito è un servizio BaaS che archivia i file caricati via SDK e li distribuisce tramite URL serviti da CDN, con controllo degli accessi.** Riduce una pipeline che i team altrimenti assemblano a mano – bucket, endpoint di caricamento, permessi, configurazione della cache – a due chiamate SDK: salvare il file, usare l'URL. Il database conserva un riferimento; i byte vivono in uno storage costruito esattamente per questa forma di dati.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Archiviazione di file gestita dalla piattaforma dietro l'SDK: entra un file, esce un URL |
| Il pattern centrale | I byte nell'object storage, riferimenti e metadati nel database |
| Percorso di distribuzione | Lo storage è l'origin; un CDN serve le letture dalle cache edge |
| Modello di sicurezza | Caricamenti autenticati; letture protette dalle ACL dell'oggetto che referenzia il file |
| Che cosa si evita | Bucket, server di upload, logica di firma, tubature della cache |

## Caricare, allegare, proteggere

L'unità di lavoro è un oggetto file: l'SDK trasmette i byte, la piattaforma restituisce un URL stabile, e il riferimento si allega a un record del database la cui ACL stabilisce chi può trovarlo:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Upload, attach, protect: three steps to a CDN-delivered private file
const file = new Parse.File('report.pdf', fileInput.files[0]);
await file.save(); // streamed to managed object storage

const doc = new Parse.Object('Document');
doc.set('file', file);
doc.set('owner', Parse.User.current());
doc.setACL(new Parse.ACL(Parse.User.current())); // only the owner reads
await doc.save();

console.log(file.url()); // CDN-backed delivery URL — no bucket configured
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Upload, attach, protect: three steps to a CDN-delivered private file
final parseFile = ParseFile(File('report.pdf'));
await parseFile.save(); // streamed to managed object storage

final owner = await ParseUser.currentUser() as ParseUser;
final doc = ParseObject('Document')
  ..set('file', parseFile)
  ..set('owner', owner)
  ..setACL(ParseACL(owner: owner)); // only the owner reads
await doc.save();

print(parseFile.url); // CDN-backed delivery URL — no bucket configured
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Upload, attach, protect: three steps to a CDN-delivered private file
var file = ParseFile(name: "report.pdf", data: pdfData)
let savedFile = try await file.save() // streamed to managed object storage

var doc = Document()
doc.file = savedFile
doc.owner = try await User.current()
var acl = ParseACL()
acl.setReadAccess(user: doc.owner!, value: true)
acl.setWriteAccess(user: doc.owner!, value: true) // only the owner reads
doc.ACL = acl
_ = try await doc.save()

print(savedFile.url ?? "") // CDN-backed delivery URL — no bucket configured
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Upload, attach, protect: three steps to a CDN-delivered private file
val file = ParseFile("report.pdf", pdfBytes)
file.save() // streamed to managed object storage

val owner = ParseUser.getCurrentUser()
val doc = ParseObject("Document")
doc.put("file", file)
doc.put("owner", owner)
doc.acl = ParseACL(owner) // only the owner reads
doc.save()

println(file.url) // CDN-backed delivery URL — no bucket configured
```

Niente in quelle quattro schede menziona un bucket, una regione, una richiesta firmata o un header di cache – la pipeline dietro la chiamata si occupa di tutto questo.

## La pipeline dietro la chiamata

Due flussi condividono l'infrastruttura, con profili di prestazioni opposti. I caricamenti sono rari e critici per la coerenza; le letture sono massicce e critiche per la latenza. La pipeline li separa di conseguenza:

```mermaid
flowchart LR
  accTitle: Pipeline di caricamento e distribuzione di un object storage gestito
  accDescr: I caricamenti partono dall'SDK client, attraversano l'API della piattaforma e un adattatore di storage fino all'object storage, con un riferimento salvato nel database; le distribuzioni partono dal file archiviato e attraversano le cache edge del CDN fino ai client che richiedono l'URL del file.
  subgraph up["Percorso di caricamento (scritture)"]
    C[SDK client] -->|"caricamento autenticato"| A[API dei file della piattaforma]
    A --> AD["Adattatore di storage<br/>(GridFS / file system / compatibile S3)"]
    AD --> OS[("Object storage")]
    A -->|"riferimento al file"| DB[("Record nel database<br/>+ ACL")]
  end
  subgraph down["Percorso di distribuzione (letture)"]
    OS -->|"recupero dall'origin (prima richiesta)"| E["Cache edge del CDN"]
    E -->|"risposta dalla cache"| U[Utenti in tutto il mondo]
  end
```

La metà destra è dove vive l'economia del sistema. Gli asset vengono scritti una volta e letti migliaia o milioni di volte, quindi servire le letture dalle [cache edge](/glossary/it/cdn/) invece che dall'origin decide sia la latenza sia il costo. Una cache aggressiva è sicura perché i file archiviati sono immutabili per convenzione – sostituire un avatar carica un *nuovo* file con un nuovo URL invece di modificare il vecchio, il che aggira del tutto il [problema dell'invalidazione della cache](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching).

## Object storage gestito vs. un semplice CDN

I due vengono confusi di continuo perché entrambi finiscono in "URL di file veloci" – ma risolvono due metà diverse del problema:

| Dimensione | Object storage gestito | Semplice CDN |
| --- | --- | --- |
| Che cos'è | Il sistema di riferimento per i file | Un livello di accelerazione per file ospitati altrove |
| Origin | Inclusa – lo storage *è* l'origin | Da fornire e gestire in proprio |
| Caricamenti | Operazione SDK di prima classe | Fuori perimetro – la scrittura sull'origin resta a carico del progetto |
| Controllo degli accessi | ACL tramite l'oggetto del database che referenzia il file | Regole di cache e URL firmati da configurare |
| Integrazione con il database | I riferimenti ai file si allegano nativamente ai record dell'app | Nessuna – la contabilità resta da costruire |
| Punto forte | Possedere il ciclo di vita caricamento-archiviazione-protezione | Spremere latenza dalla distribuzione globale |

In una pipeline gestita i due ruoli arrivano già cablati: lo storage come origin, un CDN come livello di distribuzione, e nessuna giuntura fra i due da configurare – o da configurare male.

## Adattatori di storage: il livello di portabilità

In Parse Server – il motore open-source sotto Back4app – l'API dei file e lo storage fisico sono disaccoppiati da un [adattatore di storage](https://docs.parseplatform.org/parse-server/guide/): GridFS conserva i file dentro MongoDB (l'opzione predefinita), un adattatore per file system scrive sul disco locale, e gli adattatori compatibili S3 puntano a qualsiasi object store conforme, presso un hyperscaler o ospitato in proprio. L'interfaccia degli adattatori è pubblica, quindi un backend personalizzato è a una classe di distanza. I client non se ne accorgono: `save file, get URL` è tutto il contratto, il che significa che il backend di storage può essere sostituito – da gestito a self-hosted, da uno store a un altro – senza un rilascio dell'app.

## Chi può leggere e scrivere i file

La sicurezza dei file è la parte meno trattata dalla maggior parte dei tutorial sullo storage e la prima cosa che un audit chiede. Il modello gestito offre tre livelli, con un'avvertenza onesta:

- **Le scritture sono autenticate.** I caricamenti passano dall'SDK sotto un utente autenticato (o con le credenziali del proprio server) – non esiste alcun endpoint pubblico di caricamento anonimo, a meno di costruirne uno. La validazione lato server di tipo e dimensione al caricamento resta a carico di chi sviluppa.
- **Le letture sono governate dai riferimenti.** L'URL del file vive su un oggetto del database protetto dalle [ACL](/glossary/it/liste-di-controllo-degli-accessi-acl/) – il `Document` dello snippet è leggibile solo dal suo proprietario, quindi solo il proprietario può arrivare all'URL con una query.
- **Gli URL stessi sono bearer token.** Una volta noto, un URL di file è di norma servito a chiunque lo possieda – il contenuto in cache sul CDN non viene riautorizzato a ogni richiesta. Per i file davvero sensibili, conviene servire i download tramite una funzione autenticata che verifica i permessi prima dello streaming, e trattare la semplice segretezza dell'URL per quello che è: oscurità, utile ma non sufficiente.

## Casi d'uso tipici

- **Media generati dagli utenti.** Avatar, foto e allegati – caricamento dall'[SDK client](/glossary/it/sdk-backend/), riferimento salvato sull'utente o sul post, rendering tramite l'URL.
- **Documenti con proprietario.** Fatture, report e contratti, in cui l'ACL del record che li referenzia è il sistema dei permessi.
- **Contenuti dell'app e asset di gioco.** Pacchetti di livelli, bundle di media e contenuti aggiornati da remoto, serviti dalle cache edge invece di essere spediti nei binari degli store.
- **Condivisione di asset multipiattaforma.** Un file caricato, un URL, un rendering identico su iOS, Android, Flutter e web.
- **Output di pipeline.** Export generati, miniature e media elaborati, scritti da funzioni lato server e distribuiti come qualsiasi altro asset.

## Storage gestito o pipeline costruita in casa? Matrice decisionale

| Object storage gestito quando… | Assemblare una pipeline propria quando… |
| --- | --- |
| I file si allegano ai dati dell'app (utenti, post, ordini) | Gli asset sono un prodotto a sé con un proprio ciclo di vita |
| I flussi standard caricamento/distribuzione/protezione bastano | Servono transcodifica, caricamenti riprendibili da molti GB o DRM |
| La dimensione del team sconsiglia di possedere infrastruttura | Un team di piattaforma dedicato gestisce già lo storage |
| La portabilità conta – gli adattatori tengono aperta l'uscita | Si ottimizza il costo dello storage su scala di petabyte |
| Il vincolo è il tempo di rilascio | Il vincolo è il controllo al millisecondo di ogni salto di cache |

Vale lo stesso calcolo costruire o comprare della [decisione BaaS in generale](/glossary/it/baas-vs-backend-personalizzato/), alla scala dell'archiviazione di file: la pipeline assemblata non è difficile da imitare male e piuttosto difficile da gestire bene.

## Limiti e trade-off

- **L'accesso basato su URL è grossolano.** Le ACL proteggono il *riferimento*, non ogni singola consegna dei byte di un file in cache. I prodotti con documenti sensibili hanno bisogno, in più, di endpoint di download autenticati – il salto aggiuntivo va messo in conto.
- **I limiti di dimensione sono reali.** I limiti per file della piattaforma coprono ampiamente immagini e documenti; il video di lunga durata e i dataset grezzi appartengono a una pipeline specializzata con caricamenti riprendibili.
- **Nessun livello di trasformazione per impostazione predefinita.** Ridimensionamento, transcodifica e watermark restano da aggiungere – tipicamente come funzioni lato server o [funzioni edge](/glossary/it/edge-computing/) davanti allo storage.
- **Egress e storage si accumulano.** I file non si ripuliscono mai da soli; i caricamenti orfani di record abbandonati fanno crescere la fattura in silenzio. Conviene pianificare la pulizia dei file non referenziati.
- **La freschezza della cache è un'arma a doppio taglio.** Il versionamento con URL immutabili rende gli aggiornamenti istantanei, ma se un file viene *davvero* sovrascritto sul posto, le cache edge possono servire la versione obsoleta fino alla scadenza dei TTL – versionando gli URL il problema sparisce.

## L'object storage gestito su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La sua archiviazione di file è la pipeline gestita descritta in questo articolo: i caricamenti dagli SDK passano in streaming dall'API dei file di Parse Server a un object storage gestito dalla piattaforma, gli URL restituiti sono serviti da CDN per la distribuzione globale, e il controllo degli accessi si compone con le stesse ACL che proteggono il resto dei dati. Poiché il livello degli adattatori è il Parse Server open-source, i file – come il database – restano portabili verso qualsiasi deployment gestito in proprio.