SquidSpirit a5f66616c4
All checks were successful
Frontend CI / build (push) Successful in 1m8s
BLOG-104 Implement CRUD functionality for Posts (#108)
### Description

This pull request introduces the core functionality for creating and updating posts, completing the backend CRUD operations for the `post` feature. It includes new API endpoints, database schema changes, and corresponding updates across the entire application stack from the database layer to the frontend.

#### Backend API

-   **Added new authenticated endpoints:**
    -   `POST /post`: To create a new post.
    -   `PUT /post/{id}`: To update an existing post.
-   Implemented the full vertical slice for these operations, including:
    -   `CreatePostUseCase` and `UpdatePostUseCase`.
    -   Repository and DB service methods for creating, updating, and associating posts with labels.
    -   Transactional database operations to ensure data integrity when creating/updating posts and their associated labels.

#### Database

-   Added a new migration to include an `"order"` column in the `post_label` table.
-   This column preserves the user-defined order of labels for each post.
-   Queries have been updated to fetch and sort labels based on this new column.

#### API Schema & Documentation

-   Enhanced `utoipa` OpenAPI documentation with more specific formats for data types:
    -   `#[schema(format = Uri)]` for URLs like `preview_image_url`.
    -   `#[schema(format = Email)]` for user emails.
    -   `#[schema(format = DateTime)]` for timestamps.
-   Standardized the `published_time` field to use the RFC3339 string format instead of a numeric timestamp, improving API clarity and interoperability.

#### Frontend

-   Updated the `PostInfoResponseDto` in the frontend to correctly parse the new `DateTime` (ISO string) format for `published_time`.

#### Refactoring

-   Renamed `get_full_post` to a more descriptive `get_post_by_id` across the post feature module for better code clarity.

### Package Changes

```toml
utoipa = { version = "5.4.0", features = [
    "actix_extras",
    "non_strict_integers",
    "url",
] }
```

### Screenshots

_No response_

### Reference

Resolves #104

### Checklist

- [x] A milestone is set
- [x] The related issuse has been linked to this branch

Reviewed-on: #108
Co-authored-by: SquidSpirit <squid@squidspirit.com>
Co-committed-by: SquidSpirit <squid@squidspirit.com>
2025-08-02 14:35:27 +08:00

Blog

Development

  • Frontend: SvelteKit with Tailwind CSS
  • Backend: Rust actix-web

Despite SvelteKit being a full-stack framework, I still decided to adopt a separate front-end and back-end architecture for this blog project. I believe that this separation makes the project cleaner, reduces coupling, and aligns with modern development practices. Furthermore, I wanted to practice developing a purely back-end API.

As for the more detailed development approach, I plan to use Clean Architecture for the overall structure. Of course, such a small project may not necessarily require such complex design patterns, but I want to give myself an opportunity to practice them.

These will allow me to become more proficient in these modern development practices and leave a lot of flexibility and room for adjustments in the future.

For more information about the development process, you can check out the project board. As for the details of the architecture and convention, you can find them in the wiki.

License

This project uses a combination of the MIT License and a custom license. Based on the MIT License, anyone is permitted to use the code. However, before deploying the code, they must first replace any information belonging to "me" or any content that could identify "me," such as logos, names, and "about me" sections.

Description
📕 My personal blog
https://squidspirit.com/
Readme 2.7 MiB
Languages
Rust 68.7%
TypeScript 14.7%
Svelte 12.9%
JavaScript 1.5%
Dockerfile 0.9%
Other 1.3%