You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Firebase Advent Calendar 2017 21日目の記事です。 フリーランスでフロントエンドを中心にエンジニアをやっているpotato4dです。 普段はVue.jsを中心に、案件を進めたりコミュニティに関わったりしていますが、今回はそんなVue界隈で今アツいフレームワークであるNuxt.jsとFirebaseを組み合わせて、SPA + SSRにAuthと Firestore を組み合わせたアプリケーションを高速で作る方法を、サンプルとあわせてご紹介します。 2019/10/16 追記 このサンプルは Firestore が存在しない Nuxt v1.x + RTDB 時代のコードを愚直に移行している ので全体的に資料が古くなっています。 インフラ構成については順次更新していますが、特にデータストア操作周りについては できるだけ参考にしないでください。 2019/07/02
この記事はDMM.com #2 Advent Calendar 2017の14日目です。 はじめまして、普段はDMMサービスのシステム開発、保守を行なっている@norihです。 SPAの記事を書いておりますが業務的にはバックエンド側に触れることが多いエンジニアです。 今回は書くことは僕が2017年の初旬にリリースしたSPA(シングルページアプリケーション)の失敗談と、そこから学んだことについてです。 基本的なことかもしれませんがよろしくお願いします ほかのカレンダーURLはコチラです。 DMM.com #1 Advent Calendar 2017 DMM.com #2 Advent Calendar 2017 リリースしたSPAの概要 最初に今回リリースしたSPAについて少しだけ紹介させていただきます。 詳しいことは省略させていただきますが概要としては次のようなものです。 React +
料金体系 事前にスループットを予約する DynamoDB とは異なり、完全にIOリクエストに対して課金されます。 エンティティの読み込み 0.06ドル/10万エンティティ エンティティの書き込み 0.18ドル/10万エンティティ エンティティの削除 0.02ドル/10万エンティティ データストレージの利用量に対しても課金されます。 0.18ドル/1GB DynamoDBのようなキャパシティを事前に予約することで割引を受けるような制度はありません。 DynamoDB との価格比較 DynamoDB は何もしなくても費用が発生しますが、CloudDataStore は何も操作しなかった場合は費用は発生しません。 一見、CloudDataStore は超お得に思えますが、本当にそうでしょうか。 DynamoDB の最小利用料金はグローバルインデックスしか使わず、キャパシティを読み書きそれぞれ1に
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか?と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型(32bit)で実現されます*1。
はじめに 本POSTは、Fargate Advent Calendarの12/21分の記事になります。 当社の状況 すでに、皆様もご存知だった通り。種類も、数も、質も、圧倒的な各種の魅力的なサービスが目白押しだったRe:Invent 2017でした。私の携わっているサービスでは、IaaSの上にアプリケーションをデプロイした形で展開しております。これはこれで、キャパシティプランニングの上で、対応する部分では問題がない、ということでこの構成を維持しておりますが、近年の流れは追わねばならぬ、ということでコンテナやサーバレスなどの導入の検討を進めております。(すでに開発環境はコンテナ化が完了していますが、productionへの投入は慎重になるべき、と考えています) 何を導入すべきか コンテナとサーバレス、どちらかだろうなあ・・・と思っていたのですが、とあるイベントにてコンテナのサービス投入に関す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く