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
510
初めてのAPI開発のアーキテクチャ
https://metaps.connpass.com/event/307900/
ミカイ
February 16, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
フリーランスになる前にやるべきこと ランキング1位が 意外だった件
junmikai
0
5
作りたいものがない時に進む道 〜 プログラミングを続けるための新しい視点
junmikai
0
7
職務経歴書を書くときの_ポイント1選.pdf
junmikai
0
22
炎上案件を通して 筋肉の成長を諦めた件
junmikai
0
43
フリーランス 勇気が9割
junmikai
0
23
シャイエンジニアのコミュニティ論
junmikai
0
48
雑談はファンタジーである
junmikai
0
11
未来のキャリアは「ヘアサロン」現象
junmikai
0
13
コメントアウトするべきでは「ない」こと
junmikai
0
14
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
39
2.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Designing for humans not robots
tammielis
249
25k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Producing Creativity
orderedlist
PRO
341
39k
What's new in Ruby 2.0
geeforr
342
31k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Why Our Code Smells
bkeepers
PRO
334
57k
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(データアクセス層) • 例えばデータの加工やエラーハンドリングなど
• ロジックは全部加工職人に任せるので記述量がデカくなり がち
設計の参考に なれば幸いです
ご清聴ありがとうござ います!