Hi guys
Progress mobile consumes a rest service which is connected to one appserver and this appserver connects to one specific db. We have a situation where im trying to find the best practice or way forward to a solution that involves us having 1 mobile app that can serve many clients and each client having their own db. My solution to this is to have a a DB connected to the appserver on the rest service and this will authenticate the client and get their DB details.. I will store those details in a session storage variable on the mobile app and pass these details to the rest service every time they do an appserver hit to connect to that clients DB and retrieve the information accordingly.
However this does not seem like the best solution.. Im new to the mobile developement and think there is a much easier way to do this.
any ideas or solutions?
TIA
Re-connecting every single call is a performance killer. Have you considered the multi-tenancy features of he OpenEdge database?
Multi-tenant is not an option we have to use existing architecture and the DB's as they are.
Don't even consider connect/disconnect on request, why can't you just have separate rest services one for each database set and then one entry point that can just keep references (service url's) of those so the client mobile all just get the 'service catalog' and the user will use one of the available rest services.
Instead of 1 appserver to N databases you could have N appservers to N databases as well. In this case you could have yadaaydaa.com/.../... and yadaaydaa.com/.../...
A reverse proxy (nginx f.e.) could forward companyabc to appserverAbc and companyxyz appserverXyz (or what names you have for your appservers). I would suggest 11.6 and PASOE since this makes life easier when creating appservers from script (which you probably want) and PASOE has incorporated Tomcat as well...
after yadaa.com I meant /companyabc & /companyxyz. The forum "eats" URL's.
Yeah, something along that line only I would recommend akera.io with a bunch of node.js application servers spread around and one web service as single entry point that can balance/distribute/route requests between those… works great if you want to create new instances from scripting and it does NOT have an incorporated tomcat ;)
we from akera.io recommend akera.io ;-)
right, not only because it’s better but it’s something we’ve done and darn proud of it ;)
and you have every right to be proud! I was just teasing.
Are you saying this is possible to do within the Progress toolset? I'm not following where those capabilities are.
Trying again, are you saying this is possible to do within the Progress toolset? I'm not following where those capabilities are.
I’m not sure to whom this question is addressed, can you please clarify what are you interested in? The multi-tenant feature of the database server can work very well, it was simply designed for situations like that and it’s doing a data partitioning inside the database for each tenant. It does require one to buy that extra package but I think it’s cheaper than having a set of multiple database servers anyway.