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
520
初めてのAPI開発のアーキテクチャ
https://metaps.connpass.com/event/307900/
ミカイ
February 16, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
成長するには「重要 VS 緊急」を意識しよう
junmikai
0
2
LTのテーマ決めは「多数派」を意識しよう ~ LT年40回登壇した件~
junmikai
0
0
目標は「めいそう」が大事。漢字はどう書く?
junmikai
2
11
技術選定で迷ったら『日常』を思い出そう! 〜考え方の新発見〜
junmikai
0
51
今年最も「覚醒」したコーディングテストの舞台裏
junmikai
0
8
フリーランスから正社員に戻ったお話し
junmikai
0
9
面接で価値観が変わった件
junmikai
0
12
SQLを克服する1冊
junmikai
0
4
美と機能のバランス ~フロントエンジニアに必要なUI・UXセンス~
junmikai
0
3
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Designing for humans not robots
tammielis
250
25k
We Have a Design System, Now What?
morganepeng
51
7.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Code Reviewing Like a Champion
maltzj
520
39k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
Writing Fast Ruby
sferik
628
61k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Music & Morning Musume
bryan
46
6.2k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
440
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
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(データアクセス層) • 例えばデータの加工やエラーハンドリングなど
• ロジックは全部加工職人に任せるので記述量がデカくなり がち
設計の参考に なれば幸いです
ご清聴ありがとうござ います!