Go言語によるクリーンアーキテクチャの実装例紹介
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細（フレームワークやデータベース）を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
TypeScript による Isomorphic な API Client 開発 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @koba04 です。 本記事では、kintone の REST API を使うためのクライアントである @kintone/rest-api-client (以下 rest-api-client) の構成や工夫した点について紹介します。 本記事は rest-api-client の 1.6.0 のバージョンに基づいています。 @kintone/rest-api-client とは rest-api-client とは、kintone が提供する REST API を利用するためのクライアントライブラリです。 GitHub 上は kintone/js-sdk の Monorepo の 1 パッケージとして開発されています。 kintone/js-sdk での Monorepo 開発については下記の記事を参照してください。 https://blo
平静を保ち、コードを生成せよ 〜 OpenAPI Generator誕生の背景と軌跡 〜 / gunmaweb34
Gunma.web #34 スキーマ駆動開発で発表した資料です！ https://gunmaweb.connpass.com/event/113974/ (追記) OpenAPI Generatorの電子書籍をリリースしましたのでぜひチェックしてください！ REST API のためのコード生成入門 (OpenAPI Generator) https://gumroad.com/l/openapi_generator_ebook_jp (/追記) 発表時から下記修正を加えました。 * サブタイトルをつけ忘れていたのを修正しました * 一部の画面キャプチャを非表示にしました (非表示にした理由はスライドに記載しています)
GitHub APIから学ぶ次世代のAPI実装方式GraphQL - Qiita
最近公開されたGitHubのAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubのAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯
REST API Checklist – Kenneth Lange
Resource Representation The purpose of the resource representation is to show relevant data from the server’s resource. Use these checks when designing your resource representation: Think outside-in (or Design for Intent). Don’t simply expose your underlying data model, but think through what the clients want to achieve and design for that. Only include relevant data that client needs, because it
GolangでAPI Clientを実装する
特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ（SDKと呼ばれることも多いが本記事ではClientと呼ぶ）を使うことが多いと思う．広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている．例えば以下のようなものが挙げられる． https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う（まともなものなら互換性などをちゃんと考慮してくれるはずなので）．一方で小さなサービ
Go 言語と React で考える「いい感じなURL設計」入門
Description 白ヤギコーポレーションさま主催の「最先端情報吸収研究所（AIAL）」のプレゼンテーションで使用したドキュメントです。 「URL」を軸にして、サーバーサイドを Go 言語、クライアントサイドを React (+ TypeScript) で実装する場合の要点を紹介しました。 - いい感じな URL と わるい感じな URL - RESTful API のおさらい - Echo と REST API と URL - React と SPA と URL - いい感じの URL設計を目指す旅 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. interface FooterProps { company:string } export class FooterComponent extends React.Compo
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
static link について - 兼雑記
案外、 static link ってわかってないもんです。というかリンカってわかってないもんです。そして案外はまるものです。以下のクイズに答えられるでしょうか。 クイズ1 $ nm main.o # int main() {} 0000000000000000 T main $ nm foo.a # void foo() { bar(); } void baz() {} foo.o: U bar 0000000000000010 T baz 0000000000000000 T foo $ nm bar.a # void bar() {} void baz() {} bar.o: 0000000000000000 T bar 0000000000000006 T baz $ gcc main.o foo.a bar.a最後のコマンドで、何が起きますか？ 普通にリンクできる undefine
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
登録されるとつらいユーザー名リスト - Qiita
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - t2y/openapi-springboot-sample: springboot microserver sample by generating with openapi-generator