Imagine you've got a fairly typical client-server app built in Delphi that's connecting to pretty much any SQL-based back-end server using whatever DB connection and adapters (eg., ADOConnection and ADOQuery).
Imagine you've got a fairly typical client-server app built in Delphi that's connecting to pretty much any SQL-based back-end server using whatever DB connection and adapters (eg., ADOConnection and ADOQuery).
Now, suppose you're asked to get rid of the direct server connection and adapters, and replace them with a REST-based API.
Under what conditions would this make sense (or not)?
Are there any videos or case studies that address such an architectural refactoring?
In general, are the tools available today (in the Delphi world, at least) of sufficient "quality" or "maturity" or whatever that such an approach would make sense to employ on a regular basis?
(It's a given that you'd probably need to add a service to sit between the API and the DB. I guess I'm asking if it's "easy enough" or "simple enough" to manage the additional layering in the presence of typical table maintenance activities like adding fields, tables, views, and procs, then exposing them via the REST API? Are things at a point that this is a reasonable approach to take for most DB interfacing today, or are there still sufficient hurdles that it only pays if you really NEED a service-based interface? I'm curious b/c I frequently see a TON of queries and procs dropped on a single form today, where some queries are empty and filled-in on-the-fly while others are intact but take parameters, and the SPs are effectively just interfaces for queries that have been moved over to the server. In this case, they'd ALL need to be moved into REST API services, if not the DB server, right?)
Now, suppose you're asked to get rid of the direct server connection and adapters, and replace them with a REST-based API.
Under what conditions would this make sense (or not)?
Are there any videos or case studies that address such an architectural refactoring?
In general, are the tools available today (in the Delphi world, at least) of sufficient "quality" or "maturity" or whatever that such an approach would make sense to employ on a regular basis?
(It's a given that you'd probably need to add a service to sit between the API and the DB. I guess I'm asking if it's "easy enough" or "simple enough" to manage the additional layering in the presence of typical table maintenance activities like adding fields, tables, views, and procs, then exposing them via the REST API? Are things at a point that this is a reasonable approach to take for most DB interfacing today, or are there still sufficient hurdles that it only pays if you really NEED a service-based interface? I'm curious b/c I frequently see a TON of queries and procs dropped on a single form today, where some queries are empty and filled-in on-the-fly while others are intact but take parameters, and the SPs are effectively just interfaces for queries that have been moved over to the server. In this case, they'd ALL need to be moved into REST API services, if not the DB server, right?)
Mike Margerum, TMS XData provides a full-featured query system (and other features) that are strongly inspired in OData, which allows for dynamic queries of resources.
ReplyDeleteMike Margerum anything even breathing LINQ makes me barf. I want to and need to hand-craft my queries so that they are effishient!
ReplyDeleteI'd just turn Sandman 2 on it and be done with it:
ReplyDeletegithub.com - jeffknupp/sandman2