Brainstorming GSOC 2026 Project Ideas

Community GSOC
1

Hi everyone,
Following that Gsoc announced Gsoc 2026 Program, As OpenELIS plans to participate we can always brain storm about project Ideas that we think would be fit for 2026 Program
Currently are the available projects we have, feel free to suggest more on this thread

Project Sizes:

  • Small: ~90 hours
  • Medium: ~175 hours
  • Large: ~350 hour

Useful GSoC Resources
Gsoc Guidlines for students
Google’s Guide: Defining a Project Ideas List
GSOC Eligibility rules

Looking forward to seeing amazing ideas for all of us
cc:@aditya @Moses_Mutesasira

5 Likes
2

Idea: Cache API responses using TanStack Query in OpenELIS React app

What this is about

Right now, the OpenELIS React app calls APIs in many different ways. Some pages refetch the same data again and again, even when nothing has changed. This makes pages slower, increases load on backend servers, and makes frontend code harder to understand and maintain.

My idea is simple: use TanStack Query as a common way to fetch data and cache API responses on the frontend.

This helps the app become faster, cleaner, and cheaper to run, without touching the backend.

Current problems

From looking at the current setup:

  • React 17 app with many screens and data-heavy pages
  • Data fetching is mixed (custom fetch logic, RxJS, SWR)
  • Same API gets called multiple times on navigation or re-render
  • Each screen handles loading, error, retry logic differently
  • New contributors need time to understand how data is fetched

This causes:

  • More API calls than needed
  • Slower UI, especially on low-bandwidth setups
  • Higher backend cost over time
  • Messy and duplicated frontend code

Introduce TanStack Query as a standard layer for API calls.

Instead of calling APIs directly inside components, we:

  • Create small reusable query hooks (example: usePatients , useReports )
  • Let TanStack Query cache the response
  • Reuse cached data across pages
  • Automatically refetch only when data becomes old or invalid

No backend change is required. This can be added step by step.

How it helps (real impact)

1. Performance

  • Same API response is reused instead of refetched
  • Faster page loads after first visit
  • Less waiting time for users

In many dashboards and report pages, API calls can drop by 40–70% .

2. Backend cost

  • Fewer API requests hitting the server
  • Less database load
  • Lower infra and scaling cost

Even a small reduction per user matters a lot for a system used daily by labs.

3. Cleaner code structure

  • Components focus only on UI
  • Data logic lives in query hooks
  • No repeated loading / error handling code

This makes the code:

  • Easier to read
  • Easier to test
  • Easier for new contributors

4. Better consistency

  • Same loading and error behavior everywhere
  • Fewer UI bugs caused by race conditions
  • Automatic retry for temporary network failures

Rough structure

Component
  -> useQueryHook()
      -> TanStack Query cache
          -> API call

Main rule: components do not call APIs directly.

Small example

Query hook:

export const usePatients = () => {
  return useQuery({
    queryKey: ['patients'],
    queryFn: fetchPatients
  });
};

Component:

const PatientList = () => {
  const { data, isLoading, error } = usePatients();

  if (isLoading) return <Loading />;
  if (error) return <Error />;

  return <Table data={data} />;
};

Migration plan (safe and gradual)

  • Start with read-heavy screens (reports, dashboards, lists)
  • Keep existing code working
  • Replace old fetch logic page by page
  • No big-bang rewrite

This keeps risk very low.

Testing impact

  • Query hooks can be unit tested easily
  • Existing Cypress tests stay the same
  • Less flaky UI tests because data is cached

Why this is good for OpenELIS

  • Faster UI for real users
  • Lower server and infra cost
  • Cleaner frontend architecture
  • Easier long-term maintenance
  • Better onboarding for new contributors

Summary

This idea is not about adding fancy tech. It is about:

  • Reducing unnecessary API calls
  • Making the app faster and more stable
  • Keeping the frontend codebase simple and structured

TanStack Query fits well with the current React setup and can be added slowly without breaking anything. It would be a solid and practical improvement for OpenELIS as part of GSoC 2026.

3

Idea: Upgrade OpenELIS React app to the latest stable React version

What this is about

The OpenELIS React application is currently using React 17. While it is stable, it is now outdated. Most of the React ecosystem has moved forward, and staying on an older version increases long-term maintenance cost.

This idea proposes upgrading the app to React 18 (latest stable baseline) in a careful and controlled way.

