Experiences with D2Bridge Framework

[twe 3]

What have your experiences been with D2Bridge (https://www.d2bridge.com.br/)? Good, bad, indifferent?

 

D2Bridge looks like a nice way to add a web interface to an application, but were there any gotchas that caught you out?

[omnibrain 20]

Interesting, never heard of it before. It looks like it is more in the direction of WEB framework & components for Delphi & Visual Studio Code | TMS Software than FMSoft uniGUI Web Application Framework 

 

There are of course also Elevate Software, Inc. Quartex Pascal – Research and development for the next generation object pascal (quartexdeveloper.com) and Smart Mobile Studio | About | Smart Mobile StudioAbout - Smart Mobile Studio but they are not 100% Delphi but rather Object Pascal and Delphi inspired.

 

Perhaps a user of some of them can chime in.

Edited April 5, 2024 by omnibrain

[koheleth 1]

D2Bridge delivers a true “click-to-web” experience for Delphi: just recompile, run, and open the browser—no need to change language, switch IDE, or refactor your business layers. For teams that need to put a VCL system online quickly (whether intranet or SaaS), it shrinks months of migration work down to a few days of fine-tuning. If your goal is a smooth transition, minimal rework, and full continuity of Delphi expertise, D2Bridge is currently one of the most straightforward solutions available.

Edited yesterday at 12:31 AM by koheleth

[Die Holländer 88]

Many VCL applications have been developed over the years with direct database access, which has become increasingly problematic in modern software environments.

 

As a result, developers often feel forced to transition to web-based solutions, such as sending JSON over the internet to abstract away direct database access (e.g., for login functionality).

However, this shift presents significant challenges. One major hurdle is the need to create endpoints for the countless SQL queries accumulated over time, while also transforming the rich and responsive VCL GUI into web pages.

Although modern frameworks offer solutions for this transition, the process of converting database-driven VCL applications remains highly resource-intensive.

 

These frameworks are particularly effective when building applications from scratch. But for developers who prefer to maintain their existing VCL applications and avoid going fully web-based, the question arises: is there a way to address the database access issue without a complete overhaul?

 

Could a solution exist at the database driver level—a kind of bridge between the database server and the client driver (e.g., FireDAC)—that eliminates the need to convert data into formats like JSON and then back into VCL controls or custom DataObjects?

 

[mjustin 30]

1 hour ago, Die Holländer said:

Could a solution exist at the database driver level—a kind of bridge between the database server and the client driver (e.g., FireDAC)—that eliminates the need to convert data into formats like JSON and then back into VCL controls or custom DataObjects?

 

In the early 2000s, we used MIDAS aka DataSnap to communicate from a Delphi client application with a Delphi server over the Internet. It used TClientDataSet in the client and TDataSetProvider on the server side. The server used the SocketServer DCOM bridge. It worked well, with clients around the globe, connected to a single server. The client application used all kinds of DB-aware controls, e.g. the ExpressQuantumGrid.

Client and Server exchanged data packets in a proprietary format, using a "briefcase" model, but from the developer point of view there was just a Datamodule with Datasets.

Edited yesterday at 09:37 AM by mjustin