MF KESSAIでバックエンドのエンジニアをやっているgarsueです。 先日当社のnoteのインタビュー企画でNestJSを使ったBackend For Frontend(以下BFF)について「ブログお待ちしてます！」と言われてしまったので、重い腰を上げて書くことにしました。

当社ではNestJSをGraphQLをしゃべるBFFとして使っているので、そのあたりの勘所や知見を少し紹介します。

なぜBFFとしてNestJSを採用したか

まず、フロントエンドのフレームワークはNuxtJSで決まっていました。当社での2年以上の実績もあり、もはや定番となっています。 また、NuxtJSと合わせてGraphQLを使うのも定番となっており、今回もGraphQLを使うことが決まっていました。

NuxtJSから呼び出すBFFは今までGoでgqlgenを使ったGraphQLサーバーとして実装していました。 これはこれで悪くないのですが、やりたいことはバックエンドのサービス群を呼び出してフロントエンドの都合のいい形に加工して返すことぐらいなので、もっと軽く開発できる何かにしたいなとも思っていました。

そこで高い抽象度で記述量も少なく抑えられ、フロントエンドエンジニアも触りやすいTypeScript製のフレームワークであるNestJSを採用しました。 GraphQLもサポートされていて、NestJS自体がマイクロサービスアーキテクチャを前提にしてるフレームワークでもあり、今回の要件にマッチしていました。

MF KESSAIでは「マネーフォワードグループ、新型コロナウイルスの感染拡大防止に向け在宅勤務を実施」のタイミングから全従業員がWork From Homeを実施しています。 しかし弊社では創業時からWFHでも安全に安心して行える環境、そして組織体制を構築してきました。

そのおかげか今回の新型コロナウイルス（COVID-19）への対応として原則在宅勤務となった際にも、大きく生産性を下げる事なく実施する事に繋がりました。

サーバーサイドエンジニアの@usumachiです。 For Developersチームとして、MFKESSAIを利用するエンジニアの体験向上に向けた開発をしています。 今回はGoogle Cloud FunctionsとSentryを利用したエラートラッキングについてのTipsを紹介できればと思います。

MFKESSAIでは、エラーのトラッキングにSentryを利用しています。 Google Cloud FunctionsからGolangで発生したエラーをSentryで管理する際に、 エラーがすべて1つにまとまってしまうという問題に直面しました。 その解決方法を共有できればと思います。

人事の井上（@inoueray）です。テックなブログに失礼します。CTOの篠原が「フロントエンドの方と面談や面接をした際に『デザイナーとどのように関わっているのか？』という質問をよく貰う。」とぼそっと話していたので、本日はフロントエンドエンジニアとデザイナーに、お互いの関わり方について話をしてもらってきました。

はじめまして、MF KESSAIでバックエンドエンジニアを担当しているshoheiです。

今回はGoの開発業務で触ったcontainer/heapパッケージについての話です。

container/heapとは

Overviewを読めば分かる通り、「ヒープ」データ構造とその操作関数を提供してくれるパッケージです。

使い方も非常に簡単でインタフェースを実装したスライスにheap.Pushしていくと、heap.Popでスライス内での最小値が返却されます。 スライスを二分木構造に展開してPop時にルートにあたる最小値を返しているんですね。よくあるユースケースとして以下に時刻のソートを実装してみます。