More project photos (3)
The problem
In most student teams and small companies, critical knowledge lives in chat scrollback, screenshots and one person's head — when they leave, it leaves with them. Wikis fix this only if people actually use them, and people use them only if writing is pleasant and finding is instant. This project builds a wiki engineered for both: a Markdown editor with live preview and slash-command formatting, full-text search over titles, bodies and tags with relevance ranking, nested spaces for Engineering / Product / Ops, every edit stored as a revision with diff view, and a lightweight review workflow so runbooks can be marked verified. Related-article suggestions keep readers discovering instead of re-asking.
Writes articles in Markdown.
Follow the working sequence
How it works
- Authors write in Markdown in the split-pane editor; the client renders a live preview with the same renderer used on the article page.
- On save, the article body is stored as a new revision row linked to the article, keeping the full history immutable.
- A database trigger (or save hook) updates the article's full-text search vector from its title, body and tags for ranked retrieval.
- Search queries run against the text index with ranking by match position and field weight; snippets are generated with match highlighting.
- Readers navigate spaces in the sidebar; breadcrumbs reflect the article's nesting path.
- Reviewers move articles through Draft → In review → Verified; only the latest verified revision shows the verified badge.
- Related articles are computed from shared tags and body-term overlap, refreshed on save.
Tech stack:
- Node.js + Express (app server)
- PostgreSQL full-text search (tsvector ranking)
- Markdown renderer (server + client)
- EJS/templated frontend (or React — build choice documented)
- JWT + space-level RBAC
- Redis (search and article cache)
- Docker + docker-compose
| Parameter | Value |
|---|---|
| Articles supported | Approximately 100,000 with indexed search (expected) |
| Search latency | Approximately under 500 ms on 10k articles (design target) |
| Revisions | Unlimited per article; diff view included (design target) |
| Nesting depth | Unlimited spaces/sub-pages (design target) |
| Concurrent editors | Last-save-wins with conflict warning (expected) |
| Export | Markdown source per article (design target) |
| Auth | JWT sessions + space roles (design target) |
| Deployment | Docker compose: app + PostgreSQL + Redis (design target) |
Project features
- [Markdown editor with live preview] Split-pane writing with instant rendered preview, tables, callouts and fenced code blocks.
- [Full-text search] PostgreSQL full-text indexing over titles, bodies and tags with ranked results and match highlighting, typically answering in well under a second.
- [Spaces and nesting] Articles organized into spaces with unlimited nesting for runbooks, policies and specs.
- [Version history] Every save creates a revision; browse history, compare diffs and restore any earlier version.
- [Review workflow] Articles carry Draft / In review / Verified status so teams know which runbooks are trustworthy.
- [Related articles] Tag and content-overlap suggestions surface relevant pages at the bottom of every article.
- [Permissions] Space-level view/edit roles so HR policies and engineering runbooks don't share an audience.
- [Table of contents] Auto-generated per-article TOC from headings for long runbooks.
What is included
- Wiki frontend (reader, editor with live preview, search UI, spaces sidebar)
- Backend API (articles, revisions, search, reviews, permissions)
- PostgreSQL schema with full-text indexes and seed knowledge base
- Docker compose setup for one-command run
- Project report PDF (search design, versioning model, permission design, methodology, results)
- PPT presentation for final review
- Viva Q&A preparation document (full-text search internals, Markdown parsing, RBAC)
Limitations & prerequisites
- Concurrent editing of the same article is last-save-wins with a conflict warning — there is no Google-Docs-style character-level merging.
- Search covers article text and tags only; attached files are not content-indexed.
- The permission model is space-level, not per-article — fine-grained exceptions are future scope.
- Real-time collaborative cursors in the editor are not included; edits sync on save.
- Export is per-article Markdown; whole-space PDF export is future scope.
- The demo ships with English-language search configuration; other languages need the matching text-search dictionary configured.
Frequently Asked Questions
How does the search actually work?
Article titles, bodies and tags are indexed into a PostgreSQL full-text search vector on every save. Queries are parsed into lexemes, matched against the index, and ranked by field weights (title hits outrank body hits), with highlighted snippets generated per result.
Why not just use a shared drive or chat pins?
Drives have no versioning, review state or search ranking; chat pins rot. The wiki gives every article a history, a trust state (verified or not) and instant search — the three things that make documentation survive team churn.
What happens when two people edit the same article?
The second save wins, but the editor warns that the article changed since it was opened and offers a diff view, so no edit is ever silently lost — every revision stays restorable.
Can some spaces be private?
Yes — spaces carry view/edit roles, so an HR space can be restricted while Engineering stays open, all inside one wiki.
Is the content portable?
Every article stores clean Markdown source, exportable individually, so the knowledge base is never locked into the app.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and Web Development programs. It demonstrates full-text search engineering, content versioning, access-control design and a polished editorial UX. Suitable for B.E./B.Tech final-year projects in Computer Science, IT and Web Development.
Components & software requirements
- Node.js + Express (app server)
- PostgreSQL full-text search (tsvector ranking)
- Markdown renderer (server + client)
- EJS/templated frontend (or React — build choice documented)
- JWT + space-level RBAC
- Redis (search and article cache)
- Docker + docker-compose
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.