Change registration data for synchronization
I am looking for a solution to change registration data for a public API.
The client application needs to be informed that the db tables have changed and they need to be synchronized since the application was last synced and must also be for a specific brand and country.
Current solution:
- A version table with the class names that apply to each model when creating, deleting, touching, and saving actions.
- When we touch on the model-specific version, we also look at the reflected associations and touch them too.
- The version model covers the brand and country.
- REST API responds to a request that includes last_sync_at: timestamp, brand and country
- Rails looks at the version with the given attributes and returns class_name of the models that have changed since lans_sync_at.
This solution works, but the issue is performance as well as service.
UPDATE 1:
Maybe a simple question. What's the best practice for figuring out and telling frontend apps when and what to sync. In terms of a holistic concept.
Terms:
-
Front-end apps should only load their own content changes, not the entire dataset.
-
Synchronization does not start when you need to sync an app from different countries or brands.
Thank.
source to share
I think the best solution would be to use redis (or some other keystore) and store your information there. Writing to redis is much faster than any sql db. You can write some service class that will save the data, for example:
RegisterTableUpdate.set(table_name, country_id, brand_id, timestamp)
Such a call would store the given timestamp under a key, which could look like, for example, table-update-1-1-users
where the first number is the country ID, the second number is the brand ID followed by the table name (or you could use the country and brand names if needed) ... If you want to know which tables have changed, you just have to find the redis keys with the query "table-update-1-1- *", loop through them and check which ones are newer than the timestamp sent via the api.
It's worth noting that redis is not as reliable as SQL databases. Its reliability is configuration dependent, so you can read the redis guidelines and decide if you want to go for it.
source to share
You can take advantage of the fact that the ActiveModel is automatically registered every time it updates a row in the table (column "Updated by")
When checking what needs to be updated, select the items of interest and compare them "Updated by" with the timestamp from the client application.
The advantage of this approach is that you do not need to keep an additional table listing all updates on the models, which should speed up the API user experience and be easier to maintain.
The disadvantage is that you cannot see changes in the data over time, you only know that there has been a change and you can access the latest version. If you need to track data changes over time efficiently, I'm afraid you will have to redo things from above.
source to share
(read the last part - this is what you're interested in) I would recommend using the decorator skin pattern to modify client requests. So the client sends a request for what it wants and the server decides what to give it based on the client's latest update.
So:
- the client sends a request including the time of the last synced
- the server sees the request and takes into account the nature of the client (device country)
- the server decorates (changes accordingly) the request for a request from the database only the corresponding data, and if this is not possible:
- after the data is returned from the database manager, it is truncated to be relevant to where it is going.
- returns to the client all the new things that the client cares about.
I am assuming you have entered time for entries in the database. In this case, "decorating" the query (in the abstract) would be simply to add something like a WHERE clause to your query and indicate that you want the data to be entered since the last update.
Finally, if you want this to be done for many devices / locales / regardless of the decorator implementation for the query and the query result, and serve them for your clients as they serve. (Keep in mind that unlike the subclassical approach, you will only need one decorator per device / locale / independently - not for all combinations!
Hope this helped!
source to share