Tutto ciò che fa Fóir

Definisci la struttura dei tuoi dati con sedici tipi di campo integrati, tra cui rich text, decimali esatti, media, riferimenti e geopoint, nella console o nel codice.

Collega un modello a un altro con un campo di riferimento e leggi attraverso di esso in una sola query, con tipi di relazione che decidono se accesso ed eliminazioni seguono il riferimento.

Rich text che contiene i tuoi modelli tra i paragrafi in qualsiasi ordine, modelli inline che definisci una volta e riusi come tipi di campo, e liste tipizzate.

Dichiara un campo di riferimento come gerarchia di un modello e i suoi record formano un albero, con ogni lettura che restituisce il percorso del record e i suoi antenati.

Traduci i campi text e prose per locale, con una catena di fallback percorsa campo per campo e una modalità strict che segnala quali campi non avevano traduzione.

Il server sceglie la versione di un record che riceve una richiesta, in base al contesto passato dalla lettura e ai segmenti in cui si trova l'utente autenticato. Include un esempio pratico.

Varia un intero record, un singolo campo o una singola voce di prose per pubblico, con la variante selezionata sul server da regole di targeting riutilizzabili e con priorità.

Costruisci pubblici a partire da dimensioni di contesto come dispositivo, piattaforma, locale e stato del login, e da segmenti basati su regole che il server valuta a ogni richiesta.

Indirizza un record con una chiave leggibile, e dichiara su un modello chiavi di lookup univoche aggiuntive, così un handle o uno SKU lo trova con una sola query tipizzata.

Colore, tipografia e spaziatura tenuti come token del progetto e serviti dall'API, così un'app che li legge a runtime mostra un rebrand appena viene pubblicato.

Su un modello con la pubblicazione attiva, ogni salvataggio scrive una bozza mentre l'API continua a servire la versione pubblicata. La console mostra l'anteprima di una bozza come la servirebbe l'API.

Sui modelli con versioning ogni salvataggio è una versione numerata, conservata per una finestra stabilita dal tuo piano. Il ripristino aggiunge una nuova versione, e una prova a vuoto ne riporta prima l'effetto.

Imposta un orario di pubblicazione su una versione di un record, e un orario di ritiro se il contenuto deve tornare offline. Una pianificazione può essere modificata o annullata finché non scatta.

Un rollout pubblica un gruppo con nome di versioni di record in un unico momento pianificato. Un elemento fallito viene saltato e può essere ritentato, e il gruppo può essere annullato con un rollback.

Le modifiche a modelli e configurazione vengono messe in attesa come bozze e rilasciate insieme, subito o a un orario stabilito, con un diff delle modifiche non compatibili e un rollback.

Versioning, pubblicazione e varianti si attivano per modello e sono disattivati di default, così ogni modello adotta solo il flusso di lavoro di cui i suoi record hanno bisogno.

Fóir genera uno schema GraphQL dai tuoi modelli. La produzione serve lo schema pubblicato, e un controllo della CLI fa fallire la build quando i tipi di cui hai fatto il commit restano indietro rispetto al progetto.

Una lettura passa un locale, un contesto e un flag di anteprima. Il server applica il fallback del locale, sceglie la variante e seleziona la versione bozza o pubblicata.

Iscriviti tramite WebSocket per sapere quando i record cambiano. Gli eventi portano l'id di ciò che è cambiato, e il modulo live dell'SDK li applica alla cache delle tue query.

Ogni chiave è pubblica o secret e appartiene a un solo progetto. Contiene gli scope che le dai, e può essere ristretta a modelli e operazioni scelti o a una sola organizzazione.

L'API GraphQL mette in cache le risposte risolte per 60 secondi di default e le scarta quando viene scritto un record che contengono. Un comando della CLI le svuota a mano.

Un client tipizzato che scrive il GraphQL per la tua applicazione, con tipi generati per chiave, e una CLI per contenuti, schema, pubblicazione e configurazione con output JSON per gli script.

