新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
BFFとは Backend for Frountendの略で、UI/UXを向上させる目的でフロントエンド専用のサーバーを用意したアークテクチャパターンです。 Webアプリケーションサーバーは下記の処理を行います。 リクエストを受ける DBからデータの取得・更新 ページを構築 (これはクライアントですることも) ページ or データの返却 このうち、「DBからデータの取得・更新」とそれ以外をフロントエンドとバックエンドの役割に明確にわけます。 BFFの役割となるサーバーをクライアントをWebサーバーの間に設け、「リクエストを受ける」と「ページ or データの返却」、場合によっては「ページの構築」をここで処理します。 こうすることで、これまでリクエストというUX関わる部分をフロントエンドエンジニアの責務に移行することができます。 ページの構築をクライアントではなくサーバーで行う場合、これもBB
Next.js, Prisma, GraphQL Code Generator で作るフルスタック Web アプリケーション
Next.js, Prisma, GraphQL Code Generator で作るフルスタック Web アプリケーション おもにNext.js、Prisma、GraphQL Code Generatorを用いたWebアプリケーションの構築手法について解説した書籍となります。 上記技術に加えて、以下の技術も採用しています。 ・Tailwind CSS ・NextAuth.js ・Apollo GraphQL ・Prettier ・ESLint ・Vitest ・React Testing Library ・GitHub Actions モダンなWebアプリケーションの開発手法について興味がある方にオススメです。 1章 Next.jsのセットアップ 2章 Prismaのセットアップ 3章 GraphQL Code Generatorのセットアップ 4章 テストコードの追加 5章 本番環境へ
業務システム SPA のフロントエンド技術選定（2023年版） - KAKEHASHI Tech Blog
本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。
手が痺れるエンジニアを支える技術
こちらに触発されて「そういや俺も手が痺れて色々やってたしな、共有したろ！」と思い筆を取りました。 過去形っぽく書いていますが今でも油断して悪い姿勢で作業し続けると痺れが再現します。 ひどい時は無理せず休みましょう。 手の痺れの原因 手の痺れと一口に言っても原因は実に様々ですが、痺れている部位でどの神経が痛めつけられているかわかるので、それである程度特定することができます。 私の場合は主に手の外側、小指と薬指が痺れる範囲でした。 この範囲の場合、圧迫されているのは尺骨神経という神経のため、考えられる疾患としては肘部管症候群、胸郭出口症候群、頚椎ヘルニアのあたりでした。 引用: 尺骨神経とは？解剖・支配筋・感覚枝 https://www.doctor-1.com/archives/2110 色々MRIやらCT取っても確定診断は出なかったのですが、後述する分離型キーボードを導入してかなり楽になっ
はじめに こんにちは、retail HUBで Software Engineer をしているほんだです。 今回は私が現在着手している事業譲渡されたアプリを社内で持続的なプロダクト開発を行える状態にするリプレイスプロジェクトをどのように行っているか紹介しようと思います。 この記事ではリプレイスを行うにあたってどのようなことを課題に感じてその課題に対してどのような解決策をとったか主にサーバーの実装について説明しています。 ネットスーパーアプリとは 現在弊社ではネットスーパーアプリとして Web アプリとスマホアプリの二つのシステムを提供しています。 Web アプリは販促コンテンツの設定や売り上げの管理・集計を行うことが可能な管理システムと受け取り方法に応じた価格変更や送料変更にも対応し、消費者の柔軟な買い物を実現するお客様向けアプリを 17 の小売り様に、スマホアプリでは Web アプリのお客
Rails+Next.jsでGraphQLを導入する時に考えたこと - Timee Product Team Blog
こんにちは、タイミー開発プラットフォームチームで業務委託として働いている宮城です。 タイミーはリリースから4年が経過したプロダクトで、2022年の前半から一部領域でGraphQLを利用し始め現在導入を進めています。 本記事では、GraphQLをプロダクトに導入する上で判断に迷った箇所や課題に対して、タイミーでの意思決定とその理由を紹介します。参考にしていただければ幸いです。 GraphQLの選定理由についてはこの記事では触れませんが、CTOの@kameike が以下のイベントで詳しく紹介する予定です。まだ参加申し込みは可能ですので、興味がある方はぜひ合わせてご覧ください。 timeedev.connpass.com なお、本記事のタイトルはソウゾウさんの以下の記事にインスパイアされています。 engineering.mercari.com GraphQLの「Getting Startedの
概要 先日新規の Web サービス開発でフロントエンド側の技術選定を行いました。 利用する技術の中で GraphQL を提案した際に、RESTful な API で呼び出す方法と比較して納得感がないという意見があがりました。 そこで、なぜ、どういうときに GraphQL を選定すべきだと思うか、文章にして自分なりにまとめておこうと思います。 前提 構成が BFF か BE かで意見は大きく変わりません。 例えば BFF として利用されるケースでは、バックエンド側には BE チームとマイクロサービス的な API が存在しており、 BFF として GraphQL を配置するようなケースです。GraphQL のリゾルバは API を叩きます。 一方、 BE として利用されるケースとは、リゾルバが直接 DB を叩くような形です。 今回はフロントエンドのチームが管理する BFF として、JS のみで
useState, useContext を使った状態共有 graphQL BFF + Codegen + Apollo Hooks で型安全なデータ取得 Redux の型定義、Loading 状態の運用、エラー処理、等々煩雑なコードがなくなる 1日一つ強くなる中西とは https://ja.reactjs.org/ React 日本語公式ドキュメントのトップページの翻訳を担当 Apollo Japan User Group 主宰 / 公式ドキュメントチュートリアルを翻訳しました Hasura Japan User Group 主宰 / チュートリアル公開しています JavaScript が中心となった生産性の高い Web App 開発チームの運用、及びその普及活動が今のテーマ => https://apollographql-jp.com/makeMoneyTS/ 毎月 JavaScri
Web フロントエンドの推しディレクトリ構成と Next.js App Router なコードベース | Offers Tech Blog
Offers を運営している株式会社 overflow の あほむ でございます。暖冬と言われつつもすっかり寒い季節ですね。おかげさまで割と走っているほうの師です。（師走） n 年ぶり n 回目の Web フロントエンド 最後にメイン開発者の立場でコードをスクラッチしたのいつだったっけ？と遡ると 2018年ごろのブログ記事 がでてきました💀 実際には 2017 年から 2018 年にかけての作品ですかね。当時の構想から読み取れる重厚かつ自己表現の感に内心苦笑いしつつ久々の新規建立です。 今回はディレクトリ構造の面から紹介していきます。 推しディレクトリの先達たち 推しディレクトリという言葉に乗っかってみたものの、ゴメンそこまでの熱感は持っていないかもしれない🥺 とはいえ先達の記事もご紹介しておきます。 今回の前提 本稿において、これらの前提に依存した論はほとんど含まれない認識ですが一応
Go + TypeScriptによるGraphQLスキーマ駆動開発 - 一休.com Developers Blog
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の
Blog を作りました！！！！！ 会社を辞めて 5 ヶ月経とうとしており、ついに堕落しきった生活による危機感が生まれはじめました。 その危機感が結実したものがこの Blog です。 で、Blog を作ってみたものの書く内容が特にないので、まずはこのブログをどうやって作ったかについて書きます。 「こういう記法にちゃんと対応できてる？」を試す目的でもあります。 技術スタック 根幹になっているものは、 TypeScript Gatsby です。 元々は amdx + NextJS, もしくは完全自作 SSG を考えていたのですが、 ブログは完璧を目指しているといつまでも完成しない ということは知っているので、自分にとって自信があるツールとして Gatsby を選びました。 しかし、ただ使うだけなのはチャレンジ性がなかったので、TypeScript を使ってみることにしました。 昔の Gatsby
next.js + vercel + firebase authentication で JWT の検証を行う + Graphql
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
記事の概要 この記事は、Meta 社 relay.dev チームの Jordan Eldredge 氏の Tweet で紹介された GraphQL 成熟度モデル (GraphQL maturity model) を個人的な見解を加えながら和訳した記事です。 jordaneldredge.com GraphQL を実装する上で、どの程度 GraphQL を使いこなせているか判断するための参考になれば幸いです。 実際の成熟度モデルの和訳 最初の Tweet 私は、GraphQLの利点がまだ十分には理解されていないと思っています。ほとんどの組織では、GraphQL の提供する価値を捉えきれていません。 そこで、私は「GraphQL成熟度モデル」をスケッチしてみました。あなたの組織はどの程度成熟して（＝使いこなせて）いますか？ もし以下に示す13の成熟度を達成していたとしたら、よりGraphQLを
GraphQL Code Generator で TypeScript の型を自動生成する - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。 レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ という記事を書きましたが、この中で詳しく説明しなかった GraphQL のスキーマやクエリから TypeScript の型定義を自動生成する仕組みについて紹介します。 なお、今回紹介したコードは以下で試せます。 https://github.com/hokaccha/graphql-codegen-example-for-techlife GraphQL Code Generator を使った型生成 GraphQL のスキーマから TypeScript の型を生成するためのライブラリはいくつかあります。 Apollo GraphQL Code Generator などが有名どころです。今回はシンプルさや拡張性を考えて G
はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド（ウェブアプリケーション、モバイルアプリケーションなど）は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API（REST、gRPCなど）を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
AWSの静的ウェブサイトホスティングで入門するAWS Amplify(Console、CLI) － 概要編 - NRIネットコムBlog
小西秀和です。 この記事を書こうと思ったきっかけは、タイトルの通りAWS Amplifyの登場です。 AWS CLI、AWS CloudFormation、AWS Serverless Application Model(AWS SAM)、AWS Cloud Development Kit(AWS CDK)といったAWSインフラストラクチャをプログラマブルに操作するサービスが登場してきましたが、AWS Amplifyはこれまでとは違う新たなアプローチになっています。 今までAWS CLIは使っていたけど結局色々あってAWS CloudFormationはあまり使ってこなかったというケースでもAWS Amplifyがユースケースにマッチする可能性があるかもしれません。 今回はAWSのサーバーレスな静的ウェブサイトホスティングを題材にAWS Amplifyの特徴と簡単な使い方について書こうと思
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API
この記事では、GraphQL を利用したアプリを Next.js で構築していきながら、GraphQL の初歩について書いていく。 GraphQL のクライアントもサーバも、Apollo を用いる。 また、できるだけ型安全に開発したいので、graphql-codegenで型定義ファイルを生成する方法も扱う。 利用しているライブラリのバージョンは以下の通り。 @apollo/client@3.5.10 @graphql-codegen/cli@2.6.2 @graphql-codegen/typed-document-node@2.2.7 @graphql-codegen/typescript-operations@2.3.4 @graphql-codegen/typescript-resolvers@2.5.4 @graphql-codegen/typescript@2.4.7 @type
こんにちは、koidです。 この記事は Gunosy Advent Calendar 2021 - Adventar の25日目の記事です。 昨日の記事は aitaさんの EKSにJupyterHubを構築した - Gunosy Tech Blog でした。 ドキュメントの更新って面倒だし忘れがち ドキュメントのメンテナンスを自動化しよう コードからドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 状態からドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 まとめ ドキュメントの更新って面倒だし忘れがち 本題です。 みなさん、Pull Requestのレビュー時に、 ドキュメント・READMEも修正お願いします！ こういったコメントをした/された経験ってありませんか？ コメントをする側としても
フロントエンドアプリケーションの開発を行う上で避けては通れないデータフェッチの実装。 REST APIを使うか、GraphQLを使うか、クライアントでキャッシュするか、APIレスポンスにどのようにして型を付けるか、状態管理はどうするのかなど、開発者の悩みが尽きないけれども、それに関しての設計を考えたり議論を行うのはフロントエンド開発の楽しいポイントだと僕は思っています。 この記事では、バックエンドにHasura、フロントエンドにNext.jsを使用する場合に僕が最強だと感じたツールの組み合わせ・使い方を紹介します。 モチベーション APIからのレスポンスにはTypeScriptの型が勝手についてきてほしい。asで型アサーションするのはやりたくない。 クライアントでもサーバー（SSR）でもデータフェッチの方法が同じインターフェースで提供されてほしい。 クライアントでAPIレスポンスをキャッシ
Provides functions to help TypeScript GraphQL client development including auto completion, query validation, type… このツールに限らずですが、開発支援系のツールは自分で使うモチベーションがあるときに作るのが一番ということもあり、重い腰を上げてこいつに大幅にアップデートを加えました。年末年始で時間もいっぱいありましたしね。 エディタ支援機能ts-graphql-plugin という名前にもある通り、こいつはTypeScriptのLanguage Service Pluginです。 Language Service Pluginというのは、TypeScriptの言語支援サーバー（tsserver）上で動作するため、エディタの種別を問わず動作するのが特徴です。 さて、例えばReac
Recoilにロジックを載せる運用戦略
皆さんこんにちは。株式会社バベルでエンジニアをしている uhyo です。バベルが提供しているaileadというプロダクトではNext.jsおよびReactを使用しています。以前から、自分はaileadのフロントエンドにおいてRecoilの利用を推進する活動をしてきました。実は、筆者が以前に公開した次の記事もその流れを汲んだものです。 Recoilはステート管理ライブラリとして知られていますが、筆者はRecoilのデータフローグラフを構築しその上にアプリケーションロジックを載せられるという点に可能性を感じています。実際、aileadではそのような方向性の設計に取り組んでいます。 そこで、この記事では筆者がaileadにおいて実践しているRecoilの運用を紹介します。 この記事はReact Advent Calendar 2022の8日目の記事です。 ステート更新に反応するならまずselec
GraphQL Code Generator(graphql-codegen) おすすめ設定 for TypeScript
GraphQL Code Generator v3 以降で標準となった Client preset では設定が大きく異なります。 この記事は Client preset を使わない前提の内容になっているため、注意が必要です。 Client preset 用の設定は別記事で紹介します。 全体 生成物をフォーマッタにかける graphql-codegen には Lifecycle Hooks という仕組みがあり、いくつかの用意された hook ポイントで任意のコマンドを実行できる。 これを使って生成されたコードを Prettier 等のフォーマッタに通しておくのがおすすめ。 基本 DO NOT EDIT とはいえ、コードジャンプしてきて生成された型を読みたいケースはよくある。 そういうときのために、人間が見やすいように改行しておいてもらうといい。 typescript plugin, type
GraphQL クライアントの選び方について 現状大きく次のような選択肢があります。 Apollo Client Relay Urql 他に react-query や SWR などの GraphQL に特化していないものを使うこともできるらしいがあまりメリットがピンときていない GraphQL クライアントにやってもらいたいこと 上記は Web の GraphQL クライアントの比較しか書いておらず、他のプラットフォーム(Flutter とか)でも選定軸が持てるように、もう少し "GraphQL クライアント" と呼ばれるものに何を期待しているのかを書き出してみる。 graphql リクエストを送れる 最低限の機能です。 エンドポイント、認証トークン は共通のものとして準備して、あとはクエリをのっけたらリクエストが作れたらいいでしょう。 キャッシュを保ってくれる キャッシュの正規化ってな
Photo by Lukas Tennie from unsplashはじめにこのエントリでは、僕が趣味で作っている PicoML という自作プログラミング言語の話を書こうと思う。 作ってから半年くらい経っているのだけれど、如何せん自作言語という無用の長物であり、登壇などでコイツの話をすることもないため、ある種の供養みたいなものだと思ってもらって構わない。 PicoML の概要まずは実装した言語の紹介から。ざっくり以下の特徴を備えた言語である。 ML ベースの文法による関数型言語単純 let 多相型推論による型チェックCLI として、Node.js 上での即時評価器（REPL）と WebAssembly をターゲットにしたコンパイラの双方を提供REPL やコンパイラの実装は TypeScript で行っている。自分の勉強が主目的であったため、REPL やコンパイラの CLI を動作させるの
開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
2021年お世話になったReact関連ライブラリ10選 #techtekt Advent Calendar 2021 - techtekt
この記事は techtekt アドベントカレンダー2021 の 12日目の記事です。 こんにちは！ テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしている Yuto SAGAWA です。*1 皆様今年もReactライフを満喫できていますでしょうか？ 個人的にはたくさんReactに触れる機会があり、非常に満喫することができました！ そんな2021年の個人的にお世話になったReact関連のライブラリ、フレームワーク、ツールなどの紹介をしたいと思います。 next nextjs.org Next.jsはReactのフレームワークで、昨今では使用例も多く人気のフレームワークであることが伺えます。 SSR / SSG だけではなく、ISR（Incremental Static Regeneration）など、 Webアプリケーションのパフォーマンス改善の手助けとなることが期待
はじめに サービス構成 レポジトリ一覧 サーバー側Railsアプリ クライアント側Railsアプリ 開発の流れ 利用ツール swagger-cli committee-rails 不具合1: ファイルの分割 不具合2: $refとnullableの同時使用 json-schema openapiの記法に合わせた機能拡張 openapi-generator-cli (Ruby client) 不具合1: 中途半端な型チェック 不具合2: oneOf/anyOfに非対応 factory_bot 終わりに We are hiring! はじめに 前回の記事では、OpenAPIで新しいウェブAPIを定義する際に、yamlのままで読みやすいようにファイル構成等を工夫した話をしました。 今回はそのAPIスキーマを使って、Railsでスキーマ駆動開発を実現するにあたって利用しているツール類についてお話し
TypeScriptにおけるgRPC関連ライブラリの比較とプロダクト開発で採用した方法の紹介 - CADDi Tech Blog
こんにちは、テクノロジー本部バックエンド開発グループの山田です。 弊社のプロダクト開発では、以下の図のようにフロントエンド <-> BFF <-> バックエンドの構成をとっており、Node.js上で稼働しているBFFと、Rustで作成しているバックエンドの間をgRPCで通信しています。 そこで今回は、TypeScriptにおけるgRPCの関連ライブラリについて、以下を紹介していきます。 【1】 公式チュートリアルに沿った２種類の実装サンプルに、アプリケーション開発中に認証や分散トレーシング等で利用するMetadataの実装を追加したコード 【2】 ２種類の方法をライブラリの実装も見つつ比較 【3】 直近の開発で採用している方法の紹介 お急ぎの方は下部にまとめを記述しているのでそちらを参照ください。 また、説明の都合で記事中のサンプルコードは一部を抜粋して記述していくため、完全なサンプルコー
こんにちは、技術部の石川です。 ある日、社内の各種アプリケーションを眺めている中で、とあるクローズしたサービスの管理画面を担っていたウェブアプリが今も動いていると気付きました。簡単にヒアリングしたところ、サービス自体はクローズしたものの、保有していたデータが次のチャレンジに生かせるため管理画面だけ残しているとのことでした。 一方で、その管理画面へのアクセスはそう多くありませんでした。毎日ちょっとだけのリクエストを処理するためだけにデータベースとサーバーが動いており、少し無駄がある状態になっていました。 やや気になったので検討した結果、最終的にこの管理画面アプリを Next.js 製の静的なデータビューワーサイトとしてリニューアルし、社内向けの GitHub Pages として提供されている状態にできました。この記事ではその顛末をご紹介します。 技術選定 いくつか事前調査をした結果、今回の管
Auth0で保護されたAWS AppSync(GraphQL)をReactからApollo Clientで利用する方法をチュートリアルとしてまとめた | DevelopersIO
Create React App（CRA）を使ってアプリケーションを生成します。任意の作業用ディレクトリに移動後、下記のコマンドを実行します。 再現性を高めるために、パッケージのバージョンを固定してインストールしています。 npx create-react-app@3.4.1 --template typescript react-appsync-protected-by-auth0 cd react-appsync-protected-by-auth0 React RouterとAuth0のSPA用SDKをインストールします。 yarn add react-router-dom@5.1.2 @auth0/auth0-spa-js@1.8.1 yarn add -D @types/react-router-dom@5.1.2 Auth0をReactで利用する為のCustom Hookを作成
Open API × Rails × TypeScriptでのスキーマ駆動開発｜Offers Tech Blog
プロダクト開発人材の副業転職プラットフォーム Offers を開発している、株式会社 overflow にて EM をやっております磯崎と申します。 日々プロダクトを開発している中で、様々な格闘があるかと思いますが、その中でも大分格闘してきた Open API を用いたスキーマ駆動開発について今回は書いてます。 この構成で運用してよかったと今のところは思ってますが、色々面倒な事や落とし穴にも直面してきました。自分たちの中に溜まっている知識を書き記していくのでどこかでお役に立てればハッピーです ☺️ 最初に API を定義、その後開発を進めていくスキーマ駆動開発 そもそもスキーマ駆動開発とは、はじめに API を定義し、それを元にフロントエンド・バックエンドと開発を同時に進めていく開発フローです。 フロント実装においては通信部分で、「何を送信すべきか」、「何が返ってくるのか」を予め決まった状
はじめに PDTで10/23 - 10/25に開催されたReact Conf 2019に参加してきたので、その参加レポートです。 筆者の英語力が頼りないため、内容の正確性に保証はありません。また、人名はすべて敬称略です。 ここに書ききれなかった内容については、お会いしたときに酒の肴として聞いてください。 参加した経緯 CFP募集してたから応募した 採択されなかったけど、おまけで抽選免除でチケット購入できる案内がきた せっかくだし、自前でチケット買って行くことにした なんやかんやで10/11のTSConfも行くことにした どうしてこうなったんだろう🤔 ちなみに、時系列的にはUSに3週間弱滞在してたうちの第三部です。 第一部TSConf編と第二部Los Angeles編は近いうちに書きます。 参考リンク conf.reactjs.org www.youtube.com www.youtube
今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書
GraphQLのFragment活用テクニック: colocationとmasking - ドワンゴ教育サービス開発者ブログ
GraphQLのFragment活用テクニック: colocationとmasking こんにちは。N 予備校 Webフロントエンド開発チームの中村です。 現在開発中のZEN CompassではGraphQLを採用しました。我々のチームでは（そして私個人としても）GraphQLを採用したのは初めてだったのですが、実際に設計を進めていくうちに色々と知見を得ることができました。今回はその中でも特に重要だと思った、GraphQLのFragmentという仕様を活用したコンポーネント設計のテクニックについてお話ししようと思います。GraphQLを使用したWebアプリケーションに興味がある方にとって何か参考になりましたら幸いです。 【ZEN Compass】 学習者を導く先生方などが利用するコーチング支援Webサービスです。 LMS(Learning Management System)として学習状況
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
メルカリShops のフロントエンド | メルカリエンジニアリング
npm-scripts を書く時の手癖 - mizdra's blog
SSR / SSGの理解を一段深ぼる: BFFアーキテクチャ
ネットスーパーアプリ GraphQL から REST へ移行始めました - every Tech Blog
React 時代に選ぶ GraphQL - とろろこんぶろぐ
「Redux よさようなら」最強の React 実装
Gatsby + TypeScript で技術ブログを書くための知見
GraphQL 成熟度モデル - とろろこんぶろぐ
GraphQL Gatewayはフロントエンド開発を幸せにする
Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog
流行りのBFFアーキテクチャとは？｜Offers Tech Blog
Next.js で始める GraphQL - 30歳からのプログラミング
面倒なドキュメント生成はCIにやらせよう - Gunosy Tech Blog
ぼくのかんがえたさいきょうのデータフェッチ 2021Summer🏄♂️【Next.js / Hasura】
TypeScript で GraphQL Client を便利に開発するためのツールを作っている話
GraphQL クライアント周りで知っておくと良さそうなこと
自作プログラミング言語と WebAssembly コンパイラ
OpenAPIを使ったRailsスキーマ駆動開発 - ドワンゴ教育サービス開発者ブログ
クローズしたサービスの管理画面を静的サイトにする - クックパッド開発者ブログ
React Conf 2019に参加した話 - sasurau4のブログ
next.jsでのファイルチャンク最適化の一例 - hiroppy's site