Full-Stack TypeScriptで型安全な開発サイクルを実現！ ── Legal Brain 開発事例 - 弁護士ドットコム株式会社 Creators’ blog
こんにちは！ Legal Brain エージェントを開発している下山です。 Legal Brain エージェントはリーガル特化型 AI エージェントで、法律事務所や企業の法務部門での複雑なリサーチ業務を支援するリーガルリサーチ機能を提供しています。 このプラットフォームはマイクロサービス構成で、フロントエンドとバックエンドに TypeScript を採用することで開発サイクルを大幅に向上させました。本記事では、その実践事例をご紹介します。 プロジェクト概要と課題 Legal Brain エージェントではバックエンド（Go）とフロントエンド（TypeScript）で異なる言語を使用していたため、型定義の不整合や開発効率の低下といった課題に直面していました。 開発で直面した課題 バックエンド・フロントエンド間の型定義の不一致 異なる言語で開発することで、バックエンドとフロントエンド間で型定義の
将来を見据えて管理画面のフロントエンドをガッと改善している - inSmartBank
こんにちは、株式会社スマートバンクでサーバーサイドエンジニアをやっています、すてにゃん (id:stefafafan) です。今回は社内で活用している管理画面に対して実施した様々な技術的な改善を紹介していきます。 背景 改善サイクルの高速化 開発者体験の向上 依存ライブラリのメンテナンス AIエージェントを意識した改善 将来を見据えたコード品質の担保 Linterルールの有効化 TypeScriptの設定を厳格化 パッケージのバージョン指定やアップデート周りの調整 今後の課題と展望 終わりに 背景 スマートバンクではお問い合わせ対応や調査をするために社内向けに管理画面を用意しています。この管理画面は以下のスライドにあるように、ユーザー向けの機能とはリポジトリを分けて運用しています。 この構成を取ることで、プレゼンテーションロジック (UI) とドメインロジックを分離することができ、認知負荷
Announcing Oxlint 1.0
TL;DR: The first stable version Oxlint has been released! With a 50~100x performance improvement over ESLint, support for over 500 ESLint rules, and usage in major companies like Shopify, Airbnb, and Mercedes-Benz, you should give it a try. Get started now. Oxlint is a Rust-powered linter for JavaScript and TypeScript is designed to be fast and simple to adopt. Since its first announcement back in
Rails vs Node.js
Previous slideNext slideToggle fullscreenOpen presenter view Rails vs Node.js 最終章 「Prisma」 @mizchi Cloudflare Meetup 2024/10/02 今日の Prisma + Cloudflare の様子 About https://x.com/mizchi Node.js とフロントエンドの専門家 100万円*達成率で御社のフロントエンドの高速化をやります 前書き フロントエンド/Node.js 視点のポジショントークです Railsに対するチャレンジャーとして Node.js を使ってきた話 Rubyの開発者やRubyのユーザーを否定する意図はありませんが、好き嫌いは否定しません。型が好きです 「Rails」は 2010年前後に流行っていた任意なWAFに置き換え可能 Symfony
TypeScriptでクリーンアーキテクチャを実践する - WebでもCLIでも使えるアプリケーションの作り方
概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立
フロントエンドとSPA職人の目指したものの歴史と概略
年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
API仕様書をバリデーターと型と同期させて作る
API Spec を書くとそれ通りのリクエストしか受け付けないようにバリデーションしてくれて、なおかつバリデーションされた値には Spec で期待した通りの型が付いて欲しいですよね。 これを TypeScript で実現しようとすると色々と壁があります。特に API Spec と TypeScript の型を揃えるのが難しいです。 この手の課題は NestJS であればクラスフィールドとデコレータを使って解決できるのですが、制約の強い FW であるため会社の事情で採用が難しかったりもします。そこで fastify を使って同様のことを達成できるか模索してみましょう。 (※ OGP は https://www.pakutaso.com/photo/75600.html です。型、バリデータ、API Spec 三銃士感があって選びました) API 仕様書はどうあるべきか まず、フロントエンドエ
【LINE証券 FrontEnd】LINE証券フロントエンドの全体像
こんにちは。フィナンシャル開発センターWeb開発室の鈴木です。Web開発室は現在「LINE証券」のフロントエンドを担当しています。【LINE証券 FrontEnd】 シリーズでは、Web開発室メンバーがLINE証券のフロントエンドにまつわる様々なトピックや、LINE証券の開発中に得た知見をお届けします。今回は第1回ということで、LINE証券のフロントエンドの全体像を説明します。LINE証券というアプリがどんな技術で動いているのか、そして技術に対する考え方を知ることで、LINE証券をより身近に感じていただけると幸いです。 TypeScript + React LINE証券は、いわゆるSPAとして作られています。最近のSPA開発で最初に決めることといえば、1に言語、2にViewライブラリですね。見出しにすでに出ていますが、LINE証券ではプログラミング言語としてTypeScriptを、ライブラ
Frontend Study #1: 基調講演 - Frontend 領域を再定義する
Front-End Study #1「Cloud Native時代のフロントエンド」 - connpass の発表内容のテキスト版です。 発表に載せられなかった参考資料集 StatCounter Global Stats - Browser, OS, Search Engine including Mobile Usage Share The "Developer Experience" Bait-and-Switch - Infrequently Noted JavaScriptよ。文明を捨て、自然に還れ。 ::ハブろぐ Deno - A secure runtime for JavaScript and TypeScript Rome Toolchain Blitz.js - The Fullstack React Framework | Blitz.js ⚡️ Prisma - Da
プロダクト間共通の React コンポーネントライブラリを運用する話 - SmartHR Tech Blog
こんにちは、 フロントエンドエンジニアの @nabeliwo です。 弊社には SmartHR というプロダクトの他に SmartHR の従業員 DB を利用して開発・提供される SmartHR Plus アプリ (以下、 Plus アプリ)というものがあります。 SmartHR CTOが語る中長期戦略。徹底的なアプリ開発とAPI対応で「プラットフォーム化」促進へ - SmartHR ガイド 既に多くの Plus アプリがリリースされており、そのほとんどのプロダクトのフロントエンドは React x Redux という技術スタックで構成されています。 オンライン雇用契約 カスタム社員名簿 ラクラク人事レポート etc Plus アプリは毎回新規でプロジェクトを立ち上げて開発していくことになります。 とはいえブランディングの観点から見ると、基本的なトンマナや UI パーツは SmartHR
大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deck
All slide content and descriptions are owned by their creators.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TanStack | High Quality Open-Source Software for Web Developers
select-frontend-tech.md