Can anyone please tell me what is the difference between:
aws-sdk/clients/appsync, and aws-appsync
According to the doc, aws-sdk/clients/appsync is used because just including aws-sdk is too large when we just need appsync, we use aws-sdk/clients/appsync.
However, aws-appsync seems also doing the same thing. When I create a client using aws-sdk/clients/appsync, there is no hydrated() function while aws-appsync has.
So
Why can't we simplify everything by just using aws-sdk/clients/<any_aws_package> and break everything that did not use it?
What is the point of separating something that is similar?
Thank you very much in advance for all your help.
difference between: aws-sdk/clients/appsync, and aws-appsync
GraphQL originated at Facebook and the React/React Native apps used react-apollo to talk to the GraphQL based APIs.
AWS AppSync is the AWS offering for GraphQL. aws-sdk/clients/appsync is the JS SDK to invoke various AppSync management/control APIs (like create GraphQL API, create data source etc). Not sure if they also provided apis to consume the GraphQL based api.
aws-appsync is the way to consume AppSync backed GraphQL APIs. It plays well with react-apollo which is now moved to apollo-client.
There is another high level JS library from AWS Amplify, which is used to consume AppSync backed GraphQL APIs.
aws-sdk/clients/appsync is used because just including aws-sdk is too
large
The initial release of the aws-sdk (Github repo here) contained the clients for all the AWS services and more. You need to install aws-sdk and you can talk to pretty much all the AWS services by initialising the clients for them. Obvisously it was not so good in terms of packaging JS bundles, the library was also not very modular.
Now the latest version V3 (rewritten using TypeScript) which is GA now, moves the clients to individual npm packages i.e. you need to only install the client you need e.g. npm i #aws-sdk/client-appsync instead of npm i aws-sdk. Learn more about it here. If you are getting started use the V3 packages.
Why can't we simplify everything by just using
aws-sdk/clients/<any_aws_package> and break everything that did not
use it?
It is the case with the V3 JS SDK.
What is the point of separating something that is similar?
They are not similar. One is used to consume the GraphQL based APIs (provided by AppSync) and the other is to manage AppSync itself. The V3 packages follow this very strictly while the earlier versions may have some utility code/ high level abstractions along with the core AWS apis.
Related
I'm working on a project in my University, and we want to use an Apache OpenWhisk service for our student projects. I already set up the OpenWhisk service and add some components like Java, NodeJS and Python, everything works fine. My next step is to set up a webserver, so our students can use this instances to publish their websites (written in HTML, PHP, Java Script). I have already searched for this topic but don't found anything.
Hopefully someone can help me.
There are several ways to accomplish this and it depends on how far you want to go in the serverless direction.
For example this repo https://github.com/jthomas/express_example is a way to package an existing web server inside a function. This is another variation on the same https://github.com/IBM/expressjs-openwhisk.
If you want the students to implement a serverless web application from scratch, then generally every API end point becomes a function using web actions https://github.com/apache/openwhisk/blob/master/docs/webactions.md.
You can use web actions to also serve static content (html, js, css) by inlining those files and returning them as part of the function result. This is not ideal and should be done from a CDN instead. OpenWhisk itself does not offer object storage/CDN support but you can use S3 or Google buckets to accomplish the same.
Some serverless platforms like Netlify or Nimbella might be suitable. The latter provides an integrated CDN + OpenWhisk to implement entire web applications including JAMstack.
I have a java codebase that seems to be using "com.google.api.services.cloudkms.v1.CloudKMS" to call KMS. The online docs says to use "com.google.cloud.kms.v1.KeyManagementServiceClient"
When i looked up both packages seem to be updated, however the reference docs recommend using the latter.
https://developers.google.com/resources/api-libraries/documentation/cloudkms/v1/java/latest/com/google/api/services/cloudkms/v1/CloudKMS.html
https://cloud.google.com/kms/docs/reference/libraries
Could someone tell me what is the difference between these 2 clients packages and if i should move to the one the reference links to?
In general, you should prefer the library referenced on the Reference Libraries page, currently com.google.cloud.kms. The examples and tutorials on the website will use this client library.
Probably more history than you need to know, but we have two client libraries because they run over different protocols. The new libraries (the one's listed on the reference page) use gRPC to communicate. This means less bandwidth and less time spent serializing/de-serializing JSON. On the flip side, gRPC requires HTTP/2, and some organizations can't/won't support HTTP/2 yet. As a result, we still publish and maintain legacy libraries that are REST over HTTP/1. It is strongly recommended you use the gRPC ones unless you can't use HTTP/2.
You can read more about the background and technical details in Kickstart your cryptography with new Cloud KMS client libraries and samples.
Is it possible to leverage the Amazon Web Services SDK for iOS in a server-side Swift app developed using the Perfect framework? I'd like to be able to deploy my Perfect app to AWS and make calls to DynamoDB, S3, etc. from the app. However, I haven't found any examples showing if that is even possible. Can the AWS SDK be used server-side, even though it says "for iOS"? Does it support the Swift Package Manager, which Perfect seems to use for integrating with 3rd party libraries? If not, does Perfect support CocoaPods for dependency management?
If what I'm attempting feasible, or would I have to write my own integration code using Amazon's RESTful services directly?
"Original" AWS library does not support Swift Package Manager in that moment, and also uses some Obj-c code (as far as I know), so you can't use it on linux. But there is feature suggestion, so maybe it would be there in future
Now you can use AWS services with that library: https://github.com/noppoMan/aws-sdk-swift though its a bit hacky :)
I use that one in my current projects and it's look like all the basic needs are implemented :)
As far as I know, you would probably using Perfect-CURL to perform such tasks; Perfect-MySQL supports RDS, however, you can easily add all SPM compatible 3rd party components as many as need, just edit Package.swift to include; a better idea is to user Perfect Assistant to safely import different components and quickly build / test & deploy to AWS EC2:
http://www.perfect.org/en/assistant/
About Perfect-CURL, there are many examples about Server Side Operations, such as
https://github.com/PerfectExamples/Perfect-Cloudinary-ImageUploader-Demo
which contains how to generate a digital signature in posting files,
also
https://github.com/PerfectServers/SlackBot
with curling API
I've just started on a small project to create some REST services using Google App Engine and Java. I'm new to both technologies, but I've done some reading on both. I'm familiar with SOAP (have used them previously), and I think I understand the conceptual differences between REST and SOAP.
Currently I need info regarding two things:
1) I'm trying to find some tutorial which builds a simple REST service from scratch for deploying on Google App Engine (GAE). The simpler the better, but it should have at least a few routing options. I don't need any UI, if that matters.
2) Which RESTful Framework should I use with Google App Engine. Again, simplicity is what I'd like, and something which has tutorials and a newcomer can easily grasp.
My ultimate goal is to just write a REST wrapper with multiple routing options, which eventual consumes some pre-existing SOAP services and returns their results.
Have you checked out Google Cloud Endpoints for creating a REST service? Its pretty simple and straightforward, also has support for OAuth.
I would give Jello framework a try. It offers a clean, and simple to follow, JSON format and provides a very powerful and comprehensive RESTful implementation that follows the OData specification.
Here is Jello's REST development guide: http://jello-framework.com/guide/rest.html
I have found some strategies for versioning REST APIs via SO and Google etc., but I have not found any strategies for versioning internal REST apis (and I mean by this, that I intend making a web app, an Android app etc that share a common REST api, but the general public will not get access to the API).
Seeing as the API is for internal use only, it would need less backwards compatibility, and basically a way of being 'current' and 'edge' or something similar. Any tips on a nice and simple strategy to version an internal REST api for minimal hassle would be great.
current is a very bad way to differentiate. If you have an application which carries out a call to /current/users, and then you upgrade your API so that /current/users returns different information, your application will break.
Stick with versioning. A simple /v1/users is clear and concise, and when you add /v2/users then the applications using the old API endpoint will continue to work and you can update them as and if you require.