La frequenza delle richieste è impostata per chiave dal tuo piano, e profondità delle query, numero di campi e alias hanno un tetto prima che una query venga eseguita. Le risposte riportano i limiti nei loro header.

Una pagina di login che Fóir ospita per i tuoi utenti su un dominio di login che verifichi, con il nome, il logo e il colore del tuo progetto, con login tramite password, codice inviato per email e provider.

I tuoi utenti accedono tramite qualsiasi identity provider che pubblichi un documento di discovery OpenID Connect. Tu fornisci il suo URL di discovery e le tue credenziali client, e Fóir gestisce lo scambio.

Richiedi una passkey o un codice di un'app di autenticazione come secondo passaggio dopo la password, prima di un'operazione sensibile o a ogni login in un'app.

Un ruolo è un insieme di permessi che componi tu, concesso su un workspace o su un solo progetto. I ruoli dei tuoi utenti sono dichiarati per progetto nella configurazione o nella CLI.

Un modello dichiara a chi appartengono i suoi record, e ogni record è privato o pubblico. Un record privato può essere condiviso con una persona precisa tramite un accesso che puoi revocare.

Un campo può indicare quali tipi di chiamante possono leggerlo e quali scriverlo. I tipi sono cinque, stabiliti dalla credenziale che una richiesta porta con sé.

La console elenca le sessioni che i tuoi utenti hanno su un dominio di login personalizzato, per ogni app di login, e ne revoca una qualsiasi. Gli altri login terminano con la revoca del token o la scadenza.

Chi ha fatto cosa e quando, registrato insieme alla modifica e leggibile nella console dai membri del team che hanno il permesso. Le voci sono conservate per 90 giorni.

Le regole di accesso sono compilate in row-level security di Postgres, quindi è il database a filtrare ciò che una richiesta può leggere e un controllo dimenticato nel codice dell'applicazione non espone una riga.

Un workspace è il tuo account. Ogni riga governata ne porta l'id, e la policy sulla tabella confronta quell'id con la sessione del chiamante prima di considerare qualsiasi altra cosa.

Ogni progetto ha i suoi contenuti, utenti, file, chiavi, secret e domini di login. Una chiave API appartiene a un solo progetto e non può essere puntata su un altro.

Quando il tuo prodotto ha tenant propri, ognuno è un'organizzazione. Il database marca ogni riga con la sua organizzazione e filtra ogni lettura in base ad essa.

Quando lo staff di Fóir deve guardare dentro un workspace per aiutarti, uno dei suoi amministratori approva la richiesta con un codice monouso. La visita dura un'ora e viene registrata.

Il motore che compila le regole è open source, quindi puoi leggere come sono scritte le policy ed eseguirne tu stesso i test.

Ogni cliente ha un progetto con i propri contenuti, chiavi, utenti e login. Un solo workspace li amministra tutti, e un cliente che inviti raggiunge soltanto il proprio progetto.

Dai al tuo prodotto dei tenant propri. Ogni tuo cliente è un'organizzazione dentro il tuo progetto, con i propri membri, utenti, dati e limiti.

Le organizzazioni si annidano a qualsiasi profondità. Un genitore legge tutto ciò che sta sotto di sé e modifica solo le proprie righe, e modelli e impostazioni vengono ereditati lungo l'albero.

Una sola chiamata crea un'organizzazione con il suo brand, le sue impostazioni, il suo primo membro e una chiave limitata ad essa. Eseguila due volte e ottieni comunque una sola organizzazione.

Un solo file di configurazione dichiara staging e produzione come progetti con nome, e la CLI fa il push su uno per esecuzione. Restano identici a parte le destinazioni dichiarate, e il drift viene segnalato.

Un progetto può servire la sua API da un dominio che verifichi, e un'app di login può servire da uno la pagina di login ospitata. Entrambi sono facoltativi, con TLS emesso automaticamente.

Carica un file una volta e referenzialo per id da qualsiasi record, con dimensioni e un placeholder letti dalle immagini quando l'upload viene confermato.

