Skip to content

arfazhxss/synctera-dashboard

Repository files navigation

Synctera FinTech Dashboard

synctera-dash.mp4

Completed Requirements

Task 1 ✅

  • Implemented transaction table with all data
  • Added loading indicator (LoadingContext & LoadingOverlay components)
  • Created TransactionDetailsDialog for viewing details in a modal
  • Used shadcn/ui components for a professional look

Task 2 ✅

  • Implemented advanced filters API endpoint (/api/advancedfilter)
  • Added dropdown filters for:
    • All Transactions (/api/transactions?filter=all)
    • Top 10 transactions grouped by merchants (/api/transactions?filter=top-merchants)
    • Top 10 transactions sorted in ascending order by amounts (/api/transactions?filter=top-amount)
    • Top 10 transactions grouped by catagories (/api/advancedfilter=top-catagories)
  • Created FilterSelect component for filter UI

Pending Tasks ⏳

  • Fix Advanced Filter Settings for Marchant View
  • Fix TransactionTable overflow in Mobile View
  • Map Currency, Country and City Data from Database into Advanced Filter Table

Technical Decisions

Why Next.js?

  1. Performance: Server-side rendering improves initial load time
  2. API Routes: Simplified backend implementation for filters
  3. TypeScript Support: Better code reliability and maintainability

Component Structure

  • Used shadcn/ui for consistent, accessible UI components
  • Implemented context (AlertContext, LoadingContext) for state management
  • Created reusable components (TransactionRow, CellMapping) for maintainability

Future Considerations & Discussion Points

Scalability & Performance

  • Current Implementation: Pagination, efficient data loading

My Technical Approach to Scaling

Performance Considerations

I've built the foundation with Next.js App Router, which gives me a lot of room to grow. Here's how I'd handle different user scales:

Hundreds of Users

I'm already set up for this! My current implementation with Next.js handles this easily because:

  • I'm using client-side pagination
  • My API routes are optimized for quick data fetching
  • Next.js's default caching is already helping with performance

Thousands of Users

I'd need to make some adjustments, but my current setup makes this straightforward:

// I can easily add caching to my existing API routes
import { unstable_cache } from 'next/cache'

const getTransactions = unstable_cache(
  async () => await fetchTransactions(),
  ['transactions'],
  { revalidate: 60 }
)

I chose Next.js partly because it makes this kind of optimization simple to add.

Millions of Users

This is where I'd need to make bigger changes, but I've planned for this:

  1. I can leverage my shadcn/ui components for virtualization
  2. My API structure allows for easy sharding if needed
  3. I've already set up my components to support streaming:
<Suspense fallback={<MyLoadingComponent />}>
  <TransactionsTable />
</Suspense>

Privacy Considerations

I've thought about privacy from the start. Here's my approach:

  1. I'm already hiding sensitive logic server-side using Next.js API routes
  2. I've used TypeScript for data validation
  3. For the next level, I can easily add:
    // I can add this to my existing TransactionRow component
    function maskSensitiveData(data: string) {
      return `****${data.slice(-4)}`
    }

Authentication & Authorization

I've structured my app to make adding auth straightforward:

  1. I can integrate NextAuth.js easily since I'm using Next.js:
// I can add this to my existing app
import NextAuth from 'next-auth'

export default NextAuth({
  providers: [
    // I can add providers as needed
  ],
})
  1. My middleware setup can make it simple to add route protection:
// I can extend my existing middleware
export function middleware(request: NextRequest) {
  const token = request.cookies.get('token')
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

Why I Made These Choices

  1. Next.js: I picked this because it gives me a clear upgrade path. As my user base grows, I can easily add more performance optimizations.

  2. shadcn/ui: I chose this for its built-in accessibility and performance features. It'll handle scaling well without needing major changes.

  3. API Structure: I set up my API routes to be modular. This means I can easily add caching, authentication, or even switch to a microservices architecture if needed.

User Experience Decisions

  1. Simple yet Effective Layout:
    • Focused on functionality over excessive styling
    • Responsive design for various screen sizes (okay maybe not the table, I haven't found a good table design for mobile view)
  2. Completeness vs Perfection:
    • Prioritized core functionality
    • Implemented all required features
    • Left room for future UI/UX improvements

Moving Forward

My current setup gives me a solid foundation. As the user base grows, I can:

  1. Add caching incrementally
  2. Enhance security features without major refactoring
  3. Scale horizontally thanks to my modular design

I've focused on building things right the first time, so scaling up will be about enhancing what's already there rather than rebuilding from scratch.

Code Quality & Maintenance

  1. Current Approach:

    • TypeScript for type safety
    • Modular component structure
    • Consistent coding style
  2. Future Improvements:

    • Add comprehensive test coverage
    • Implement CI/CD pipeline
    • Documentation for component library

The focus was on creating a functional, performant application while maintaining clean, maintainable code. The modular structure allows for easy scaling and addition of features, with considerations for future growth and security needs.

About

A FinTech banking dashboard, made for Synctera Inc.

Resources

Stars

Watchers

Forks