Skip to content
Antoine Boucher

SpringBootFilesUploader: File bytes and metadata on separate paths

SpringBootFilesUploader is a Kotlin and Spring backend with a file-upload path that separates binary storage from document metadata. A file identifier returned to the client connects those two representations during download.

Application and services
  • Updated
  • Kotlin · 99.52%
  • MIT
View source README
Repository languagesKotlin 99.52%3

Shares calculated from GitHub Linguist bytes.

Language%Bytes
Kotlin99.52%68,077
Java0.31%214
Dockerfile0.17%114

GitHub · README · Language statistics

Overview

Why it exists

Spring Boot microservice written in Kotlin with streaming multipart file upload and integrity validation.

Best fit

High-throughput file ingestion and storage backend.

Getting started

These commands come from the repository documentation. They were not run during this review.

Repository references

The repository does not provide a detailed guide for these steps. Start with its README and the source walkthrough above.

Source documentation

1 documents read from 1 candidates.

Features and components 2

HTTP validation
FilesController accepts a multipart document, checks its filename extension and declares moderator/admin upload roles. The size-check block is commented out. Downloads use a file ID and return stored content type and length.
Storage coordination
FilesService creates a UUID-based path and sends bytes to FileRepository. It then saves a FileModel through FilesMongo. Reads look up the metadata first, then use its path to retrieve the bytes.

Architecture

The components and their connections remain available as text. The diagram adds an interactive view.

System context Context
  1. Multipart upload
  2. FilesController
  3. FilesService
  4. FileRepository binary storage
  5. FilesMongo metadata
  6. File ID response

Links verified in the repository.

Mermaid Interactive diagram (loads on open)

System overview of the components and connections verified in the repository.

Static architecture view for SpringBootFilesUploader
Static preview. The interactive diagram replaces it after Mermaid loads.
flowchart LR
  n0["Multipart upload"]
  n1["FilesController"]
  n2["FilesService"]
  n3["FileRepository binary storage"]
  n4["FilesMongo metadata"]
  n5["File ID response"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n2 --> n4
  n4 --> n5
Text version of the diagram
  • Multipart upload → FilesController
  • FilesController → FilesService
  • FilesService → FileRepository binary storage
  • FilesService → FilesMongo metadata
  • FilesMongo metadata → File ID response
Follow one path through the code

Follow addDocument in FilesService: binary storage is written before metadata. If the second write fails, the first can leave an orphaned file. A production version needs cleanup or another explicit consistency strategy.

Types and file structure

81 declared types, with 12 in the base-relationship overview.

Type diagram
classDiagram
direction TB
class t26c1a3dc5125["FilesController"] {
  addDocument()
  getDocument()
}
class te841f2b44b30["FilesService"] {
  addDocument()
  getDocumentData()
  getDocumentInfo()
  getExtType()
}
class td9932b4881df["Application"] {
}
class t710fa2aa2d64["DockerConfig"] {
  dockerClient()
}
class ta335e3882e82["GeneralConfig"] {
  messageSource()
}
class tdcc31183d80f["S3Config"] {
  awsClient()
}
class t303a3f345023["SpringDocOpenAPI"] {
  customOpenAPI()
}
class t6d6a2852fe9e["WebClientConfig"] {
  httpClient()
}
class tbb8a532c7ab9["WebSecurityConfig"] {
  authenticationJwtTokenFilter()
  configure()
  authenticationManagerBean()
  passwordEncoder()
}
class t2d4df6b4ca46["AuthController"] {
  authenticateUser()
  registerUser()
  registerAdmin()
}
class tcac10360aa2f["CaddyController"] {
  getPing()
}
class t0f5aed8fe95a["DockerComposeController"] {
}
class b807ef8f8f99e["WebSecurityConfigurerAdapter"] {
  <<unresolved_base>>
}
tbb8a532c7ab9 ..> b807ef8f8f99e : declared base

Unresolved bases remain labelled; full signatures are not reconstructed.

Type index

Reference

60 / 60 eligible files read (70 in the tree); 0 oversized, 0 failed reads and 0 syntax diagnostics.

What the scan covers

Known dependency/build folders, credential files and binaries are excluded. The scan covers READMEs, recognized manifests and parser-supported source files.

Linguist statistics cover the whole repository and may include other languages.

File map
flowchart TD
  root["SpringBootFilesUploader"]
  f0["build.gradle.kts"]
  root --> f0
  f1["src/main/kotlin/com/api/project/controller/FilesController.kt"]
  root --> f1
  f2["src/main/kotlin/com/api/project/service/FilesService.kt"]
  root --> f2
  f3["README.md"]
  root --> f3
  f4["docker-compose.yml"]
  root --> f4
  f5["src/main/kotlin/com/api/project/Application.kt"]
  root --> f5
  f6["src/test/kotlin/com/api/project/ApplicationTests.kt"]
  root --> f6
  f7["src/main/kotlin/com/api/project/config/DockerConfig.kt"]
  root --> f7
  f8["src/main/kotlin/com/api/project/config/GeneralConfig.kt"]
  root --> f8
  f9["src/main/kotlin/com/api/project/config/S3Config.kt"]
  root --> f9
  f10["src/main/kotlin/com/api/project/config/SpringDocOpenAPI.kt"]
  root --> f10
  f11["src/main/kotlin/com/api/project/config/WebClientConfig.kt"]
  root --> f11
  f12["src/main/kotlin/com/api/project/constants/Constants.kt"]
  root --> f12
  f13["src/main/kotlin/com/api/project/controller/AuthController.kt"]
  root --> f13
  f14["src/main/kotlin/com/api/project/controller/CaddyController.kt"]
  root --> f14
  f15["src/main/kotlin/com/api/project/controller/DockerComposeController.java"]
  root --> f15

Files to read 3

References