このエントリは以下のエントリをベースにしています。
This entry is based on the following one, written by Jean-François James
(Senior Software Architect, Head of Worldline Expert Community).
https://jefrajames.wordpress.com/2019/01/04/when-graphql-meets-microprofile/
Java EEからJakarta EEへの移行が進んだ1年の後、2019年にもっと具体的に参加することに決め、MicroProfile GraphQLイニシアチブに参加することになりました。
このエントリではこのグループが開始した経緯、課題、次のステップについて説明します。
ことはEclipse MicroprofileのGoogle GroupでPhillip Krugerが切り出したディスカッションから始まりました。
Phillip Kruger
https://www.phillip-kruger.com/about
Eclipse MicroProfile Google Group
https://groups.google.com/forum/#!forum/microprofile
Phillipは、著名かつアクティブなOpen Source Javaエコシステムへのコントリビュータで、Java EEのコンテキストでGraphQLを使用する方法を紹介するデモプロジェクトをすでに作成しており、さらにExtensions for MicroProfileプロジェクトにも貢献しています。
Membership service – GraphQL Demo
https://github.com/phillip-kruger/membership
Extensions for MicroProfile
https://www.microprofile-ext.org/
IBMのAndy McCright（プロジェクトリーダー）を含む他の何人かがこのグループに参加しました。GraphQL SPQRプロジェクトの主な貢献者であるBojan Tomicのサポートを受けることができて幸運です。これからわかるように、GraphQL SPQRは私たちの達成目標のインスピレーションの主たるソースです。
GraphQL SPQR
https://github.com/leangen/GraphQL-SPQR
What is GraphQL?
GraphQLは、API用のオープンソースのデータクエリおよび操作言語であり、既存のデータでクエリを実行するためのランタイムです。 GraphQLはRESTの置き換えになるわけではなく、代替手段を提供するものです。
GraphQLはFacebook内で2012年に開発され、2015年に公開されました。
2018年11月7日、GraphQLプロジェクトはFacebookから、非営利組織のLinux FoundationがホストするGraphQL foundationという新規設立された団体に移管されました。これは業界およびコミュニティの採用という点で重要なマイルストンです。Atlassian、Coursera、Facebook、GitHub、PayPal、Twitter、などなど大小問わず多数の企業がGraphQLを使っています。
GraphQL
https://graphql.org/
The Linux Foundation Announces Intent to Form New Foundation to Support GraphQL
https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/
GraphQL Users
https://graphql.org/users/
筆者がGraphQLを知ったのは数ヶ月前にBojan Tomicによるすばらしいgraphql-java Tutorial – Introductionを見たときでした。このチュートリアルでは、シンプルなユースケースに基づいて、一般的なGraphQL、特にgraphql-javaの機能を説明しています。強力なクエリ言語と利用可能なデータと操作を記述したスキーマのおかげで、クライアントは必要なデータだけをリクエストするという、非常に柔軟で正確な方法でサーバーと対話できるという点に感銘を受けました。これは、特にモバイルアプリケーションの開発にとって大きな利点です。
graphql-java Tutorial – Introduction
https://www.howtographql.com/graphql-java/0-introduction/
graphql-java
https://www.graphql-java.com/documentation/v11/
How is MicroProfile going?
Eclipse MicroProfileはJava EEの開発の遅さに反応して2016年夏にスタートし、その後Eclipseプロジェクトになってすでに8回リリースをしています。直近のリリースは2018年Q4にリリースされた 2.1（原文記載当時、2019/04/22現在は2.2）です。2019年には、2.2（2019年2月）、2.3（2019年6月）、2.4（2019年10月）の3回のリリースが予定されています。
MicroProfileの正式な目的は、Enterprise Javaをマイクロサービス・アーキテクチャ用に最適化し、複数のMicroProfileランタイム間でのアプリケーションの互換性を提供することです。
具体的には、最先端のマイクロサービスとクラウドネイティブアプリケーションを開発するための機能（外部設定、フォールトトレランス、ヘルスチェック、JWT、メトリクス、OpenAPI、Open Tracing、Rest Client）を提案します。これらの機能は、Open Liberty、Payara、Thorntail、およびTomEEなどのサーバーランタイムによって実装されます（訳注：ThorntailはQuarkus、その背後のSmallRyeが出てきたので風向きが変わってしまいましたが・・・）。
Open Liberty
https://openliberty.io/
Payara
https://www.payara.fish/
Thorntail
https://thorntail.io/
Apache TomEE
http://tomee.apache.org/
What about Jakarta EE?
Jakarta EEは将来のJava EEのブランド名で、Eclipse EE4Jプロジェクトが支えています。EE4Jはトップレベルプロジェクトで、39個のプロジェクトから構成されています。Dmitry Kornilovが書いている通り、2018年のほとんどはOracle Java EEからEclipse EE4Jへの移管に費やされました。
Jakarta EE
https://jakarta.ee/
First year of Eclipse EE4J
https://dmitrykornilov.net/2018/10/22/first-year-of-eclipse-ee4j/
この移行を記録するための大きなマイルストーンは、2019年1月のEclipse GlassFish 5.1のリリースで達成されました（原文では2018年12月中旬の表記がありましたが、実際のリリースは2019年1月なので記載を変更しています）。
Jakarta EEプラットフォームの将来を確実にし、そしてJava Community Processを置き換えるために、EclipseはEFSP（Eclipse Foundation Specification Process）という新しい仕様プロセスを定義しました。
How is the Eclipse Foundation Specification Process (EFSP) different from Java Community Process (JCP)?
https://blogs.eclipse.org/post/tanja-obradovic/how-eclipse-foundation-specification-process-efsp-different-java-community
EFSPに従う最初のプロジェクトはJakarta EE NoSQLであり、これはOtavio Santanaが説明するように、既存のEclipse JNoSQLプロジェクトを利用する予定です。この仕様の目的は、さまざまな種類、ベンダーのNoSQLデータベースと連携するための共通のAPIにより、JavaアプリケーションとNoSQLデータベース間の統合を容易にすることです。
Jakarta NoSQL
https://projects.eclipse.org/proposals/jakarta-nosql
Eclipse JNoSQL
http://www.jnosql.org/
JNoSQL and Jakarta EE
https://www.tomitribe.com/blog/jnosql-and-jakarta-ee/
ちょっと補足すると、NoSQLはデータベースに関するもので、GraphQLはAPIに関するものです。Neo4jのようなグラフ指向のNoSQLデータベースがあり、ArangoDBのようないくつかのNoSQLデータベースがネイティブのGraphQL APIを提案しているという事実は、全体的な理解を単純化するものではありません…
Jakarta EE vs MicroProfile?
MicroProfileとJakarta EEの間には強いつながりがあり、どちらもEclipseプロジェクトであり、同じコミュニティ（IBM、Red Hat、Payara、TomiTribe、Oracleを含む）が支えています。簡単に言うと、MicroProfileはJakarta EEのインキュベーターと見なすことができます。MicroProfileは非常にダイナミックに仕様を提案し、その提案された仕様のうちいくつかはJakarta EEプラットフォームの一部になると期待されています。Jakarta EEが成熟した時点で2つのプロジェクトをマージするのが適切かもしれませんが、当分の間、それらを別々にしておくべきでしょう。
A short introduction to SPQR
SPQRはSchema Publisher and Query Resolverの略称です。（スキーマ優先アプローチに対して）一連のJava注釈をベースにしたコード1stアプローチを提案することで、MicroProfileのコンテキストに非常によく適合します。
GraphQL SPQR
https://github.com/leangen/graphql-spqr
アプリケーションを開始すると、スキーマはこれらの注釈から自動的に生成されます。スキーマ構造はその後指定のURL（schema.jsonが後に付きます）で利用可能になり、GraphIQLのようなイントロスペクションツールを使って検出、テストができます。
An in-browser IDE for exploring GraphQL
https://github.com/graphql/graphiql
Javaのような強力な静的型付け言語を使ったコード1stアプローチに従うと、非常に生産性が高くなります。Schema Domain Specific LanguageとJavaコードを両方メンテナンスする必要はありません。
技術的には、SPQRはgraphql-javaの上位層で、スキーマ1stアプローチに従うことを可能にするgraphql-java-toolsに代わるものです。
GraphQL Java Tools
https://github.com/graphql-java-kickstart/graphql-java-tools
手を動かして知識を増やすために、上記のGraphQL Java tutorial introductionを作り直すことにしました。できるだけ早くGitHubで公開します。 プラス面としては、その使いやすさを評価しました（ほんの数アノテーションで解決できます。特定のクラスやインターフェースを実装または拡張する必要はありません）。 マイナス面では、ドキュメンテーションの欠如に苦しんでいます。GraphQLとSPQRの両方の微妙な点を同時に発見するのは困難でした。
graphql-java Tutorial – Introduction
https://www.howtographql.com/graphql-java/0-introduction/
しかし結局のところ、SPQRはMicroProfileで達成したいことの良い出発点であることは明らかです。
Next steps
正式にMicroProfileプロジェクトになるためには、 提案を最終化し、MicroProfile Boardの承認を得る必要があります。
承認された場合には、スタンドアロン使用として進化することになるため、つづく目的は、上述のMicroProfileリリースに含まれるようにすることです。
その前に、我々の目前には数多くの課題があります。
- トランスポートの管理方法。GraphQLはHTTPで広く使用されていますが、実際にはトランスポート層に依存しません。さらに、MicroProfileはServlet仕様に直接依存していません。その意味では、MicroProfile GraphQLの正確な範囲を定義することが重要ですが、HTTPでGraphQLを具体的に使用する方法を定義することも同様に重要です。
- MicroProfileスタックとの統合を強制する方法（特に外部ライブラリへの依存関係を取り除くことによって）。例えば、独自のライブラリではなくJSON-PとJSON-Bを使用する、とか。
- Server Sent EventやWebSocketを使ってGraphQLサブスクリプションを適切に管理する方法
- GraphQL Unionの実装方法
- 一般的な開発者体験を改善する方法。いくつかの注釈、優れたCDI統合、および優れた「設定より規約（convention over configuration）」を使用して、JAX-RSでRESTを使用するのと同じくらい、GraphQLは簡単に利用できるべきです。
念頭に置いているプログラミングモデルの使いやすさを説明するために、2つのコードスニペットを例示します。
前途に他の多くの課題があるでしょうが、そのようなプロジェクトに取り組んで仕様に貢献しインパクトを出せるのを光栄に思っています。ご興味があれば、是非Eclipse Microprofile Google Groupに参加してください。
Eclipse MicroProfile Google Group
https://groups.google.com/forum/#!forum/microprofile
NoSQLとGraphQLを視野に入れ、「Java EEの将来」は順調です。
（訳注）
現在はMicroProfile-SandBoxで作成中の仕様をご覧いただけます。
Microprofile GraphQL Specification
https://github.com/eclipse/microprofile-sandbox/tree/master/proposals/graphql
eclipse/microprofile-sandbox
https://microprofile.io/project/eclipse/microprofile-sandbox
Logico Inside 