Production Lessons from iGradePlus

iGradePlus is a commercial SaaS application built entirely on Oorian. With 500,000+ lines of code, hundreds of pages, and 10+ years in production, it's been the ultimate test bed for the framework. Here are the lessons we've learned.

Lesson 1: Communication Mode Matters

We initially used WebSocket everywhere because it seemed most powerful. Over time, we learned that simpler modes are often better:

AJAX for 80% of pages (forms, CRUD, reports)
SSE for dashboards and notification systems
WebSocket only for collaborative features

Each mode has infrastructure implications. Choose the simplest one that meets your needs.

Lesson 2: Component Reuse is Critical

With hundreds of pages, we couldn't afford to duplicate code. We built a library of base classes:

// Base class for all data management pages
public abstract class DataManagementPage<T> extends HtmlPage
{
    protected abstract void configureGrid(AgGrid grid);
    protected abstract T createNewEntity();
    protected abstract void saveEntity(T entity);
    protected abstract void deleteEntity(T entity);

    // Common toolbar, grid, and dialog handling
}

New CRUD pages now require minimal code.

Lesson 3: Performance Patterns

Lazy Loading

Don't load data until needed:

// Tab panel with lazy loading
tabPanel.registerListener((TabChangeEvent event) -> {
    if (event.getNewTab() == reportsTab && !reportsLoaded)
    {
        loadReports();
        reportsLoaded = true;
    }
});

Pagination

Never load all data for large datasets:

grid.setRowModelType(RowModelType.SERVER_SIDE);
// Load 50 rows at a time, fetch more on scroll

Lesson 4: Error Handling Strategy

Wrap all event handlers with consistent error handling:

@Override
public void onEvent(MouseClickedEvent event)
{
    try
    {
        performAction();
    }
    catch (ValidationException e)
    {
        showUserError(e.getMessage());
    }
    catch (Exception e)
    {
        logger.error("Unexpected error", e);
        showSystemError();
    }
}

Lesson 5: Session State Management

Be mindful of what you store in page state. Large objects consume memory across all active sessions.

Store IDs, not full objects
Reload data when needed rather than caching everything
Clear state when users navigate away

Lesson 6: Testing Strategy

We test at multiple levels:

Unit tests: Business logic and services
Component tests: UI component behavior
Integration tests: Full page interactions

Conclusion

Ten years of production use has taught us that Oorian scales well when you follow good patterns: appropriate communication modes, component reuse, lazy loading, proper error handling, and careful state management.