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

3 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!!!