App Quality & Performance
Master app quality and performance for Buzzy. Learn data model efficiency, display rules optimization, and performance best practices for great user experiences.
Why Quality Matters with Buzzy
Non-technical explanation: Building an app is like cooking a meal. Even with professional kitchen equipment (Buzzy's Core Engine), you can still create a bad meal if your recipe (app design) is poor. Good ingredients arranged badly still taste bad. Similarly, even though Buzzy handles the technical infrastructure, you control the user experience through your design decisions.
While Buzzy handles the underlying code quality automatically through its professionally-maintained Core Engine, you're still responsible for your app's design quality and performance.
The cost of poor app design:
Poor app design leads to:
❌ Slow user experiences (pages take too long to load)
❌ Confusing navigation (users can't find what they need)
❌ Inefficient data structures (queries take too long)
❌ Poor user adoption (people don't use the app)
❌ Frustrated users (negative feedback, abandonment)
This guide covers:
🏗️ Data model quality (Subtables and Linked Table Fields best practices)
🎯 Display rules and actions optimization
⚡ Buzzy Functions performance tuning
📊 Performance considerations for Buzzy apps
✅ Complete app quality checklist (focused on design, not code)
Data Model Quality
1. Efficient Use of Subtables
Subtables are Buzzy's implementation of one-to-many relationships. Design them well:
Good Subtable design:
Invoices → Invoice Lines (each invoice has multiple line items)
Blog Posts → Comments (each post has multiple comments)
Projects → Tasks (each project has multiple tasks)
Organizations → Departments → Teams → Members (multiple nested levels)
Common mistakes:
Using Linked Table Fields when you should use Subtables
Loading many nested levels all at once (creates expensive queries and joins)
Not considering query performance for large Subtables
Best practices for nested Subtables:
Use Subtables for true parent-child relationships
Deep nesting is OK - you can nest more than 2-3 levels
The key: Use progressive disclosure - don't load all levels at once
Good approach: First screen shows 1-2 levels, then user drills down to see next level
Bad approach: Loading 10 items in a tree with 5+ nested levels all at once (monster queries!)
Example pattern:
Screen 1: Show Organizations list
Screen 2: Show selected Organization → Departments (1 level)
Screen 3: Show selected Department → Teams (1 level deeper)
Screen 4: Show selected Team → Members (1 level deeper)
Consider pagination for Subtables with many records
Use meaningful names for Subtable fields
Test query performance when nesting deeply - drill down progressively rather than showing everything
2. Proper Use of Linked Table Fields
Linked Table Fields enable many-to-many relationships. Use them correctly:
Good Linked Field design:
Products ↔ Categories (products in multiple categories)
Students ↔ Classes (students take multiple classes)
Articles ↔ Tags (articles have multiple tags)
Projects ↔ Team Members (members work on multiple projects)
Common mistakes:
Using Subtables when you need Linked Table Fields
Not storing additional relationship data when needed
Creating circular dependencies
Best practices:
Use Linked Table Fields for true many-to-many relationships
Consider using a junction table (Subtable + Linked Field) when you need to store relationship metadata
Use meaningful field names that indicate the relationship
Set appropriate display labels for the linked field
3. Field Validation and Formulas
Use Buzzy's built-in validation and JSONATA formulas effectively:
Field validation:
Mark required fields appropriately
Use field type validation (email format, number ranges)
Set appropriate min/max lengths for text fields
JSONATA formula examples:
Calculations:
quantity * priceConditional logic:
user.highestRole = "admin" ? "Full Access" : "Limited Access"Date validation:
dueDate > $now() ? "Valid" : "Date must be in future"Best practices:
Use formulas for calculations rather than storing computed values
Validate data at the field level when possible
Use clear, readable formula expressions
Test formulas with edge cases
Learn more about Formula fields
4. Display Rules Best Practices
Display rules control when UI elements are visible in Buzzy. Use them wisely:
Good display rule patterns:
Show "Edit" button only for record owners:
viewers contains $currentUser._idShow admin features for admins:
$currentUser.highestRole = "admin"Show subtable when parent has data:
invoice.invoice_lines.$count() > 0Conditional field display:
status = "approved"
Common mistakes:
Overly complex nested conditions
Not testing all user scenarios
Forgetting to test with different user roles
Using display rules for security (use Viewers fields instead)
Best practices:
Keep display rules simple and readable
Use display rules for UX, not security
Test with different user roles and data states
Document complex display rule logic
5. Actions Best Practices
Actions in Buzzy control what happens when users interact with your app:
Common action types:
Submit actions: Save form data to Datatables
Navigation actions: Move between screens
CRUD actions: Create, read, update, delete operations
Function calls: Execute Buzzy Functions
Good action patterns:
Validate before submit (use required fields)
Provide user feedback (success/error messages)
Clear navigation flows (back buttons, home navigation)
Confirmation for destructive actions (delete confirmations)
Common mistakes:
No feedback after actions complete
Confusing navigation (users get lost)
No undo for destructive operations
Missing error handling
Best practices:
Always provide user feedback
Use consistent action patterns throughout your app
Test all action paths thoroughly
Show loading states for slow operations
Performance Best Practices for Buzzy Apps
1. Data Model Performance
Efficient data relationships:
Design Subtables with performance in mind
Avoid deeply nested relationships (more than 3 levels)
Use Linked Table Fields appropriately
Consider query patterns when designing data model
Query optimization:
Use filters at the Datatable level
Implement pagination for large datasets
Limit Subtable record counts when possible
Use indexes effectively (Buzzy handles this automatically for common fields)
Example patterns:
✅ Good: Orders datatable with OrderItems subtable (1-2 levels)
❌ Bad: Company → Department → Team → Projects → Tasks (5 levels)
Best practices:
Design flat data structures when possible
Use Linked Table Fields to avoid deep nesting
Test with realistic data volumes
Monitor query performance in production
2. Screen Design Performance
Efficient screen layouts:
Limit the number of components on a single screen
Use pagination for large lists
Implement search and filter features
Load data progressively when possible
Mobile performance:
Buzzy's React Native apps include offline-first architecture
Test on actual mobile devices
Optimize images for mobile bandwidth
Consider data usage for mobile users
Best practices:
Show 20-50 items per page (not thousands)
Use infinite scroll or "Load More" buttons
Implement search for large datasets
Test with slow network connections
Optimize image sizes (compress before uploading)
3. Buzzy Functions Performance
When using Buzzy Functions (AWS Lambda), optimize for performance:
Function best practices:
Keep functions focused and small
Minimize dependencies (reduces cold start time)
Use environment variables for configuration
Implement error handling and retries
Set appropriate timeout values
Example efficient function:
export const main = async (event) => {
// Validate input quickly
if (!event.body?.email) {
return {
statusCode: 400,
body: { error: "Email required" }
};
}
// Do work
const result = await processEmail(event.body.email);
// Return promptly
return {
statusCode: 200,
body: result
};
};Performance tips:
Cache API responses when appropriate
Use Promise.all() for parallel operations
Return errors quickly (don't waste time)
Test function performance before deploying
Learn more about Buzzy Functions
4. Caching Strategies
Where to cache:
Browser cache:
Static assets (images, CSS, JS)
API responses (for appropriate duration)
Server cache:
Database query results
External API calls
Computed values
Example:
const cache = new Map();
async function getWeatherData(city) {
const cacheKey = `weather:${city}`;
const cached = cache.get(cacheKey);
if (cached && Date.now() - cached.timestamp < 30 * 60 * 1000) {
return cached.data; // Use cache if < 30 minutes old
}
const data = await fetchWeatherFromAPI(city);
cache.set(cacheKey, {
data,
timestamp: Date.now()
});
return data;
}Reviewing Buzzy Functions Code
When you use Buzzy Functions (AWS Lambda) for external integrations, you write minimal Lambda code. Here's what to review:
Common Issues in Buzzy Functions
1. Hard-Coded API Keys (Critical Security Issue)
❌ Never do this:
export const main = async (event) => {
const apiKey = "sk-abc123..."; // EXPOSED!
const response = await fetch(`https://api.service.com/data`, {
headers: { 'Authorization': `Bearer ${apiKey}` }
});
return { statusCode: 200, body: await response.json() };
};✅ Always use Buzzy Constants:
export const main = async (event) => {
const apiKey = process.env.API_KEY; // From Buzzy Constants
if (!apiKey) {
return { statusCode: 500, body: { error: "API key not configured" } };
}
const response = await fetch(`https://api.service.com/data`, {
headers: { 'Authorization': `Bearer ${apiKey}` }
});
return { statusCode: 200, body: await response.json() };
};2. Missing Error Handling
❌ Assumes everything works:
export const main = async (event) => {
const data = JSON.parse(event.body);
const result = await externalAPI(data.email); // What if email is missing?
return { statusCode: 200, body: result };
};✅ Validates input and handles errors:
export const main = async (event) => {
// Validate input
const data = JSON.parse(event.body || '{}');
if (!data.email) {
return { statusCode: 400, body: { error: "Email required" } };
}
try {
const result = await externalAPI(data.email);
return { statusCode: 200, body: result };
} catch (error) {
console.error('API call failed:', error);
return { statusCode: 500, body: { error: "Service unavailable" } };
}
};3. Missing Timeout Handling
Buzzy Functions have execution time limits. Handle slow operations:
export const main = async (event) => {
const timeout = 5000; // 5 seconds
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), timeout);
try {
const response = await fetch(url, { signal: controller.signal });
clearTimeout(timeoutId);
return { statusCode: 200, body: await response.json() };
} catch (error) {
if (error.name === 'AbortError') {
return { statusCode: 504, body: { error: "Request timeout" } };
}
throw error;
}
};4. Poor Response Structure
Buzzy expects consistent response formats from Functions:
✅ Good pattern:
return {
statusCode: 200,
body: {
success: true,
data: result
}
};Learn more about Buzzy Functions best practices
Buzzy App Review Checklist
Before publishing your Buzzy app:
Data Model:
Security:
User Experience:
Functionality:
Performance:
Buzzy Functions (if applicable):
Improving Your Buzzy App Over Time
When to Redesign
Redesign when:
Data model is causing problems
Users find navigation confusing
Performance is poor with real data
Adding features is difficult due to design
Don't redesign when:
App works well for users
Performance is acceptable
Just cosmetic preferences
Time better spent on new features
Improvement Process for Buzzy Apps
1. Test current functionality (ensure you don't break what works) 2. Make one change at a time (data model first, then screens, etc.) 3. Test after each change (use Buzzy's preview mode) 4. Use Buzzy's version control (Versions tab for safe rollback)
Example: Improving a Buzzy app's data model
Before (Poor design):
Single "Orders" Datatable with text fields for items
Manual calculation of totals in display rules
Difficult to query individual items
Can't report on product popularity
After (Better design):
"Orders" Datatable with order metadata
"OrderItems" Subtable (child of Orders) for line items
Formula fields for automatic total calculations
Easy to query and report on products
Benefits of improved Buzzy data model:
Better data integrity
Automatic calculations via formulas
Easier to extend with new features
Better reporting capabilities
Follows Buzzy best practices (Subtables for 1:M relationships)
For Buzzy Functions refactoring:
Keep functions small and focused
Extract complex logic into helper functions
Use Constants for all configuration
Add comprehensive error handling
Test thoroughly before deploying
Monitoring Your Buzzy App
What to Monitor
User Experience:
How users navigate your app
Where users get stuck
Error reports from users
Feature usage patterns
Session duration
Performance:
App load times (web and mobile)
Screen navigation speed
Buzzy Function response times
Data query performance
Data Quality:
Data integrity issues
Missing required fields
Invalid data entries
Orphaned records
Monitoring Approaches
User feedback:
Built-in feedback mechanisms
User testing sessions
Support ticket analysis
Direct user conversations
Buzzy platform monitoring:
Check Buzzy Function logs
Review error reports
Monitor deployment status
Track usage statistics
Testing with real scenarios:
Test with production-like data volumes
Simulate real user workflows
Test on actual mobile devices
Test with slow network connections
Performance Optimization Process
1. Measure First
Use Buzzy's preview mode to test app speed
Test with realistic data volumes
Check on actual mobile devices
Monitor Buzzy Function execution times
2. Focus on Biggest Impact
Optimize screens users visit most
Fix slowest data queries first
Improve most complex Buzzy Functions
3. Make One Change at a Time
Test each optimization in preview
Use Buzzy's version control to rollback if needed
Document what you changed and why
4. Set Performance Goals
Screen load < 3 seconds
Buzzy Functions < 1 second
Search results < 2 seconds
Mobile app responsive and smooth
Buzzy App Organization
Datatable Organization
Good organization:
Group related Datatables logically
Use clear, descriptive names
Document complex relationships
Keep data model diagram updated
Example structure:
Users (main user table)
Organizations (multi-tenant)
Teams (within organizations)
Projects (linked to teams)
└─ Tasks (subtable of projects)
└─ Comments (subtable of projects)
Products (main products table)
Categories (linked via Linked Table Field)
Orders
└─ Order Items (subtable)Screen Organization
Good patterns:
List → Detail → Edit flow
Clear navigation hierarchy
Consistent naming conventions
Group related screens
Example:
Project List
Project Detail
Project Edit
Project Tasks (subtable view)
Task Detail
Task Edit
Testing for Quality in Buzzy
Testing Approach
Functional testing:
Test all user workflows
Verify display rules work correctly
Confirm actions complete successfully
Test with different user roles
Data testing:
Test with empty state (no data)
Test with large datasets
Test edge cases (very long text, special characters)
Verify Subtables and Linked Fields work correctly
User testing:
Have real users try the app
Watch where they get confused
Note what they expect vs. what happens
Iterate based on feedback
Continuous Improvement
Regular activities for Buzzy apps:
Weekly:
Review user feedback
Check Buzzy Function logs
Test new features added
Monitor app performance
Monthly:
Review data model efficiency
Optimize slow screens
Update Buzzy Functions if needed
Review security settings
Quarterly:
Major UX improvements
Data model refactoring if needed
Performance optimization
User testing sessions
Next Steps
Security best practices: Compliance & Security
Understanding maintenance: Maintenance with Buzzy
Testing strategies: Testing Approaches
Building examples: Hello World App
Remember: App quality in Buzzy isn't about code quality—it's about design quality. Buzzy handles the code. You handle the data model, user experience, and business logic. Focus on making your app intuitive, performant, and valuable to users. Quality compounds over time.
Last updated