Ogni immagine viene servita in otto dimensioni con nome e quattro formati, renderizzata la prima volta che un URL viene richiesto, con ritagli e punti focali impostati per ogni utilizzo.

Un file ha il proprio proprietario e la propria visibilità, con i file pubblici serviti da un URL semplice e i file privati tramite un link firmato che scade.

Ogni video caricato ottiene una miniatura, una breve anteprima animata e la sua durata, e lo streaming HLS adattivo è incluso in alcuni piani.

Una pianificazione esegue una delle tue operazioni con un'espressione cron, in un fuso orario che indichi, e può essere messa in pausa, ripresa o attivata a mano.

Un hook esegue una delle tue operazioni quando succede qualcosa in un progetto, come la pubblicazione di un record, e ogni consegna viene salvata con il suo stato.

Un'operazione è un endpoint HTTP che ospiti tu e registri presso Fóir, che lo chiama con un payload firmato, ritenta i fallimenti e registra ogni esecuzione.

Una quota limita quante volte un'operazione può essere eseguita in una finestra mobile, per utente autenticato o su un insieme più ampio, e restituisce un messaggio che scrivi tu.

Una precondizione decide se un'operazione può essere eseguita, in base all'appartenenza del chiamante a un segmento o a una regola sull'input, e rifiuta con un messaggio che scrivi tu.

Un vault per le credenziali che le tue operazioni usano, conservate cifrate, richiamate per riferimento e ruotate senza un nuovo deploy.

Invia notifiche email, in-app e push ai tuoi utenti, direttamente o da un evento, con preferenze che ogni utente imposta per categoria e canale.

Ricerca per parola chiave nei record di un progetto, ordinata per rilevanza e limitata ai record che il chiamante può leggere.

Fóir genera embedding per i modelli che attivi, così i record possono essere recuperati per significato, abbinati a un record simile o cercati con i tuoi vettori.

Aggiungi un campo geopoint a un modello e cerca i record più vicini a un punto o a un altro record, ordinati per distanza e, se vuoi, limitati a un raggio.

Commenti in thread che il tuo team allega a un record, a un file, a un modello o a un altro soggetto, fino a un singolo campo o a un singolo passaggio, con menzioni e una inbox per progetto.

Assegna una nota a un membro del team e diventa un'attività, con una scadenza, sotto-attività e una coda per persona. Chiudere la nota la segna come completata.

Un assistente nella console che lavora con i permessi della persona autenticata. Le sue modifiche arrivano come modifiche non salvate, come bozze o come richieste che approvi.

Passa un thread di note all'assistente per una breve esecuzione senza supervisione. Legge il progetto e risponde nel thread, e non può modificare, pubblicare o eliminare contenuti.

Collega il tuo agente al server MCP ospitato di Fóir. Lavora entro i permessi di chi lo ha collegato, o gli scope della chiave segreta che gli è stata data.

Gli utenti autenticati possono scrivere note su un record e leggere le risposte del tuo team. Un widget React registra la nota per te, e un progetto può accettare feedback dai visitatori.

Un solo comando esporta un progetto come tabelle Postgres tipizzate generate dai tuoi modelli, con chiavi esterne, i tuoi contenuti pubblicati e link di download per i tuoi file.

Il bundle dell'export include la row-level security di Postgres su quali righe ogni utente può leggere. La applichi tu. Permessi sui campi, scope API e regole di scrittura restano indietro.

Fóir non ospita il tuo codice. Registri come operazione una funzione che ospiti tu, e Fóir la chiama con un token firmato e con scope limitato, ritenta i fallimenti e registra ogni esecuzione.

Estendi la console con i tuoi strumenti. Un'app è una pagina web che ospiti tu, incorporata come pagina, scheda dell'editor, barra laterale o editor di campo.

Modelli, chiavi API, hook, provider di login e il resto della configurazione di un progetto in un solo file di cui fai il commit. Un push mette in attesa una bozza e una release la pubblica.