0

Please check the answer and comments of my previous question in order to get a better understanding of my situation. If I use Google DataStore on AppEngine, my application will be tightly coupled and hence loose portability.

I'm working on Android and will be using backend which will reside in the cloud. I need client-cloud communication. How do I build an application maintaining portability. What design patterns, architectural patterns should I be using?

Should I use a broker pattern? I'm perplexed.

Community
  • 1
  • 1
Harshal Kshatriya
  • 5,630
  • 11
  • 44
  • 60
  • 1
    Re: portability. The DataStore API code itself can maybe be translated easily to another, similar NoSQL database. But for an actual migration you'd also need to get all you data out of App Engine, which could be very difficult if you have a lot. – Thilo Mar 26 '13 at 09:11
  • Thilo, got that, but I need to store my data in RDBMS and AppEngine endpoints deal with DataStore. How do I overcome that? – Harshal Kshatriya Mar 26 '13 at 09:17
  • 1
    Unless you plan to store the data in AppEngine, there is probably not much point to use AppEngine endpoints. – Thilo Mar 26 '13 at 09:33
  • That is true and I want to store data in RDBMS. A proxy pattern? Spare me, I'm in a "programmer's" dilemma. – Harshal Kshatriya Mar 26 '13 at 09:45

3 Answers3

0

Google AppEngine provides JPA based interfaces for its datastore. As long as you are writing your code using JPA APIs, it will be easy to port the same to other datastores (Hibernate for example also implements JPA).

I would ensure that the vendor specific code doesn't percolate beyond a thin layer that sits just above the vendor's APIs. That would ensure that when I have to move to a different vendor, I know exactly which part of code would be impacted.

Param
  • 2,420
  • 1
  • 14
  • 10
0

It u really want to avoid portability issues use google cloud sql instead. If u use the datastore unless its a trivial strucfure you sill not be able to trivially port it eve if you use pure jpa/jdo, because those were really not meant for nosql. Google has particularifies with indexes etc. Of course sql is more expensive and has size limits

Zig Mandel
  • 19,571
  • 5
  • 26
  • 36
  • I cannot afford to compromise with portability. Initially, I'm planning to have my own dedicated server due to cost factor and then if things work out I would like to migrate to the cloud. – Harshal Kshatriya Mar 30 '13 at 14:54
0

In order to maintain portability for my application, I've chosen Restlet, which offers Restful web apis, over endpoints. Restlet would help me to communicate between server and client.

Moreover, it would not get my application locked in to a particular vendor.

Harshal Kshatriya
  • 5,630
  • 11
  • 44
  • 60