any demo for TAdvmyCloudData or TTMSFNCCloudMyCloudData

The docs for TAdvmyCloudData and TTMSFNCCloudMyCloudData say what's there, but doesn't say anything about how it's used. Are there any demos available for either of these? I want to use them in WEB Core.

They seem to be very similar -- are there any advantages of one over the other if they're just for use on one platform (WEB Core)?


Please note that only TTMSFNCCloudMyCloudData from TMS FNC Cloud Pack is compatible with TMS WEB Core. The TAdvMyCloudData from TMS VCL Cloud Pack is only compatible with VCL applications.

Usage of TTMSFNCCloudMyCloudData is demonstrated in the Overview demo included with the TMS FNC Cloud Pack install.

The Overview demo looks like a test suite. It generates forms dynamically and has many layers that are data-driven, and it does not give much insight into how one would build an app for any of these cloud APIs.

The documentation is like a list of ingredients with no recipe provided. The reader is assumed to know how to put them together.

I'm looking for a demo that has a form with components on it and either an explanation of what order is typically employed to do things, or that shows it in the code.

The Overview demo is a marvel of obscurity and looks like it might have been generated from some kind of tool. But it doesn't compile for WEB Core unless you add a $DEFINE WEBLIB and then it give a bunch of errors for duplicate files in Uses clauses as well as things that are missing.

Where can I find the "recipe" for using all of the ingredients listed in the API spec for MyCloudData API? You had to have built one to act as a reference model used to create that multi-layered data-driven test demo...

From another reply elsewhere:

Under the WebCore install folder .../Demos/Services/myClouddata is a simple demo

Also, under .../Demos/DBBackend/MyCloudData is a more substantial demo

I'd still like to see the docs have a section added that explains a typical use-case scenario (what I call the "recipe") with some code sketches.

I mean ... should your code assume the tables and fields are all created via the UI? or via code? If by code, then do you need to build-in the ability to do versioning so if there's an update then do you need to handle that in code as well? I've seen apps that do that, and they can be awfully convoluted. But typically those are situations where the DB is on an in-house server.

I've also seen where there's a separate app to do this, but I'm not sure it's viable when you're using a central DB service that supports a web-based front-end for users scattered around the world.

TBH, doing this sort of thing in a web-app context is new to me and presents some questions I've not encountered before, so some guidance would be very helpful. Most APIs need to take versioning into account for obvious reasons. And if you're working with a DB that can change over time, there's an additional level of versioning that the API should be able to reflect indpendently of the API's own version.

Are there any "best practices" that can be followed? Does the API offer any help in this respect?

I realize this is all much "higher-level" than just saying, "Here's a table, here's a field, here's how to get the metadata for everything"; but the first time you make an update to the DB, the whole shebang is going to come crashing down if that kind of change wasn't anticipated.

Please note that the application developer is responsible to handle any possible changes made to the DB as this is outside the scope of the API.

We already started adding separate demo applications next to the Overview demo and adding more demos is on the planning for a future version of TMS FNC Cloud Pack.

Thank you for your feedback on the documentation, we'll take your suggestions into account for the next update.

Also I would like to inform you in advance that a myCloudData API successor based on .NET is in the works.
We expect this new and improved solution to become available in the second half of the year.

Thanks. I noticed this mention of .NET elsewhere, which tells me it will be restricted to Windows hosting, not Linux.

I see this as mainly a headless server. I don't understand why you wouldn't make the DB's REST API fairly generic and then build the UI separately. If someone wants to host in Windows, then they could use the .NET UI.

MySQL is completely headless, but there's a tool called phpMySQL that lets you do basic admin work on it that runs in virtually any Linux host. And there are literally dozens of other tools that let you manage a MySQL DB from a fancy UI. In fact, TMS even makes one! It's called the TMS Data Modeler. I haven't looked, but ... does it support myCloudData installtions via the REST API?

So why are you building a next-gen tool that will only run on Windows? I much prefer running on Linux hosts! For one thing, they're cheaper and easier to maintain, and you're not constantly required to update them.

