I'm building my first app which uses an external database for storing data..
And I'm struggling with the following question:
How to connect with my database: use the Amazon DynamoDB sdk for Android or create a restful api based on NodeJS on my own server, which passes the data to DynamoDB?
I'm very new to this and when I look over the internet I see amazon suggesting to use the SDK.
The only problem is, if I want to change the data structure in the feature, what kind of problems will my users experience with the current versions of the app? And is it safe to save my Amazon keys inside the app (cause people may be able to decompile the app)?
On the other hand, I do have to pay for the extra server which handles the connections between my app and DynamoDB. So... is it worth it?
So I'm quite struggling with this.... What do you guys think?
I would go for direct access from your mobile application to DynamoDB.
This would allow you to scale your application much easier : you do not need to maintain, operate, secure a middle layer, AWS does that for you. You will also save on the cost of running your couple of NodeJS servers, load balancers etc ...
You should not store access keys / secret keys in your application but rather use AWS Cognito Identity service to dynamically receive access keys and secret keys for your user session. These keys will be limited in scope to whatever permission you define for your Cognito users and limited in time (default is 15 min)
Cognito works with backend identity providers to authenticate your users (Facebook, Google, Amazon, openID connect or your own backend) and can also work with unauthenticated users.
More about Cognito : http://aws.amazon.com/cognito/
More about Cognito ID for Android Mobile Applications :http://docs.aws.amazon.com/mobile/sdkforandroid/developerguide/cognito-auth.html
I'm not sure that the accepted answer is complete because it does not acknowledge use cases, and it does not address the question asked of "what if I want to change the data structure." Well, if you have outdated clients, and change the data structure of the documents in your nosql database, then those clients will not be able to access it. I don't believe DynamoDB offers a middleware platform to support this kind of old-to-new model adaptation. You'll have to force an update to your clients.
In fact, there are many operations beyond user-based permissions (which Cognito does do well) like this that you might need middleware for. Perhaps you want sorting logic to occur at request-time, and not maintain a copy of that sorting logic in every client application.
The question of "is it worth it" probably depends on the complexity of your application and your users' relationship with the data (ie. if the presentation layer basically just wrapped data -- then directly access DynamoDB. If you your presentation layer is not just wrapped data, then you should probably use custom middleware). In truth, I stumbled upon this question while running my own cost-benefit analysis, and am not sure which approach I will take. Another major factor of mine is that I might choose to switch database solutions in the future.. this will be more challenging to update on every client, if my clients are directly accessing the DB.
The one certain conclusion I've reached is that you should use middleware somewhere in your system, such that you can decouple your database vendor from either the client logic or the server logic as much as possible, eg. in a mobile app:
writeToDatabase(Data data){writeToDynamo(data);}
To achieve this, AWS suggests using Amazon Api Gateway as a proxy for AWS services, and even has premade configurations for Amazon API Gateway to behave as AWS service proxy.
Related
I am not clear with architecture of using Firebase for Android apps. Can you make everything from client side without using Cloud Functions, since it is possible to access database with functions in java. Is it used only for security purposes to restrict client from making problems?
Most functionality can indeed be performed directly from the client-side app, using the Firebase SDK for your application platform. And whenever this is possible, I highly recommend implementing it this way.
But certain types of functionality don't lend themselves well for performing directly from the client. They typically fall into these main categories:
The operation requires privileged information. For example if you want to send push notifications to your app users, you will need to specify the FCM server key. As its name implies, this key should only be used on a server you control, or in an otherwise trusted environment, such as Cloud Functions. This same reason also applies to things like interacting with payment gateways, and many APIs in the Google Cloud Platform that require server-side API keys.
The code of the operation itself is a privileged operation. For example you'll often find this in games, where you want to validate that the user isn't cheating. If you put this code in your app itself, a malicious user can see it and use it to circumvent your detection. By moving the code into Cloud Functions, the users of the app can't see the code anymore.
The code requires more "power" (CPU, network, memory, disk space, battery) than you can rely on being available on your user's devices. Since Cloud Functions run in Google data centers, they are always connected to mains power, they have a reliable CPU, a great network, and configurable memory/RAM disk space.
Another advantage is that Cloud Functions are the same for users on any platform that you target. Say you have a complex algorithm that you want the users on Android, iOS, and Web to use. If you implement the algorithm in Cloud Functions you only have to implement it once, and then call it from each platform, instead of having to implement the algorithm for each one.
I also recommend that you check out the list of use-cases in the Cloud Functions for Firebase documentation.
I have been searching for a proper answer to this question, have a bit of background in front end development, but with new concepts like SaaS, PaaS, etc. want to get information from experts out there, that could help any newbie to understand what it's all about.
Say I am trying to develop eBay like an app that takes a product from a user and sells it back to the other user who needs it.
Will my app need a backend server? If so why? I am already uploading my app to Google Play Store or Apple Store.
How will the backend server like HEROKU or FIREBASE or AWS help my app?
Can I implement two different services in single app, say for eg., firebase for backend database and HEROKU for payment processing?
Thanks again for your time and information.
SaaS
Answer: SaaS stands for "Software as a Service". In layman's terms, someone developed some software and hosted it somewhere. You can use that hosted software in your software project/product as a third party service (like public API); or directly use that as individual software under some license like Firebase as mentioned.
PaaS
Answer PaaS stands for "Platform as a Service". In layman's terms, someone configured some hardware and exposed the hardware controls via some web based application or REST APIs. You can use that hardware to deploy/run/manage your application without having the actual hardware on premises.
Backend Server
Answer First of all, let me explain the server. The server is a middle-man who serves whatever is requested of it, and all browsers/mobile apps act as client. So for example, the web is all about client-server communication.
So taking the example you mentioned, an eBay-like app takes a product from a user (client action) and puts it on the server (client requests in background for server to put product on server). Then another user opens the app (client action) and searches for the product (mobile client requests server to return that product, if valid and matching search criteria), and then he can buy it (mobile client will request server to complete the purchase).
You have to understand that for any communication between web application, mobile application or desktop application, there will always be a server. Even in file sharing applications like shareit, one mobile app works as server and same mobile app elsewhere works as client.
Yes, backend servers like Heroku or Firebase or AWS will help your app to complete your application business flow.
Yes, you can implement two different services in single app, say for example, Firebase for backend database and Heroku for payment processing or hosting your application/APIs.
Unless you are experienced with building distributed applications that can persist data across multiple nodes in a consistent manner, and ensure data available, I'd say you most definitely need some kind of backend. Unless of course you only plan to have user-to-user transactions, that can rely on direct messaging between client applications - which seems pretty pointless and quite far from the requirements of an EBAY-like product.
In terms of the architecture, you can follow many different approaches, but in most of them you will require some sort of data access layer. I'd recommend looking into the three-tier software design pattern (https://en.wikipedia.org/wiki/Multitier_architecture) to better understand the way this type of software product is typically designed.
After sorting out which type of data persistence you prefer, you'll need to setup the backend where your mobile app will connect to retrieve the data from (things like products being sold, user profiles and ratings, your own history). Of course you could also connect directly to the database from the app, but that would be a big mistake - it would meaning making the DB access publicly available, and thus exposed to attack, not to mention that you would be hard-pressed to find a solution for user registration and authentication, which would have to be provided by other means anyway. Typically your backend will also manage user registration and authorisation.
Heroku, Firebase and AWS are all very different, each with their strengths and weaknesses, but there's nothing like trying them out to see what fits best. What you refer to as "Google Server" and "Apple Server" sounds like a misconception, and you probably mean the Google Play Store and the Apple Store. These are not applicational servers that you can use as a backend, and serve only as a repository for your mobile app from where users can download it, and nothing else.
Without some sort of backend mechanism, the challenge of making data available for the consumption of multiple users would be overwhelming.
I know this isn't a very specific answer, but your question is quite broad-reaching, and it seems you need to look into some basic fundaments of software engineering before going into more detail.
I'm busy building an app for android. When it's properly received by Android users I would like to expand to iOS.
But, before we get there, I first want to make the right choice. So my question, what to do?:
writing all the logic inside the app and use Cognito (https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider) to access the data from DynamoDB
or let my app connect with my own API which handles the validation rules, which I then connect with DynamoDB database (don't know or API -> Cognito -> DynamoDB is a better solution, didn't really used it yet so...).
Now we all know about those issues where hackers built ways to bypass certain validation rules (as far as I read, most commonly by decompiling the app). I really want to avoid that!
So what do you experienced Android developers use? I know the answer seems obvious. But the reason I ask this is because I would like to avoid having my infrastructure, which I need to update etc. But to be able to register users, without the need of an third party which supports OpenID like twitter, facebook or Google, AND secure my validation rules, it seems like I have no choice. Or do I?
If you are targeting multiple platforms, it's usually best to conduct the majority of your business logic in an api outside of the app. It reduces code duplication and if validation is done at the api level, it limits the ability of malicious users to bypass validation rules.
With that said, running your own api doesn't necessarily require running your own infrastructure. Two AWS web services that could help are Amazon API Gateway and AWS Lambda. Registering your users can be done using Amazon Cognito Your User Pools.
Its driving me nuts,somebody pls help me out here.This google cloud stuff is confusing me.I m little bit off here,something is missing in my understanding.I want to use cloud storage.Now I have a default Android Studio Project which has an android client,an app engine backend,consisting of entity,endpoint,library for client etc and A WEB CLIENT.While going through the google cloud storage doc, I found the following-
Google APIs Client Libraries
Google Cloud Storage Client Library
Google Cloud Storage API
Google Cloud Storage JSON API Client Library for Java
I m still not sure what each one does actually.I dont know how to implement cloud storage in my android client.
If I use cloud storage why do I need app engine backend app? I dont need API for my backend,right? I can directly consume my bucket using Google Cloud Storage JSON API as we do using Volley. Am I missing something here?
Is there any "hello world" tutorial on how to use cloud storage from android client/app or can anyone help ?
If you're 100% sure that you don't need any back-end logic, and never, ever will, see Using Google Cloud Storage JSON api in android for direct Android <-> Google Cloud Storage operations.
Usually, in the course of a successful app's lifetime, some logic on the back-end is eventually required (e.g to deal with different versions of clients -- not all update in the same nanosecond:-), so it's normally more prudent and future-proof to have the front-end go to an App Engine back-end that can apply whatever logic is required besides providing access to Cloud Storage.
At version 0.1 the amount of logic required may be very small (though usually at least some kind of authentication) but if the application is successful likely new versions will be required and the back-end will be able to evolve to deal with that.
Then in a comment you ask:
As far as I have understood the appengine, if I need to store data in
NoSQL datastore, then I can make a backend with endpoint support which
will in turn consume my Restful API.
A more common arrangement is to have the back-end supply a restful API for the front-end to consume; and, that's what Cloud Endpoints can do for you (though you could design and implement that restful API in many other different ways, if you'd rather).
I mean, can I/should I consume the cloud storage rest API from within
my backend endpoint, which itself is used to call my own rest API?
One robust architecture is based on separation of concerns. Let the front-end running on Android concern itself essentially with the "human interface" part of your overall application -- presenting data clearly and usefully, interacting with the user.
The front-end can delegate just about every other concern to the back-end, including both storage and most aspects of app-specific logic concerned with what to store where, whether to allow access (of what kind -- read/write or read/only) to certain data depending on authentication of the user, and so on.
This delegation can take advantage of Cloud Endpoints, or, you could choose to design and implement it differently (e.g producing and consuming the app's REST API via different frameworks).
Why do I need backend logic to deal with different versions of
clients?
You'll need that, for example, if and when a new version of the client wants to store and retrieve more data than older versions did -- for example, in some future version you may decide it can be useful to add GPS location data, or optionally multiple photos or an audio snippet, etc, etc, which were not used in previous versions. (It's hard to be specific of course without any idea as to what your app is all about, but in general there's always something that you didn't do in early versions and want to add to some future one:-).
In such cases, the back-end needs to know what bits and pieces of data, exactly, to expect from the client, and conversely which ones to serve back to the client -- and those crucial aspects will then depend on the client's version; and without back-end logic to mediate, smooth seamless transition between old and new clients won't be feasible, particularly during the transitional period when some clients have upgraded to the newer version but others are still stuck on the old one.
I am in the process of developing an app with the help of someone else for a site I am developing. This app being developed will require access to the database on the web server. So my question here is typically I would want to keep my servers access limited to specific IP's however. Mobile devices all have there own ip's from what I hear. So if this is the case I essentially have to open up my database access to allow any inbound remote connection. Which is more than possible, but I forsee a potential security risk with that. namely in the notion of someone attempting to brute force the DB to gain root access or something to the effect there of. With that my question comes down to is there a more secure way of doing what I need in the overall? Is there any methods I can apply that would allow me a little more peace of mind. The DB I am currently using is mySQL, and will generally remain that type til later in the future.
Your concerns about security risks are valid. You should avoid a situation where countless mobile apps are making database connections to your MySQL database. A better solution would be to host a REST API layer in front of the database. This would allow you to control what portions of your database are accessed, but potentially include authentication routines as well. The REST web services you publish will give you the opportunity to produce permitted representations of your data rather than raw access to the data. That means in addition to producing web services, you'll need to develop the app to be a REST client that consumes these services or makes "requests" to them on an as needed basis. Obviously, this requires planning on both sides of development (back-end and front-end).
One possible solution to consider for producing REST web services is here:
http://phprestsql.sourceforge.net/
There are additional frameworks available for PHP, Java, ASP.NET and other platforms.
http://peej.github.com/tonic/
http://jersey.java.net/
Good luck!
Why not access the database via an API and then secure the API? So in essence, you should have a REST(or anything) API on your web server which your mobile application talks to which subsequently talks to the database. Accessing and securing your API will make a more cleaner and leaner design.