Skip to main content

Retool Well-Architected Framework

The Retool Well-Architected Framework provides enterprises guidance on developing and deploying Retool web applications that are well-designed, operationally sound, performant, secure, reliable, scalable and cost effective in a Enterprise configuration. This document is not a replacement for existing product documentation, rather it is a collection of constructs, principles and best practices that our field team has developed over hundreds of customer implementations.

Constructs​

Retool applications provide a wide range of capabilities and options to consider. Constructs provide guidance on how to effectively implement these capabilities while also understanding the tradeoffs to consider. The following constructs will be detailed in the following sections:

Design​

Design with Retool relates to the user interface layout, themes, components and actions that a developer can leverage to build their application. Definition of a consistent design language within an organization simplifies the user experience enabling consumers of the application to be more productive.

Overview​

When developing a Retool application a standardized design process should be considered. This process can be thought of as a three-part framework as shown in the following figure:

Principles​

Applications employ a consistent design language​

Consider defining a standardized look and feel of your application (e.g., navigation, color palette, button, text placement, fonts etc.) and re-using this in future applications. This simplifies the experience for the end-user, decreasing onboarding time and improving productivity.

Supporting Best Practices​

Less is more​

Applications should only provide relevant information required to support the business process and inform the users. Overloading an application with unnecessary data and capabilities can reduce the usability of the application and increase onboarding time. Simplifying the application into multiple applications and using navigation can help in this effort.

Supporting Best Practices​

Understand your Data and How Users Need to Interact with It​

Applications often provide views into critical business data. Understanding how end-users need to interact with it and what components can provide that capability is critical. For example if end-users need to perform Create, Read, Update, and Delete operations (CRUD), a table component may provide a good starting point. If the end-users need to examine the data in multiple visual modes to make an informed decision, graph components may be more appropriate.

Supporting Best Practices​

Operations​

Operations within Retool focuses on scaling the Retool Platform via various administrative tasks including app management, org and user management, release management, security configuration, and source control.

Overview​

Scaling the Retool Platform in an organization requires having operational controls for Retool developers and users. These include managing the Retool users and permissions, the Retool applications releases and source control, software patching and upgrades, and Retool application documentation to name a few. In addition for large enterprises, the use of a Hub and Spoke model to simplify the administration experience (Self-hosted only). Finally management of external data sources via Cloud Providers and the management of those dependencies is discussed.

Principles​

Centralize and scale user management via SSO​

The Retool Platform requires that all users have registered via email, or for Self-hosted, employ Single Sign On for user authentication. Large enterprises often centralize user management operations within a provider (e.g., Okta, Microsoft Active Directory) and have developed best practices and automation for user provisioning.

Supporting Best Practices​

Centralize Retool management​

Administrators follow practices to initially organize development teams and their work in a hub and spoke model. Developers are provided appropriate permissions to develop new applications and have local control with administrators managing releases, upgrades, and other actions.

Supporting Best Practices​

Leverage Retool Environments or Instances To Manage Rollout​

Production applications should not be the default for adding new features or capabilities of Retool Developers. Administrators should create at a minimum a development environment (sandbox) that developers work in by default and a production environment that is exposed to the application consumers. In many organizations the following environments or variations of exist to support maturation of a new version of an application with data that correlates to the environment:

  • Development - Environment or Instance to use for development of the application with anonymized data.
  • Testing - Environment or Instance for quality assurance to test the application using prepared test data.
  • Staging - Environment or Instance that is identical to production to perform final validation using real customer data.
  • Production - Environment or Instance that consumers use.

To support the above approaches, Retool Environments or separate Retool Instances support creation of Development, Testing, Staging, and Production environments.

Retool Environments provide a way to effectively namespace applications and resources when operating within Retool Enterprise Cloud. For customers employing Retool Self-hosted, multiple instances installed within the cloud provider provides separate infrastructure to host each environment and connect to appropriate resources. When using multiple instances of Retool, it is important to leverage Protected Apps to propagate the application from one instance to another.

Use of source control provides a further level of protection, auditability, and human review via Pull Requests and Git Branches. Finally, administrators have releases that allow new features to be deployed as well as rolled back in the event of failure.

Supporting Best Practices​

Security​

Security within Retool focuses on implementing best practices for authentication, authorization, privacy, auditing, and logging.

Overview​

Resource: https://docs.retool.com/page/security

Retool provides a security overview in the link above. This covers data utilization, security testing practices, and other details. The following section goes into further detail of specific security actions one can take to protect the Retool platform and its assets.

Principles​

Provide Secure Identity Foundation​

The Retool Platform for developers, administrators, and end-users implements least-privileged access to resources.

Supporting Best Practices​

Provide Auditing for User Access​

Application usage by developers, administrators, and end-users is traceable to support auditing requirements.

Supporting Best Practices​

Encrypt At Rest and In Transit​

Data that applications employ is encrypted at rest and in transit to protect against unauthorized access.

Supporting Best Practices​

Remove Direct Access to Data​

Applications should eliminate direct access to data, instead relying on automation and mechanisms to standardize data retrieval and modification.

Supporting Best Practices​

