As of now, there are at least 5 packages for the AWS SDK as it pertains to Cognito.
Custom built via multiple mechanisms: https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/building-sdk-for-browsers.html
https://github.com/aws/amazon-cognito-identity-js
https://github.com/aws/amazon-cognito-auth-js
https://github.com/aws/amazon-cognito-js
The global SDK https://github.com/aws/aws-sdk-js
Some of them overlap in terms of methods. Many are only slightly different. The docs and links vary from outdated to flat out incorrect.
Most docs are in ES5, some in ES6, some in TypeScript, some in Node.
How are developers supposed to know how to make heads or tails from these?
I work with Cognito everyday as a developer. I recommend starting with the AWS JavaScript SDK (the full SDK). Everything that you need for Cognito development is there and is always the latest. Once you know the details for Cognito, take a look at the higher level packages. By that time you will probably have written your own library of code and then won't consider the others.
The problem with Cognito development is that unless you stay with the core SDK, the other packages either don't exist or are not compatible with SDKs for other platforms or for other languages such as PHP or Java.
Depending on your goals / requirements, you may need to support mobile, desktop, server, Lambda, etc. If you stay with the core SDK then you can quickly adapt to each environment. If you use a higher level package that only works, for example with node.js, then you have a porting problem.
[EDIT]
One item that I forgot to mention is that Cognito is really three different services and therefore three different sections (classes, etc.) within the SDK. There is Cognito User Pools, Cognito Federated Identities and Cognito Sync. Some of the higher level SDKs only support one or the other or just parts of one to make interfaces easier (or more intuitive).
Related
I'm working on a project centered around API Change Management. I'm curious as to how AWS informs developers of changes to its APIs. Is it through the document history (https://docs.aws.amazon.com/apigateway/latest/developerguide/history.html)? Or do they send out emails to developers?
Regarding emails, are emails sent to all developers using the API (ex. API Gateway) or just developers using a particular endpoint and will be affected by the change? What is the frequency of notifications - breaking changes, minor changes, etc.
Thanks so much for your help!
For non-breaking changes, you can learn about them on the Developer Guide as you pointed out. Some of these changes are also announced on their What's New page (RSS feed). You can also follow the SDK releases which are updated often (e.g. by using the RSS feed for aws-sdk-go releases). I believe that most of the SDKs are using code generation to generate a lot of the API functionality. They push updates to these files in the SDK git repositories (ruby example, go example), but it is not clear if there is another place to find these files. It doesn't seem like they want us to consume these directly (see this developer forum thread from 2015). There's also awsapichanges.info, which appears to be built by AWS themselves.
AWS very rarely makes breaking changes to their API. Even SimpleDB, which is a very old AWS product, still works.
Having said that, they do make breaking changes from time to time, but they try to announce them well ahead of time. The biggest breaking change that they are trying to complete is probably their attempt to deprecate S3 path-style access. This was first quietly announced in their AWS Developer Forums, which caused a lot panic especially since the timeline was incredibly short. Based on the panic, AWS quickly backtracked and revised the plan, more publicly this time.
They have done some other S3 breaking changes in other ways. For example, S3 buckets must now have DNS-compliant names. This was only recently (March 1, 2018) enforced on new buckets in us-east-1, but for most other regions this was enforced from the start when the regions were made available. Old S3 buckets in us-east-1 may still have names that are not DNS-compliant.
Lambda is removing old runtimes once the version of the programming language stops being maintained (such as Python 2.7). This should be a known expectation for anyone who starts using the service, and there is always a new version that you can migrate to. AWS sends you email reminders if you still have Lambda functions that is using the old runtime, when the deadline nears.
Here is a GitHub repository where people try to track breaking changes: https://github.com/SummitRoute/aws_breaking_changes. You can see that the list is not that long.
Can we deploy QlikSense/QlikView on serverless architecture?
Currently using Monolithic architecture, any other way to move on to serverless?
While I am not familiar with Qlik's products, it is unlikely they would be suitable for serverless architecture.
Companies generally offer the products either as:
Downloadable products that you run on your own server (which could be a virtual server in the cloud), or
Software-as-a-Service, where you access their website directly and no server is required (eg Salesforce)
"Serverless architecture" is a design decision that can be made when designing a software product. It means the the application is broken-down into small components ('microservices') that can be run on services like AWS Lambda, with no actual server.
However, such architecture would normally only be used for your own applications that you create. If another company has designed their system to be 'serverless', then they would normally run it on a cloud system (eg AWS) and offer it to users as Software-as-a-Service. It would be highly unusual to have a 'download' product that runs on a serverless architecture.
I notice that Qlik has product offerings that run on AWS (AWS Marketplace: Qlik), which runs on an Amazon EC2 instance, rather than serverless.
If you look into the Qlik Core product then yes Qlik can be deployed on an elastic containerised enviroment. But then as I understand it you don't get the standard objects and visualisations, user management etc. So you have to code your own stuff that ties into the Qlik Data Analytics Engine via apis.
From https://core.qlik.com/why-qlik-core/
So, how do you get it? Licensing info here but let’s talk components
Linux-based Associative Engine – provided as a Docker image with built-in support for Amazon Web Services, Microsoft Azure and Google Cloud Platform
Supporting APIs – these ingest your data into the Qlik Associative Engine through connectors
Supporting Open Source Libraries – these various libraries by Qlik expose the engine to help you build solutions faster
It’s all language agnostic but JavaScript lovers will find it easier to work with given the number of our open source tools available in JavaScript. Other top languages and tools used include R, Go, Shell, C#, Python, Java and D3. Qlik Core can also be managed with the orchestration tool of your choice for implementing, scaling and managing containerized applications.
It really depends on what exactly are you building. As The Budac mentioned you can use Qlik Core
If you just want invoke Qlik API (for example some automation jobs) then serverless functions are making sense.
Qlik Sense (both Enterprise and Kubernetes versions) expose a lot more different API which can be called from technically everywhere.
QlikView on the other hand is more ... conservative. QV is an older software and the API/integrations are more limited. For example: to call the Management API you have to be on the same domain as QV. Personally I've only connected to QV Management API only with C# and pretty sure you cant use JS/Node
I like fast code execution (because of that I switched from Python to Go) and I do not like dependencies. Amazon recommends using SDK for simpler authentication (but in Lambda I can get tokens from IAM from environment variables) and because of built into SDK retry on errors (few lines of code, as I think). Yes it is faster to write my code using SDK, but what additional caveats about using pure HTTP API instead of SDK? Am I too crazy about milliseconds? Such optimizations worth it?
Anything you do with AWS is the result of an API call, whether executed by CLI, Web console, or SDK.
The SDKs make it easier to interact with those APIs. While you may be able to come up with some minor improvements for some calls, overall you will spend a lot of time doing it to very little benefit.
I think the stated focus on performance belies real trade-offs.
Consider that someone will have to maintain your code -- if you use an API, the test area is small, but AWS APIs might change or be deprecated; if you an SDK, next programmer will plug in new SDK version and hope that it works, but if it doesn't they'd be bogged down by sheer weight of the SDK.
Likewise, imagine someone needs to do a security review of this app, or to introduce something not yet covered by SDK (let's imagine propagating accounting group from caller role to underlying storage).
I don't think there is a clear answer.
Here are my suggestions:
keep it consistent -- either API or SDK (within given app)
consider the bigger picture (how many apps do you plan to write?)
don't be afraid to switch to the other approach later
I've had to decide on something similar in the past, with Docker (much nicer APIs and SDKs/libs). Here's how it played out:
For testing, we ended up using beta version of Docker Python bindings: prod version was not enough, and bindings (your SDK) were overall pretty good and clear.
For log scraping, I used HTTP calls (your API), "because performance", in reality comparative mental load using API vs SDK, and because bindings (SDK) did not support asyncio.
AWS provides SDK only for some languages. How could I integrate AWS services in an application for which an official SDK is not provided. Eg C of Scala or Rust? I know that for Scala, some aws sdk projects are available but as they are individual contributions (and not aws releases), I am reluctant to use them.
All the SDKs do is wrap some minimal interface around the API calls made to the AWS servers. For any service you wish to integrate into your application, just head over to their API documentation, and write your own codes/wrappers.
For eg. this link takes you to the API reference for EC2 service.
In the early days of AWS, we needed an SDK for C++. At that time an SDK for C++ did not exist, so I wrote one based upon the REST API. This is no easy task as the Amazon API is huge and by the time you complete coding for one service, you have to go back and update with all of the AWS feature improvements and changes. This seems like a never ending loop.
Several of the AWS SDKs were started by third party developers and then contributed to Amazon as open source projects. If you have a popular language that you feel that others could benefit from, start an open source project and get everyone involved. It could become an official project if there is enough demand. Ping me if you do as I might be interested in contributing.
I'm building an Alexa skill that will allow Alexa users to interact with a consumer facing e-commerce site. There is functionality to call a representative that already exists on the site. Now, I want to build out a voice app as a side project that extends that same option via a conversation. There will be a need for slots like location, category of call, etc. It's basically an Application/Transactional bot.
In the future, if this is successful, I'd like that same general app to be accessible on different IoT devices (like Google Home Assistant, etc.) Therefore, I'd like to abstract out the voice interactions and have the same (general) flow and API to interact with.
This leaves me doing some research on different technologies like api.ai, wit.ai, Lex, etc.
But, since this is an app for Alexa and I already rely on AWS and Amazon in general, I think I'd prefer to use Lex or just write a native Alexa app for now.
I'm having a hard time understanding the differences between the two. I understand that Alexa was built using Lex and I see that they have similar concepts like intent, slots, etc.
But, I'm looking for any differences between the two services:
Would using Lex allow me to more easily integrate with other devices? Or is there any benefit?
Would using Lex allow me greater flexibility in designing/modifying the flow of a conversation? It seems like Lex is a little more complex and, therefore, might allow greater functionality.
Or is it just that Lex offers nearly the exact same functionality and is just meant for devices that aren't Alexa?
Does Lex offer any more analytics processing than Alexa? In Alexa I can only see intents/slots, but if I could see the actual text in Lex, that would be ideal.
Alexa Skills Kit (ASK) is used to build skills for use in the Alexa ecosystem and devices and lets developers take advantage of all Alexa capabilities such as the Smart Home and Flash Briefing API, streaming audio and rich GUI experiences. Amazon Lex bots support both voice and text and can be deployed across mobile and messaging platforms.
Lex Faqs
In my view (very limited Alexa dev experience) AWS Lex allows greater control over the bot dialog. It defines separate validation and fulfilment code hooks, enables specific prompts for slots on the UI, supports programmatic transitions between intents, gives proper versioning and alias handling, etc... so it seems it's more of an enterprise offering as opposed to "consumer-level" Alexa skills.
But surprisingly it lacks a few important features, e.g. it does not have a built in "boolean" slot type, so you have to code around yes/no questions. Or there are no Cloudwatch logs for lex at all. Also the (growing) list of integrations will make it more generic.
But despite being a huge AWS fan, I have to say that api.ai seems to be a reasonably more polished, feature rich proposition at least for now.
With regards to integrations with other devices, I do not think any of these platforms promise that. It seems that if you target Google home, than it's their platform, if you target Alexa, then hmm it's alexa or api.ai (not sure if Google will push this in the future). But if you plan to integrate with chat platforms, or directly into web applications, then I think all major platforms can give you that, or in the near future.
By the way, have you checked IBM Watson or Microsoft Bot framework (with LUIS)? They are also very capable, complete frameworks, too, don't discount them!
There is a risk using an external NLP service to process raw text delivered by Alexa over its native hobbled interaction model. Amazon may not certify your skill. This is unfortunate to hear, but their excuse is the threat of exposing private user data users may not realize they're sending. This is sickening because to do anything robust you must avoid Alexa's native NLP system. And I don't believe LEX is advanced much beyond it. You're caught in a bind. This is what will set Alexa back perhaps in the long run with respect to natural conversation. We've been preparing our skis in stealth mode, and an Amazon rep said our approach was a "hack" and may not get certification when published. I'm not yet sure what the answer is. Does this raw text issue exist with Google Home or other voice platforms? Beware.
"Alexa for Business is intended to enable organizations to take advantage of Amazon’s voice enabled assistant, Alexa. Alexa for Business provides Alexa capabilities that make workers more productive, while working alongside all of the other capabilities that Alexa has today like music, smart home controls, shopping, and thousands of third party skills.
Amazon Lex is intended to help build custom conversational interfaces and chat bots for use cases like call centers or application based bots. Bots built with Lex can be highly customized and exist separately from Alexa but they do not take advantage of Alexa’s built in capabilities or third party skills. Both Alexa for Business and Amazon Lex use Amazon’s deep learning capabilities that provide Automatic Speech Recognition (ASR) and Natural Language Understanding (NLU)."