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
550
初めてのAPI開発のアーキテクチャ
https://metaps.connpass.com/event/307900/
ミカイ
February 16, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
今からフロントエンドを0から勉強するならSvelteもありかも
junmikai
0
21
tsoaはいいぞ!APIドキュメントを自動生成!
junmikai
0
10
生成AI活用はHOWが大事な理由
junmikai
0
110
2025年の抱負: フリーランスから 正社員に戻るので 組織に貢献します!
junmikai
0
65
Chakra UI v3にバージョンアップしてほぼ別物になった件
junmikai
0
350
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
5
成長するには「重要 VS 緊急」を意識しよう
junmikai
0
10
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
12
目標は「めいそう」が大事。漢字はどう書く?
junmikai
2
24
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Become a Pro
speakerdeck
PRO
28
5.3k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
The Pragmatic Product Professional
lauravandoore
33
6.6k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
180
53k
What's in a price? How to price your products and services
michaelherold
245
12k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
122
52k
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(データアクセス層) • 例えばデータの加工やエラーハンドリングなど
• ロジックは全部加工職人に任せるので記述量がデカくなり がち
設計の参考に なれば幸いです
ご清聴ありがとうござ います!