Come i framework full-stack sfumano i ruoli di frontend e backend

Cosa significavano “frontend” e “backend”

Prima dei framework full-stack, “frontend” e “backend” erano separati da una linea abbastanza chiara: il browser da una parte, il server dall'altra. Quella separazione definiva i ruoli dei team, i confini dei repo e persino come si parlava dell’app.

Frontend (tradizionale)

Il frontend era la parte che girava nel browser dell'utente. Si concentrava su ciò che gli utenti vedono e con cui interagiscono: layout, stile, comportamento client-side e chiamate alle API.

In pratica, il lavoro frontend spesso significava HTML/CSS/JavaScript più un framework UI, poi inviare richieste a un'API backend per leggere e salvare dati.

Backend (tradizionale)

Il backend viveva sui server e si occupava di dati e regole: query al database, logica di business, autenticazione, autorizzazione e integrazioni (pagamenti, email, CRM). Esponeva endpoint—spesso REST o GraphQL—che il frontend consumava.

Un modello mentale utile era: il frontend chiede; il backend decide.

Che cos’è dunque un “framework full-stack”?

Un framework full-stack è un framework web che intenzionalmente abbraccia entrambi i lati di quella linea all’interno di un unico progetto. Può rendere pagine, definire route, recuperare dati ed eseguire codice server—pur producendo comunque un'interfaccia per il browser.

Esempi comuni includono Next.js, Remix, Nuxt e SvelteKit. L’importante non è che siano universalmente “migliori”, ma che rendono normale che il codice UI e il codice server convivano più da vicino.

Di cosa parla (e non parla) questo articolo

Non si tratta di affermare che “non serve più un backend”. Database, job in background e integrazioni esistono ancora. Il cambiamento riguarda responsabilità condivise: gli sviluppatori frontend toccano più aspetti server e gli sviluppatori backend toccano più rendering ed esperienza utente—perché il framework favorisce la collaborazione oltre il confine.

Perché sono emersi i framework full-stack

I framework full-stack non sono apparsi perché i team hanno dimenticato come costruire frontend e backend separati. Sono nati perché, per molti prodotti, il costo di coordinamento di tenerli separati è diventato più evidente dei benefici.

Forze che avvicinano il codice

I team moderni ottimizzano per spedire più velocemente e iterare meglio. Quando UI, fetching dei dati e “glue code” vivono in repo e workflow diversi, ogni feature diventa una staffetta: definire un'API, implementarla, documentarla, collegarla, correggere supposizioni sbagliate e ripetere.

I framework full-stack riducono quei passaggi permettendo a un'unica modifica di coprire pagina, dati e logica server in una sola pull request.

Anche l'esperienza sviluppatore (DX) conta. Se un framework ti dà routing, caricamento dati, primitive di caching e valori di default per il deploy, passi meno tempo a assemblare librerie e più tempo a costruire.

Perché browser e server condividono più strumenti

JavaScript e TypeScript sono diventati la lingua comune tra client e server, e i bundler hanno reso pratico impacchettare codice per entrambi gli ambienti. Quando il tuo server può eseguire JS/TS in modo affidabile, è più facile riutilizzare validazione, formattazione e tipi oltre il confine.

Il codice “isomorfo” non è sempre l'obiettivo—ma gli strumenti condivisi abbassano l'attrito per collocare le preoccupazioni insieme.

Da “pagine + API” a funzionalità end-to-end

