Synopse Open Source

The first requirement is to allow WebSockets on your Master HTTP server, so initialize the TSQLHttpServer class as a useBidirSocket kind of server - see Network and Internet access via HTTP:

  MasterServer := TSQLRestServerDB.Create(MasterModel,'master.db3');
  HttpMasterServer := TSQLHttpServer.Create('8888',[MasterServer],'+',useBidirSocket);
  HttpMasterServer.WebSocketsEnable(Server,'PrivateAESEncryptionKey');

On the Slave side, the HTTP client should also be upgraded to support WebSockets:

  MasterClient := TSQLHttpClientWebsockets.Create('127.0.0.1',HTTP_DEFAULTPORT,MasterModel);
  MasterClient.WebSocketsUpgrade('PrivateAESEncryptionKey');

Of course, the model should match for both MasterServer and MasterClient instances.
As the WebSockets protocol definition - here above the same 'PrivateAESEncryptionKey' private key.

Then you enable the real-time replication service on the Master side:

  MasterServer.RecordVersionSynchronizeMasterStart;

In practice, it will publish a IServiceRecordVersion interface-based service on the server side - see Client-Server services via interfaces.

Assuming that the slave database has been defined as such:

  SlaveServer := TSQLRestServerDB.Create(SlaveModel,'slave.db3');

(in this case, the SlaveModel may not be the same as the MasterModel, but TSQLRecordPeopleVersioned should be part of both models)
Then you can initiate real-time replication from the slave side with a single line, for a given table:

  SlaveServer.RecordVersionSynchronizeSlaveStart(TSQLRecordPeopleVersioned,MasterClient);

The above command will subscribe to the remote MasterSlave replication service (i.e. IServiceRecordVersion interface), to receive any change concerning the TSQLRecordPeopleVersioned ORM table, using the MasterClient connection via WebSockets, and persist all updates into the local SlaveServer database.

To stop the real-time notification for this ORM table, you could execute:

  SlaveServer.RecordVersionSynchronizeSlaveStop(TSQLRecordPeopleVersioned);

Even if you do not call RecordVersionSynchronizeSlaveStop(), the replication will be stopped when the main SlaveServer instance will be released, and the MasterServer be unsubscribe this connection for its internal notification list.

The real-time notification details have been tuned, to consume as minimum bandwidth and resources as possible.
For instance, if several modifications are to be notified on a slave connection in a short amount of time, the master is able to gather those modifications as a single WebSockets frame, which would be applied as a whole to the slave database, in a single BATCH transaction.

Feedback is welcome in our forum, as usual!