This is not about adding new features. It is about keeping the frontend healthy, supported, and easier to maintain.

Why this upgrade is useful

1. Lower long-term maintenance cost

  • React 17 is already several years old
  • New libraries and tools assume React 18+
  • Staying behind makes future upgrades harder and more expensive

Upgrading now prevents technical debt from growing.

2. Better performance for data-heavy screens

React 18 brings internal improvements like:

  • Better batching of state updates
  • Improved rendering behavior

For pages like reports, dashboards, and tables, this means:

  • Smoother UI updates
  • Fewer unnecessary re-renders
  • Better experience on slower machines

3. Cleaner and more future-proof codebase

  • Modern root API (createRoot)
  • Better compatibility with current and future libraries
  • Easier adoption of modern patterns later if needed

Even without using new features immediately, the base becomes cleaner.

Why React 18 (and not React 19)

Why React 18

  • Widely used in production
  • Well-tested and stable
  • Strong ecosystem support (routers, UI libraries, testing tools)
  • Considered the current industry baseline

React 18 is the safest upgrade step from React 17.

Why not React 19 (for now)

  • Too new for large production systems
  • Many dependencies may not fully support it yet
  • Higher risk of unexpected issues

For a healthcare-focused system like OpenELIS, stability matters more than early adoption.

React 19 can be evaluated later once the ecosystem matures.

Routing and navigation improvement (related to React upgrade)

Currently, many places in the app use window.location.href for navigation. This forces a full page reload and breaks the single-page app flow.

This issue is already tracked here:
https://github.com/DIGI-UW/OpenELIS-Global-2/issues/1465

Using window.location.href causes:

  • Full reload of the app on navigation
  • Loss of in-memory state and cache
  • Slower navigation between pages
  • Harder-to-maintain navigation logic

With a proper React upgrade, we can move toward React-based navigation instead:

  • Use React Router navigation (history.push, useNavigate where applicable)
  • Let React handle routing without full reloads
  • Make navigation faster and more predictable

This change:

  • Improves user experience
  • Reduces unnecessary reloads
  • Makes the app behave like a true SPA
  • Fits naturally with a React 18 upgrade

Risk and cost impact

This upgrade:

  • Does not change business logic
  • Does not require UI redesign
  • Can be done incrementally

Main work includes:

  • Updating React and React DOM
  • Fixing minor compatibility issues
  • Running existing unit and Cypress tests

Doing this now is cheaper and safer than delaying it.

Suggested upgrade approach

  • Upgrade React and React DOM to React 18
  • Keep existing patterns and APIs working
  • Fix issues module by module
  • Validate behavior using existing tests

No big-bang rewrite is required.

Why this is good for OpenELIS

  • Keeps the frontend stack supported and modern
  • Reduces future migration risk
  • Improves performance without changing user workflows
  • Makes the codebase easier for new contributors to understand

Summary

Upgrading to React 18 is a practical and low-risk improvement. It reduces technical debt, improves performance, and prepares OpenELIS for future development — without introducing instability. This makes it a solid and valuable GSoC 2026 contribution.

4

Project Idea : Typescript support in react frontend.

Goal :

  • Type safety
  • lint checking ( eslint and prettier )

Project Idea : Enable testing and github actions in react frontend.

Goal:

  • Automated end to end test, unit test using jest/cypress/playwright.
  • Enable github actions for checking test cases passing or not!!!
1 Like
5

Thanks @shauryag2002 for this great Ideas.

I think i can summarize all these into a single Project

Modernizing the OpenELIS React Frontend with TypeScript and Performance Optimization.

we can improve perfomancee by adopting TanStack Query for handling server side API and useMemo for optimising synchronous calculations

3 Likes
6

Project Idea: Modernizing OpenELIS with Microservices, Kafka-Based Event Streaming, and DevOps Automation

Goal

To modernize the OpenELIS platform by introducing a microservices-based architecture, integrating Apache Kafka for event-driven communication, and implementing DevOps automation using CI/CD pipelines. The project focuses on scalability, reliability, performance, and cloud readiness without a full cloud migration.

Project Description

OpenELIS is a widely used Laboratory Information System in healthcare environments. As usage grows, there is a need to improve scalability, decouple tightly coupled components, and enable real-time data processing.

