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
500
初めてのAPI開発のアーキテクチャ
https://metaps.connpass.com/event/307900/
ミカイ
February 16, 2024
Tweet
Share
More Decks by ミカイ
See All by ミカイ
フリーランスになる前にやるべきこと ランキング1位が 意外だった件
junmikai
0
2
作りたいものがない時に進む道 〜 プログラミングを続けるための新しい視点
junmikai
0
4
職務経歴書を書くときの_ポイント1選.pdf
junmikai
0
20
炎上案件を通して 筋肉の成長を諦めた件
junmikai
0
34
フリーランス 勇気が9割
junmikai
0
20
シャイエンジニアのコミュニティ論
junmikai
0
41
雑談はファンタジーである
junmikai
0
10
未来のキャリアは「ヘアサロン」現象
junmikai
0
13
コメントアウトするべきでは「ない」こと
junmikai
0
14
Featured
See All Featured
Infographics Made Easy
chrislema
239
18k
Debugging Ruby Performance
tmm1
72
12k
Large-scale JavaScript Application Architecture
addyosmani
508
110k
The Pragmatic Product Professional
lauravandoore
31
6.2k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
GraphQLとの向き合い方2022年版
quramy
43
13k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Docker and Python
trallard
39
3k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
GitHub's CSS Performance
jonrohan
1030
450k
The Language of Interfaces
destraynor
153
23k
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(データアクセス層) • 例えばデータの加工やエラーハンドリングなど
• ロジックは全部加工職人に任せるので記述量がデカくなり がち
設計の参考に なれば幸いです
ご清聴ありがとうござ います!