Currently, I'm developing a native application using React-Native. I've decided to go with AWS Amplify because of it's real time updates as well as its authentication.
I also have a Web Application that runs on a Node.js with Epxress server. This web application connects to a Mongo database.
My big problem is that I would like to have all of my aws amplify queries run to my existing MongoDb instead of a new dynamoDb database which is provided with AWS AppSync, but unfortunately I dont know where to start. This is especially helpful in adding authentication easily in my existing web application as well.
My first idea was to just create all my API endpoints in a new node js server and have app sync call to these API end points, but I'm not sure how to implement calling end points on an existing server (and this seems kind of counter intuitive to the 'serverless' idea)
My other idea came from this: Can AWS App-Sync be used without dynamoDB
This states to use AWS Lambda to 'pipeline' my data to the existing mongodb, but I'm not really sure what that entails.
TL;DR - I would like to be able to query an existing Mongodb instead of using DynamoDb when using AWS Amplify with AppSync.
I hope this is clear enough and doesn't sound like I'm rambling. Thanks in advance!
I would suggest using either an HTTP datasource to connect to your MongoDB backend or a Lambda function. Here are a couple getting started tutorials for both:
https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-http-resolvers.html
https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-lambda-resolvers.html
If you go the Lambda route, then you can leverage the new #function feature of the GraphQL Transformer in the Amplify CLI: https://aws-amplify.github.io/docs/cli/graphql#function
Related
I'm trying to connect next.js app to mongodb via mongoose in _middeware file(./pages/_middleware.ts )
But I get this error on incoming requests:
error - (middleware)\node_modules\mongoose\dist\browser.umd.js (1242:0) #
ReferenceError: regeneratorRuntime is not defined
How can I fix it?
+1 I have the same issue when trying to use in the middleware the instance created for mongoose so I don't have to connect it every time I make a request... but it seems this might not be supported yet.
It appears that it is not possible to use node api calls inside of NextJS middleware as this middleware is executed in the Edge runtime. Mongoose is a Node.js api, hence why is doesn't work.
Edge and Node.js Runtimes
I am new to Flutter and Couchbase, trying to connect to a sample bucket travel-sample using fluttercouch plugin, but getting error "unable to set target endpoint to ws//10.0.2.2:8091/travel-sample" for setting endpoint as ws//10.0.2.2:8091/travel-sample. Could some one explain to me what will be the endpoint for me and are there any changes needed else where. I am trying to test the server on the master repository of fluttercouch plugin. Here is the main.dart and bucket overview.
Couchbase Lite (the library underlying FlutterCouch implementation) cannot directly sync with Couchbase Server. A Couchbase Sync Gateway has to be deployed with the next instructions to allow syncing between the server and the mobile database:
"enable_shared_bucket_access": true,
"import_docs": "continuous",
You can find further documentation about Couchbase Sync Gateway in the Couchbase Documentation.
The primary point of confusion is you're trying to connect your fluttercouch plugin directly to Couchbase Server, and it's designed for Couchbase Lite, which is what runs on on a mobile device. I don't have enough experience with flutter to tell you what that endpoint should be, but it looks like you're targeting the wrong thing at the moment.
How can KeystoneJS be used to implement multi-tenancy? Is it possible at all?
Example use case: A company is creating a new blog platform using KeystoneJS and it wants to allow for multiple blog sites using the same models from one KeystoneJS instance but each blogger should only be able to control their own site.
Keystonejs does not really support this. Something that you could do, however, is to use something like Docker with an image of the Keystonejs website, then add some configuration to give each instance a different db path.
Or Spring up multiple Node Servers, something like this:
// Keystone 1
process.env.PORT=3000
// Keystone 2
process.env.PORT=3001
// ...
and Spring up one MongoDB server, and assign a unique database name to each node server / keystone instance, like
// Keystone 1: .env
MONGO_URI=mongodb://localhost:27017/KT_1
// Keystone 2: .env
MONGO_URI=mongodb://localhost:27017/KT_2
More info, check out Connection String URI Format[mongodb]
I like only use docker to spring up a MongoDB server and run Keystone locally since Docker works quite tricky with node.js.
When Spark is deployed in YARN cluster mode, how should I issue the Spark monitoring REST API calls http://spark.apache.org/docs/latest/monitoring.html ?
Does YARN have an API that takes the REST call for example (I already know the app-id)
http://localhost:4040/api/v1/applications/[app-id]/jobs
, proxies it to the correct driver port, and returns the JSON back to me? By "me" I mean my client.
Assume (or already by design) I cannot directly talk to the driver machine due to security reasons.
pls have a look at spark docs
- REST API
Yes with the latest api its available.
By this article
It turns out there is a third surprisingly easy option which is not documented. Spark has a hidden REST API which handles application submission, status checking and cancellation.
In addition to viewing the metrics in the UI, they are also available as JSON. This gives developers an easy way to create new visualizations and monitoring tools for Spark. The JSON is available for both running applications, and in the history server. The endpoints are mounted at /api/v1. Eg., for the history server, they would typically be accessible at http://:18080/api/v1, and for a running application, at http://localhost:4040/api/v1.
These are the other options available..
Livy jobserver
Submit Spark jobs remotely to an Apache Spark cluster Linux using Livy
Other options include
Triggering spark jobs with REST
This is what worked for me,
In yarn resource manager UI, click on link of the "application manager" for the running application and note the URL that it directs to
For me the link was something like
http://RM:20888/proxy/application_1547506848892_0002/
Append "api/v1/applications/application_1547506848892_0002" to the URL for the api.
For above case the api url is
curl "http://RM:20888/proxy/application_1547506848892_0002/api/v1/applications/application_1547506848892_0002"
Normally, Node-RED flows are stored somewhere in the filesystem, in a file named flows_XXX.json.
When running Node-RED on Bluemix where are they stored?
This could be important if your node instance doesn't start anymore.
A Node-RED instance on Bluemix when created from the Node-RED boilerplate always comes with a Cloudant database service connected.
Open the Cloudant dashboard
Open the database nodered
Open the document <app_name>/flow (Use the edit icon to open it)
You can now copy all the flows from this Node-RED instance.
Simply remove this part from the beginning:
{
"_id": "HUe-IoT-RED/flow",
"_rev": "6-3813d11089aa3e3adb9e704d4251bcdd",
"flow":
and the tailing }
Everything between the [ ] are the flows. They can be imported into another Node-RED instance.
More info on Node-RED website and Node-RED GitHub repo
For the boilerplate install all data including flows is persisted to the bound cloudant database.
Details can be found in the node-red-bluemix repo - https://github.com/node-red/node-red-bluemix
As described by Harald in a previous answer once you create an instance of nodered boilerplate it is bound to a cloudant nosql instance for data, instead of the classic json file: this because a file on the filesystem would be reset as soon as your application restarts, while a db service persists.
So if you wish to retrieve your application flows once it isn't able to start anymore, you have to access the cloudant nosql dashboard and extract the data locally.
Generally when the node-red instance doesn't start anymore (if something is changed, etc.), you can 're-push' the starter - code on your old bugged application. So, the app is 'resetted' as the first time, but you don't lose the flows, cause they are stored in a Cloudant DB.