0

I want to create an Android application with cloud-based functionality.

It would entail a (rather simple) loyalty program for consumers and retailers; so, just managing user accounts and some associated data such as collected points.

My question: is it feasible to base it on some ready-made solution such as Amazon AWS or Firebase? I mean, just using a database in the cloud, plus authentication services - but without implementing my own, custom backend, rolling out custom API etc.? What do I lose by taking that approach?

Obviously in such case no business logic can be implemented on the backend side, which might be a liability as far as backwards compatibility goes.

Is there anything else I'm missing, though?

Happy to provide more info if required.

2

As a quick proof of concept, that's a decent way to get started.

What do you lose?

  • Control of design, API, and authorization (i.e. controlling who can do what)
  • Consolidation of some of the queries you need. The power of the cloud is when you pull from different data and merge it together in an interesting way.
  • Performance when you attempt to do everything in the client that should have been consolidated (point 2)

These are all aspects that in a proof of concept phase aren't super important, but as the number of users scale up, you need to have enough control over your infrastructure.

Remember that cloud based authentication is determining who it is that is accessing your services. That does nothing to control who attempts to do any activity. Your app is responsible for enforcing its own authorization, which validates the privileges an authenticated user has.

  • good answer, +1. I would point out that some cloud authentication services also provide authorization, but how well their offering matches the OPs needs is indeterminable from what was posted. – Paul May 12 '17 at 14:41
  • @Paul, yes, sort of. For example, you can set roles for read/write to an AWS S3 bucket and use the AWS identity to access that, but many times the types of authorization that apps need is much more fine-grained. – Berin Loritsch May 12 '17 at 15:02
  • I wasn't speaking specifically about AWS, but even AWS provides finer grained options than you describe, e.g. Without building your own app you can still use API Gateway to define resources and routes and then secure them with a high degree of granularity. Again, it won't hit every use case, but it's a far sight better than what you describe. docs.aws.amazon.com/apigateway/latest/developerguide/… – Paul May 12 '17 at 20:31
  • Thanks for the answer. I'm not sure if I understand your point about consolidation of queries, ie. how it translates to a real life use case. Fair point about authorization - yes, my understanding is going by this implementation, it's the mobile app that bears the responsibility of "knowing" who's using it and thus which operations on the cloud db are valid, and it can't rely on the backend to prevent eg. messing another user's data. If that's what you meant – Salvatore Turati May 14 '17 at 19:09
  • @SalvatoreTurati When you consolidate multiple accesses to different services in your cloud provider from within the cloud, you typically are not charged for the bytes transferred, but you are when it leaves the cloud provider's domain. Further, the connection between the different services is typically much faster within the provider than it is from without. – Berin Loritsch May 16 '17 at 12:17
1

When using for example firebase as backend for your app you have to rely on the underlying API/functionality not to change. As you are not the one actually running the backend you cannot 'freeze' a certain status, but you have to follow possible changes in the future e.g. by implementing updated method calls in your app etc., which of course costs some time and therefore money.

The benefit (=resources you save) of using such a out-of-the-box solution in this way requires some investment (=resources you have to spend) over the lifetime of your product to keep it up to the pace of the development of the third party you rely on.

So IMHO it's not really a technical question, it's more a economical trade-off.

  • That's a good point, although I imagine AWS, Firebase etc. surely at least avoid breaking backwards compatibility, or else these services wouldn't be reliable at all (?) – Salvatore Turati May 14 '17 at 19:11
0

Its not clear exactly what you mean.

If you have a cloud database eg amazon RDS its unlikely that your app will connect to it directly. You'll want a 'custom' API of some sort in front of it (which can also be 'in the cloud') But the work involved could be minimal. On the same order as setting up the RDS instance in the first place.

A simpler, in terms of external dependencies solution might be to use the app store of your choice's in app purchase model to buy 'subscription' products. Which your app could then apply business logic to in order to limit its functionality.

  • "If you have a cloud database eg amazon RDS its unlikely that your app will connect to it directly" - why not? They seem to provide SDK that takes care of that: docs.aws.amazon.com/mobile/sdkforandroid/developerguide/… – Salvatore Turati May 14 '17 at 19:05
  • the issue isnt the lack of client but the lack of row level permission options in most dbs. Now it seems that you can do it for dynamoDb!! with the new fine grained access controls. But RDS is not dynamoDB and even the fine grained control is not as fine grained as you would normally want on an api – Ewan May 14 '17 at 21:52
  • indeed, thinking about your specfic case. do you think it would be possible to limit users access in such a way that they would be unable to create fake points? – Ewan May 14 '17 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.