I just want to avoid use of custom/manual resolvers in appsync completely. So I'm using Amplify to setup GraphQL appsync API in my app. I'm doing all the stuffs by changing schema.graphql and amplify push.
I have 2 questions :
1. What are the limitations and what problems I'm going to face in future?
2. Can graphql subscriptions get update when app is not running(like user should be notified)?
tons of business logic will be exposed on the client side code.
I think for push notifications you would still have to go via external integrations like FCM/APNS. Multiple integration options are available in SNS
Just to preamble these answers, the fact that you use an amplify generated graphQL and resolvers doesn't stop you from later including custom resolvers and pipeline functions - it's just that you need to learn quite a bit about where to include them in the backend file structure of amplify.
1. What are the limitations and what problems I'm going to face in future?
This depends on how well your applications use-case matches the graphQL schema design and if your application is relatively self-contained. Amplify becomes more complex when your application needs to talk to other back-end systems, you'll need to start using DynamoDB triggers to notify other state machines/event bridge/SNS or similar services.
As mentioned none of these problems are crippling, you can deal with them later but it will be a step up in the AWS knowledge required to implement them.
For small high-volume/availability apps Amplify and DynamoDB as-it-comes is great. If your application matures into many micro-services and sites then you'll need to learn quite a bit more AWS to make them play together well. Amplify does determine your DynamoDB on a table per object basis and you'll probably be stuck with (paying for) that. Think hard about if you ever might want to go to a different optimised data source (RDS or single dynamo table) to reduce the number of queries required to fulfil your graphQL requests.
2. Can graphql subscriptions get update when app is not running(like user should be notified)?
No. Anurag mentions SNS which would be a good option to out-app notify users, best to blend subscriptions and another service.
Related
In our project we are using 2 regions (Oregon, N.virginia) one for Production and other for DR(Disaster recovery) site, we have the same Rest APIs over both regions, but the overhead arives when we have any update for the APIs we need to update on both sites.
Is there any method for synchronizing both APIs in different regions.
Currently, We are exporting the Rest APIs in JSON format and importing to other region on a timely basis.
I want to know if there any way to automate this process or other way for syncing both APIs.
My first thought is to write a script of CLI commands to do this whole export and import procedure. That way you minimize manual work and standardize it. I will encounter this same problem in production after a awhile.
I have two seprate apps each has seprate AWS cognito userpool appsync api but has shared dynamodb. I want to create subscription for chat feature where app 1 (client app) and app 2 (admin app) will communicate. Is it possible please advise.
I have followed this article from aws:
enter link description here
need advise how would that work in my case with two different apps.
I think you first need to take a step back and separate the problem from the technology. You want to create a chat app, how would you build this? Do you need a data store or a queue? First think in abstractions then look what technology fits those abstractions best. If you start with the technology first you will most likely end up with a sub-par solution.
If you really want to go for the technology first approach you could think of storing chats in DynamoDB(DDB) and using DDB streams to update the subscription. It can work but it will most likely be expensive.
I've enjoyed working with AWS Amplify a lot lately, its code generation for GraphQL queries based on defined schema is outstanding.
I came across one complication for defining custom logic / validation server-side. Out of the bag AppSync (part responsible for GraphQL api in Amplify) generates resolvers and DynamoDB tables for your schema. Resolvers are created using Apache Velocity templating language and if you are new to it, its a bit of a learning curve in my opinion.
Furthermore, these resolvers are auto generated by Amplify cli. I'm not sure if editing them makes sense either in AppSync console or locally, as every time we push api changes they will be auto generated again?
To add to this, these resolvers that are auto generated actually achieve a lot in terms of linking type models together, enabling search and authentication checks, I really don't want to touch them since development velocity enabled by automatic generation is insane.
Hence only other solution to introduce my custom logic seems to be Lambda functions that listen for create / update events of associated DynamoDB tables.
I think I can set this up in a way thats demonstrated below, essentially allowing users to use GraphQL api normally and when action that requires server validation is made react to it in lambda?
For example player adds item to their inventory, we fire lambda function to check if player had this item before, if not it was purchased, we validate item data and subtract gold of its cost from player table. I think this works fine but my concerns are
We allow to write unvalidated data to database first (although it is validated by graphql type system and auth check prior.)
Additional costs for involving Lambda (in my opinion worth it for time saving and ability to use NodeJS instead of Apache Velocity to define language)
Am I missing something else?
So lambda will do validation behind the scenes, we assume majority of users are good actors here and data they pass to GraphQL api is correct since they use our client.
In case data is unexpected (bad actor) lambda will react and ban the user.
Is this solution viable / common, is there other alternative?
I'm new to AWS, so apologies in advance if this question is missing some important considerations, or has incorrect assumptions.
But basically I want to implement a service on AWS to store and retrieve data from multiple clients, which may be Android apps, Windows applications, websites etc. The way I've considered doing this is via a RESTful service using API Gateway front end, with a Lambda back end and maybe an S3 bucket to hold the data.
The basic requirements are:
(1) Clients can publish data to the server, where it is stored, perhaps with some kind of key/value structure.
(2) Clients can retrieve said data by key.
(3) If it is possible, clients to be able to subscribe to events from the service, so that they are notified if the value of a piece of data changes. This would avoid the need to poll the service, which would presumably start racking up unnecessary charges if the data doesn't change often.
Any pointers on how to get started with this welcome!
Creating a RESTful API on top of Lambda and API Gateway is one of the main use cases for this architecture. You can think of Lambda functions as controllers with methods and API Gateway as a router that forwards requests to functions based on the URL pattern. There are many frameworks and approaches that can help out here if you don't want to write from scratch:
Lambdasync
https://medium.com/#fredrikanderzon/create-a-rest-api-on-aws-lambda-using-lambdasync-e46c68f8043f
Serverless
https://serverless.com/framework/docs/providers/aws/events/apigateway/
Swagger
https://cloudonaut.io/create-a-serverless-restful-api-with-api-gateway-swagger-lambda-and-dynamodb/
As far as event subscriptions go (requirement #3) you can model this in many datastores, certainly in a relational/SQL database, with a table like this:
Subscription (key_of_interest, user_id, events_of_interest)
I'm leaving out data types for you to figure out, but you get the idea hopefully. After each data modification on a particular key, see if that key is of interest in the subscription table, then wire up a response to the user's who indicated interest. The details of this of course depend on your particular requirements. A caution though: this approach will increase the cost of data modifications because of the additional overhead needed to process subscriptions.
EDIT: One other thing I forgot. S3 is better suited for non-structured data (think 'files'). For relational databases, checkout RDS. For a simple NoSQL database you might use DynamoDB, or host your own NoSQL database of choice on an EC2 instance.
I've just started messing around with AWS DynamoDB in my iOS app and I have a few questions.
Currently, I have my app communicating directly to my DynamoDB database. I've been reading around lately and people are saying this isn't the proper way to go about getting data from my database.
By this I mean is I just have a function in my code querying my Dynamo database and returning the result.
How I do it works but is there a better way I should be going about this?
Amazon DynamoDB itself is a highly-scalable service and standing up another server in front of it requires scaling the service also in line with the RCU/WCU configured for your tables, which we can and should avoid.
If your mobile application doesn't need a backend server and you can perform all the business functions from the mobile device, then you should probably think about
Using the AWS DynamoDB SDK for iOS devices to write your client application that runs on the mobile device
Use AWS Token Vending Machine to authenticate your mobile users to grant them credentials to be used to run operations on DynamoDB tables.
Control access (i.e what operations should be allowed on tables etc.,) using IAM policies.
HTH.
From what you say, I can guess that you are talking about a way you can distribute data to many clients (ios apps).
There are few integration patterns (a very good book on this: Enterprise Integration Patterns), one of which is called shared database. It is essentially about using a common database for multiple clients to share the data. Main drawback for that pattern (in your case) is that you are doing assumption about how the database schema looks like. It can potentially bring you some headache supporting the schema in the future, if your business logic changes.
The more advanced approach would be sending events on every change in your data instead of directly writing changes to the database from client apps. This way you can add additional processing to the events before the data they carry is written to the database. For example, you may want to change the event format in the new version of your app, but still want to support legacy users, so you add translation procedure which transforms both types of events to the format which fits the database schema. It's basically a question of whether to work with diffs vs snapshots.
You should be aware of added complexity of working with events, and it can be an overkill if your app is simple and changes in schema are unlikely.
Also consider that you can do data preprocessing using DynamoDB Streams, which gives you some advantages of using events still keeping it simple to implement.