A web application provides services to users through a browser, rather than merely publishing information. It uses HTTP to receive requests and return responses. A distributed web application can split that work among components that communicate over a network; the browser need not expose that backend structure to the user. section 1.0 section 1.1
In Actix Web, an HTTP server receives a request and passes it to an App. The App groups routes; each route pairs a path and HTTP method with a handler. For example, a browser GET to /health reaches a handler that returns a health response. Actix creates an application instance per worker thread, while async I/O lets an instance do other work as it waits for I/O. section 3.1.2 section 3.3
cfg.route(
"/health", #1
web::get() #2
.to(health_check_handler)); #3
The /health route shows the three pieces to locate when tracing a request: path, HTTP method and handler. section 3.1.2
For a server-rendered application, the handler produces the page as well as processing the request. It combines an HTML template with data from a database or web service, then sends the rendered page to the browser. A bank home page can be static, while an authenticated account page shows data specific to the customer. A template engine such as Tera supplies the dynamic values. section 7.1 section 8.4
A practical Rust application can grow in small steps:
- Serve a static HTML page from a dedicated Actix web-app project using actix-files. section 7.2
- Add routes and handlers that render Tera templates, then replace a mock tutor list with data fetched by an HTTP client from a backend REST service. Deserialize the JSON response into a typed tutor list. section 7.0 section 7.7
- Add forms and persistence: a browser POST submits registration data to a handler, which validates it, reports errors through the template, and stores user-management data locally. Store passwords as hashes rather than clear text. section 8.4
- Add sign-in and handlers for creating, updating and deleting data through HTTP requests. Keep request handlers, data models, database logic and templates in separate modules. section 9.0 section 9.8
Tutor frontend and backend
A tutor-list page receives GET /tutors at the frontend. Its handler requests tutor data from a separate backend service, interprets the JSON response and renders the list with Tera. Keeping that request behind the frontend avoids duplicating the service’s database-access logic or placing its database credentials in both applications. Registration details, by contrast, live in the frontend’s local database, while tutor profiles live in the backend service. section 7.7 section 9.0
Service design must also account for safety, reliability, resource use, latency and concurrency. Those concerns apply both within an individual service—for example, through async I/O—and across an architecture with multiple service instances. Server-side rendering is one approach; a single-page application is another. A working server-rendered frontend need not imply a complete HTML and JavaScript interface: remaining screens can be implemented separately while APIs are exercised with a command-line HTTP tool. section 1.2.1 section 7.0 section 9.0
