ブラウザからDBに行き着くまでただまとめる
はじめに あなたはブラウザからデータベース(DB)に情報が行き着くまでにどんな技術が使われているか説明できますでしょうか？ どのようなプロトコルが用いられ、どの技術を駆使してサーバと通信しているのか、Webサーバでは何が行われ、どのようにして負荷が分散されているのか、トランザクションはどのように管理されているのか、そしてデータベースではシャーディングや負荷対策のためにどのような対策が取られているのか… なんとなくは理解しているものの、私は自信を持って「こうなっている！！」とは説明ができません。 そこで今回は「大規模サービス」を題材としてブラウザからデータベースに至るまでの、情報の流れとその背後にある技術について、明確かつ分かりやすく解説していきたいと思います。 対象としてはこれからエンジニアとして働き出す、WEB、バックエンド、サーバーサイド、インフラ、SREを対象としております。 1.
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
ソフトウェアアーキテクチャ入門
はじめに 今回の記事では、ソフトウェアアーキテクチャの入門的な内容を解説する。 対象とする読者 ソフトウェアアーキテクチャを勉強するエンジニア アーキテクチャに関して全くわからない初心者 タイトルで気になったひと ソフトウェアアーキテクチャとは？ ソフトウェアのアーキテクチャは、システムの主要なコンポーネント、それらの関係（構造）、およびそれらがどのように相互作用するかを記述する。ソフトウェアのアーキテクチャとデザインには、品質属性、人間のダイナミクス、デザイン、IT環境など、多種多様な寄与要因が含まれる。アーキテクチャは、品質、保守性、パフォーマンス等のような全体的な成功に影響を与える重要な決定を含む。 ソフトウェアアーキテクチャの主な目的は、アプリケーションの構造に影響を与える要件を特定することだ。良好なアーキテクチャは、技術的な解決策を構築する際のビジネスリスクを削減し、ビジネス要件
Code Tour を使ってじっくり確実にコードを読む
日々のタスクに忙殺されていると、ついつい既存コードを流し読みして、ざっと動くコードを書いてしまいたくなります。 一発でうまく動けば短期的にはいいのですが、長期的にはコードの理解が追いつかなったり、一発でうまく動かなかった場合にかえって時間がかかってしまいます。 VSCode の拡張機能である Code Tour を使うと、コード上にメモを残しながら読み進めることができるので、既存のコードを読む際に便利です。 Code Tour とは VSCode の拡張機能で、コード上にメモを残しつつ、そのメモをたどることができるツールです。 使い方 ツアーを始める コマンドパレットから「Code Tour: Record Tour」を選択すると、ツアーの記録モードになります。 ツアーの名前 どのソースに紐づけるか（紐付けなし、ブランチ、タグ） を選択すると、リポジトリ直下に .tours/${指定したツ
その例外、いつキャッチするの？
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
この記事は一休.com Advent Calendar 2023 8日目の記事です。 2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。 『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。 前提 観点 どのようなサービスかを調べる どのようにデータを保持するかを調べる どのようなコードかを調べる 「未知の未知」をできるだけ早く減らす チームの開発体制に興味を持つ 所感 前提 レストラン予約のサービスの開発に参加した 歴史が長い（2006〜） Webアプリケーションを開発する 技術スタックは転職前後で完全に変わった 前: Rails, PHP, Nuxt, MySQLなど7年 後: Rust, Next.js, Python, Microso
【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています
アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
はじめに 僕はDeno Land Inc.でDenoを利用したサーバレスエッジホスティングサービスのDeno Deployを開発するチームに所属しています。OSSのほうのDenoのメイン言語はRustで、Deno Deployのバックエンドも同様にRustで書かれています。 今年のアドベントカレンダーで一休さんから以下の記事が公開されましたが、日本でもRustをWebバックエンドの言語として採用する企業がじわじわと増えてきている印象があります。 Deno DeployのバックエンドをRustで開発してきて、RustでWebバックエンドを書くことのメリットやデメリットをいくつか感じたので、この記事で紹介したいと思います。 Deno Deployの構成 まず、ざっくりとDeno Deployのバックエンドの構成を紹介します。 多くのコンポーネントがありますが、ここではどのようにRustを利用し
9ヶ月かけて全ての API を REST から GraphQL にリプレースした話 - がぶちゃんの日記
サマリー システム構成の変遷 創業フェーズ はじめての API と技術選定 GraphQL 移行直前 GraphQL への移行を決めたきっかけ GraphQL 移行方針 移行期間 ふりかえり 1つ目の方針は正解だった 2つ目の方針は微妙だったかもしれないけど、正解だったかもしれない 3つ目の方針はやはり苦戦した さいごに サマリー サービス開始から3年経った Next.js + Rails なシステム 全ての API を REST から GraphQL にリプレース 約9ヶ月かかりました 早速フロントエンドの都合でバックエンドにも手を入れるということが減って快適です という話です。 システム構成の変遷 創業フェーズ 1人目エンジニアとして入社して、何から手を付けようかなーと考えた結果、事業の肝の部分からシステム化していくことにしました。弊サービス https://moneiro.jp/ は
はじめに 4年ぶりの開催となるServerlessDays Tokyoに参加してきました https://tokyo.serverlessdays.io/ 「もっとうまくやりたい、誰よりも上手にやりたい」 というメッセージとともに開催されたServerlessDays Tokyo 2023ですが、超豪華なスピーカー陣を国内外から集め、ここ数年のServerlessの成熟と未来をしっかりと味わえる濃いイベントです。 1日目がセッション、2日目がワークショップということで、熱力の高いうちに激熱なサービスを素早く学べる構成になっていて、とても充実した内容でした。 所感 4年前のServerless LambdaをはじめとするFaaSをいかに簡単にデプロイ、運用していくかというツール系の話と S3やSQS,SNSなどのFaaS以外のServerlessなサービスの組み合わせでLowOpsな仕組みを
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
はじめに エンジニアの皆様、テストコードはちゃんと書けておりますでしょうか？（挨拶） どんな開発言語や開発手法を導入していたとしても、アプリケーションの機能実装とテストは表裏一体であると言えます。場合によっては機能の作り込みよりも時間をかけるべきケースが多いくらい重要である（・・・と信じたい）反面、デッドラインが近づくにつれて真っ先に工数が削られやすく軽視されがちな工程でもあります。 時間に追われてテストコードを書いた結果、テストの体をなしていないコードになっていたり後で見返したときに記述が煩雑すぎてメンテ不能になっていたり・・・といった苦い経験は誰しもがあるかと思います。かくいう自分もそんなことは多々ありました。 そんな今までの経験則を基に「自分がテストコードを書くにあたってどんなことを意識しているのか？」をいくつかピックアップして備忘録も兼ねて紹介したいと思います。 一応注意なのですが
この記事はエムスリーAdvent Calendar 2023の20日目の記事です。 エムスリーエンジニアリングG コンシューマチームの松原(@ma2ge)です。 今回はコンシューマチームで利用していたSaaSのメール配信システムを、新規に開発した社内システムに移行した経緯や設計時に意識したことなどについて紹介します。 最近使っているキーボードの様子 背景 今回移行する契機となったのはメールの配信数増加に伴うSaaSの利用料金増です。 特に定期的に送るメルマガ配信については、配信量も多く利用コストを押し上げる要因となっていました。 そのためメルマガ配信で大量に使用する部分についてのシステム移行検討が始まりました。 移行検討 SaaSから移行後のシステムについて試算すると、システムの開発や利用料といったコスト面では社内で構築したシステムの方が大幅にコストが下がることがわかりました。 しかしなが
この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) October 4, 2023 本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド
2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデリング(パターン)の解脱」のスライドログです。 この2冊で書かれているドメインモデルパターンを「古典」の対象にします。 ドメインモデルパターンは「複雑さに対処するため」と述べています。が、古典では次の2点が課題となっていると考えます。 これら2点について個別に見ていきます。 まずドメインモデルパターンから。 Patterns of Enterprise Application Architecture(以降PofEAA)ではこのように定義されています。 PofEAAのドメインロジックの章で使われている「収益認識」の例を取り上げます。 ContractやProduct, RecognitionStrategyなどといったクラスが作られて、これらのインタラクションでビジネスロジックが実現されると説明されています。 では、これらのド
出荷目安アイコンを改善するのに9か月もかかって辛かったので、システム分割を爆速で進めてリードタイムが9分の1になった話 - MonotaRO Tech Blog
こんにちは。2019年に初々しい記事を書いていた山本です。今でも元気にモノタロウで働いております。 この記事では、社内カンファレンスで私が業務部門向けに行ったプレゼンテーションを基に、マイクロサービス化に踏み切ったエピソードを紹介します。モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス と被る部分もありますが、同じ内容でも今回は易しめに解説していますので、空き時間にでもさらっとお読みください。 -- --まさか共通化されてないなんて 2022年の暮れに、こんな改修依頼を受けました。私はプロジェクトの開発リード担当でした。 出荷目安アイコンとは、当社商品が何日で出荷されるかを表すアイコン群のことです。 正確な値を表示するように工夫していますが、モノタロウでは自社在庫を含む様々なパターンの出荷があり、当時拡大が進んでいた「サプライヤ在庫連携」では特に出荷
こんにちは。LINEヤフー株式会社で、出前館というプロダクトのサーバーサイドエンジニアをしている古田大志です。 株式会社出前館はLINEヤフーのグループ会社です。資本業務提携を結んでいて、LINEヤフーが開発などをサポートしています。 詳しくはこちらをご参照ください。（https://corporate.demae-can.co.jp/pr/news/demaecan/line.html）（外部サイト） 今回の記事では、その出前館における開発の内容を紹介させていただきます。 出前館はデリバリーサービス事業のプロダクトで、開発においてはマイクロサービスアーキテクチャを採用しています。出前館のマイクロサービスの1つに、クーポンに関するドメインの責務を持ったコンポーネントであるクーポンサービスがあります。 クーポンサービスでは、ビジネスエンハンスに伴う「非機能要件の増大」や「仕様の複雑さの肥大化
チュートリアルでDDD体験: ドメインモデルの成長を紹介 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
プロダクト技術本部の川口です。 3年間、ビッグローブ光といった固定回線のインフラ部門に所属していましたが、今年の4月に BIGLOBE の基幹システムのリニューアルを推進していく部署に異動することになりました。 所属するチームでは、ドメイン駆動設計（DDD）で開発しています。 チームにジョインすると開発チュートリアルをやることになっており、そこで IntelliJ や Spring Boot での開発の仕方を学んだり、チュートリアルを通して DDD を学んだりします。 今回は、DDD のチュートリアルで実際に作成したドメインモデルがどういう風に成長していったかについて紹介します。 勤怠管理アプリ チュートリアル 初期ドメインモデル 中期ドメインモデル 後期ドメインモデル 学んだこと、感想 勤怠管理アプリ チュートリアル お題は GitHub のパブリックリポジトリに公開されています。 ht
あけましておめでとうございます。年がもう明けてしまいましたが、2023年に読んでよかった本について簡単に書いていこうと思います。noteで書いていましたが、こちらのブログをしっかり使わないといろいろもったいなと思ったので、技術に関係ない話題ではありますがこちらに書いていきます。 技術書 単体テストの考え方/使い方 フロントエンド開発のためのセキュリティ入門 知らなかったでは済まされない脆弱性対策の必須知識 プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで 技術書でないもの サピエンス減少 縮減する未来の課題を探る ネガティヴ・ケイパビリティで生きる 2050年の世界 見えない未来の考え方 訂正可能性の哲学 GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ 2024
Web フロントエンドの推しディレクトリ構成と Next.js App Router なコードベース | Offers Tech Blog
Offers を運営している株式会社 overflow の あほむ でございます。暖冬と言われつつもすっかり寒い季節ですね。おかげさまで割と走っているほうの師です。（師走） n 年ぶり n 回目の Web フロントエンド 最後にメイン開発者の立場でコードをスクラッチしたのいつだったっけ？と遡ると 2018年ごろのブログ記事 がでてきました💀 実際には 2017 年から 2018 年にかけての作品ですかね。当時の構想から読み取れる重厚かつ自己表現の感に内心苦笑いしつつ久々の新規建立です。 今回はディレクトリ構造の面から紹介していきます。 推しディレクトリの先達たち 推しディレクトリという言葉に乗っかってみたものの、ゴメンそこまでの熱感は持っていないかもしれない🥺 とはいえ先達の記事もご紹介しておきます。 今回の前提 本稿において、これらの前提に依存した論はほとんど含まれない認識ですが一応
本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか？ ～関心の分離と疎結合～」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか？」ということを、理解いただくのが本日のゴールとなります。 というわけで本
結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは？ MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd
はじめに クリーンアーキテクチャは、ソフトウェア設計の分野で非常に重要な概念です。 しかし、その理解は容易ではなく、明確な正解が存在するわけではありません。 多くの人が異なる解釈を持ち、他の設計思想と混在していることもあります。 この記事では、自分なりの視点からクリーンアーキテクチャを解釈し、その整理した内容を共有します。 このアーキテクチャの目的は、システムの各層を独立させ、変更に強く、テストしやすい設計を実現することです。 この記事では、クリーンアーキテクチャの基本概念、Golangでの実装方法、およびディレクトリ構成について詳しく説明します。 なお、この記事では個人的な見解を述べており、必ずしも正解を書いているわけではありません。もし誤りがあれば、ぜひご指摘いただけると幸いです。 クリーンアーキテクチャの基本概念 クリーンアーキテクチャの元となったのは、ロバート・C・マーチン（通称「
はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記：ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向けフロントエンドアーキテクチャの基本原則 エンタープライズ規模のアプリケーション向けにフロントエンドソリューシ
あれこれ 備忘録的な書き殴りな文書です。あしからず。 オシャンティーな技術スタックで、大きな組織でやるのも面白いと思うけど、小さな会社でレガシーなシステムやメンバーと向き合うのも悪く無いよ！ってことを伝えたいのだけど、これが楽しめる人いるかな？私は楽しいよ！ ジョインした時点の状況 開発体制 開発エンジニア（入社半年） インフラエンジニア（５年前後、QA兼ねる） 主力サービスの協力会社 0.5人月程度 会社の屋台骨の 主力事業のSaaSサービスがあるが、業務委託の0.5人月程度の工数の範囲でできる改修を行っていた。 開発エンジニアは新規機能を開発していた。 課題感 一度作られたシステムは、表(UI/UX)も、裏(システム)もレガシーな状況であった。 限られたエンジニアのリソースは、営業視点で、あったら売りやすい機能開発に費やされており、負債返却や、使い心地の改善には充てられていなかった。
公開日 2024/06/25更新日 2024/07/01モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス：パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背
生成AI時代のフロントエンド開発術
2022年11月にChatGPTがリリースされて、1年と約半年が経過しました。私はChatGPTが話題になった頃から、継続して利用しています。ChatGPTを使い続けていると、Webアプリケーションのフロントエンド開発に役立つことがありました。 そこで、本記事ではフロントエンド開発でChatGPTを活用して効率よく進める3つのパターンにまとめました。これらのパターンを紹介し、読者の皆さんの開発に役立ててもらえればと思います。 以下は、本記事で紹介するFigma、ソースコード、デプロイ先URLです。 Wireframing photo - Figma silverbirder/figma-photo-sample-app-for-ai - GitHub https://figma-photo-sample-app-for-ai.vercel.app ChatGPTを使う前に ChatGPTに
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細（フレームワークやデータベース）を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
Next.js App Router と控えめにお付き合いして普通の Web アプリを配信する | Offers Tech Blog
まずは長いものに巻かれたいときもある Offers を運営している株式会社 overflow の あほむ でございます。 先日 コードベースのディレクトリ構成にフォーカスした記事 を公開した関連記事として、Next.js App Router をどのように取り扱っているかについてご紹介します。 【AD?】今回の記事の内容を含んだり含まなかったりすると思いますが、来週 2024/01/17(水) 19:20 〜 オンライン開催の PWA Night vol.59 で発表予定なので興味のある方はぜひ。（終了済み） 下記は本記事の内容を含むイベント発表資料です。ご参考までに。 今回の前提 前回記事 の引用ですが今回も同様です。 最終目標は単体事業でありつつ実質マルチプロダクトな画面群のリプレース クライアントサイドでヘビーなビジネスロジックを持つ必要がない アプリケーション特性としては SaaS
確定申告の時期なので、米国の一風変わった(?)所得申告システム(Information Return)と連携するアプリケーションを開発した話について書こうと思う。 米国の所得申告 所得申告システム、FIRE 不思議なファイルフォーマット みよ、これがメジャーの仕様書だ レスポンス(多分速達のほうが早い) 初心者には厳しすぎるテスト環境 FIREへの申告自動化ツールを開発する おわりに 米国の所得申告 米国で申告義務のある人は、だいたい1月 - 4月の間に確定申告(Tax Return)を行う。この際、所得申告に関する数々の書類を提出する。例えば、雑所得がある場合は 1099-MISC、ギャンブルの収益は W-2G といった具合だ。 書類には膨大な種類がある じゃあこの書類は誰が用意するのかというと、支払った側になる。例えば契約社員は1099-NECという書類が申告に必要になるのだが、これを
Software Design 2024年5月号 連載「レガシーシステム攻略のプロセス」第1回 ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計 - ZOZO TECH BLOG
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2017年に始まったリプレイスプロジェクトにおいて、ZOZO がどのような意図で、どのように取り組んできたのか、読者のみなさんに有益な情報をお伝えしていければと思いますので、ご期待ください。第1回目のテーマは、「ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計」です。 目次 はじめに 目次 ZOZOTOWNリプレイスの背景、目的 背景 目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ZOZOTOWNリプレイスの歴史とアーキテクチャの変遷 アーキテクチャの変遷 2004年〜2017年：オンプレミス（リプレイス前） 2017年〜20
ここ2年ほど、すっかりフロントエンド開発者になっている藤田です。以前、Reactフロントエンドの状態管理ライブラリRecoilについて記事を書きました。 Recoilで快適フロントエンド開発 Recoil Syncでさらに快適フロントエンド開発 その後どうなったかというと、実はRecoilからJotaiに乗り換えていて、半年ほど経ちましたので、Jotaiについて書きたいと思います。 サイトの一行目から「Recoilにインスパイアされた」と言ってるとおり、Recoilの良いところを受け継ぎ、不便なところを無くしたような状態管理ライブラリです。 Jotaiの基本 基本はRecoilとほとんど同じで、React.useStateを便利にしたような感覚で非常に簡単に使えます。3ステップで見てみましょう。 1. Providerで囲む アプリケーション全体を<Provider>で囲みます。 impo
こんにちは、近藤です。 commmune Advent Calendar 2023 18日目の記事は『TypeScriptにおけるDDDのドメインオブジェクトの課題と対策』です はじめに ドメイン駆動設計（DDD）は、複雑なビジネスロジックを扱うアプリケーション開発において、重要かつ効果的なアプローチとして広く認識されています。 コミューンでは、現場で役立つシステム設計の原則の著者、増田さんのご協力を得て、プロダクト開発を進めています。 幸運なことに私は増田さんとの密なコミュニケーションを取らせて頂いており、DDDの理論と実践方法に関する貴重な知見を深めその有用性を感じております。 しかし、TypeScriptのような構造的型付けを採用する言語でDDDを適用する際には、特有の課題が生じることがあります。本記事では、TypeScriptでの構造的型付けに伴う課題、そしてそれらを克服する方法に
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サブスクリプション課金システム開発ケーススタディ - inSmartBank
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
中途入社のソフトウェアエンジニアがWebサービス開発に参加するとき役立ったこと - kymmt
RustでWebバックエンドを書き始めてから1年くらい経った
ServerlessDays Tokyo 2023が最高すぎた！ - Qiita
削除のビジネスロジックをドメイン層に閉じ込める簡単で強力な「DeletableIDパターンの紹介」
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
テストコードを書く上で個人的に気をつけている5つのこと - Qiita
メール配信システムを SaaS から新規社内システムへ移行した - エムスリーテックブログ
一休レストランのふつうのRustバックエンド開発 - 一休.com Developers Blog
古典ドメインモデリングパターンの解脱 - 大吉祥寺.pm - kawasima
イベント駆動とドメインモデルの完全性を意識したアーキテクチャ設計
2023年、読んで印象に残った本 - Don't Repeat Yourself
なぜDependency Injectionなのか？ ～関心の分離と疎結合～
RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)
Golang開発者のためのクリーンアーキテクチャ
Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD
開発責任者として、事業会社にジョインして半年の振り返り
モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
Go言語によるクリーンアーキテクチャの実装例紹介
あなたのしらない米国所得申告システム - tomoima525's blog
Jotaiで快適フロントエンド開発 | 株式会社ヌーラボ(Nulab inc.)
TypeScriptにおけるDDDのドメインオブジェクトの課題と対策