I'm using flask/flask-sqlalchemy/flask-restx to build small micro-services; I'm using AWS Aurora with MySQL as database tech. Aurora conveniently provides separate read/write endpoints for the db and routes traffic/connections to either the master or to the read-replicas depending on what endpoint is used.
Is there a way to discriminate the session URL that is used by flask-sqlalchemy by configuring two database URLs in the app.config and using one or the other endpoint depending on whether the get method is used versus of the post, put and delete ones?
Related
I am building a serverless application using AWS, with AWS API, AWS Lambda functions, and AWS RDS (database).
I have an existing MySQL schema (basically, a table dump), and I want to create the API automatically from this schema, ideally something that I can easily import into AWS API Gateway (like something from SwaggerHub or similar service).
Then, I want to have the operations for the database (CRUD operations that match the API) also automatically generated for NodeJs or Python, which I can then easily deploy to AWS Lambda, for example using SAM templates, or maybe just uploaded as a package somehow to AWS.
The lambda operations should be able to connect to my AWS RDS database, and perform the CRUD operations described by the API.
The idea is to determine some way to simplify this process. If the database schema changes significantly, for example, I do not want to manually edit a bunch of lambda functions to accommodate the new DB schema every time!
I'm wondering if anyone has any suggestions as to how I could make this work.
I am trying to deploy my django app on aws lambda using zappa. However, when I try to login to the app I get attempt to write a readonly database.
My understanding is that this is because sqlite is an embedded database and you can't use embedded databases on lambda because they require write-access which is not possible on lambda and just generally not a good idea to try and persist data on lambda.
Is this correct? Is my only option to thus switch to using postgres or mysql or another server database?
If you need permanent storage, then yes, some flavor of RDS or Dynamodb or any other datastore you have access to would be more appropriate. Lambda by itself can't persist data between executions.
What are your suggestions for how I should creating maintenance/administration pages that allow me to add/modify/report on entries in my DynamoDB tables on AWS?
What I would like to do is to create web pages that are hosted in AWS S3 but allow me to script Dynamo DB access.
I'm trying to avoid setting up something like a LAMP stack on another host.
Without any backend code... JavaScript (or a derivative). Try the AWS SDK for JavaScript. Or, you can use API Gateway, Lambda and JavaScript. Either work with S3-only hosting. Lambda could hide some implementation details behind an API and you don’t need to worry about managing servers. More moving parts is the trade-off.
I would like to have a cluster of gateway in api manager. I saw the documents how to split the 4 components with mysql, I saw also the document explaining how to cluster the api gateway (Mgt / Worker) but I miss some information: Is it necessary that both clusters connect to the same database or each cluster can/must have is own database?
A image is better than words:
So what I would like to do is to have 1 KeyManager, 1 store and 1 publisher and 2 Gateways. SO when I publish 1 endpoint it is available on both gateways (I will use host file the specify hostnames instead of ip). I don't know if it is possible that kind of configuration.
Another possibility is to have a shared keyManager between both wso2 servers. When the user has his authorization key he can use both wso2 servers.
You should share databases among clusters. Basically there are 3 databases used. UserDB, registryDB, APImanager DB.
If you want to allow same users to login/publish APIs (for example) you must share UserDB among clusters. Same thing applies to other DBs too.
When you cluster the gateway you should consider following
if your are using muti-tenancy
then point all gateway nodes should be pointed to usermgt db and registry db
if no muti-tenancy
all gaetway nodes should be pointed to registry db(because there you will have tier.xml ,so when adding custom tier.xml it should be synced with all gateway nodes)
gateway doesn't use apimgt db , but you need to have the config of apimgt db which points to default h2 db,other wise you will get error when start the gateway node.
I'm building a mobile app that needs a backend that I've chosen to host using Amazon Web Services.
Their mobile SDKs provide APIs to work directly with the DynamoDB (making my app a thick client), including user authentication/authorization with their IAM service (which is what I'm going to use to track users). This makes it easy to say "user X wants their information. Here's their temporary access key. Oh, here's the information you requested."
However, if I used RDS as a backend database, I'd have to create web services (in PHP or Java/etc) that my app can talk to. Then I'd also have to implement the authentication/authorization myself within my web service (which I feel could get very messy). I'd also have to host the web service on an EC2 instance, as well as having the RDS instance. So my costs would increase.
The latter seems like it would be a lot of work, something which I could avoid by using DynamoDB (and its API) as my backend.
Am I correct in my reasoning here? Or is there an easy way to authenticate/authorize a PHP web service with an AWS RDS database?
I ask because I've only ever worked with relational databases before, so there would be a learning curve to get the NoSQL db running. Though hypothetically my plan is to eventually switch to a NoSQL db at some point in the future anyways due to my apps increasing demands.
Side note: I already have my database designed in MySQL.
There is no solution to use IAM directly with RDS because of the unavailability of fine-grained access control over RDS tables. Moreover IAM policies cannot be enforced dynamically (i.e. with an Identity Pool).
RDS is an unmanaged service, so it is not provided as a SaaS endpoint. DynamoDB is a REST service presented as a distributed key-value store and exposes endpoints to clients (AWS SDK is just a wrapper around them).
DynamoDB is born as a distributed service and can guarantee fine-grained control over data access, thus allowing concurrent access.