2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。 最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。 Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。 Web アプリケーション + API の 3-Tier 構成 (SPA) Web アプリケーション + API の 3-Tier 構成 (SPA) SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は N
こんにちは、Web チームの井手です。今日は私たち Web チームが作っている SSR フレームワーク(以下 FW)にについて紹介します。 記事を書くモチベーション 私たちのメインプロダクトである日経電子版においては k2 という自作 SSR 基盤を 2020 年から運用しています。SSR FW といえば多くの方が Next.js を想起すると思いますが、私たちは自作しています。一方で最近は Next.js の進化が凄まじく、自作 SSR 勢としても意識せざるを得なくなっています。もしかしたら「あぁ Next.js で作っておけばよかった」と思う時が来るかもしれません。特に k2 を保守する際には Next.js では実現できない機能を実現するために様々な手法や工夫を編み出していましたが、Next.js の進化に伴ってその必要性はだんだん減ってきているのを実感しています。そのためいつか N
September 15, 2021 @ iCARE Dev Meetup #25
こんにちは！ソウゾウのSoftware Engineerの@napoliです。先日、7月21日にメルカリグループの新規事業「メルカリShops」がプレオープンされました。 開発・企画を担うソウゾウが設立されたのは2021年1月28日。それから嵐のように過ぎさった約半年間の開発の裏側を、約２週間に渡って毎日公開していきます！ メルカリShopsとは？ 「"売り買い"の楽しみを、より広げる」、というコンセプトのもと、ものづくりをしている事業者の皆さまと、メルカリのお客さまをつなぐサービスです。 開発はソウゾウという、メルカリグループの中で独立した組織で行われました。全体のシステムもメルカリのメインのシステムからは独立したかたちで構成されており、メルカリグループとしての技術基盤を活かしつつ、さまざま技術的なチャレンジが積極的に行われています。 執筆するエンジニアとテーマは以下の公開表をご覧くださ
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)です
まえがき ここ最近、Vueを使って実装されたWebアプリが随分と増えてきたように感じます。自分も何度となく実装してきました。すごく小さなデモを作るときにも使えるし、中規模以上のWebアプリを作るときにも使えるし、扱いやすいライブラリでとても好きです。 ある程度の規模になってくると「複数の画面でデータを共有したい」「こっちのComponentの状態をあっちのComponentに伝えたい」といったような問題にぶち当たり、アーキテクチャを導入することでそれらを解決するというのもお馴染みな感じです。特にVueでは双方向データバインディングの特性上、MVVMアーキテクチャが使われることが多いと思います。 今回は、VueでMVVMを実現する際に起き得る設計上の問題について、現時点での私の解決方針をまとめてみました😌 まえがき Vue+MVVMとはどんなものか 一般的なMVVMを理解する View V
CAMPFIRE iOS #1 - connpass https://yj-meetup.connpass.com/event/51735/ での発表資料です。 (2017/3/23追記): 各所からいただいたフィードバックに基づき、不正確な記述を修正しました。（Nyohoさん、あんざ…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔のメモを整理してると出てきました。今となっては心底どうでもいい。 上流工程に関するあれこれ 大まかな流れ 基本的な流れとしては要件定義→外部設計→内部設計→開発の流れが採用される。 ここで外部設計は基本設計、内部設計は詳細設計とも呼ばれる。 一般にウォーターフォールモデルでの考え方では外部設計までが上流工程と考えられるようだ。 要件定義 要求開発(超上流工程) [ 業務フロー ] 業務とその流れを表現するもの。素人にもわかるように → アクティビティ図 業務機能関連図 [ 業務モデル ] 業務を静的に表現する。 → ERD クラス図
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
