RemoteDB with WebCore

WEB TMS WEB Core
1

Is there anything in TWebCore that can act like a TXDataset in VCL - connecting to RemoteDB and using SQL to query data?

Thanks,

Rhett Price

1 Like
2

We created the TXDataWebDataSet that can connect to an XData REST server for this.
This is demonstrated in the music TMS WEB Core demo app that comes with TMS XData.
It is live here:
https://app.devgems.com/xdata/music/app/
See also this video
https://www.tmssoftware.com/site/videos.asp?v=98

3

Hi Bruno, thanks. Yes, we use the TXDataWebDataSet and it works great. There are just times where updating the REST server is inconvenient while in use by customers and would nice to sometimes have a more flexible option for querying data and returning only specific fields. So I was just curious if this was something that existed. Thanks for the info.

  • Rhett
4

Not sure I understand your question or need.
You could add an endpoint to your XData server that returns only specific fields?

5

An example is a customer that has our XData Server running. When adding new features, testing, etc. We'd have to take down their XData Server during the workday which is not possible. Well we could do load balancing but customers generally have simple setups that wouldn't allow for that. RemoteDB queries would give the flexibility of retrieving the data we need on the fly without this requirement. XData is definitely a more secure/better way to do it but this flexibility is also nice for development. Right now we are also experimenting with GraphQL as it gives 1 Endpoint that gives similar functionality in that you can ask for any data structure and have it return just the fields you need for performance - without replacing the middle tier.

6

You could create endpoints in XData that receive arbitrary parameters (a list of field names, for example) and freely implement it the way you want - for example, perform an SQL or an Aurelius query using projections - to retrieve the fields asked by the client.

In any case, GraphQL indeed is a good option for that specific use case, I've recently talked about it in my personal blog: https://landgraf.dev/en/graphql-from-the-perspective-of-a-delphi-developer/.