Invece di pensare a due deliverable (una pagina e un'API), i framework full-stack incentivano a spedire una singola funzionalità: route, UI, accesso dati e mutation insieme.

Questo si allinea meglio con come si definisce il lavoro di prodotto: “Costruire il checkout”, non “Costruire l'UI del checkout” e “Costruire gli endpoint del checkout”.

Il compromesso

Questa semplicità è un grande vantaggio per team piccoli: meno servizi, meno contratti, meno parti mobili.

A scala maggiore, la vicinanza può invece aumentare il coupling, sfumare la responsabilità e creare rischi di prestazioni o sicurezza—quindi la comodità richiede regole e guardrail man mano che il codebase cresce.

I modi di rendering portano preoccupazioni di backend nello strato UI

I framework full-stack rendono il “rendering” una decisione di prodotto che impatta anche server, database e costi. Quando scegli una modalità di rendering, non stai solo scegliendo quanto appare veloce una pagina—stai decidendo dove avviene il lavoro e con quale frequenza.

SSR, SSG e ibrido—definizioni in parole semplici

Server-Side Rendering (SSR) significa che il server costruisce l'HTML per ogni richiesta. Ottieni contenuto aggiornato, ma il server lavora di più ogni volta che qualcuno visita.

Static Site Generation (SSG) significa che l'HTML è generato in anticipo (durante la build). Le pagine sono molto economiche da servire, ma gli aggiornamenti richiedono rebuild o revalidazione.

Rendering ibrido mescola approcci: alcune pagine sono statiche, altre sono renderizzate dal server, e alcune sono parzialmente aggiornate (per esempio rigenerando una pagina ogni N minuti).

Le scelte di rendering cambiano sia l'UI sia il carico sul server

Con SSR, una modifica “frontend” come aggiungere un widget personalizzato può trasformarsi in problemi backend: lookup di sessione, letture al database e tempi di risposta più lenti sotto carico.

Con SSG, una modifica “backend” come aggiornare prezzi può richiedere di pianificare la cadenza dei rebuild o la rigenerazione incrementale.

Le convenzioni del framework nascondono molta complessità: cambi una flag di configurazione, esporti una funzione o posizioni un file in una cartella speciale—e all'improvviso hai definito comportamento di caching, esecuzione server e cosa gira in build vs a richiesta.

Il caching fa parte del rendering, non solo dell'ops

Il caching non è più solo un’impostazione CDN. Il rendering include spesso:

• Regole di caching per route (cache forever, cache per 60 secondi o mai cache)
• Caching a livello di dato (cache dei risultati di una query al DB)
• Revalidation (servire HTML cache fino al refresh)

Per questo i modelli di rendering portano il pensiero backend nello strato UI: gli sviluppatori decidono freschezza, prestazioni e costi mentre progettano la pagina.

Route che gestiscono sia pagine sia API

I framework full-stack sempre più trattano “una route” come più di un URL che rende una pagina. Una singola route può includere anche il codice server che carica dati, gestisce submit di form e restituisce risposte API.

In pratica, questo significa avere una sorta di backend dentro il repo frontend—senza creare un servizio separato.

Loaders, actions e API route: un solo modello mentale

A seconda del framework, vedrai termini come loader (carica dati per la pagina), action (gestisce mutation come post di form) o API route esplicite (endpoint che restituiscono JSON).

Anche se sembrano “frontend” perché stanno vicino ai file UI, svolgono lavoro classico da backend: leggere parametri di richiesta, chiamare DB/servizi e formare una risposta.

Questa co-locazione basata sulla route è naturale perché il codice per capire una schermata è vicino: il componente pagina, i suoi bisogni di dati e le operazioni di scrittura spesso stanno nella stessa cartella. Invece di cercare in un progetto API separato, segui la route.

La gestione delle richieste diventa adiacente all'UI

Quando le route possiedono sia rendering sia comportamento server, le preoccupazioni backend entrano nel flusso di lavoro UI:

• La validazione avviene vicino al form o al componente che raccoglie l'input.
• Gli errori possono essere restituiti in una forma che l'UI può mostrare immediatamente (errori per campo, banner, redirect).
• I controlli di autorizzazione spesso vivono nello stesso modulo di route che decide cosa rendere.

Questo loop stretto può ridurre la duplicazione, ma aumenta il rischio: “facile da collegare” può diventare “facile accumulare logica nel posto sbagliato.”

Non nascondere la logica di business negli handler di route

Gli handler di route sono ottimi per l'orchestrazione—parsing degli input, chiamare una funzione di dominio e tradurre gli esiti in risposte HTTP. Sono un posto povero per far crescere regole di business complesse.

Se troppa logica si accumula in loader/action/API route, diventa più difficile testarla, riutilizzarla e condividerla tra route.

Una regola pratica: mantieni le route sottili e sposta le regole core in moduli separati (per esempio, layer di dominio o servizi) che le route chiamano.

Il fetching dei dati si sposta vicino ai componenti

I framework full-stack sempre più incoraggiano a collocare il fetching dei dati insieme all'UI che lo usa. Invece di definire query in un layer separato e passare props attraverso molti file, una pagina o un componente può richiedere esattamente ciò che gli serve proprio dove viene renderizzato.

Per i team, questo spesso significa meno contesti da cambiare: leggi l'UI, vedi la query, capisci la forma dei dati—senza saltare tra cartelle.

Accesso solo server vs dati sicuri per il client

Quando il fetching sta accanto ai componenti, la domanda chiave è: dove viene eseguito questo codice? Molti framework permettono a un componente di eseguire sul server per default (o di optare per l'esecuzione server), ideale per accesso diretto al database o servizi interni.

I componenti client-side, invece, devono toccare solo dati sicuri per il client. Qualsiasi cosa recuperata nel browser può essere ispezionata in DevTools, intercettata in rete o memorizzata da strumenti di terze parti.

Un approccio pratico è trattare il codice server come “trusted” e il codice client come “pubblico”. Se il client ha bisogno di dati, esponili intenzionalmente tramite una funzione server, un'API route o un loader fornito dal framework.

Serializzazione, privacy e fughe accidentali

I dati che fluiscono dal server al browser devono essere serializzati (solitamente JSON). È in questo confine che campi sensibili possono sfuggire accidentalmente—pensa a passwordHash, note interne, regole di prezzo o PII.

Guardrail utili:

• Restituire view model (solo i campi necessari all'UI), non record grezzi del DB.
• Di default negare proprietà sensibili; aggiungi campi intenzionalmente.
• Stai attento agli oggetti annidati; un singolo include user può portare attributi nascosti.

Checklist rapida: server vs browser

• Server: query al DB, chiamate a servizi interni, segreti, logica admin, controlli di permesso.
• Browser: rendering, interazioni utente, UI ottimistiche, stato client-only, chiamare endpoint pubblici.

Quando il fetching si sposta vicino ai componenti, la chiarezza su questo confine conta tanto quanto la comodità.

Tipi e schemi condivisi riducono il gap dei contratti

Una ragione per cui i framework full-stack sembrano “misti” è che il confine tra UI e API può diventare un insieme di tipi condivisi.

I tipi condivisi sono definizioni di tipo (spesso TypeScript) che sia frontend sia backend importano, così entrambi concordano su com'è fatto un User, Order o CheckoutRequest.

Perché TypeScript rende appetibili i tipi condivisi

TypeScript trasforma il “contratto API” da PDF o pagina wiki a qualcosa che il tuo editor può far rispettare. Se il backend cambia il nome di un campo o rende una proprietà opzionale, il frontend può fallire in build anziché rompersi a runtime.

Questo è particolarmente utile in monorepo, dove è semplice pubblicare un piccolo pacchetto @shared/types (o importare una cartella) e mantenere tutto sincronizzato.

Schemi e DTO riducono i mismatch UI/API

I tipi da soli possono scivolare dalla realtà se scritti a mano. Ecco dove aiutano schemi e DTO (Data Transfer Objects):

• Uno schema (per esempio, uno schema di validazione) può definire la fonte di verità per ciò che l'API accetta e restituisce.
• I DTO rendono esplicito che la forma dell'API non è la stessa del modello database o dell'entità ORM.

Con approcci schema-first o schema-inferiti, puoi validare l'input sul server e riutilizzare le stesse definizioni per tipare le chiamate client—riducendo i mismatch del tipo “funzionava sulla mia macchina”.

Il rischio nascosto: accoppiamento stretto

Condividere modelli ovunque può anche incollare gli strati insieme. Quando i componenti UI dipendono direttamente da oggetti di dominio (o peggio, da tipi modellati sul DB), i refactor backend diventano refactor frontend e piccoli cambi hanno effetti a catena sull'app.

Mantenere i confini chiari

Un compromesso pratico è:

• Contratti: definire tipi request/response stabili per route (DTO), non modelli “globali”.
• Adapter: mappare entità di dominio in DTO al bordo (handler o action).
• Interfacce stabili: versionare o deprecare contratti deliberatamente, anche dentro un singolo repo.

In questo modo ottieni la velocità dei tipi condivisi senza trasformare ogni cambiamento interno in un evento di coordinamento tra team.

Le Server Actions fanno sembrare le chiamate al backend chiamate di funzione

Le Server Actions (nome varia col framework) permettono di invocare codice server-side da un evento UI come se chiamassi una funzione locale. Un submit di form o un click può chiamare createOrder() direttamente, e il framework si occupa di serializzare l'input, inviare la richiesta, eseguire il codice sul server e restituire il risultato.

Ergonomia vs REST/GraphQL

Con REST o GraphQL pensi in termini di endpoint e payload: definire una route, formare una richiesta, gestire codici di stato e parsare la risposta.

Le Server Actions spostano quel modello mentale verso “chiama una funzione con argomenti”.

Nessun approccio è intrinsecamente migliore. REST/GraphQL può essere più chiaro quando vuoi confini espliciti e stabili per più client. Le Server Actions risultano più fluide quando il consumatore principale è la stessa app che rende l'UI, perché il punto di chiamata può stare vicino al componente che lo attiva.

Validazione e autorizzazione sono comunque obbligatorie

La sensazione di “funzione locale” può ingannare: le Server Actions sono comunque entry point server.

Devi validare gli input (tipi, range, campi richiesti) e far rispettare l'autorizzazione dentro l'action stessa, non solo nell'UI. Tratta ogni action come se fosse un handler API pubblico.

La rete esiste ancora

Anche se la chiamata sembra await createOrder(data), attraversa ancora la rete. Questo significa latenza, errori intermittenti e retry.

Hai comunque bisogno di stati di loading, gestione degli errori, idempotenza per reinvi sicuri e gestione attenta dei fallimenti parziali—solo che è più comodo collegare i pezzi.

Autenticazione e autorizzazione diventano “full-stack” di default

I framework full-stack tendono a distribuire il lavoro di auth su tutta l'app, perché richieste, rendering e accesso ai dati spesso avvengono nello stesso progetto—e a volte nello stesso file.

Invece di un passaggio netto a un team backend separato, autenticazione e autorizzazione diventano preoccupazioni condivise che toccano middleware, route e codice UI.

Un login, molti checkpoint

Un flusso tipico copre più livelli:

• Middleware / edge logic verifica se una richiesta ha cookie o token validi prima di consentire l'accesso a certe route.
• Route handler (pagine e API) caricano l'utente corrente, rinnovano la sessione o respingono richieste non autenticate.
• Guard UI nascondono o disabilitano pulsanti, reindirizzano utenti da pagine protette e mostrano inviti al login.

Questi livelli si integrano. Le guardie UI migliorano l'esperienza, ma non sono sicurezza.

Cookie, sessioni e token (alto livello)

La maggior parte delle app sceglie una di queste strategie:

• Sessioni basate su cookie: il browser invia automaticamente un cookie di sessione; il server lo cerca e decide chi sei.
• Cookie firmati / JWT: il cookie o l'header contiene un token firmato; il server lo verifica ed estrae identità/ruoli.
• Setup ibridi: token a breve durata rinnovati tramite cookie sicuri.

I framework full-stack rendono facile leggere i cookie durante il rendering server e associare l'identità al fetching server—comodo, ma significa anche che gli errori possono verificarsi in più posti.

L'autorizzazione appartiene vicino all'accesso ai dati

L'autorizzazione (cosa puoi fare) dovrebbe essere applicata dove i dati sono letti o modificati: nelle server actions, negli handler API o nelle funzioni di accesso al DB.

Se la applica solo nell'UI, un utente può bypassare l'interfaccia e chiamare direttamente gli endpoint.

Trappole comuni da evitare

• Esporre route o action “admin” senza un controllo di permessi server-side.
• Fidarsi dell'input client (per esempio, role: "admin" o userId nel body della richiesta).
• Fare affidamento su elementi UI nascosti invece di imporre regole nel codice di data-layer.
• Dimenticare che anche le pagine renderizzate server-side hanno bisogno di controlli di autorizzazione, non solo le API route.

I modelli di deployment cambiano cosa significa “backend”

I framework full-stack non cambiano solo come scrivi codice—cambiano dove il tuo “backend” effettivamente gira.

Molta confusione sui ruoli deriva dal deployment: la stessa app può comportarsi come un server tradizionale un giorno e come un insieme di funzioni piccole il giorno dopo.

Edge, serverless e server long-running (in parole semplici)

Un server long-running è il modello classico: esegui un processo che resta acceso, mantiene memoria e serve richieste continuamente.

Serverless esegue il codice come funzioni on-demand. Partono quando arriva una richiesta e si spengono quando inattive.

Edge sposta il codice più vicino agli utenti (spesso in molte region). È ottimo per bassa latenza, ma il runtime può essere più limitato di un server completo.

Cosa cambia la scelta del framework: cold starts, streaming, caching

Con serverless e edge, i cold start contano: la prima richiesta dopo una pausa può essere più lenta mentre la funzione si avvia. Funzionalità come SSR, middleware e dipendenze pesanti possono aumentare quel costo di avvio.

D'altra parte, molti framework supportano lo streaming—inviare parti di una pagina man mano che sono pronte—così gli utenti vedono qualcosa rapidamente anche se i dati sono ancora in caricamento.

Il caching diventa una responsabilità condivisa. Caching a livello di pagina, caching delle fetch e caching CDN possono interagire. Una decisione “frontend” come “renderizza questa sul server” può influire su problemi tipicamente backend: invalidazione cache, dati obsoleti e consistenza regionale.

Preoccupazioni condivise: segreti e osservabilità

Variabili d'ambiente e segreti (chiavi API, URL DB) non sono più solo “backend”. Serve chiarezza su cosa è sicuro per il browser vs server-only, più un modo coerente per gestire i segreti negli ambienti.

L'osservabilità deve coprire entrambi gli strati: log centralizzati, tracce distribuite e report di errori coerenti così un render lento può essere legato a una chiamata API fallita—anche se girano in posti diversi.

Struttura del team e ownership quando i confini sfumano

I framework full-stack non cambiano solo la struttura del codice—cambiano chi “possiede” cosa.

Quando i componenti UI possono girare sul server, definire route e chiamare DB (direttamente o indirettamente), il vecchio modello di handoff tra team frontend e backend può diventare confusionario.

Team per funzionalità vs team separati frontend/backend

Molte organizzazioni si orientano verso feature team: un team possiede una fetta dell'esperienza utente (per esempio, “Checkout” o “Onboarding”) end-to-end. Questo si adatta a framework dove una route può includere pagina, server action e accesso ai dati in un unico posto.

Team separati frontend/backend possono comunque funzionare, ma servono interfacce e pratiche di review più chiare—altrimenti la logica backend si accumula silenziosamente nel codice vicino all'UI senza la solita scrutinio.

Il pattern BFF, incoraggiato dai framework moderni

Un compromesso comune è il BFF (Backend for Frontend): l'app web include un layer backend sottile su misura per la sua UI (spesso nello stesso repo).

I framework full-stack ti spingono verso questa direzione rendendo facile aggiungere API route, server actions e controlli auth vicino alle pagine che le usano. È potente—trattalo però come un vero backend.

Accordi di lavoro che prevengono confusione

• CODEOWNERS e regole di review per cartelle server-only, logica auth e accesso ai dati.
• Review di API e schemi (anche se “è solo una server action”): valida input, definisci forme di errore e pensa al versioning.
• Check di sicurezza: threat modeling per nuove route, gestione dei segreti, test di autorizzazione e aspettative su logging/monitoring.

Documenta “cosa vive dove”

Crea un documento breve nel repo (per esempio, /docs/architecture/boundaries) che dica cosa mettere in componenti vs handler di route vs librerie condivise, con alcuni esempi.

L'obiettivo è coerenza: tutti dovrebbero sapere dove mettere il codice—e dove non metterlo.

Vantaggi e rischi da tenere d'occhio

I framework full-stack possono sembrare una superpotenza: costruisci UI, accesso ai dati e comportamento server in un flusso coerente. È un vantaggio reale—ma cambia anche dove risiede la complessità.

Benefici che noterai subito

Il guadagno più grande è velocità. Quando pagine, API route e pattern di fetching convivono, i team spesso consegnano feature più rapidamente perché ci sono meno overhead di coordinamento e meno passaggi.

Si vedono anche meno bug di integrazione. Strumenti condivisi (linting, formatter, type checking, test runner) e tipi condivisi riducono i mismatch tra ciò che il frontend si aspetta e ciò che il backend restituisce.

Con un setup in stile monorepo, i refactor possono essere più sicuri perché le modifiche attraversano lo stack in una sola pull request.

Costi che emergono più tardi

La comodità può nascondere complessità. Un componente può renderizzare sul server, idratarsi sul client e poi innescare mutation server-side—debuggare richiede tracciare più runtime, cache e confini di rete.

C'è anche il rischio di coupling: l'adozione profonda delle convenzioni di un framework (routing, server actions, cache) può rendere costoso cambiare strumenti. Anche senza intenzione di migrare, gli upgrade di framework possono diventare operazioni ad alto rischio.

Rischi di prestazioni da gestire

Gli stack misti possono incoraggiare over-fetching (“prendi tutto nel componente server”) o creare richieste a cascata quando le dipendenze dati vengono scoperte sequenzialmente.

Lavori server pesanti durante il rendering a richiesta possono aumentare latenza e costi infra—soprattutto sotto picchi di traffico.

Implicazioni su sicurezza e compliance

Quando il codice UI può eseguire sul server, l'accesso a segreti, DB e API interne può essere più vicino allo strato di presentazione. Questo non è intrinsecamente negativo, ma spesso richiede valutazioni di sicurezza più approfondite.

Controlli di permesso, logging di audit, residenza dei dati e requisiti di compliance devono essere espliciti e testabili—non dati per scontati perché il codice “sembra frontend”.

Pattern pratici per confini chiari nelle app full-stack

I framework full-stack rendono facile collocare tutto, ma “facile” può diventare intricato.

L'obiettivo non è ricreare silos vecchi—è mantenere responsabilità leggibili così le feature restano sicure da modificare.

1) Metti la logica di dominio in un service layer

Considera le regole di business come un modulo a sé, indipendente da rendering e routing.

Una buona regola: se decide cosa deve succedere (regole di prezzo, idoneità, transizioni di stato), appartiene a services/.

Questo mantiene la UI sottile e gli handler server banali—entrambi risultati positivi.

2) Separa UI, handler server e accesso ai dati

Anche se il framework permette import ovunque, usa una struttura semplice in tre parti:

• UI pura: componenti che accettano dati e callback; senza client DB, senza oggetti request.
• Handler server: route handler/server actions che traducono il contesto HTTP/session in chiamate ai servizi.
• Accesso ai dati: repository/query che sanno parlare con il DB o API esterne.

Una regola pratica: la UI importa solo services/ e ui/; gli handler server possono importare services/; solo i repository importano il client DB.

3) Testa dove il confine conta

