Frontend service

This publication isolates the Frontend Architecture of SinPluma and explains it in depth: the technology stack, internal structure, routing model, state management strategy, page composition, and integration patterns with backend services.

The goal is to clearly demonstrate frontend engineering competency — not just UI development — but architectural thinking, maintainability, and scalability decisions.

SinPluma’s frontend is a Single Page Application (SPA) built with React. It is designed as a rich writing platform that allows users to:

• Create and edit notebooks
• Write structured content (multi-page documents)
• Upload and embed images
• Read published works
• Search for content
• Receive real-time writing assistance (linguistics feedback)

Although it delivers a user-facing writing experience, its internal architecture emphasizes:

• Component modularity
• Predictable state management
• Clear API abstraction
• Separation of presentation and business logic
• Scalable routing and layout structure

• React
  Component-based UI architecture. Functional components with hooks are used to encapsulate local state and lifecycle logic.

• React Router
  Client-side routing for SPA navigation. Enables URL-driven state (e.g.,/notebooks/:id,/read/:slug).

• Redux
  • Global application state management.
  • Stores authentication state, notebooks metadata, pages, and UI state.
  • Uses reducers to ensure deterministic state transitions.
  • Actions represent domain events (e.g.,CREATE_NOTEBOOK,LOAD_PAGES,LOGIN_SUCCESS).

This architecture separates:

• UI rendering (React components)
• State mutation logic (Redux reducers)
• Side effects (async API calls)

• Slate.js
  • A highly customizable rich-text editor framework.
  • Enables structured document editing (not just plain text).
  • Supports:
    • Inline formatting (bold, italic, headings)
    • Structured blocks
    • Embedded media
    • Custom plugins (e.g., sentiment feedback)

Slate was selected instead of simpler editors because:

• It exposes a document tree model.
• It allows fine-grained control over rendering and editing behaviors.
• It integrates cleanly with React state.

• Material-UI (MUI)
  • Provides standardized UI components.
  • Enables consistent visual system (buttons, forms, dialogs, app bars).
  • Theming support for centralized styling control.

This ensures visual consistency while keeping custom CSS minimal.

• Axios
  • HTTP client abstraction.
  • Centralized configuration for:
    • Base URL
    • Authorization headers (JWT)
    • Error interceptors
  • Used inside Redux async actions (thunks or similar middleware pattern).

The frontend follows a layered SPA architecture:

Reusable UI building blocks:

• Editor components
• Toolbar components
• Navigation bars
• Page lists
• Modal dialogs

These components are generally:

• Stateless or minimally stateful
• Connected to Redux viauseSelectoranduseDispatch

Each major route corresponds to a high-level page component.

Key pages include:

1. Authentication Pages

• Login
• Register
• Password validation flow

Handles:

• Form validation
• JWT acquisition
• Redux auth state updates

2. Dashboard / Notebooks Page

• Lists user notebooks
• Allows creation and deletion
• Fetches data from/api/notebooks

State flow:

1. Page loads
2. Dispatch async action
3. API response stored in Redux
4. UI re-renders based on global state

3. Notebook Editor Page

• Central writing experience
• Integrates Slate editor
• Loads pages dynamically
• Saves changes via API

Key responsibilities:

• Maintain current page content
• Handle autosave logic
• Display inline image embeds
• Trigger linguistics analysis

This page is the most complex and contains:

• Editor state management
• Debounced save operations
• Optimistic UI updates

4. Reader Page

• Public reading view for published works
• Clean, minimal UI
• Stateless content rendering
• Fetches by slug or ID

5. Search Page

• Query input
• Results listing
• API-driven content rendering

The application uses a predictable data flow model:

1. User action triggers dispatch.
2. Async action performs API request.
3. Response updates Redux store.
4. React components re-render from updated state.

This ensures:

• Deterministic UI updates
• Clear debugging path
• Separation of concerns

• Login request → backend returns JWT.
• JWT stored in Redux and optionally local storage.
• Axios attaches JWT to subsequent requests.
• Logout clears token and state.

• Editor selects file.
• Frontend sends multipart request.
• Backend stores in MinIO.
• URL returned and embedded in Slate document structure.

• Editor sends sentence text.
• Receives sentiment classification.
• UI visually indicates tone or structure.

This interaction is stateless and lightweight.

The frontend is containerized using Docker:

• Production build created usingnpm run build.
• Static files served through Nginx.
• Environment variables injected during build time.
• Service is deployed behind reverse proxy for API routing.

This makes the frontend:

• Portable
• Environment-configurable
• Easily deployable alongside backend services

• Clear separation between UI, state, and side effects.
• Rich document model using Slate.
• Predictable global state via Redux.
• Modular page-based routing.
• Scalable component organization.
• Clean API abstraction via Axios.
• Containerized and environment-driven deployment.

• Redux introduces boilerplate for smaller components.
• No dedicated client-side caching layer (e.g., React Query).
• Search UX tightly coupled to backend SQL search.
• No SSR (server-side rendering), limiting SEO for public content.

The SinPluma frontend is not merely a UI — it is a structured client application with:

• Modular component design
• Predictable state transitions
• Rich text document modeling
• Clean API abstraction
• Production-ready containerized build

It demonstrates strong frontend engineering fundamentals:

• State architecture discipline
• Editor integration complexity
• Real-world API consumption
• Maintainable SPA routing structure