Push la client modificari din baza de date

Salut!

Avem urmatorul scenariu: avem un client conectat prin socket la un server, server-ul monitorizeaza operatiile pe o baza de date, iar cand apar le comunica clientului, client-ul face cache local.

Sa zicem ca se conecteaza un client care are o parte din date salvate local, dar nu pe toate.  Ideal ar fi sa nu primesc tot datasetul de la 0 ci sa primesc doar change-urile care s-au petrecut cat eu nu am fost contectat.
Din pacate skill-urile mele de cautat pe Google n-au fost suficiente si n-am reusit sa gasesc o solutie. Am vazut ca si MongoDB si MySQL suporta subscribe-ul la real-time changes, dar m-ar interesa si un oarecare management al istoricului. Cam cum face GIT, cand dai pull nu trage tot repository-ul din nou, ci doar change-urile pe care nu le ai.

Stie cineva o solutie? Solutie insemnand library/framework/serviciu. Preferabil ceva care sa mearga cu Python/NodeJS, dar si niste indrumari ar fi utile, pentru ca nu sunt foarte sigur ce anume sa caut.

Mersi

MS SQL Server-ul are un feature numit Change Tracking cu care poti face ce vrei tu; mysql-ul are si el coloane de tip timestamp, dar functionalitatea nu e la fel de bine implementata.

Ideea e cam aiurea. De ce vrea clientul sa tina tot? Ce se intampla daca ii scapa o schimbare sau isi da restart?

Serverul nu are alt rol decat de a pune clientului datele in ordine cronologica a schimbarilor? Atunci iti faci un message queue din care sa citeasca clientul ce are nevoie cu diverse garantii.

 LittleWho, on 30 martie 2020 - 12:08, said:

Tu descrii aici o soluție, nu o problemă.

Vino cu problema reală. De ce ar avea nevoie clientul să știe tot istoricul?

Ai putea sa:
- Adaugi o coloana de status/timestamp si iti faci proceduri de insertie si update care actualizeaza respectiva coloana. Sau un trigger.
- Serverul anunta clientul ca a aparut o modificare noua.
- Clientul face un pool pt modificari mai noi decat ultimul timestamp pe care il detine si isi actualizeaza timestampul de referinta.

Cumva, nu pare cel mai eficient daca faci un select de fiecare data. Mai degraba un log in care ai o referinta si recreezi totul din punctul respectiv.
dar, de ce ai face asta? toata baza de date e la dispozitia clientului?

couchbase, firebase au sincronizare "selectiva" trag doar ce nu ai pe client dar nu sunt relaționale

Deci?

Revin dupa cam mult timp ce-i drept, dar mi-am dat seama intre timp cat de proasta era abordarea mea si am uitat sa mai raspund aici.

Aveam un set de date relativ mic si pentru o perioada am avut impresia ca ar fi mai rapid si ar pune mai putina presiune pe server daca as tine tot dataset-ul asta in clienti si ei si-ar face query-urile necesare local (nu aveam nevoie deloc de update-uri). Dupa ce am analizat mai bine, mi-am dat seama ca mergea oribil si complica toata solutia mult prea mult asa ca am trecut pe varianta clasica, am o baza de date pe un server, un mic API, iar client-ul face request-uri acolo pentru ce are nevoie.

In intrebarea initiala mi-am exagerat un pic situatia din curiozitate. Am zis sa detaliez despre ce a fost vorba ca sa ofer un pic de background la motivul pentru care am postat.

Mersi pentru raspunsuri!

Foarte interesanta solutia PostgreSQL + PostgREST :
https://github.com/d...gres-websockets

Permite websockets unde se pot primi real-time evenimentele ridicate din baza de date + evident api/rest ptr CRUD si altele
PS: N-am folosit inca dar conceptul e frumos