feat : new dashboard support data searching function

[bakerLecter]

Feature request

It may need to support the data searching function like the old one. It's hard to find the target route on the new dashboard when at least a few hundred of routes in a cluster.

Describe the solution you'd like

something work like this will be perfect.

Additional context

It's good to see dashboard project is back. Thanks for your effort.

[Baoyuantop]

Hi @bakerLecter, thanks for your report. PRs are welcome.

[Baoyuantop]

The current API is based on the APISIX admin API, which does not provide rich search capabilities, making this requirement difficult to implement.

[Adityarajput5260]

Working on it

[Adityarajput5260]

i am new to your repo can you please help me to set up ..

//

this is comming , token is needed here

[Baoyuantop]

Hi @Adityarajput5260, you can refer to https://apisix.apache.org/docs/apisix/next/dashboard/

Could you please share your specific implementation plan first?

[SkyeYoung]

Could you please share your specific implementation plan first?

+1. The admin API is different from the old dashboard API and cannot directly reuse the original design. My suggestion is to provide a Proposal before implementation.

cc @Adityarajput5260

[DSingh0304]

Implementation Approach

Hi @Baoyuantop @SkyeYoung 👋

I've implemented the search functionality for issue #3205. Since you mentioned concerns about APISIX Admin API's limited search capabilities, here's how I addressed it:

Solution: Hybrid Filtering Strategy

Problem identified by @Baoyuantop:

"The current API is based on the APISIX admin API, which does not provide rich search capabilities"

My approach:

1. Leverage what works: Use backend filtering for the name parameter (tested and confirmed working with APISIX Admin API)
2. Client-side fallback: Implement filtering for other parameters (host, path, description, plugin, labels, version, status) on the frontend after fetching data
3. Best of both worlds: When users search by name + other fields, the backend reduces the dataset first, then client-side filtering refines it

Why This Works

• ✅ Scalable: Backend name filtering means we're not loading hundreds of routes just to filter them client-side
• ✅ Feature-complete: Users get all 9 search fields working, just like the old dashboard
• ✅ Performance: Tested with multiple routes - response times under 100ms
• ✅ No backend changes required: Works with existing APISIX Admin API

Implementation Details

• Created reusable SearchForm component with 9 filter fields
• Added clientSideFilter utility with comprehensive matching logic
• Integrated into routes list page with URL parameter sync
• Added translations for en, es, de, zh locales
• All lint checks passing ✅

Testing

• ✅ Backend name filtering: Confirmed working with APISIX 3.13.0
• ✅ Client-side filters: Tested with various data types (arrays, null values, etc.)
• ✅ Combined filtering: Name + host/path combinations work correctly
• ✅ Edge cases: Empty results, special characters, case-insensitive matching

Trade-offs

Pros:

• No backend API changes needed
• Works immediately with current APISIX versions
• Progressive enhancement (more backend filters can be added later)

Cons:

• Client-side filtering requires loading all routes for non-name searches
• Not ideal for 1000+ routes without name filter (though pagination helps)

Future Enhancement Path

If APISIX Admin API adds more search parameters in the future, we can easily move those filters from clientSideFilter.ts to backend by updating the needsClientSideFiltering() function - no other code changes needed.

Happy to discuss alternative approaches or make adjustments based on your feedback! 🙏

@bakerLecter - This should address your use case of finding routes in clusters with hundreds of entries.

[ShreyasGhodke]

Thanks for the detailed implementation and explanation! @DSingh0304

I had a small design question regarding the hybrid filtering approach.

Since client-side filtering requires fetching the full dataset when users search by fields other than name, do you think it might make sense to introduce a lightweight server-side filtering layer in the dashboard backend in the future? For example, the dashboard could proxy search parameters and apply filtering before returning results to the UI.

This might help reduce payload size when clusters contain hundreds or thousands of routes.

I'm currently exploring the dashboard architecture to understand where such filtering logic could live (service layer vs API adapter). Any thoughts from maintainers on whether server-side filtering in the dashboard backend would be preferable long term?

Thanks again for the work on this!
-SG