Thin Backend: Instead of manually writing REST API endpoints or GraphQL resolvers you can use a Thin Backend server to automatically get a fully featured API backend.
Instant API for your Postgres DBInstead of manually writing REST API endpoints or GraphQL resolvers, use a Thin Backend server to automatically get a fully featured API backend on top of your Postgres DB. Create your Backend → Documentation 🚀 Build 10x faster, no boilerplate🛡️ End-to-end type safe⏭ Great Autocompletion✅ Optimistic Updates import { query, createRecord } from 'thin-backend'; impor
無料でも使える新サービス「Azure Static Web Apps」はここまでできる！
今回は2020年の5月に発表され、2021年5月に正式に一般公開されたばかりのホヤホヤサービスである「Azure Static Web Apps」についてご紹介します。 AzureでWebアプリをデプロイしようと思ったら真っ先に思い浮かぶのはAzure Web Appsです。 Azure Web AppsはPaaSの一種であり、.NETやJava、Node.js、PHP、Pyhton等多様な言語で書かれたWebアプリをインフラのことを気にすることなくデプロイできるのが特徴になります。 また、静的なサイトのホストティングということでは 「Azure Storageでの静的Webサイトホスティング」という方法もあります。 既にいくつかの選択肢があるなかで新たに追加された「Azure Static Web Apps」は何が特徴なのでしょうか。 1. 安価 Static Web Appsには二種類
Modern web apps without JavaScript bundling or transpiling
August 12, 2021 Modern web apps without JavaScript bundling or transpiling I didn't much care for vanilla JavaScript prior to ES6. Through all of the 2000s, I chased different approaches to avoid writing too much of it. First there was RJS (Ruby-to-JavaScript). Then there was CoffeeScript. Both transpiling approaches that turned more enjoyable-to-write source code into the kind of JavaScript that
Hobson's Browser - Infrequently Noted
Update: This post was turned into a talk for State of The Browser in October 2021; you can watch the recording here. Update, The Second: Welp, I was wrong. I assumed that Facebook PMs and engineers were smart. Of course they were going to get found out modifying content via In-App Browsers, just as this post warned they could. It's long past time for Google and Apple to act to curb this abuse via
Web Neural Network API
Web Neural Network API W3C Candidate Recommendation Draft, 5 September 2024 More details about this document This version: https://www.w3.org/TR/2024/CRD-webnn-20240905/ Latest published version: https://www.w3.org/TR/webnn/ Editor's Draft: https://webmachinelearning.github.io/webnn/ Previous Versions: https://www.w3.org/TR/2024/CRD-webnn-20240830/ History: https://www.w3.org/standards/history/web
Clean Architectureにおいてバリデーションはどこでやるべきか
クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか？と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか？という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同
Web Application開発に10080番ポートは使ってはいけない
要約 現在最新のGoogle Chormeで10080番ポートが使用できなくなった Firefoxではすでにブロック済み NAT Slipstreaming v2攻撃への対応のため ブラウザからアクセスするサーバを建てる場合は10080以外のポートにするべき 回避方法は一応ある Chrome 91以降は10080番ポートがブロックされる Google Chormeの91 (2021/05/25 リリース)から10080番ポートへのサーバに接続できなくなります。 例えば Google Chrome 90だと以下のように10080番のポートを受け付けるサーバにアクセスできますが、91以降だとアクセスできなくなります % python -m http.server 10080 Serving HTTP on 0.0.0.0 port 10080 (http://0.0.0.0:10080/) .
Azure Static Web Apps で Puppeteer を動かしたかった - ほりひログ
はじめに 前回のエントリーでは、Azure Functions で Puppeteer を動かして、特定のページのスクリーンショットを取得する Web API を作ってみました。 uncaughtexception.hatenablog.com Web API で動作がするのは確認できましたが、Web ブラウザーのアドレスランを編集して URL クエリーに対象の URL を入れるのがやや面倒なので、Web API を使用しつつ Web ページで UI を作ってみたいと思い、 静的ページとバックエンド API を一緒にデプロイできる Azure Static Web Apps (以下 SWA、ちな Preview) で試してみました。 Azure Static Web Apps を作る クイック スタートがあるので、そのまま使います。 docs.microsoft.com ざっくりいうと、
Wasp
app todoApp { title: "ToDo App", // visible in the browser tab auth: { // full-stack auth out-of-the-box userEntity: User, methods: { google: {}, gitHub: {}, email: {...} } } } route RootRoute { path: "/", to: MainPage } page MainPage { authRequired: true, // Limit access to logged in users. component: import Main from "@client/Main.tsx" // Your React code. } query getTasks { fn: import { getTasks
Good Bye Web APIs
When building a single-page application or a mobile application, we usually need to implement a web API (REST, GraphQL, etc.) to connect the frontend and the backend. Technically, it's not very difficult, but it has some unfortunate consequences. Imagine two planets. The planet "frontend" speaks JavaScript and the planet "backend" also speaks JavaScript or any other advanced language. Now let's sa
SPA+SSR+APIで構成したWebアプリケーションのセッション管理 - Pepabo Tech Portal
カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント
GAS 家計簿 - Google Apps ScriptとVueで作られたWeb家計簿
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました IT技術の発展はめざましく、日々新しい技術が登場しています。例えばサーバレス、VueやReactの仮想DOM、ちょっと前であればRESTful APIなどがあります。それらを漏れなくキャッチアップするのは大変です。 今回紹介するGAS 家計簿はサーバレスにGAS（Google Apps Script）を使って家計簿Webアプリケーションを作るハンズオンを兼ねたソフトウェアです。 GAS 家計簿の使い方 デモです。動作しているのはGitHub Pagesです。サーバの管理が不要ですね。 データの追加用モーダルウィンドウ。フロントエンドはVueを使っています。 設定画面です。データはGoogle Apps Scriptを使ってGoogleスプレッドシートに保存されています。 GAS 家
AI Visual Sitemap Builder Tool, Website Planner, Architecture
Plan website architectureSite mapping has never been so easy and fun! Within minutes you can start website planning, create colourful visual sitemaps that are pleasant to look at. Prototype with lo-fi wireframesUsing low fidelity wireframes can help you visualize the contents of every website section, so that it's easy to understand the page layout. Our wireframes Plan website contentPrepare, writ
マイクロソフト、「Blazor WebAssembly」正式版を5月にリリース。BlazorでPWAやデスクトップアプリも開発へ
マイクロソフト、「Blazor WebAssembly」正式版を5月にリリース。BlazorでPWAやデスクトップアプリも開発へ マイクロソフトは1月14日（日本時間1月15日未明）にオンラインインベント「.NET Conf Focus on Blazor」を開催、同社が開発中のWebアプリケーションフレームワーク「Blazor」の最新動向と今後について明らかにしました。 Blazorは、C#と.NET Coreを用いてWebアプリケーションの開発を可能にするフレームワークです。JavaScriptを用いず、C#によるプログラミングでSPA（Single Page Application）のWebアプリケーションを開発できるため、.NETの知識や経験をWebアプリケーションに活かせると同時に、Visual StudioなどC#に対応した豊富な開発ツールによる開発生産性の向上を期待できるとい
JavaScript が読み込まれる前でもWeb Applicationを動かす - from scratch
今回は最近取り組んでいる、 JavaScript が読み込まれる前であっても「ちゃんと」 Web Application が動作するように作る話をします。 Server Side Rendering における注意点と対策 BFFを使ってServer Side Rendering をすることに数年前から取り組んでいます。 まずはSSRをやる上での注意点と対策について紹介します。 SSRをすることはSEOのためだと思われがちですが、個人的にはSEOのためにしているわけではなく、 First View を向上するため（特に First Meaningful Paint を向上するため）にやっています。 First View SEOとSSRに関しては Google が最近出したこの記事の SEO Considerations 節が詳しいです。ここでは説明しません。 SSRをしない、Client S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - yusukebe/ramen-api: Web API about 🍜
Patterns.dev
Webアプリケーション概要 2021 / Web Application Overview 2021
GitHub - authelia/authelia: The Single Sign-On Multi-Factor portal for web apps
認証・認可基盤に Keycloak を使って開発生産性を上げた話
