Using AWS QuickSight to Improve your Business
AllCode helped IBids.io integrate their application with AWS’ QuickSight suite to better improve its functionality with the use of data-driven customer analytics. Our engineers applied their knowledge in conjunction with their understanding of RDS to thread data through to a dashboard for a client.
About IBids.io
IBids enables people in the Dominican Republic to acquire information on the bids for state sales opportunities. IBids reached out to AllCode because they needed engineering resources to meet with members of the AWS QuickSight team in Seattle, Washington.
The Goal
Ibids.io’s application proposed a project that had been accepted into the AWS Embedded Analytics Data Lab to help with QuickSight integration. The main issue was figuring out a method of properly embedding that data source into the aforementioned dashboards. With that, they requested two of our experts to join the development team for a 4-week phase of Pre-Lab work with a subsequent week of dedicated build-time. The idea was for the experts to replicate existing templates and work for five hours per week over the 4-week phase and an additional forty hours during the execution phase.
How AllCode helped IBids.io
Over the span of a week, AllCode engineers were invited to a datalab to QuickSight dashboards for this use case. Those dashboards were then embedded into the REACT application. This way, our engineers had a better grasp of the use cases for QuickSight and the APIs we would be working with. The project required multiple iterations of the framework before it successfully worked. The solution was a two-pronged approach.
Anonymous Embedding
One of the options was to embed anonymously to allow open access to provide the same data to whoever has access. This is helpful in situations where the data is readily accessible, making it unnecessary to log the user on QuickSight.
From here, the workflow is somewhat flexible on how the embedding is to be applied. For static websites, when the page is loaded, a JavaScript function will invoke the API Gateway, executing a Lambda function and in turn making an anonymous call to QuickSight. Subsequently, QuickSight returns an embedded URL for the requested dashboard as well as any other dashboards requested by the initial call. The embedded URL is then passed back to the API Gateway and the embedDashboard function to then pull content from QuickSight and display on the dashboard.
If the page is dynamic, threading will work somewhat similarly to threading for a static site. Launching the site is still done through the API Gateway which then executes a Lambda Function to make that anonymous call to QuickSight. The steps are otherwise the same with the exception that Lambda will also return a dynamic url in a wrapper file. Dashboard content is then pulled from QuickSight with additional dashboards the end user might select being pulled from the QuickSight JavaScript library without the need to embed another url.
User-based Embedding
Comparatively, user-based embedding is for circumstances where the information being accessed is much more personal. Obviously, some dashboards will call for information to be kept separately on a per-user basis or users will be only interested in more specific bits of information.
To start, the OIDC/SAML-based SSO provider will be mapped onto a Identity and Access Manager (IAM) to provide a base role. The portal page is then served out to the user via a web server simulated by the API Gateway and AWS Lambda with JavaScript code being used to check if the user is signed in once the page loads. From this point onward, embedding will require user authentication. The API Gateway will then pass an OpenID token and invoke a Lambda function for the user to assume the role of the token. After verifying the token as valid, parallel calls are made to the Gateway to get the dashboard list and embed the urls. If a user doesn’t exist, an exception is made and the user is added to a QuickSight group.