Provide Security Event Communications​

Retool Cloud Hosted solutions employ Best Practices and Procedures that are followed to proactively look for security defects.

Supporting Best Practices​

Performance​

Performance within Retool focuses on implementing best practices for reducing latency outside and inside the application.

Overview​

Latency within a Retool application can come from several sources. The first is the dependency that Retool Data Sources have on outside Cloud Services, Databases, and APIs. These services run regionally at a Cloud Provider and thus latency can occur due to distance between a consumer, the Retool application, and Cloud resources. Additional latency can occur due to configuration of the Cloud Resource and how it is being queried. A second more consistent problem is in querying large data sets and how that can impact the browser performance and Retool application performance. A third issue could be the complexity of the Retool application and its use of nested components that can add to front end loading time. The following best practices identify mechanisms to help avoid these scenarios.

Principles​

Reduce Latency In Applications​

Applications should provide data access in a reasonable amount of time (1-3 seconds). Longer times can reduce the impact and effectiveness the application provides due to compounding latency for each operation.

Supporting Best Practices​

Reliability (Self-hosted only)​

Reliability within Retool Self-hosted focuses on properly configuring container orchestration in support of reliable execution of Retool applications.

Overview​

Reliability is the ability of an application to consistently and correctly support users requests. Having application resiliency to support these requests even in the face of infrastructure outages and downtime is critical. Within cloud providers, reliability and resiliency of applications is supported through the use of availability zones (AZ). For every cloud provider’s regional services, an AZ consists of 2 or more availability zones. These AZs have 1 or more interconnected data centers supporting the respective cloud services that are separated by a meaningful distance (e.g., 100 Km). Applications that are deployed across multi-AZs increase the reliability and resilience of the workload in the event that one AZ is impacted (e.g., earthquake, fire, power outage). The following best practices identify how an application can be made more resilient through container orchestration, load balancing, and cloud providers.

Principles​

Implement Resiliency​

Resiliency focuses on the implementation of an architecture that can withstand failure when supporting infrastructure fails.

Supporting Best Practices​

Scalability (Self-hosted only)​

Scalability within Retool Self-hosted focuses on different considerations a Retool Operator can implement to support scaling of Retool container(s) and the container orchestration solution.

Overview​

Retool’s Platform Self-hosted requires that the customer manage the appropriate number of containers based on their utilization. Use monitoring solutions to track key metrics such as CPU, memory, I/O, storage, and network traffic of the containers and separately the database health and notify when thresholds are exceeded. Depending on the mechanism used to Self-host, the Retool application can be vertically scaled (e.g., larger instance) or horizontally scaled (e.g., more pods). The following best practices will discuss best practices as well as leveraging load balancing to help distribute load when horizontally scaling.

Principles​

Use Cloud Elasticity to Scale Infrastructure​

Public Cloud Providers (e.g., AWS, Microsoft and Google) provide automated scaling options for compute, storage and networking. Leveraging these features to support auto-scaling when demand exceeds the default configuration. Public cloud providers provide a variety of automation options for scaling VMs and managed Kubernetes clusters. Use of these solutions matches the observed traffic, bringing appropriate resources online or offline depending on scale out or scale in event.

Supporting Best Practices​

Implement storage in Cloud Provider Managed Services​

Retool leverages a PostgreSQL database for user, app and other administration activities. Removing the burden of maintenance and providing simple mechanisms for scaling are inherent in these solutions.

Supporting Best Practices​

Cost Efficiency​

Cost efficiency focuses on considerations for managing Retool Self-hosted when leveraging a Cloud provider (e.g., AWS, Azure, GCP). It also considers external data providers for hosting the Retool database or data consumed by Resources.

Overview​

Cost management provides mechanisms for a customer to enable visibility of their cloud computing costs. For Self-hosted, containers can be orchestrated in several different ways. This section will assume the use of Kubernetes Orchestration. Cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google provide managed Kubernetes offerings including:

  • Amazon Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)
  • Google Kubernetes Engine (GKE)

For Self-hosted, a PostgreSQL database is also required. Use of the provided containerized database is not recommended but rather use a managed service offering from the major cloud providers including:

  • Amazon Aurora PostgreSQL
  • Azure Database for PostgreSQL
  • Google Cloud SQL

For Resources, Retool supports a wide range of data sources. These data sources referenced by Resources will run typically in another cloud provider. Consider these charges also into the overall cost of the application.

Costs for these platforms are rolled up to your respective account that you have associated a payment method with.

Principles​

Track Retool Platform Spend​

Retool platform when run in Self-hosted mode executes within a container or pod. Tracking the spend of the Retool Platform (VM or Kubernetes) can be performed via tagging practices and employing solutions such as Kubecost.

Supporting Best Practices​

Optimize Retool Platform Spend​

Customers that leverage Cloud Platforms can employ auto scaling, optimized VM instances, and other on-demand solutions that help provide optimal performance for the Retool Platform while reducing costs. Use of managed services (e.g. PostgreSQL), helps reduce the management overhead of maintaining a database cluster, snapshots, replication, patching etc.

Supporting Best Practices​