The whole reason I want to use this is to avoid having to deal with security issues with hiding it behind the Windows firewall if I connect directly using IP:port# because of the security issues.

Now you want to build a UI that forces me to run it behind that very Windows firewall I don't want to use just to have a UI that I don't want or need? If we can get access to it by simply using TMS Data Modeler, why would you need a separate UI?

Why don't you put your effort into improving Data Modeler (a Windows-based tool) and using it as the UI for myCloudData and keep the myCloudData service operating cross-platform with no UI dependencies?

At this moment, the service is what we offer as solution for not having to host a data backend yourself.
We'll take your considerations in account for future developments.

Have you thought about using XData, Aurelius, and Sphinx to build something similar (a common REST API) that basically bolts onto whatever DB that Aurelius supports? And it could run in whatever environments that Delphi and those tools support.

It just seems very odd to me that a vendor of advanced Delphi tools would be using .NET to build their next-generation version of myCloudData rather than Delphi and their own tools.

What I'm looking for is something similar to Memberful, but that lets me add tables and fields via the REST API that can, but aren't required, to be exposed via the UI. Memberful doesn't let you change the DB at all, and it gives you 5 fields in the User's profile that you can name whatever you like and access via the API -- but they're just strings and the user can access them and change them via their UI (they can't be hidden). So you can't save BLOBs or binary data or JSON or any user-related state data that the user doesn't need to see.

So to use Memberful, I'll need to maintain a separate DB to save member-specific data that can sync with what's in the Memberful DB but cannot be accessed from it. In other words, I'll need two DBs instead of one because Memberful has no extensibility.

The nice thing about Memberful is that it handles ALL of the membership details: signups, one-time and recurring payments, authentication, member levels, etc., and all of those details are available on a per-member basis via their API.

AirTable is similar except it's designed from the ground-up to be a friendly drag-n-drop UI-based app builder that uses DB tables underneath. The API lets you see into the DB, but that's about it (from what I can tell).

At the other extreme is your basic MySQL DB. It supposedly has a REST API that you can activate, but it requires root access to set up, and you have to run it in a dedicated server because of how it grabs the incoming traffic from Apache. There's no special UI, it does not handle payments or know anything about any kind of particular usage model -- you need to build whatever you need on top of it. But there are dozens of high-level design tools that work with it.

I also work with a tool called AppGini to build web apps; it spits out php code and uses MySQL, but they don't have any sort of REST API. Anything you add to support REST needs to be built by hand. I've found several tools that will create a REST API that mirrors the DB, which isn't usually what you want -- the REST API should implement Views that restrict access to certain things for security and data integrity purposes. Which gets us back to using XData, Aurelius and Sphinx to build a higher-level API tailored for a specific purpose like a membership site. (AppGini will let you build a fairly simple membership site, but it doesn't handle payments.)

  1. There is an XData music DB demo that demonstrates binding between XData back-end and TMS WEB Core front-end.
  2. The choice for .NET is driven by deployment abilities.
  3. From the very beginning, it was always a choice to make TMS WEB Core as open as possible, both with respect to back-end binding as using all kinds of front-end libraries.
  4. Going forward, we certainly have bindings to other back-ends on the radar, to widen the freedom of choice even more.
1 Like

I'm referring to myCloudData, not things that connect to it.

I don't understand why it has a mandatory UI when there are so many GUI-based tools that let you manage the underlying DBs, which for myCloudData can be either MS SQL Server or MySQL. So it's mainly a REST API that attaches to one of these existing DBs. But why is the UI part mandatory? I'm seeing comments from people who are struggling getting the SDK to work with newer versions of UI components -- stuff that has nothing to do with the REST API.

I do understand why AirTable and Memberful have a UI -- because they were designed to be easy-to-use no-code solutions. The REST API is an add-on. When I ask them if you can create data fields in the DB via the REST API that are not visible in the UI, they say, "No". Because they use the UI part to manage the entire DB.

I'm sorry but I do not understand your question.
Where do you see myCloudData having a mandatory UI?
You can do everything with the REST API. From adding tables, adding metadata to working with data in the tables, all with the API. No UI required.
If you do not want to use the REST API, you can use the UI via