見よ、これがHonoのRPCだ
僕が開発しているWebフレームワークHonoは、同じJavaScriptのフレームワーク、Expressと比べられることが多いです。どちらもやれることはほぼ同じですが、HonoのアドバンテージはファーストクラスでTypeScriptをサポートしていることです。特に「RPC」機能は他のフレームワークにはなかった「TypeScriptの型でサーバーとクライアントの仕様を共有する」ことを可能にしています。今回はそのHonoのRPCについて紹介します。 どんなものか まず、どんなものかを箇条書きで共有します。 Web APIの仕様、特にインプット・アウトプットをサーバーとクライアント間で共有するためのもの OpenAPIやgRPCを使ってやりたかったことを叶えるかもしれない サーバーとクライアントをどちらもTypeScriptで書くことが大前提である 同種のものにtRPCがあるが、Honoの場合、
フロントエンドの Monorepo をやめてリポジトリ分割したワケ - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい
Chrome拡張機能をGitHub ActionsでChrome Web Storeにデプロイ
どうも。えーたん（@eetann092）です。 先日、Chrome拡張機能「Choomame（チューマメ）」を公開しました。 本記事では、Choomame開発時に使っている「Chrome拡張機能をGitHub Actionsを使ってChrome Web Storeへデプロイする手順」を紹介します。 メリットは以下です。 自分で拡張機能のversionを制御しなくて良い 更新版をアップロードするときのバージョンの上げ忘れを気にしなくて良い Chrome Web Store Developer Dashboardに手動でアップロードする手間が省ける Chrome Web Store Developer Dashboardから手動で審査の申請をする手間が省ける GitHubの「Releases」に自動でリリースノートを作成＆拡張機能のzipファイルをアップロード 初回はChrome Web St
GitHub - pavlobu/deskreen: Deskreen turns any device with a web browser into a secondary screen for your computer. ⭐️ Star to support our work!
If you don't live in a cave and aware of what is going on in the world 🌍 , Russian 🇷🇺 government had started global armed invasion on the territory of Ukraine on the 24th of February 2022. This is for real, this is a WAR. Russian army is killing Ukrainian soldiers, Ukrainian civil citizens and Ukrainian children RIGHT NOW because Russian government gave them an order to do so. You can search on
GoogleのWebAPI設計とWebAPI設計のベストプラクティスを比較してみる
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
JSONをURIに埋め込んでも%地獄にならない「Rison」のススメ - Qiita
さくらのクラウドでバックエンドを担当しております、@townewgokgok と申します（記事はフロントエンド寄りの記事になります）。これは さくらインターネット Advent Calendar 2018 11日目の記事です。 JSONのように階層化された値をURLに埋め込みたいことってありませんか？ たとえば 価格.com の商品検索結果ページ のように、リンクを開いたら検索フォームの内容が復元されて、URLのコピー時に見ていたものがそのまま表示されて欲しい。 これを実現するには、従来なら文字列のキーバリューとしてごく一般的な application/x-www-form-urlencoded 形式でURLにパラメータを埋め込むところです（上記の価格.comの例でもやはりそうなっています）。ただ、そこそこ複雑な検索フォームの値をいちいちこの形式にまとめたり復元したりするのはわりと面倒です
速報: Basecampがリリースした「Hotwire」の概要｜TechRacho by BPS株式会社
12/23の朝方、DHHが以下のツイートを発信しました。 Hotwire aka NEW MAGIC is finally here: An alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This includes our brand-new Turbo framework and pairs with Stimulus 2.0 😍🎉🥂 https://t.co/Pa4EG8Av5E — DHH (@dhh) December 22, 2020 取りあえず様子を知りたかったのでDHHのツイートを追ってみました。お気づきの点がありましたら@hachi8833までお知ら
lerna/yarn/npm workspacesとTypeScript Project Referencesの設定を同期するツール
lerna/yarn/npm workspacesとTypeScript Project Referencesの設定を同期するツール TypeScript Project Referencesは、tsconfig.json同士の依存関係を定義することで、効率的なビルドが可能になる仕組みです。 Project Referencesの仕組みを使うことで、monorepoなど一つのリポジトリ内で複数のTypeScriptで書かれたパッケージがある場合に効率的なインクリメンタルビルドなどができます。 また、VSCodeなどのコード補完に使われるTS-Serverなどのスキャンも効率的になります。 Migrating Large TypeScript Codebases To Project References — Developer Tooling Optimizing multi-packag
Capability URLsをBearer Tokenと捉えた場合のJWT適用の可能性 - r-weblife
こんばんは。ritouです。 少し前に、このようなスライドを見かけました。 docs.google.com 今回はこのCapability URLsにJWTを使ってみてはいかがかなというお話をします。 私ぐらいになるとこういうやつもeyJ派なので...https://t.co/7FodQaA8ap— 👹秋田の猫🐱 (@ritou) 2020年8月11日 Capability URLs as a Bearer Token 挙げられている特徴や要件として 推測できてはいけない URLとして適切な長さ(ブラウザによって処理できないやつが出てこない) ぐらいで、"えいち、てぃー、てぃー、ぴー、..." とラジオのDJが番組内で紹介できるぐらいの短さを求められたりしないのであれば、OAuth 2.0のBearer Tokenの要件と同等に捉えることもできそうです。 qiita.com JWTの適
webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
twitterに書いたやつ再掲+加筆。 Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではな
「外部パッケージの型定義もインストールし推論できるTypeScript playgroundを作った」という題で登壇してきました＋スライドの補足
「外部パッケージの型定義もインストールし推論できるTypeScript playgroundを作った」という題で登壇してきました＋スライドの補足 “外部ライブラリもインストール・型解釈できる TypeScript playground を作った”という題で俺得フロントエンド (1) LT 会という勉強会で登壇してきました。スライドはこちらです。 — 外部ライブラリもインストール・型解釈できる TypeScript playground を作った スライドの内容をそのまま書いても意味がないので詳しくはスライドを読んでいただきたいのですが、発表時間の都合・構成力不足で伝えきれなかった部分の補足・補完的なものを書きます。 この playground のより詳細な説明、内部で使ってる技術の説明、この playground に限らず汎用的に活用できそうな技術の話をします。 何を作ったの — Type
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に｜ハイクラス転職・求人情報サイト AMBI（アンビ）
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に JavaScriptプロジェクトでTypeScriptを導入する際には、“柔らかい”静的型付き言語とするのがおすすめです。藤吾郎（gfx）さんがまとめた「がんばらないTypeScript」のガイドラインです。 TypeScriptは、すべてのJavaScriptプロジェクトで採用する価値のある技術です。TypeScriptとこれに対応したエディタを導入することで、補完や型ベースの整合性のチェックにより、すべてのプロジェクトで生産性が上がります。またリファクタリングも容易になるので、長期あるいは大規模なプロジェクトでも品質を保ちやすくなります。 この記事では、TypeScriptについて最低限の知識とともに、サクッと（どちらかというと既存のプロジェクトに）導入するための
ECMAScript 2019の議事録を全部読む #TC39MTG 読書会をしました
ECMAScriptの仕様策定に関する行うTC39のミーティングログはすべて公開されています。 rwaldron/tc39-notes: TC39 Meeting Notes ECMAScript は 毎年5-6月あたりに新しいバージョンが公開されます。 新しいバージョンに入る仕様は、毎年1月のミーティングで確定します。(なのでES2019はもう決まっています。) そのため、ECMAScript 2019の仕様に関する議事録は2018-03 から 2019-01 の6回分になります。(2ヶ月に1度開催される) https://github.com/rwaldron/tc39-notes/tree/master/es9 このログを読みながら、進んでいるプロポーザルや進まなかったプロポーザルについてを見ていく読書会をしました。 なぜそのStageになっているのかという、数値だけではわからない背
Webサイトのクローリングやスクリーンショット撮影が簡単にできるヘッドレスChromeがGCPに登場
Googleのクラウドである「Google Cloud Platform(GCP)」のサービスの1つである「Google App Engine」が2018年6月にJavaScriptの実行環境であるNode.jsに対応し、それに伴ってさまざまなNode.jsアプリがApp Engineで動作するようになりました。その中の一つに「Puppeteer」というものがあり、このPuppeteerを用いるとGUIを描画しないヘッドレスなChromeを簡単に使うことができ、Webサイトのクローリングやスクリーンショットの撮影などが容易に行えるようになります。 Introducing headless Chrome support in Cloud Functions and App Engine | Google Cloud Blog https://cloud.google.com/blog/pro
Angular + Firebaseで作ったWEBサービスをリリースしたので、たまった知見を書き出してみる - Qiita
Angular + Firebaseで作ったWEBサービスをリリースしたので、たまった知見を書き出してみるJavaScriptAngularSEOSPAFirebase はじめに 以前からちょこちょこ新しいWEBサービスを作っているということをQiitaの記事に掲載していましたが、このたび[SCORERA（verβ）」を正式にリリースしました。（2019年3月にサービス終了） サービス構築、リリースにあたって色々と知見がたまったので、作成過程で詰まったことや、リリースにかかる作業のうち技術的な側面のものを中心に公開しておこうと思います。 目次 前提 どんなサービス？ 使用している技術 トピック SCORERAのディレクトリとモジュール構成 RxJSの状態管理 外部ライブラリの選定 FirebaseのRealtime DatabaseとFirestore クライアントサイドのエラー取得 An
管理画面は設定ファイルぐらいシンプルに作れるべき！『Viron』を使ってみました - pixiv inside
こんにちは。Web APIにちょっとこだわりのある、CTOの@edvakfです。 最近福岡のヌーラボさんで開かれたGeeks Who Drink -Public API Edition-で「お前はこれまでに作ったAPIの数を覚えているのか？」というタイトルで30分ほど発表してきました。発表資料はこちらです。 Vironと私 そんなWeb API好きの自分ですが、どうしてもUIを作るのはあまり得意ではなく、管理画面を実装したりするのは苦手意識があったのです。…などと思ってところ、今年の2月にCAモバイルさんからVironというツールが発表され、「まさに欲しかったやつだ！」となったのでした。 全ての管理画面開発に悩めるエンジニアに捧ぐ 〜Viron誕生〜 ピクシブ福岡オフィスで作っているpixiv chatstoryでは、「RailsのAPI」と「iOSアプリ」と「Webフロントエンド」という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ノーコード・コードレスでGoogleスプレッドシートからAPIを作成できる「SSSAPI」β版がリリース
GitHub - GoogleChromeLabs/AutoWebPerf: AutoWebPerf provides a flexible and scalable framework for running web performance audits with arbitrary audit tools including PageSpeedInsights, WebPageTest and more.
https://tamanyan.me/typescript-nuxtjs-firebase/
