QuickSight Limitations

Base Concept

QuickSight (QS) base concept is DESIGN and CLONE. Meaning that initially you manually design the report and then programmatically clone it. The design phase includes all the resources, not just the report itself, e.g.: Data Source, Data Set, Analysis .

Limitations

1. Data Computation - All the data computation needs to happen at SQL/QS level. Meaning you cannot compute the data inside your application and after that pass it to QS.
2. Reusability - Analysis visuals cannot be reused. That said if you have more reports that have some common charts between them, you can't reuse the visual from one analysis to another, requiring to design same thing again.
3. Filter (Local) - User can do filtering in QS that apply to individual/some/all visuals. But that filtering is primitive, meaning that you can filter data by a string. You cannot let's say do it like a normal browser dropdown. Select the label but the values is actually something else. Plus you cannot do some interaction after the filter selection. Here are some examples to understand it properly:
   • If you have users and those users have IDs. And you create a filter that shows the names of those users. The data will be filtered by the primitive string - user name - not user ID.
   • Or if you have a hierarchy for those users and you would like to filter by it, there is no way to interact with the selection to see which users fall under that hierarchy.
4. Filter (Dynamic) - The only way to achieve dynamic filtering is to create Parameters and bind them to defined filters. After which those parameters can be sent from your application during QS embedding process. But there is one big downside to this - each filter change on your application requires re-fetch the QS Dashboard.
5. Isolating Visuals - It is not possible to embed a single visual, you are bound to embed the entire dashboard. We can say why not just create one single visual per dashboard? The answer is simple - each dashboard is equivalent to one HTTP request. Let's say you have a table and each row of a table has a small bar chart. Having 30 rows will mean 30 HTTP requests, combine this with the above mentioned dynamic filter limitation, and on each single filter change again +30 HTTP requests!
6. Visuals within visuals - There is no way to include in one chart another chart. The usage is fairly common. We can take the above example from the above limitation (Table with 30 rows + charts). Let's say we design the whole table as a visual directly in QS, so that we don't do for each row one HTTP request. It is not possible to include another chart in each table row to represent the report for each row separately.
7. Design Security - Each and every single resource inside QS is only visible to the owner and needs to be specifically allowed if we want somebody else to see it. Now, this being said, if I create any resource (Data Source, Data Set, Analysis, Dashboard, etc.), I am the only one who can see it. Or an even better example, if I create the resource with CLI, nobody can see it, only the CLI user! Meaning that if I go to my dashboard in QS I won't see that resource being created unless I added that person into permissions.
8. Access Security - When embedding a QS Dashboard on your application, all users when requesting the dashboard need to have a pre-signed embed URL in order to fetch that dashboard. This means that each registered user of your application needs to also be registered in QS. This can be done programmatically when creating the resource you can also create a group, allow that group to access that specific dashboard, register a new user in QS and add to the specific group. But why would someone need to register all his users? Plus QS charges $5 for each user per month! WORKAROUND - Since the URL signature is done in lambda we can use one single user to pre-sign all URLs for all the users... not sure if this falls under some violations, from my point it shouldn't, as I can have such a specific need.
9. No sight of resources - during the programmatic clone of the QS resources, one type of resource called template can't be seen anywhere except CLI and by the same CLI user who created it. Explanation:
   
   • When cloning an analysis we don't actually cone analysis, instead, we create a "template" which uses as a source an existing designed analysis, and from that template we create another Analysis.
   • Templates can't be visualized in the QS dashboard, meaning you can't actually see them anywhere.
   • Resources are created and nobody is aware of their existence. Only the CLI owner can list them and remove them if no longer required. 
10. Apply changes - If we want to change something in our designs of Analyses, we can't just make the design change and re-deploy. We need to go and remove all the affected resources via QS UI (visible) + CLI (non-visible) for each customer. And after that to re-deploy for each customer.