Tagged: REST Wordpress OMNIS
February 13, 2017 at 10:02 am #10012Henk NoppeParticipant
Inspired by the comments of @bastiaanolij in one of the other topics I am wondering how many people within this community are doing the same thing or are considering it? It is definitely a interesting topic. What I mean with REST based apps is that the application is no longer accessing the database directly but all the CURD communication is handled by a API layer. In my team we are also pondering this technology and how to start to apply this. So I am curious what your experiences are and which snags to look out for.
Grtz HenkFebruary 13, 2017 at 11:02 am #10013rayParticipant
OMNIS has always been open to interconnect with other platforms/techniques in a cross platform manner, like .NET, JAVA…
But RESTful opens a much bigger stage where ALL relevant actors are playing : database providers SQL/NOSQL, CMS systems, Realtime communications, any kind of servers…
After finishing an complex OMNIS/SOAP project I startet to investigate OMNIS’s REST approach and : WOW, OMNIS REST-workers are working great !
I published a short example where OMNIS works as a REST Client against a 3’rd party Server offering complex features for all relevant platforms.
Modern applications in those days are using REST as a protocol and JSON as the data delivery format, and this will continue for next 3-5 years. Database providers are already offering JSON output on demand like PostGres, ORACLE, MySQL. In addition all of the relevant NoSQL systems, like mongoDb, couch…, do have REST API’s.
Therefore I’m going to turn my OMNIS applications as a central “turntable”for :
1. consuming other REST services for features OMNIS does not offer
2. Open my OMNIS applications for other REST Clients to consume my services
Actually I’m writing an general purpose OMNIS REST-Client using WORDPRESS to manage WORDPRESS-sites from an OMNIS Backend-REST application.
The next step is to figure out the performance of some open-source 3rd party servers.
Amazing times…February 13, 2017 at 10:52 pm #10018Alex ClayParticipant
We moved our native mobile apps from a direct connection to our PostgreSQL servers to use a RESTful API built in Rails. While not a desktop app nor Omnis, I think it’s a valuable comparison. Some pros:
- Flakey connections are much easier to handle since there is no persistent TCP connection to maintain.
- We adhere to the JSON API spec which prescribes some powerful features like field sets and included data. This allows the client to tune and express “queries” without needing extra backend development.
- We can deploy fixes and enhancements on the backed without requiring an app update.
- If done properly, versioning provides and incredible amount of flexibility and agility to support multiple clients simultaneously and decouple backend development from your apps.
- Using authentication tokens is great for security. Set them to auto-expire and you’ve got a much less vulnerable system than a persistent database user with predefined rights.
- It’s slower. Even with caching, which adds extra work and complexity, you’re still bouncing through extra layers to serialize data to JSON and back again. There’s also extra overhead to hold the results in both a JSON format and native objects during deserialization.
- App developers’ work can be blocked waiting for the backend developers to add new functionality.
- We’ve pushed code to our backend for years with stored procedures, views, and custom types. (PostgreSQL is awesome!) One of the selling points of a RESTful server is to migrate your business logic out of your app and into the middle tier. For us, this is moot and sometimes results in duplicated work where certain endpoints or actions just expose a stored procedure.
- To build on the previous point, you have to re-imagine your data into endpoints and handle complex operations in a single POST or PUT. For work that involves touching many tables, like posting accounting entries, this is no small feat.
That last point is a big one. Our mobile apps provides very lightweight data entry features–they’re mostly for consuming information and making small updates. With a RESTful app there are no transactions, so each action needs to survive atomically, or we have to build a single endpoint that updates multiple tables all at once. This can present not only unique design challenges, but even require an altered user experience to allow for all your data collection up front that drives to a single POST. We have an Ember app that uses the same API to make more involved changes in the data, and it absolutely works, but the app is built so that each step collects the data for the final action, and the blasts it to the API in one POST. Your desktop app might need some work to move to that model.
Are we thinking about using REST against an API to access data from our Omnis apps? Yes, and we already do this a tiny bit for our account discovery service. I can see a RESTful approach working well in some cases, but a direct connection excelling in others.February 13, 2017 at 11:54 pm #10019Bastiaan OlijParticipant
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.February 16, 2017 at 3:21 pm #10027Klaus SchrödlKeymaster
Anybody heard of CData REST Api Server or got any experiences together with Omnis?
KlausFebruary 21, 2017 at 2:48 pm #10030Henk NoppeParticipant
Thanks for your replies. Some of it confirms of what I suspected, like the slower performance. But most of them gave me more inside of what to keep in mind and what the benefits are of the REST approach of a application.
Thanks again guys! And yes @ray I am curious to in hearing what your experience what to use outside Omnis to build a REST server.
You must be logged in to reply to this topic.