Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
初めてのAPI開発のアーキテクチャ
Search
ミカイ
February 16, 2024
0
560
初めてのAPI開発のアーキテクチャ
https://metaps.connpass.com/event/307900/
ミカイ
February 16, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
今からフロントエンドを0から勉強するならSvelteもありかも
junmikai
0
35
tsoaはいいぞ!APIドキュメントを自動生成!
junmikai
0
21
生成AI活用はHOWが大事な理由
junmikai
0
120
2025年の抱負: フリーランスから 正社員に戻るので 組織に貢献します!
junmikai
0
76
Chakra UI v3にバージョンアップしてほぼ別物になった件
junmikai
0
480
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
5
成長するには「重要 VS 緊急」を意識しよう
junmikai
0
10
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
15
目標は「めいそう」が大事。漢字はどう書く?
junmikai
2
29
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
140
7k
Site-Speed That Sticks
csswizardry
10
680
GitHub's CSS Performance
jonrohan
1031
460k
Designing Experiences People Love
moore
142
24k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Code Review Best Practice
trishagee
69
18k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Rails Girls Zürich Keynote
gr2m
94
14k
Automating Front-end Workflow
addyosmani
1370
200k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Transcript
はじめてのAPI開発 アーキテクチャ設計 三海 純(ミカイジュン)
自己紹介 • 三海純(ミカイ ジュン) • 現在フリーランスエンジニア ◦ Next.jsの新規開発・設計 + Laravel
◦ Python API新規開発・設計 • 趣味 ◦ アニメ(BanG Dream!・ぼざろ 等) ◦ ネット麻雀(雀魂・雀豪)
キャリア • 2020/06 - 2022/02: 正社員(受託企業) ◦ Vue.js/Nuxt.jsをメイン • 2022/03
- 2023/09: 正社員(自社開発) ◦ バックエンドはPython / Nest.js(Node.js) ◦ フロントエンドはReact.jsとNext.js • 2023/10 - : フリーランス(自社開発) ◦ Next.jsの設計とバックエンド実装を担当 ◦ Python APIの新規開発・設計
アーキテクチャ設計 っていうとどんな イメージですか?
None
はっきり言いますね
None
こんな自分が API開発の 0→1を行うことに
無闇に開発するのも あれなので それっぽく設計した
・バックエンドはAPIのみ開発。俗にいうマ イクロサービスというやつです ・リリースしたら終わり!という訳ではない (はず) 前提条件
っdd 補足: APIとは(get) データ欲しいです データです
っdd 補足: APIとは(post・put) 保存したいです 保存成功しました
今回採用したのが
3層アーキテクチャ 引用元:https://qiita.com/os1ma/items/7a229585ebdd8b7d86c2
3層アーキテクチャとは? • プレゼンテーション層 ◦ ユーザーインターフェースを担当します。ユーザーからの入力を受 け取り、処理結果を表示します。 • ビジネスロジック層 ◦ ビジネスロジックを担当します。データの処理や計算を行い、プレゼ
ンテーション層とデータアクセス層の間の橋渡し役を務めます。 • データアクセス層 ◦ データベースへのアクセスを担当します。アプリケーション層からの 要求を受け、データベースからデータを取得したり、データを更新し たりします。
専 門 用 語 時 間
っdd 簡単にしてみました 窓口 (プレゼンテーション層) 収納Box (データアクセス層) 加工職人 (ビジネスロジック層) 使用ユーザー 〇〇のデータください
〇〇のデータです データ送受信
ディレクトリ構成はこうなる root ├── controller(窓口) ├── services(加工職人) └── repositories(収納Box)
っdd 赤枠部分が3層アーキテクチャ 窓口 (プレゼンテーション層) 収納Box (データアクセス層) 加工職人 (ビジネスロジック層) 使用ユーザー 〇〇のデータください
〇〇のデータです データ送受信
っdd 窓口の役割 窓口 (プレゼンテーション層) 収納Box (データアクセス層) 加工職人 (ビジネスロジック層) 使用ユーザー 〇〇のデータください
〇〇のデータです データ送受信
窓口(プレゼンテーション層) • ユーザーからの入力を受け取り、処理結果を表示する • 収納Box(データアクセス層)に以下のような命令をする ◦ データください ◦ データを更新してください
◦ データを削除してください • 逆にいうとそれ以外のロジックはここでは行わない
っdd 収納Boxの役割 窓口 (プレゼンテーション層) 収納Box (データアクセス層) 加工職人 (ビジネスロジック層) 使用ユーザー 〇〇のデータください
〇〇のデータです データ送受信
収納Box(データアクセス層) • データベース(DB)から取得したり、保存したりする ◦ MySQL ◦ Firebase など •
逆にいうとデータの加工やエラーハンドリングなどは行わな い • 理論上、DB移行を行う時はこの層しか触らない ◦ Firebase→MySQL移行など
っdd 加工職人の役割 窓口 (プレゼンテーション層) 収納Box (データアクセス層) 加工職人 (ビジネスロジック層) 使用ユーザー 〇〇のデータください
〇〇のデータです データ送受信
加工職人(ビジネスロジック層) • 以下のこと「以外」は全て担当 ◦ 窓口(プレゼンテーション層) ◦ 収納Box(データアクセス層) • 例えばデータの加工やエラーハンドリングなど
• ロジックは全部加工職人に任せるので記述量がデカくなり がち
設計の参考に なれば幸いです
ご清聴ありがとうござ います!