In this guide
Every web app a student builds eventually needs a search box: a library catalogue, a hostel room list, a notes portal, a lost-and-found board. Users type a few letters and expect the right rows back in under a second. Getting that to work well is not one feature — it is a small pipeline of matching, ranking, and paging, and each part has a cheap version and a correct version.
This guide walks through that pipeline the way you would actually build it: start with simple filtering, move the work to the database when the data grows, add full-text search when simple matching stops being enough, and finish with pagination and a responsive input so the feature feels finished instead of half-built.
Quick answer
Search in a student web app usually means matching a typed query against one or two text columns, returning the best matches first, and showing them ten or twenty at a time. For a few hundred rows, filtering in the browser or a SQL LIKE query is enough. For thousands of rows, or when users expect partial words and ranked results, use the database's full-text search. Debounce the input so a request fires only after the user pauses typing, and always paginate — never send the whole table to the browser.
What search actually has to do
A search box looks simple, but it hides four jobs:
- Match — decide which rows are relevant to the typed words.
- Rank — order the matches so the most likely result comes first.
- Page — return a small slice of the results, with a way to fetch the next slice.
- Respond fast — keep the round trip short enough that typing feels instant.
Most student search features fail on job 2 or 3, not job 1. They return every row that contains the letters, in database order, and dump all of them on one page. The result looks like search, but nobody can find anything in it.
Approach 1: filter in the browser
When the dataset is small — a few hundred rows that the page already loads — the simplest search is a JavaScript filter over the rows already on the page. No server call, no database query, and the result appears as the user types.
This works well for admin tables, short lists, and demo data. It stops working when the list grows: loading 10,000 rows into the browser just to filter them is slow, wastes memory, and sends data the user may never see. As a rule of thumb, if the full list takes more than a second to load, move the search to the server.
A basic client-side filter looks like this:
function filterRows(rows, query) {
const q = query.trim().toLowerCase();
if (!q) return rows;
return rows.filter((row) =>
row.title.toLowerCase().includes(q) ||
row.author.toLowerCase().includes(q)
);
}
Keep the comparison case-insensitive, trim the query, and search the fields users actually type — title and author for books, name and room number for hostel records. Searching every column, including IDs and internal codes, produces confusing matches.
Approach 2: SQL LIKE on the server
Once the data lives in a database, the natural next step is a LIKE query. The server receives the query string, searches the relevant columns, and returns the matching rows. This keeps the browser light and works for thousands of rows.
@app.route("/api/books")
def search_books():
q = request.args.get("q", "").strip()
pattern = "%" + q + "%"
rows = db.execute(
"SELECT id, title, author FROM books "
"WHERE title LIKE ? OR author LIKE ? "
"ORDER BY title LIMIT 20",
(pattern, pattern),
).fetchall()
return jsonify([dict(r) for r in rows])
Two details matter here. First, the query value is passed as a parameter, never pasted into the SQL string — pasting user input into SQL is how injection attacks happen, and parameterized queries close that hole completely. Second, the query is capped with LIMIT 20. An uncapped search that returns 5,000 rows will be slow and will flood the page.
LIKE has real limits, though. It matches substrings, so searching for "net" also matches "network" and "planet". It cannot rank — a title match and a description match look identical. And a leading wildcard (%net) cannot use a normal index, so it scans the whole table. For a student project with a few thousand rows that scan is still fast, but it does not scale, and the ranking problem remains.
Approach 3: full-text search in the database
When users expect search to behave like a real search engine — partial words, multiple words, best match first — use the database's built-in full-text search instead of LIKE. SQLite has FTS5, MySQL has FULLTEXT indexes, and PostgreSQL has tsvector. All three are free, built in, and far better than LIKE for this job.
The idea is the same in each: the database builds an index of the words in your text columns, then answers a query against that index and scores the matches. In SQLite, a minimal setup looks like this:
# One-time setup: a virtual table that indexes title and author
db.execute("CREATE VIRTUAL TABLE books_fts USING fts5(title, author)")
# Searching it, with results ranked by relevance
db.execute(
"SELECT title, author FROM books_fts "
"WHERE books_fts MATCH ? ORDER BY rank LIMIT 20",
(q,),
)
Full-text search handles the cases LIKE gets wrong: searching for "data structures" finds rows containing both words, ranks a title match above a passing mention in the description, and ignores stop words like "the" and "of" in most setups. The trade-off is a second table to keep in sync — when a book is added or edited, the full-text table must be updated too. For a student project this is usually a handful of lines in the same function that writes the main table.
Choosing between the three approaches
| Situation | Best approach |
|---|---|
| Under ~500 rows, already loaded on the page | Browser filter |
| A few thousand rows, exact substring match is fine | SQL LIKE with LIMIT |
| Users type several words and expect the best match first | Full-text search (FTS5 / FULLTEXT / tsvector) |
| Searching across many tables or files | Full-text search, or a dedicated search service |
| Results must respect who is logged in | Server-side search with a permission filter in the query |
Start with the simplest approach that fits your data size today, and switch when you feel the pain — slow loads, irrelevant results at the top, or users complaining they cannot find things. Do not build a dedicated search service for a 500-row table.
Pagination: never send everything
Pagination is the part students skip, and the part users notice first. A search that returns 400 rows and renders them all makes the page heavy, the scroll endless, and the browser sluggish on a low-end phone.
The standard pattern is offset pagination: the client asks for page N with a fixed page size, and the server skips the earlier rows.
page = int(request.args.get("page", 1))
size = 20
offset = (page - 1) * size
rows = db.execute(
"SELECT id, title, author FROM books "
"WHERE title LIKE ? ORDER BY title LIMIT ? OFFSET ?",
(pattern, size, offset),
).fetchall()
Return the total count alongside the rows so the page can show "Page 2 of 18" and disable the Next button on the last page. Counting costs one extra query, but it is a cheap one.
Offset pagination has one quirk worth knowing: if rows are added or deleted between page requests, a row can appear twice or be skipped. For a student project this is a minor edge case. For feeds where new items arrive constantly, cursor pagination — asking for "rows after this ID" — is the more robust pattern, and it is worth learning once offset pagination feels comfortable.
Making the input feel responsive
A search box that fires a request on every keystroke will send ten requests for a ten-letter word, and the responses can arrive out of order, so the box briefly shows stale results. The fix is debouncing: wait until the user stops typing for a short pause, about 250–300 milliseconds, then send one request.
let timer;
input.addEventListener("input", () => {
clearTimeout(timer);
timer = setTimeout(() => runSearch(input.value), 300);
});
Two more touches make a big difference. Show a small "Searching…" indicator while the request is in flight, so users know the app heard them. And if the query box is empty, show a sensible default — the newest items, or the most popular ones — instead of an empty page or the entire table.
Common mistakes
- Searching with the query pasted into SQL. Always use parameters. This is the single most important rule in this guide.
- Returning every match. Cap results with LIMIT and paginate. An uncapped query is a performance bug waiting for a large dataset.
- No ranking. If a title match and a footnote match sort the same way, users lose trust in the search and stop using it.
- Case-sensitive matching. Lowercase both sides, or use a case-insensitive comparison, so "Python" and "python" find the same rows.
- Ignoring empty queries. Decide what an empty search shows, and make it deliberate — newest, popular, or a prompt — not an accident.
- Firing a request per keystroke. Debounce, or the server gets hammered and results flicker.
Frequently asked questions
Should search run in the browser or on the server?
In the browser for a few hundred rows that are already loaded; on the server for anything larger, anything shared between users, or anything that must respect login permissions. Server-side search is the default for real apps.
Is LIKE enough for my project?
Usually yes, if the table has a few thousand rows and you only need substring matching. Move to full-text search when ranking matters, when users type several words, or when LIKE queries start feeling slow.
How do I search across multiple fields, like title and author?
Search each field with OR in the same query, and order the results so title matches come first. In full-text search this ranking is built in; with LIKE, add a CASE expression in ORDER BY that scores title matches above author matches.
Why does my search return nothing for a word I know exists?
The usual causes are case sensitivity, extra spaces in the query, or the word living in a column you did not include in the WHERE clause. Trim the query, lowercase both sides, and check which columns the query actually covers.
How many results should one page show?
Ten to twenty is the comfortable range for a list. Fewer feels fiddly, more feels endless. Match the page size to the row height — a compact table can show twenty, a card layout with cover images is happier at ten.
Limitations
Browser filtering and LIKE cover most student projects, but they are not a search engine. They do not handle spelling mistakes, synonyms, or searching inside uploaded files such as PDFs. Full-text search in SQLite or MySQL is a big step up, yet it still ranks by word frequency, not by meaning — a query for "cheap hostel near college" will not understand that "affordable" means the same thing. Those problems are what dedicated search tools solve, and they are a reasonable next step once the basic pipeline in this guide is working and you can measure where it falls short.