Goで作られたシステムをRuby on Railsに移植しています 〜GraphQL編〜 - STORES Product Blog
STORES でエンジニアをしている片桐です。 先日、「Goで作られたシステムをRuby on Railsに移植しています」という記事を投稿させていただきました。 product.st.inc product.st.inc ベース部分の実装について別ブログで紹介したいと書かせていただきましたが、今回はその中から「GraphQLの移行基盤としてのGraphQL Stitchingの導入」について紹介させていただきます。 GraphQL Stitching の導入 GraphQL Stitchingの実現には、すでに弊社内で採用実績のある graphql-stitching gemを利用します。 導入後、graphql-stitching gemのREADME.mdのQuick Startを参考に、graphql-rubyで作成されるgraphql_controllerのschema実行部分を
フロントエンドに汎用APIを使わせてはいけない（4年後の続編記事）（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Don’t Build a General Purpose API (4 Years Later) - Max Chernyak 原文公開日: 2025年12月11日 原著者: Max Chernyak 日本語タイトルは内容に即したものにしました。 私は2021年に、フロントエンド向けにわざわざ汎用のAPIを構築して苦労を増やしてはいけないと呼びかける記事を書きました↓（よろしければ本記事を読む前に目を通しておいてください）。 参考: Don’t Build A General Purpose API To Power Your Own Front End - Max Chernyak この記事はHacker Newsに2度取り上げられましたが、2度目は評判がよろしくありませんでした（その分議論は白熱しましたが）。推測ですが、2
Goで作られたシステムをRuby on Railsに移植しています - STORES Product Blog
STORES でエンジニアをしている片桐です。 STORES では店舗運営に関するさまざまなプロダクトを提供しています。これらのプロダクトは元々別の会社で運営されてきた完全に異なるプロダクト群で、アカウント体系から全く異なるシステムになっていました。近年はこれらのシステムを本格的に統合する取り組みを進めてきており、その中で統合のためにいくつかのシステムが新たに作成されてきました。 ある程度統合が進み、うまくいったところ・いかなかったところが見えてきた中で、これまでに作ったシステムの技術選定・システムの役割に対する課題感が見えてきました。 現在弊社ではこの課題を解決していくプロジェクトを進めています。その中の1つで、Goで作られたシステムをRuby on Railsで作られたシステムに移植する作業を行なっているので、今回はそれについて紹介させていただきます。 移植元のシステムの課題 今回別シ
Reactチームが見てる世界、Reactユーザーが見てる世界
Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
GraphQLは「オワコン」「流行らない」のか？ - Qiita
はじめに 今回はタイトルの通り、「GraphQLは「オワコン」「流行らない」のか？」という問に対して、個人的に調査した内容となります。 今回のタイトルで記事を書くことにしたのは、Googelの検索フォームに「GraphQL」と入力したところ、サジェストに「Graphql 流行らない」「Graphql オワコン」と表示されたことがきっかけです。 (試しにシークレットモードで入力してもサジェストされるので、私の検索履歴などのパーソナル情報によるバイアスはかかっていないはずです) 「Graphql オワコン」での検索結果TOPに「GraphQLはオワコンですか?これからはtRPCの時代ですか?REST APIの位置づけは何ですか?」というページがあったので読んでみました。 回答者はNodejsユーザグループ代表の古川さんで「GraphQLをオワコンと称するにはまだ早い」と回答されています。 私も
ObjectSpace を利用して Ruby 製 worker のメモリ使用量を改善した - @watson1978 の日記
現在、Ruby 製 worker を作成することを業務で行っているのですが、継続的にメモリ使用量が増加する現象に遭遇してました。 （グラフの値が下がったタイミングが数回ありますが、それぞれでデプロイが行われてリセットされただけ） ObjectSpace.allocation_sourcefile や ObjectSpace.allocation_sourceline を利用してどのファイルのどの行でメモリ確保が多くなるのか調べれるようにしました。 以下のようなコードを worker に追加しました。 require 'objspace' class MemoryProfiler INTERVAL = 5 * 60 DISPLAY_COUNT = 20 def self.start Thread.start do loop do memory_usages = {} ObjectSpace.
Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature / Mediumの独自ドメインプランを使って訪問者のメールアドレスが窃取できる脆弱性の開示
0_medium_vuln_en.md Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature Author: mala Introduction This article describes a vulnerability in a web service called Medium that allows you to steal visitors' e-mail addresses by using custom domain plan of Medium. This is done as my personal activity and is not related to my organization.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/koichik/status/1796778428240416769
https://twitter.com/bulkneets/status/1679468465613312001