Allinea i test ai layer:

• Unit test per i servizi (veloci, senza rete, senza framework).
• Integration test per repository e handler server (DB reale in CI o container di test).
• E2E test per percorsi utente critici (login, checkout, modifica impostazioni).

Confini chiari rendono i test più economici perché puoi isolare cosa stai convalidando: regole di business vs infrastruttura vs flow UI.

4) Rendi i confini visibili nelle code review

Aggiungi convenzioni leggere: regole di cartella, restrizioni lint e controlli “no DB in components”.

La maggior parte dei team non ha bisogno di processi pesanti—solo default coerenti che prevengono accoppiamenti accidentali.

Dove si posiziona Koder.ai quando lo stack sfuma

Mentre i framework full-stack collassano preoccupazioni UI e server in un unico codebase, il collo di bottiglia spesso si sposta da “riusciamo a collegarlo?” a “riusciamo a mantenere confini chiari mentre spediamo velocemente?”.

Koder.ai è progettato per questa realtà: è una piattaforma vibe-coding dove puoi creare applicazioni web, server e mobile tramite un'interfaccia chat—ottenendo comunque codice sorgente reale ed esportabile. In pratica, significa che puoi iterare su funzionalità end-to-end (route, UI, server actions/API route e accesso ai dati) in un unico workflow, poi applicare gli stessi pattern di separazione descritti sopra nel progetto generato.

Se stai costruendo una app full-stack tipica, lo stack di default di Koder.ai (React per web, Go + PostgreSQL per backend, Flutter per mobile) si mappa bene sulla separazione “UI / handler / services / accesso ai dati”. Funzionalità come planning mode, snapshot e rollback aiutano quando cambi di framework (modalità di rendering, strategia di caching, approccio auth) si ripercuotono sull'app.

Che scrivi tutto a mano o acceleri la consegna con una piattaforma come Koder.ai, la lezione principale resta: i framework full-stack rendono più semplice collocare le preoccupazioni insieme—quindi servono convenzioni deliberate per mantenere il sistema comprensibile, sicuro e veloce da evolvere.