This project proposes breaking selected OpenELIS backend modules into independent microservices, introducing Apache Kafka for asynchronous communication, and setting up DevOps pipelines for automated testing, building, and deployment. The system will remain compatible with existing deployments while enabling modern distributed system practices.

Key Objectives

1. Microservices Architecture

  • Identify suitable OpenELIS modules (e.g., patient management, test orders, reporting) for microservice extraction

  • Develop REST-based microservices using Java (Spring Boot)

  • Implement service-to-service communication and centralized configuration

  • Enable scalability and independent deployments

2. Apache Kafka Integration

  • Introduce Apache Kafka for event-driven communication between microservices

  • Publish events such as:

    • Patient registration

    • Test order creation

    • Lab result updates

  • Implement Kafka producers and consumers in Spring Boot services

  • Improve system reliability using asynchronous, decoupled processing

3. DevOps and CI/CD Automation

  • Set up CI/CD pipelines using GitHub Actions

  • Automate:

    • Build and test execution

    • Code quality checks

    • Docker image creation

  • Optional deployment to cloud or on-prem environments

4. Containerization and Deployment

  • Dockerize OpenELIS microservices

  • Use Docker Compose or Kubernetes (basic setup) for service orchestration

  • Enable environment-specific configuration and scalability

5. Monitoring and Logging

  • Implement centralized logging and monitoring

  • Track service health, performance metrics, and Kafka message flow

  • Improve observability and debugging for distributed services

Expected Outcomes

  • A partially microservices-based OpenELIS architecture

  • Kafka-enabled event streaming for real-time workflows

  • Automated DevOps pipelines for reliable deployments

  • Improved scalability, fault tolerance, and performance

  • Clear documentation for future contributors

Required Skills

  • Java, Spring Boot

  • Microservices architecture

  • Apache Kafka

  • REST APIs

  • Docker & basic Kubernetes

  • CI/CD (GitHub Actions)

Impact

This project modernizes OpenELIS into a scalable, event-driven system while maintaining backward compatibility. It prepares the platform for high-volume laboratory environments and future cloud adoption, improving both system reliability and developer productivity.

7

Offline-First Progressive Web App (PWA) Enhancement

Why This is VITAL:
OpenELIS serves laboratories in resource-limited settings in 30+ countries where:

  • Internet connectivity is unreliable (frequent outages, low bandwidth)
  • Critical lab operations cannot stop when internet fails
  • Current system requires constant online connection (frontend + backend tightly coupled)
  • Data loss risk when network disconnects during sample entry, test results, or analysis

Impact: This enables OpenELIS to function in offline mode, making it mission-critical for areas without stable internet.
Project Scope (GSOC 3-month timeframe)

Phase 1 (M1): Backend - Offline Data Sync Architecture
Implement queued transaction system for offline operations
Create delta sync protocol (only changed data syncs when reconnected)
Build conflict resolution for concurrent edits (sample moved offline vs online)
Add data integrity validation on reconnection

Technologies: Spring Boot background tasks, Liquibase versioning, Event sourcing

Phase 2 (M2): Frontend - Service Worker Enhancement
Expand existing service worker (currently partial implementation) to full offline-first pattern
Implement optimistic UI updates (immediate feedback, sync later)
Add offline status indicator (show user when data is pending sync)
Cache critical workflows: sample entry, test results, analysis

Technologies: Service Workers, IndexedDB, React, Carbon Design System

Phase 3 (M3): Critical Features for Field Labs
Sample Status Tracking: Record sample receipt, assignment, testing offline
Analyzer Result Import: Accept analyzer files when offline, queue for import
Result Entry: Record test results offline, sync on reconnection
Audit Trail: Track all offline operations with sync timestamps

cc: @Moses_Mutesasira @caseyi

1 Like
8

Hi @Moses_Mutesasira @caseyi @Agaba_Derrick_Junior ,

This proposal strongly aligns with my prior experience.
I’ve worked on an offline-first Android health application deployed in rural villages where internet connectivity was unreliable. The app supported offline data capture, local storage, and delayed sync, ensuring no data loss during critical health workflows.

I collaborated closely with an NGO, and the solution was used in immediate, real-world healthcare scenarios, making offline capability mission-critical rather than optional.

Because of this background, I clearly understand the challenges around offline transactions, sync conflicts, audit trails, and data integrity, and I’m confident I can contribute effectively to this OpenELIS offline-first PWA enhancement.