Enterprise
Enterprise è il piano per le organizzazioni che superano Business: più membri del team, nessun limite di catalogo per progetti e richieste, e limiti che possono essere adattati al Tuo contratto. Questa pagina spiega cosa comprende il piano, come Mockomat separa il Tuo account dagli altri e come mantenere coerente la modellazione di dominio tra più team.
Ottenere Enterprise
Enterprise si concorda con il nostro team commerciale e non si acquista online. Usa Parla con il commerciale nell'app oppure il modulo di contatto; il prezzo è su richiesta.
Cosa comprende Enterprise
- Tutto ciò che comprende Business: API key, ruoli del team, export del codice, analytics degli endpoint.
- Nessun limite di catalogo per progetti, workspace, richieste API mensili, API key per progetto, tabelle, attributi, relazioni, operazioni e note della board.
- Fino a 26 membri del team, di cui 5 gestori.
- Il pacchetto di codice Enterprise: l'export del codice genera un backend NestJS e un frontend Angular (vedi Export).
- Limiti adattati al Tuo contratto: il nostro team imposta i limiti del Tuo account secondo quanto concordato con il commerciale.
Per i limiti degli altri piani, vedi Account e piani.
Panoramica del modello di accesso all'account e ai progetti.
Come è separato il Tuo account
Enterprise usa la stessa piattaforma di tutti gli altri piani. Questi confini valgono per ogni account:
- Il Tuo account è il confine. Progetti, modelli, membri, API key e limiti del piano appartengono al Tuo account. Ogni richiesta viene verificata rispetto ad esso, quindi i membri di altri account non possono aprire i Tuoi progetti.
- Accesso ai progetti per membro. I gestori vedono tutti i progetti dell'account. Gli altri membri vedono i progetti a cui hanno ricevuto accesso con l'invito, con una sovrascrittura opzionale per progetto che può limitare il loro ruolo, ma mai innalzarlo.
- Una API key per consumer. Ogni progetto di un account risponde sulla sua mock API solo alle richieste con una API key di quel progetto. Le chiavi possono essere revocate in qualsiasi momento.
- Dati mock condivisi e in sola lettura. La mock API restituisce righe dal pool di dati di Mockomat, che il nostro team importa e mantiene. Le Tue richieste lo leggono soltanto, ed è lo stesso su ogni piano. Non puoi caricare dataset Tuoi.
Confini di account, progetti e dati.
Team e ruoli
| Ruolo | Cosa aggiunge |
|---|---|
| Solo lettura | Vede i progetti, il modello e l'anteprima dei dati; legge le note della board |
| Reporter | Scrive e modifica le note della board e i relativi commenti |
| Editore | Costruisce il modello, crea progetti, gestisce le API key, esegue l'export del codice |
| Gestore | Elimina progetti, gestisce i membri e il loro accesso ai progetti, gestisce i workspace |
Ogni ruolo comprende tutto ciò che consentono i ruoli sopra di esso. Il proprietario dell'account è gestore e gestisce la fatturazione. L'elenco completo dei permessi e il flusso di invito sono in Team & Roles (in inglese).
Gestione dei membri del team e assegnazione dei ruoli.
Sessioni e consumer esterni
- Sessioni di accesso: su Enterprise il proprietario dell'account può restare connesso su più dispositivi contemporaneamente. I membri invitati non ottengono questa possibilità dall'account a cui si uniscono: possono essere connessi in un solo posto alla volta, a meno che non siano proprietari di un account il cui piano consenta di più, e un accesso altrove chiude la loro sessione precedente. Tutti vengono disconnessi automaticamente dopo un periodo di inattività.
- Consumer dell'API: ogni richiesta alla mock API porta una API key del progetto. Usa una chiave per consumer o ambiente (sviluppo, staging, CI) così puoi revocarne una senza toccare le altre.
- Actor token (opzionali): un consumer può richiedere un actor token in modo che l'uso contemporaneo di una API key possa essere limitato. Vedi la sezione «Actor token» della pagina Integratori.
Modello di governance
Un approccio pratico alla governance mantiene coerente la modellazione di dominio man mano che si aggiungono altri team.
Domain ownership
Assegna una responsabilità chiara per ogni area di business:
- Responsabile di dominio — responsabile della denominazione delle entità, delle definizioni degli attributi e della strategia delle relazioni nel proprio dominio.
- Revisori — membri del team che verificano le modifiche prima che i consumer vi facciano affidamento (il ruolo Reporter è adatto).
- Consumer — sviluppatori frontend e integratori che interrogano la mock API senza modificare il modello (il ruolo Solo lettura è adatto).
Convenzioni di denominazione condivise
Definisci standard a livello di organizzazione per:
- Denominazione delle entità — PascalCase, sostantivi al singolare, linguaggio di business (es.
Customer, noncustomers_tbl) - Denominazione degli attributi — camelCase, descrittiva, senza abbreviazioni (es.
totalAmount, nontot_amt) - Denominazione delle relazioni — direzione e cardinalità chiare
- Denominazione delle operazioni — nomi al plurale coerenti per le operazioni di lista, al singolare per le operazioni di dettaglio
Mantieni un progetto di riferimento che segua queste convenzioni e copialo con Forka un progetto come punto di partenza per i nuovi progetti.
Gate di revisione
| Fase | Focus della revisione | Chi rivede |
|---|---|---|
| Modifica del modello | Coerenza dei nomi, completezza degli attributi, correttezza delle relazioni | Responsabile di dominio |
| Modifica dell'esposizione API | Operazioni, parametri, dimensioni di pagina | Responsabile di dominio + integratore |
| Prima dell'export | Comportamento runtime, parametri, ordinamento, relazioni | Responsabile di dominio + QA |
| Dopo l'export | Codice generato, confini dei moduli, input | Responsabile del team di sviluppo |
Criteri di prontezza
Definisci cosa significa «pronto» per ogni entità prima che i consumer ne dipendano:
- Ogni attributo che serve ai consumer è collegato a una colonna dei dati importati
- Le relazioni si risolvono nell'anteprima
- I parametri delle operazioni e l'ordinamento restituiscono le righe attese
- La paginazione produce confini di pagina puliti
Controlli di governance tra le fasi di modellazione e runtime.
Sicurezza
- Accesso: l'app usa un token firmato per ogni sessione di accesso. Il logout, l'inattività e un cambio di password chiudono le sessioni sul server.
- API key: le chiavi sono segreti. Usale da codice lato server, dalla CI o tramite un proxy — non includere mai una chiave in un bundle frontend — e revoca una chiave appena non serve più.
- Traffico cifrato: l'app e la mock API sono servite via HTTPS.
- Nessun dato di produzione necessario: le mock API restituiscono righe dal pool di dati di Mockomat, quindi i Tuoi ambienti di test non hanno mai bisogno di dati reali dei clienti.
Panoramica della sicurezza.
Best practice operative
- Definisci criteri di prontezza per entità prima di assegnarla a un team.
- Includi verifiche runtime nelle revisioni — esegui l'anteprima prima che i consumer dipendano da una modifica.
- Esporta alle milestone — conserva il codice generato nel controllo di versione e annota da quale stato del modello proviene.
- Osserva l'utilizzo — consulta gli analytics degli endpoint per vedere quali operazioni chiamano i consumer prima di modificarle.
- Rivedi regolarmente — mantieni le definizioni di dominio allineate ai requisiti di business che cambiano.
Validazione runtime enterprise e checkpoint operativi.