Just to weigh into the discussion 🙂
While client-server where Omnis communicates directly with the database will always be relevant IMHO this is indeed what lies in our future.
We’re not there yet, we’ve still got a client-server application and are only wetting our toes so to speak. There are three main reasons for us to make this move and I think these are core things to consider whether or not a 3 tier client-api-database type approach is right for you.
1) We’re looking at an architecture with more then 1 client, Omnis being just one in a group of products with which we wish to access our data. That means moving our business logic out of the client. Now an architecture where different client solutions talk directly to the database and staying with the 2-tier approach can be very valid, especially with a database like Postgres allowing you to put a lot of business logic into stored functions, it’s not what we’d like to do (except as an in-between stepping stone for a some parts of the application). First there is no structure to the stored functions and its easy to get lost in the large number of them. Second there are security worries we have that are better dealt with if there is a middle tier
2) We believe in exposing more complex units through my API instead of a 1:1 exposure of the underlying tables. Instead of submitting a multitude of header and detail records to save a single entity, say an invoice, we supply that entity as one document to the API which then does the atomic actions to commit the change. Besides the structural improvement this is also a performance improvement as the client may be communicating over a slow network connection with the API server while the API server is generally sitting next to the database server. The lag time on dozens of insert or update queries accumulates very fast while the lag time for a single API call is neglectible. Combine that with generally a smaller datasize as we’re purely sending data over in JSON format without the overhead of queries, it can make a huge difference in performance.
3) Finally there is the issue of connection reliability. Especially with our solution being used more and more ‘in the cloud’ dealing with appallingly bad internet connections out in rural Australia, or dealing with client in the C.B.D that solely want to use WIFI while in a building with hundreds of other companies with their routers all fighting for the same ‘air’, a client<->servers reliance on a state-full connections is a pain. Now this can be solved by automatic reconnect logic or by creating a stateless interface with your database connecting as it needs to, the generally state-less designs of APIs towards the front while using connection pools towards the backend seems a better solution.
Those are our 3 key points that are making us move to this. A bonus 4th point would be that having that API also opens up the door to collaboration with 3rd parties who can offer services to our clients by tying their product into ours.
That all said, this IMHO is not a one size fits all solution. If you are in a LAN environment not having to deal with ‘the cloud’, if you just have the Omnis application talking to a back end, or if you have a local single user application talking to a local database (native datafile/sqlite), or many other scenarios I can think of, client<->server still has a simplicity that allows you to build solutions far more rapidly then when you have to think of 3 distinct tiers that have to work together.
Ray, I’m interested in hearing your experience for what you’re using to build a REST server in. This is where I am still searching. I’ve used both Ruby and Node to build a REST server in and I’m slowly getting to a point of putting my ego aside and giving Python another try but I still haven’t found an environment that really has my fancy.
Owh and the WORDPRESS client in Omnis, that would be awesome as something to talk to the developer portal with.