Coffee Products App

Coffee Product App

Section 1: Frontend with Svelte

Svelte SPA with the following features:

• CRUD Operations: Add, edit, and delete coffee products
• Persistence: Use local storage so that products remain after a page refresh
• Maintainability: Use Svelte stores and components for a clear structure
• Unit Testing: Use Vitest for tests

Section 2: Performance Optimization

Imagine that users are experiencing delays in the SPA. Below are three key performance issues and strategies to improve them:

1. Large Bundle Size / Unused Code:

Issue: A monolithic bundle can slow down initial load times.

Solution:

• Code Splitting & Lazy Loading: Break the app into smaller chunks. For example, lazy load components that aren’t needed immediately.
• Tree Shaking: Ensure unused code isn’t bundled by using modern build tools (Vite, Rollup) that support tree shaking.

2. Unoptimized Images:

Issue: High-resolution or uncompressed images can degrade performance.

Solution:

• Image Optimization: Use tools or services to compress images before serving them.
• Lazy Loading: Implement lazy loading for images so that they load only when scrolled into view.

3. Excessive DOM Updates:

Issue: Frequent re-renders, especially in large lists, may lead to sluggishness.

Solution:

• Svelte’s Reactivity: Use Svelte’s reactive declarations and keyed each blocks to minimize re-rendering.
• Virtualization: If the list grows large, consider using list virtualization (only render items in view).

Section 3: Backend & Database API

A simple Node.js API using Express and SQLite (as our relational database).

This API will have two endpoints:

GET /api/coffee-products (Retrieve all coffee products) POST /api/coffee-products (Add a new coffee product)

Database Schema Explanation

The schema for the coffee_products table includes:

• id: A unique identifier (auto-incremented primary key).
• name: The product’s name (required).
• description: A textual description of the product.
• price: The product’s price (required, stored as a real number).
• image: A URL or path to an image representing the product.

This simple schema is sufficient for demo purposes and can be extended as needed.

Section 4: Multi-Language Support (i18n) Refactor

In many applications, hardcoded strings make translation difficult. The recommended approach is to externalize all user-facing text and use an internationalization (i18n) library.

High-Level Architectural Approach

• Externalize Strings: Remove all hardcoded text from components and store them in separate JSON files for each language.
• Use an i18n Library: For Svelte, libraries like svelte-i18n are ideal.
• Dynamic Locale Selection: Load translations based on user preferences or browser settings.
• Fallbacks: Use a fallback language (e.g., English) when a translation is missing.

In any Svelte component, import the translation function and use it:

<script>
  import { t } from 'svelte-i18n';
</script>

<h1>{$t('welcome_message')}</h1>

This approach decouples text from code, making it easier to support new languages

Section 5: Security Enhancements

Even in a simple application, adding security measures is essential. Below are some recommended security elements along with technologies and tools we could use

Frontend (Svelte) Security Measures

Input Sanitization:

• Why: To prevent Cross-Site Scripting (XSS) attacks by ensuring that user-supplied content is sanitized before being rendered.
• How: Use libraries like DOMPurify if we're rendering HTML from user input.

Content Security Policy (CSP):

• Why: To restrict the sources from which content can be loaded, reducing the risk of malicious scripts.
• How: Configure CSP headers on the server (or in meta tags for static pages).

Backend (Node.js API) Security Measures

Helmet:

• Why: To set various HTTP headers that protect against common vulnerabilities (e.g., XSS, clickjacking).
• How:

const helmet = require('helmet');
app.use(helmet());

Input Validation:

• Why: To prevent SQL injection and other injection attacks by ensuring that only valid data is processed.
• How: Use validation libraries like Joi to validate incoming data.

CORS (Cross-Origin Resource Sharing):

• Why: To control which domains can access API, minimizing the risk of cross-origin attacks.
• How: Use the cors middleware and configure it to allow only trusted origins.

Rate Limiting:

• Why: To protect API from brute-force attacks and denial-of-service (DoS) attacks.
• How: Use middleware like express-rate-limit.

HTTPS Enforcement:

• Why: To secure data in transit by encrypting communication between the client and the server.
• How: Configure the server (or use a reverse proxy like Nginx) to redirect HTTP requests to HTTPS.

Final Thoughts

Svelte + TypeScript requires additional configuration (e.g., svelte-preprocess, typescript, tsconfig.json). For a 4-hour limitation, JavaScript avoids this overhead because we don't need to define interfaces/types for simple data structures like coffee products

AND ALSO:

Svelte’s has a built-in Runtime Safety:

Svelte’s compiler already catches many common errors at build time (e.g., unused variables, invalid props).

Runtime validation (e.g., form input checks) can be added manually for critical paths without TypeScript.