Bene e benvenuti su Geekbar nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori questa settimana sono solo sono solo perché questa puntata è stata registrata all'ultimo momento stiamo registrando all'ultimo momento perchè mi sono reso conto che era già giovedì e non avevo un episodio pronto ma prontamente ecco qua appunto l'episodio di cosa vi voglio parlare in questo episodio vi voglio parlare di super base ho già fatto un talk per codemotion dove racconto come funziona ma siccome il tempo era molto limitato e le cose da dire erano tante eccoci qua ad entrare un pochino nel merito di quelle che sono i comportamenti interni l'architettura e alcune funzionalità interessanti che rendono questo backend as a service un player interessante e disruptive in così poco tempo perché in realtà è un progetto molto giovane ma ne parleremo subito dopo avervi ricordato rapidamente i nostri contatti.Info che ho sulla github.it o @brainrepo su twitter sono i modi canonici per contattarci.In alternativa abbiamo anche come sapete un bellissimo gruppo telegram se non vi siete iscritti mi raccomando fatelo perché è il nostro punto d'incontro.molte puntate appunto nascono dalle conversazioni che avvengono nel gruppo Telegram detto questo io direi che possiamo andare al sodo e iniziare questo episodio benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo [Musica] come sapete io ho tanti side project no? o almeno cerco di avviare i miei side progett che insomma spessamente volte come direbbe qualcuno falliscono miseramente no? falliscono non vengono completati e fondamentalmente quest'ultimo periodo ho deciso subito dopo la puntata sui sui said project che abbiamo fatto con francesco malattesta l'abbiamo registrata a gennaio era l'episodio numero 101, ho fatto un'analisi, ho provato a capire e a riflettere sul motivo per cui molti dei miei side project muoiono e ho distillato due motivi principali.Il primo è perché fondamentalmente mi rendo conto che il side project preso in considerazione è inutile questo perché spesso sono talmente preso bene dal dall'idea iniziale che parto subito a scrivere il codice senza invece far decantare come francesco ci ha suggerito l'idea almeno un mesetto per fargli perdere quella pill temporaneo che tutte le idee anche quelle più becere hanno quindi diciamo che partendo subito a scrivere il codice mi rendo conto magari dopo la prima settimana e dopo diverse ore investite nel fare boilplating, preparare il progetto, iniziare a scrivere il codice che l'idea era del tutto stupida e quindi non aveva senso portarla avanti.Esiste però anche un'altra motivazione che in qualche modo mi spinge ad abbandonare il SAID project che è fondamentalmente legata al fatto che i SAVE PROJECT spesso mi portano a fare delle attività che non ho voglia di fare anche perché ragionandoci no spesso quello che sappiamo fare non corrisponde con quello che vogliamo fare e quindi nel partire, nell'avviare del save project mi rendo conto che sto facendo delle robe noiose e questo smorza l'entusiasmo, fa perdere la carica e l'interesse verso il progetto e anche perché questo viene da una forma mentis che in qualità di sviluppatore e di sviluppatori ereditiamo che è quella di non ripeterci, non fare le cose noiose, cercare di automatizzare il più possibile.Nel momento in cui io non faccio queste attività è facile cadere nel tranello, trovarsi a fare delle robe ripetute, perdere l'entusiasmo.Ma che cos'è in realtà che spesso mi fa perdere l'entusiasmo? Beh ho fatto un piccolo ragionamento, mi son guardato attorno, ho guardato un po' tutti i progetti che ho fatto e mi sono reso conto che c'erano due elementi fondamentali che rendevano il tutto molto noioso.Scrivere la parte di crude e fare il boiler plating.Queste due attività che sono ripetute spesso all'interno del progetto e sono maledettamente noiose sono capaci di davvero chillare qualunque tipo di entusiasmo.Allora partendo da questo ragionamento ho detto ok bene se queste sono le due attività che mi rendono noioso il progetto come faccio a distillarle.Il primo passo per distillarle dal resto è stato quello di provare a capire quali sono gli elementi essenziali che vanno a giocare un ruolo nella mia applicazione e fondamentalmente gli elementi che ho individuato sono sei più o meno in tutte le applicazioni.C'è un database che è un posto dove vado a mettere e a togliere le cose fondamentalmente dal quale prendo le cose, c'è un sistema di autenticazione e di autorizzazione quindi la gestione fondamentalmente dell'utente e di quello che l'utente può fare c'è un sistema di crude API quindi un modo per semplificare la scrittura e la lettura del database nel database e potrei dire che metà degli unicorn della Silicon Valley si basano sulla sul crude c'è talvolta però anche un sistema per l'archiviazione dei file e la gestione e l'upload dei file e un sistema di comunicazione real time perché io amo scrivere le interfacce con react e avere un'interfaccia responsiva che magari si aggiorna senza dover calcare sul pulsante refresh può essere particolarmente comodo e figo in termini di usabilità verso il nostro utente.Per finire c'è una parte che è sempre molto contenuta che è la parte della business logic.Fondamentalmente io non invento il nuovo algoritmo di compressione alla Piper o come era l'azienda di Silicon Valley, quindi non c'è una business logic così disruptive nei miei side project ma è un elementino di un puzzle ben più grande e fondamentalmente è l'elemento, uno dei due elementi più entusiasmanti del mio side project, quello è la costruzione della UI, sono le cose che mi divertono di più.Tutto il resto lo trovo un po' ripetitivo e noioso, infatti su tutti i miei progetti c'è un'autenticazione un'autorizzazione ed è sempre la stessa cosa fondamentalmente cambia di pochissimo quasi tutti i miei progetti c'è una crew dpi e anche quella c'è fa una cosa va a leggere scrivere nel database ed è uguale in tutti i progetti idem potrei dire per la gestione appunto dei file quindi questi elementi ritornano sono presenti in buona parte dei miei progetti ho fatto un lungo percorso ho provato diversi tool ne abbiamo parlato tante volte insieme per semplificare la creazione dei miei site project.Vi ho raccontato dei miei tentativi con Laravel, ho provato e amo Next.js, ho utilizzato Firebase e Amplify.Sono tutte soluzioni diverse che però mostravano dei limiti per esempio l'approccio alla Laravel Rail non eliminavano completamente il boilerplate anche se avevano dei code generator dei code generator...raga il controller lo devi fare le rotte le devi scrivere insomma quella parte di codice la devi fare nextjs è usato come full stack framework eredita le stesse problematiche richiede effort e in più rispetto alla ravel non ha un sistema di autenticazione out of the box o perlomeno ce l'ha ma è una libreria che devi utilizzare insomma integrare fare io cercavo qualcosa di pronta out of the box ho provato asura ne abbiamo parlato anche di questo tool all'interno degli episodi di github ma anche la non avevo un sistema di autenticazione out of the box era un po' tricky integrare della business logic.Ho provato anche Firebase e Amplify che sono dei servizi molto fighi però forse è un po' un overthinking forse un limite mio personale ma partire con un side project avendo un vendor locking così forte come Amplify e Firebase un po' mi spiazza mi lascia quella sensazione di pericolo di ma sei sicuro di quello che stai facendo non voglio già dall'inizio avere quel vendor locking quindi Superbase poteva essere una soluzione può essere una soluzione ancora non so se lo è però comunque sto facendo un tentativo in quella direzione.Cosa voglio fare? Voglio provare a utilizzare Superbase come back end as a service.Magari ho standomelo perché la cosa bella di Superbase in realtà sta nel fatto che loro ti offrono il servizio oppure essendo tutto completamente open source tu puoi tirarlo su sulla tua macchina o sulle tue macchine e quello viaggia.Quindi la parte di back end delegarla completamente a super base opportunamente configurato e tenermi da fare solo la parte di front end magari con next che adoro e la parte di back end per il front end la parte di business logic che in quel caso farei o con un fastify della situazione oppure con direttamente le rotte API di next.js per cui cosa mi rimane da fare.Il front end è quel pezzettino di business logic che colma il gap.Concentrandomi su questi due obiettivi quello che volevo fare era delegare tutto il resto a Superbase.Ma che cos'è in realtà Superbase? Se noi entriamo nel sito di Superbase vediamo che c'è questo mega payoff gigante che dice l'alternativa open source a Firebase.Ecco per me quella una mega marketata perché non è l'elemento centrale il core di Superbase.Secondo me la cosa veramente interessante è un'altra.Intanto che cosa è Superbase? Superbase è due cose allo stesso tempo.È un back end as a service, è una piattaforma che gira su AWS per la quale vendono un servizio e quindi tu ti loghi nel loro sito e c'hai direttamente il tuo back end, le tue API, il tuo database che ti mettono a disposizione loro.C'è un bel piano free o in alternativa paghi l'abbonamento.Insomma costruisci la tua applicazione su di loro e la campanella vendor lock-in comunque si riaccende esattamente come come si accendeva per per per per Firebase è come se accendeva per Amplify no? Però la cosa interessante di SupaBase è che allo stesso tempo è un toolkit selfostabile quindi un insieme di librerie che tu ti puoi mettere nella tua macchina loro danno anche un docker compose e so che stanno lavorando su un Elm chart per fare anche l'installazione su Kubernetes quindi c'è una roba che ti puoi selfostare e che ti offre direttamente il back end.Ma la cosa veramente interessante è che non so se avete visto mai il castello errante di Hall, il film del maestro Miyazaki, uno dei più grandi maestri dell'anime.In quel cartone animato c'è questo castello che è una sorta di cozzaglia di elementi, andatevelo a vedere, ma è il vero cuore del castello, quello che gli permette di muoversi, è Calcifer che è un piccolo demone rappresentato da una fiammella che in realtà è l'anima di questo castello senza senza il quale questo castello si scioglierebbe come neve al sole.Ecco, Superbase ha il suo calcifer, il suo calcifer è Postgre, un database fighissimo, in questo episodio potremmo anche chiamarlo apologia a Postgre SQL, è un database fighissimo che fa da base sul quale si poggiano tutte le feature del nostro Backend As a Service.Sopra a Postgre che fa molte più cose rispetto a quello che farebbe un classico database all'interno delle nostre applicazioni si posano tutta una serie di librerie open source per esempio per l'autenticazione c'è GoTru che è una libreria sviluppata dal team di Netlify fatta in Go che permette l'autenticazione dell'utente in modalità diverse lo vedremo poi.C'è Postgres che è un come la chiamo un'applicazione un servizio scritto in Haskell che serve per trasformare il database quindi le tabelle per esporre le tabelle sotto forma di API REST.C'è poi un servizio che si occupa del real time quindi di trasformare gli eventi sulle tabelle di Postgre sotto forma di messaggi su WebSocket scritta in Elixir, molto interessante e tenuta dal team di Superbase.C'è poi un altro microservizio che espone delle API per la gestione, lo storage dei file, quindi la creazione dei file, la lettura dei file su API e se tre compatibili.Poi c'è un'altra libreria che si occupa di interagire, espone un API REST per interagire sulla struttura del database, creare nuove tabelle, eliminare tabelle modificare aggiungere campi e poi abbiamo tutta una serie di plus che sono una UI figa per creare tabelle fare tutte le azioni sul database abbiamo una UI kit molto interessante per react abbiamo un sdk per interagire con il nostro database quindi se non vogliamo usare rest o graphql come come come dirò più dopo possiamo usare l'Sdk direttamente nel linguaggio che ci piace ci sono diversi linguaggi tra cui javascript per cui l'interazione è fatta in modo semplicissimo dalla nostra applicazione sopra tutti questi servizi in modo da esporli verso fuori facendo un url mapping ci sta Kong che è un API gateway tra l'altro notte a margine scritto da da un'azienda a guida italiana se non mi sbaglio sono i ragazzi di Meshap Meshap che era una startup italiana poi adesso loro stanno stanno negli Stati Uniti che insomma fa da API Gateway e mette tutti questi microservizi servizi chi più chi meno micro sotto un cappello un unico cappello e un unico danno la percezione di complettezza ecco perché visto da fuori adesso che ne conosciamo la struttura non sembra più il castello errante di Hall con tanti pezzi attaccati a sputo ma una bella struttura compatta con un'unica porta d'ingresso.Quindi andiamo a vedere piano piano i componenti che in qualche modo diciamo compongono Superbase.L'elemento centrale come vi ho detto la single source of truth è Calcifer il nostro postgre SQL.Cosa fa? Fa un botto di cose, molte di più di quelle che fanno le classiche app che gli fanno fare le classiche app che utilizzano il database perché contiene i dati e lo schema e vabbè e questo è abbastanza standard ma oltre a quello gestisce tutta la parte di autorizzazione perché dentro Postgre utilizzando una funzione che si chiama row level security è possibile definire tutta una serie di regole che regolano a loro volta l'accesso alle righe del database ai record del database e questa cosa è una figata pazzesca perché in realtà tutta la parte di autorizzazione che di solito nelle applicazioni sta nel nostro codice sta direttamente nel database noi sappiamo che Postgres e Quell supporta anche la full text search utilizzando la funzione ts vector e quant'altro quindi abbiamo anche questa funzionalità supporta un sistema di subscription una sorta di pub sub per cui si possono sottoscrivere una serie di eventi all'interno del database insomma fondamentalmente offre il backbone per Superbase perché ti dà l'autorizzazione tutto il sistema di autorizzazione ti permette di salvare i dati ti supporta la ricerca anche la full text search supporta le subscription che poi verranno utilizzate dal modulo real time in realtà poi Superbase fa molto di più perché permette anche l'esecuzione di business logic come vedremo dopo.Tutto questo dentro Postgre.Superbase per l'interazione col database oltre ad avere un API c'è anche una interfaccia grafica che è molto semplice che tra l'altro permette dalla creazione della tabella alla creazione delle autorizzazioni quindi tutte le regole di autorizzazione persino all'attivazione delle delle estensioni e questa è disponibile queste funzionalità sono disponibili sia nella versione BUS offerta dall'azienda Superbase che in realtà nella versione diciamo open source community che ti installi poi nella nella tua macchina.Oltre al database esiste una CRUD API quindi un modo per andare a scrivere nel database.Questa CRUD API è esposta da Postgres, che come vi ho detto è un microservizio scritto in elix, in scusatemi si, in Haskell, che in qualche modo trasforma la porta d'accesso al nostro database esponendo delle API i rest.La cosa interessante è che Postgres è scritto in modo da fittare perfettamente Postgres non è come un ORM che utilizza magari un query builder che poi lo ha strain con i driver in 4, 5 6 10 database no questo trasforma le request direttamente in query che girano su postgres e quindi un layer sottilissimo e quindi super performante tra l'altro questo postgres si occupa anche di fare in modo che possano essere eseguite e supportate le ROSS level security che vedremo poi.Ci espone un API REST e la cosa figa è che attraverso l'utilizzo di questo API REST è possibile anche quando andiamo a prendere i dati dalle tabelle è possibile anche percorrere le relazioni, quindi se io, cosa ne so, la tabella podcast, la tabella episodi e la tabella ospite dove per ogni podcast ci possono essere più episodi, per ogni episodio ci possono essere più ospiti, io posso percorrere le relazioni e andarmi a prendere i dati collegati e di quei dati collegati andarmi a prendere solo alcune colonne.quindi è una specie di GraphQL via REST se così lo possiamo lo possiamo rappresentare.La cosa interessante quindi è tutto un sistema di filtri molto figo quindi possiamo fare veramente qualunque tipo di filtro e un'altra cosa figa è che in realtà questa questa API è compliant con OpenAPI questo vuol dire che out of the box direttamente dall'interfaccia di SuperBase abbiamo la documentazione già generata e siccome SupaBase supporta diversi SDK abbiamo anche la documentazione per quell'SDK specifico che sia per JavaScript, che sia per Dart, che sia per Kotlin, che sia per linguaggi diversi ecco c'è già la documentazione bella bella pronta come vi ho detto quindi è un livello sottilissimo che però fa tanto perché ci evita di scrivere tutti quei controller e di usare active record o il mio ORM per andare a farmi quelle e quelli pallose ma se già le sto esponendo ciccia uso questo layer e mi risolve il problema.Tra l'altro postgres, postgresst può essere utilizzato al di là di supabase per cui non c'è quel vincolo.E supabase che utilizza quella libreria per creare delle API REST ma potreste tranquillamente utilizzarlo senza supabase.Un altro elemento fondamentale dei miei site project è tutto il sistema di autenticazione e di autorizzazione.Sono due cose diverse l'autenticazione e l'autorizzazione.L'autenticazione serve a definire chi sei, quindi chi è l'utente che sta accedendo.L'autorizzazione invece ha il ruolo di definire quali sono i compiti, cioè tu puoi farlo lo puoi fare o non lo puoi fare.Tutto questo su Supabase è fatto grazie a JWT non me ne vogliano i puristi, JWT lo dirò con la zappa come mio solito è un modo per scambiare dei messaggi codificati e in qualche modo firmati verificabili.Codificati vuol dire che fondamentalmente abbiamo questa stringa di caratteri alfanumerici che però se noi decodifichiamo contiene una serie di informazioni.Non vi spiego com'è fatto JWT perché se entrate nel sito, mi sa che si chiama JWT.org capite al volo di cosa si tratta.Ma la cosa interessante di JWT è che questo pacchettino può essere costruito da un elemento e verificato da un altro server.l'importante è che questi due server abbiano la chiave o le chiavi per poterlo fare quindi immaginate che il mio servizio A fa l'autenticazione e genera questo JWT token lo firma a quel punto un servizio, il mio servizio di API, prende questo token lo legge, vede il contenuto Siccome il contenuto può essere manomesso, verifica se la firma corrisponde, perché c'ha la chiave quindi può farlo, e a quel punto farà quello che deve fare.Insomma è un modo distribuito per gestire l'autenticazione dell'utente.Se poi questo modo distribuito fitta perfettamente con quella che è la struttura di SupaBase, perché? perché abbiamo due entità diverse che si occupano dell'autenticazione e l'autorizzazione infatti l'autenticazione è fatta da un servizio scritto in go come vi ho detto prima dai ragazzi e le ragazze di netlify che ci permettono appunto l'autenticazione dell'utente e l'autorizzazione invece come vedremo tra pochissimo è delegata a postgres fondamentalmente su super base esistono tre tipologie di utenti e quindi tre tipologie di token JWT.una tipologia è l'utente anonimo tutti i nostri side project hanno un utente anonimo l'utente anonimo semplicemente è l'utente che non si è ancora autenticato per il quale può vedere delle cose poi abbiamo invece l'utente Dio che su Superbase è rappresentato dal service role key io utilizzo l'utente Dio quando c'ho una lambda per dirvene una che si occupa di fare la pulizia dei record vecchi ecco lo fa attraverso API REST esposta da abbiamo visto prima Postgres e lo fa utilizzando una chiave che gli permette di fare tutto quello che vuole e poi abbiamo invece un tipo di chiave che la chiave user djwt token che è il token per l'utente che dentro conterrà le informazioni dell'utente che poi verranno verificate in fase di autorizzazione perché se io voglio vedere una risorsa ok il sistema di autorizzazione dice ok fammi vedere che token hai lo legge verifica che la firma sia corretta con il contenuto sia compatibile col contenuto e a quel punto verifica che quell'utente che sta scritto dentro il token gwt abbia i diritti per vedere quella risorsa.Come vi ho detto quindi abbiamo due elementi autenticazione e autorizzazione.L'autenticazione lo ripeto ancora una volta è fatta da una libreria fatta dai ragazzi di Netlify scritta in Go che si chiama "Go through" che supporta tutta una serie di funzionalità.Sentitele abbiamo l'autenticazione dell'utente, la registrazione dell'utente e la gestione dell'utente.Che cos'è l'autenticazione dell'utente? L'autenticazione è quando l'utente inserisce il nome utente e password ma non solo perché esistono diverse modalità d'autenticazione.Superbase supporta un un gozziliardo di provider per esempio per l'out 2 supporta apple azur beat bucket discord facebook github slack notion spotify twitter zoom twitch twilio non so ne supporta davvero una marea in più ci sono altre modalità d'autenticazione per esempio i magic links che arrivano via via email quindi tu inserisci la tua e-mail clicchi login ti arriva un'e-mail con un link tu lo clicchi e sei autenticato.Ecco nettlyfai go through e spone un API rest per fare tutte queste cose in più per fare la registrazione dell'utente e per fare il user management la password persa tutte quelle cosettine che sono abbastanza pallose da fare è che ci dovremmo fare a manina se non utilizzassimo un sistema di autenticazione di questo tipo.Ma come funziona però l'autorizzazione? Io vengo o per tanti anni ho lavorato nel mondo PHP con Symfony e Laravel e adesso sto lavorando parecchio con Fastify.Solitamente l'autenticazione della mia applicazione funziona così.a immaginarvelo io il mio client che ha un JWT token quindi che si è già autenticato e dopo l'autenticazione ha ricevuto un token fermato con le sue informazioni dell'utente che poi dovrà passare a un API.L'API prende il token lo verifica a quel punto l'API il servizio che espone l'API fa una query e questa query la fa con l'utente di Postgre che in qualche modo può vedere tutto da quella tabella.Postgre risponde i dati all'API service che poi li rimanda il client.Quindi fondamentalmente API ha accesso a tutto il database ed API che valida il token.Su Superbase non funziona così perché perché il layer API è sottilissimo ed è fatto da Postgres, il cui compito è solo quello di trasformare fondamentalmente un url, una richiesta HTTP in una query SQL.Quindi in realtà cosa fa Postgres? Passa direttamente il token a Postgre SQL al nostro database.Il nostro database ha un'estensione attivata il cui compito è quello di decodificare il token, siccome il nostro database ha configurata la nostra chiave per verificare se la firma sul token è vera, verifica se il token è accettabile, a quel punto prende le informazioni dal token JWT e le imposta, le setta su una una specie di variabile globale del database ok queste variabili globali hanno degli scope esiste una variabile globale il GUK o KUG non mi ricordo la sigla ma è una funzione in sita a Postgres che è visibile durante tutta la connessione al database.Quindi cosa fa Postgres? Estrae l'informazione dell'utente, se la va a mettere in questa variabile globale disponibile per tutto il tempo in cui siamo connessi al database, a quel punto quell'informazione che è per esempio l'user ID può essere utilizzata per verificare delle regole d'accesso alle righe basate su un'altra feature di Postgres che è chiamata row level security.Cos'è la row level security? Sono una serie di regole che tu ti scrivi come se fosse una una query SQL quindi fai create policy dentro questo create policy metti questa regola che ti dice per esempio che questa la riga può essere vista se nella colonna user id se la colonna user id di quella riga corrisponde all'id utente che è disponibile che l'utente autenticato autorizzato quindi è diciamo quell'informazione che sta dentro la variabile kuguci.Superbase in automatico setta, passa una serie di valori, passa la user id, passa la user email e se non mi sbaglio passa anche dei ruoli che puoi configurarti.Ma se voi andate nel sito di Superbase e andate a vedere come sono queste regolette sono quasi banali quindi fondamentalmente tutta la parte di autorizzazione è delegata a Postgres che in modo molto figo cosa fa? Sa chi è l'utente e restituisce i dati.Avrei queste regole dentro Postgre, fa sì che la nostra API non è onnisciente, non si collega al database e può gettare, prendere tutto il contenuto del database, ma può prendere solo quello che fitta la regola perché gli sta passando, sta passando attraverso appunto l'API un JWT token che ha degli scopo, che ha delle limitazioni.Questo vuol dire in realtà che se l'utente non può accedere a una serie di informazioni queste informazioni non usciranno dal database per cui anche a livello di UI noi possiamo trascurare tutta una serie di edge case che in realtà se l'API fosse onnisciente dovremmo in qualche modo preoccuparci di validare.Vi faccio un esempio.immaginiamo di fare una regola che dice che per un certo utente che sta in un certo gruppo, sta in un certo team, i dati nella tabella working hours possono essere inseriti solo dalle nove del mattino a mezzogiorno.Non lo so, è una regola un assurda ma per dirvene una se non mi preoccupo di correggere la UI e per mettere un timer anche su javascript per dire fammi sparire questo form dopo mezzogiorno potrei non preoccuparmi cosa succede che l'utente fa una query fa una chiamata utilizzando Postgres o l'SDK questa chiamata arriva al database, il database vede fallire la regola non dà nessuna risposta non scrive niente, gli risponde la query è fallita direttamente all'interface e il problema è risolto quindi tutta la parte di securizzazione in realtà essendo fatta l'atto database ci tranquillizza, ci scarica di una serie di responsabilità perché tanto i dati da là dentro non escono.Un'altra funzionalità molto interessante di SupaBase è la funzionalità real-time fatta da quel servizietto che vi dicevo, open source anche quello scritto dal team di Superbase questo in Elixir che si occupa di ascoltare le modifiche nel database e quindi gli eventi nel database che ne so l'inserimento di una riga, l'eliminazione di una riga e andare a dispacciare degli eventi legati appunto a questo cambiamento su websocket.La cosa figa di questo sistema real time per il quale c'è anche un SDK javascript per cui tu direttamente con una funzione una piccola funzione javascript fai la subscribe a un certo evento o un gruppo di eventi di una tabella e viene notificato.Però ci sono due cose molto fighe.La prima è che questo sistema di sottoscrizioni supporta tutto quello che abbiamo detto prima della Raw security Raw level security.Quindi se io sottoscrivo la tabella messaggi ok c'è una regola che non mi permette di vedere determinati messaggi.Se quei messaggi vengono aggiornati io non verrò notificato perché non sono autorizzato a ricevere quelle informazioni e tutto questo a livello database per cui non sul mio canale WebSocket non riceverò nessun messaggio di aggiornamento o di evento.Quindi questa integrazione avete idea di quanti mal di testa elimina? Io per un mio progetto ho utilizzato Pusher e mi ricordo che rottura di scatola era dover fare l'autorizzazione a un certo canale con l'utente.Cioè era un giorno di lavoro, mezza giornata di lavoro per ogni progetto che utilizza quell'approccio sto usando un servizio sto pagando un servizio che dovrebbe ridurre la la la la mole di lavoro in quella direzione immaginate se non lo usassi qua in questo caso questa funzionalità è out of the box e anche sulla funzionalità real time vediamo che tutto si basa su una feature che postgres mette a disposizione out of the box che è chiamata logical replication.Che cos'è fondamentalmente? è la feature che permette la sincronizzazione tra due database è una sorta di pub/sub dove c'hai un publisher che pubblica appunto i cambiamenti alle tabelle e gli inserimenti e l'eliminazione e le modifiche dei dati e tu puoi fare utilizzare il tuo subscriber per metterti in ascolto di questi cambiamenti quindi cosa fa in realtà questa libreria open source sottoscrive appunto una serie di sottoscrive il database prende i cambiamenti e poi li dispaccia su websocket cosa veramente veramente figa e comoda.Abbiamo anche un'altra funzionalità interessante che è la funzionalità di file storage.Buona parte delle nostre applicazioni ha l'esigenza di andare a scrivere dei file.Chi è che non ha un upload file all'interno della propria applicazione e per fare questo Superbase, i ragazzi di Superbase hanno creato un servizio scritto orgoglio aziendale on top of fastify che in qualche modo permette l'upload e la gestione di file su servizi di object storage compatibili con i driver S3 di AWS e questo vabbè è un API che mi permette l'upload su S3 grazie Mauro molto interessante ma qual è la parte veramente figa del concetto di file storage? è che in realtà questo file storage funziona in un modo un po' particolare perché dovete immaginare che per ogni file per ogni bucket e per ogni cartella esiste una riga in un database ok una riga metadata nel database su questa riga metadata però io posso applicare le row level securities quindi posso dire questo utente può accedere a questa riga questo utente può accedere a quest'altra riga ma se la riga rappresenta il file che sta su s3 io in questo modo ho gestito un sistema che mi permette l'autorizzazione all'accesso dei file quindi in un solo colpo io ho un sistema di regole lo stesso sistema di regole anche per i file con tutti i vantaggi che ne conseguono.Sul sito di Supabase trovate queste regole, un paio di esempi di queste regole, ma possono essere veramente complicati, davvero complicate, che coinvolgono magari tabelle differenti se questo utente fa parte di un team può scrivere su questo bucket ma solo dalle 8 alle 9.Il gioco si fa veramente veramente interessante.L'ultima parte di cui vi voglio parlare è la parte riguardante la business logic.La business logic su SupaBase si può fare in due tipi, in due modalità diversi.La prima chiamata function è diciamo la modalità più a parer mio limitante che sono le classiche stored procedure dal quale sono scappato tanto tempo fa, sono quelle funzioni iscritte in plpgsql che fanno delle robe molto vicine ai dati delle modifiche dei dati agiscono sui dati.In realtà su supabase è possibile attivando delle estensioni direttamente da UI poter fare queste funzioni anche in javascript funzioni che in realtà possono essere chiamate da postgres via api rest oppure direttamente dal nostro sdk utilizzando il metodo rpc chiamiamo direttamente la funzione gli passiamo i valori altra cosa interessante non mi ricordo se ve l'ho detto possono contenere anche del codice javascript ma bisogna attivare e o python ma bisogna attivare l'estensione.Io non sono mai stato un grande conoscitore di plp gsql quindi diciamo che questa modalità per scrivere della business logic la guardo un po' da lontano percepisco che può essere utile magari legata a un'altra funzionalità che sono i trigger che li vediamo tra pochissimo per agire attivare delle modifiche successive a un certo evento quando inserisco quando faccio la registrazione utente me la fa direttamente la libreria il servizio di authentication bene a quel punto io metto un trigger quando viene inserito un nuovo utente nella tabella user mi crea una nuova riga dentro la tabella user metadata già con la relazione con quell'utente ecco per fare queste cose utilizzare le stored procedure può essere una cosa interessante ma in realtà quando si vuole scrivere della business logic forse questo è un modo un po limitante.Un altro motivo per usare queste funzioni è quella di fare delle chiamate verso webhook esterni.Il vero problema è che l'esecuzione di queste funzioni è sincrona quindi è essendo fatta dal database e non avendo il controllo sui tempi di risposta del server che stiamo andando a chiamare, qualche problema in termini di performance potremo averlo.Comunque come vi dicevo queste funzioni si basano o possono essere utilizzate attraverso i trigger che sono un'altra funzione nativa di PostgreSQL che è fondamentalmente un grilletto che si attiva al succedere di un certo evento.Possiamo definire se attivarlo prima o dopo che un evento SQL avviene, che ne sono una select, una update, una delete e chiama una certa funzione.Una cosa interessante dei trigger è che abbiamo una UI per farli e quindi non mi devo scrivere codice SQL.ah bello per me che non sono molto bravo con le SQL e poi che in realtà immaginiamo una una bulk update cioè un evento che a seguito di un aggiornamento di multiple di più righe del database ecco c'è la possibilità di dire ok il il trigger farlo scattare una sola volta per update oppure una volta per ogni riga aggiornata e questo è molto figo perché ci possono essere dei casi come quello che vi ho detto prima dove io voglio aggiornare che ne so tutti gli utenti per dire ok tutti gli utenti devono avere la privacy attivata e deve scattare un trigger una volta per ogni utente quindi una volta per ogni riga per aggiornare anche un'altra tabella e magari criptarmi i dati.Interessante ma comunque io non sono un grande amante delle stored procedure e quindi cercavo un modo diverso per eseguire la mia business logic.E' un po' come Asura fa, il modo diverso poteva essere quello di chiamare attraverso webhook un servizio scritto in un linguaggio X ditemi un linguaggio in COBOL, no scherzo, un qualunque linguaggio ecco che rimane in ascolta appunto di questo di questa chiamata HTTP e fa robe.Superbase supporta una funzionalità che si chiama Function Hook il cui compito è proprio questo quindi creare una sorta di webhook che chiama la tua logica di business scritta nel linguaggio che più preferisci e come funziona in realtà fondamentalmente si basa su una richiesta HTTP e la fa posgre questa chiamata quindi per far farla fare a posgre come vi ho detto prima abbiamo il problema del del fatto che le funzioni sono sincrone e quindi a livello di performance una chiamata HTTP fatta da un plugin da un'estensione di Postgre che la esegue in modo sincrone è lentissima.Immaginiamo che utilizzando un approccio sincrono Postgre è in grado di fare tre richieste e mezzo ogni 10 secondi.ragazzi di Superbase hanno sviluppato un'estensione per Postgre che si chiama PGNET che invece cosa fa? Implementa un worker e una coda e quindi fa sì che le richieste HTTP siano asincrone e questo porta le performance da, come vi ho detto prima, tempi vergognosi tipo tre richieste e mezzo ogni dieci secondi a 300 richieste al secondo che è già interessante è già una performance accettabile tra l'altro stanno lavorando per permettere l'integrazione non solo a chiamate HTTP classiche tra l'altro vabbè in queste chiamate noi possiamo configurare il metodo i parametri da passare gli header abbiamo un bel controllo ma in più out of the box stanno lavorando per fare delle integrazioni verso Google Cloud Run e AWS Lambda.Tra l'altro stanno anche lavorando per una loro feature super base function una loro roba serverless.Immagino che si appoggi su AWS Lambda.Quindi in realtà in questo modo noi abbiamo la nostra business logic nel linguaggio che più ci piace fatta attraverso un microservizio che espone appunto un webbook.quindi leggero, veloce, facile, che però si integra a tutto un backend strutturato che è quello che vi ho appena raccontato.E allora cosa manca? Beh, questa settimana Superbase sta annunciando le nuove funzionalità e ha annunciato GraphQL, che era il grande assente su Superbase.Adesso, fino a qualche tempo fa, loro proponevano di utilizzare Asura che permette appunto la strazione, la trasformazione di API REST in API GraphQL in realtà c'è ci sono tanti servizi mi viene in mente anche Mesh la libreria della GraphQL Guild che fa più o meno la stessa cosa e questo secondo me è il modo migliore per implementare GraphQL su Superbase.Esiste un altro modo che quello che stanno lanciando i ragazzi di Superbase e che mi lascia un po' perplesso.Hanno sviluppato un'estensione Postgre che espone direttamente GraphQL.Quindi è Postgre che sta esponendo un API GraphQL.Tra l'altro è bellissimo visto oggi l'hanno annunciata ieri ho visto oggi un video di come funziona c'è graffi SQL graffi ql che è l'interfaccia grafica per generare le query è carina però qual è la mia preoccupazione è che il database debba gestire anche le richieste delle API.Questo plugin fa tutta una serie di ottimizzazioni ed è molto vicina al database quindi si occupa della trasformazione fondamentalmente delle query GraphQL in query SQL e quindi gestisce il problema dell'NPU 1.Insomma tutta una serie di problematiche che ci sono con GraphQL.E perché il team di Super Base ha deciso di fare un'estensione per per Postgre e non scrivere un altro microservizio? In realtà la cosa è simpatica perché Super Base i profili free girano su un'istanza immagino sia un EC2 l'EC2 più piccola e loro sono già quasi a tappo con la RAM quindi dovevano trovare una soluzione per offrire questa feature ottimizzando RAM e tirare su un altro micro servizio perché già hanno Kong, hanno il servizio delle subscription hanno il servizio fatto su Fastify per l'utente hanno Postgres che è un servizio solo hanno un altro servizio in go che è quello dell'autenticazione.Insomma morale della favola non volevano aggiungere un altro microservizio per cui hanno creato questa estensione che utilizza pochissima ram perché non deve tirare su un server o quantomeno non deve tirare su un microservizio che lo so espone questa questa API.Io la proverò ci farò un po un po di benchmark proverò a farci un po di benchmark giusto per capire se è un mio preconcetto oppure c'è il problema c'è.Altra cosa che in realtà mi lascia un po' perplesso è che io volevo provare a deployare Superbase su Kubernetes e non c'è un chart helm c'è solo un docker compose con un po di tricchini da fare delle configurazioni non è un'installazione che parte semplice senza problemi ci sono delle cosettine da da aggiustare quando lo si lo si installa e manca appunto un elm chart per per kubernetes ho visto che c'è una issue penso ci stiano lavorando loro suggeriscono di utilizzare compose che è un tool che trasforma i docker compose in file per per il file yaml per kubernetes ma non funzionano quindi in realtà o vi mettete di buona lena a scrivere gli yaml oppure bisogna trovare una soluzione alternativa ecco quello che manca è appunto un one command install che ti genera le chiavi fa tutto quello che deve fare e ti spie fa il setup del progetto anche se la cosa più semplice mi rendo conto che non investono tantissimo in questa direzione perché devono rendere semplice l'utilizzo del servizio o stato da loro quindi ha anche senso che questa cosa insomma se la vuoi te la devi fare ci devi mettere dell'effort.Concern e cose interessanti.Intanto è un progetto giovane c'è tanto da fare.Ci sono alcune piccole inconsistenze.Ci sono tante issue quindi se volete contribuire potrebbe essere il momento giusto per iniziare anche perché insomma ci sono tech stack diversi.Il loro pannello di controllo si basa su Next.js alcuni microservizi si basano su fastify quindi non è neanche poi così difficile contribuire in questo progetto a meno che non vogliate lavorare nel team che scrive le estensioni per postgre ma in quel caso io non ne sarei in grado non so voi però la vera paura è che in realtà delegare tutte queste cose a postgre un po' mi mette in ansia perché come sappiamo il database non è il componente più semplice da scalare e fagli fare tante cose un po' mi lascia mi lascia perplesso no? Quindi se il progetto scala come mi muovo tutte queste responsabilità che sto dando al database possono essere un problema non sono ancora riuscito a darmi delle risposte sono solo delle preoccupazioni e delle domande che mi faccio spero di avervi incuriosito raccontando appunto su pub e provando ad andare a vedere come funziona un po sotto il cofano.Ho voluto dirvi un po di più di quello che ho detto a CodeMotion voi se avete interesse e vi fa piacere buttate comunque un occhio sul sito di Superbase, sul blog, al di là che utilizziate Superbase o meno, l'idea che Superbase sia un insieme di microservizi che lavorano insieme raccolti appunto da un API Gateway che è Kong e poggiati su Pods Postgres è interessante io per esempio guardavo con una particolare attenzione e gotro che l'API del microservizio di autenticazione mi è venuto in menti di dire ok potrebbe essere utile utilizzarlo anche in altri contesti oppure postgres quindi quello che trasforma il microservizio che trasforma il database in un API rest perché non utilizzarlo in un altro contesto magari con un altro sistema di autenticazione o al di là di super base Ma il vero takeaway, quello che mi porta a casa da questa esperienza, è che in realtà da tanti anni stavo usando Postgre come un posto dove mettere e togliere i dati.Guardavo alcuni amici che lavorano su SQL Server e ci picchiavano duro di "stored procedure" come degli alieni, no? Lungi da me era l'idea di installare delle estensioni su su Postgre per fare delle robe tipo il parsing JWT cioè per me erano robe lontane anni luce e in realtà questa esperienza con Superbase e questa questa esplorazione ecco che ho fatto su super base mi ha insegnato mi ha reinsegnato che postgres è molto di più di un posto dove mettere i record e tra l'altro aggiungo anche postgres è molto fino spero che questo episodio vi sia piaciuto sono stanco in realtà parlare così tanto da solo era da un po' che non lo facevo e tutto sommato mi ha riportato ai vecchi tempi primi tempi di gitbar io vi ringrazio per essermi stati ad ad ascoltare vi devo dare il mio balocco sapete che vi dico il mio balocco di oggi è l'episodio nel senso che il mio balocco di oggi è Super Bass provatelo provate i vari esempi tra l'altro Super Bass è ricco di piccoli progetti piccoli grandi progetti interessanti da provare per esempio un progetto che io ho guardato con attenzione era un progetto che utilizzando next.js e stripe faceva un sas, tirava su tutta la parte noiosa del sas quindi in realtà se voi vi scaricate quel progetto ci configurate le variabili d'ambiente ci mettete la vostra business logic e le vostre quattro maschere avete un sas che gira.Ci sono degli esempi con Next, con Nuxt, con React Classic, ci sono degli esempi con Remix, Prima o poi ne faremo una puntata su Remix, quindi buttateci un occhio perché è interessante, perché secondo me ha uno spazio nel panorama globale, non so quanto grande ma senza dubbio interessante, perché mi ha fatto riscoprire e riamare POSGRE.Detto questo io mi accingo a salutarvi vi ringrazio per essermi stati ad ascoltare e vi ricordo rapidamente di nuovo i nostri contatti info@gitbar.it per un repo su twitter e il nostro gruppo telegram Vi ricordo anche che nel nostro sito c'è un'area donatori la settimana scorsa ne abbiamo avuto diversi Questa settimana almeno c'è nessuno ma perché l'episodio uscito domenica oggi è giovedì quindi Non c'è stato abbastanza tempo per le nuove donazioni va bene non c'è problema vi ricordo che ghit bar è gratis quindi Non c'è nessun tipo di problema se ci state ad ascoltare senza donare ma se volete supportarci e Fare una colletta, condividere con noi quelli che sono i costi che in realtà pur essendo gratis ci sono beh trovate un'area su portaci nel sito quindi buttateci un occhio per il resto io vi ringrazio nuovamente e alla prossima ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica]
