GraphQL

[Phillip Krüger]

Hi All.

Are there any (other) interested to see a standard way to do GraphQL in MicroProfile / Java EE / Jakarta EE ?

Something like JAX-RS but for GraphQL (JAX-QL ??) including a client to access GraphQL endpoints ?

Thanks

Phillip

[Jean-Francois James]

This is an interesting proposals indeed! GraphQL  is now a credible alternative to REST and there are uses cases where it is really a good fit.

[Andy McCright]

Phillip, Jean-Francois,

Are you guys still interested in a MP GraphQL project?  I've been looking into the technology, and I agree that it would be a great addition to the MP stack.  Would you (or anybody else) be interested in working on a joint proposal for a GraphQL project?

Thanks,

Andy

[Phillip Krüger]

Hi Andy.

I would definitely be interested. Let me know how we proceed. (Maybe we should take this offline ? I am name dot surname at gmail :)

Thanks

[Emily Jiang]

I was at Java2Days in the past three days. A couple of people also brought up this topic and would like to participate. Phillip, why don't you start a proposal and involve the interested parties to brainstorm further. I will point them to this thread as well.

Thanks

Emily

[Jean-Francois James]

I would be happy to contribute. I see a lot of interest in my company and around on GraphQL. I've never been involved on a MP project so far. So let me know how this can happen.

Le dimanche 1 juillet 2018 18:24:12 UTC+2, Phillip Krüger a écrit :

[Emily Jiang]

Hi Jean-Francois,

Thanks for showing your interest on this! You need to follow up ECA wiki for actively participating in MP specifications, e.g. submitting PRs etc.

Thanks

Emily

[Daniel Dias Dos Santos]

Hello,

I would like to take part in this proposal.

thank you .

--
Daniel Dias dos Santos

Java Developer

SouJava & JCP Member

GitHub: https://github.com/Daniel-Dos

Linkedin: www.linkedin.com/in/danieldiasjava

Twitter: http://twitter.com/danieldiasjava

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e0f27ee3-9b7d-405c-b398-4bd1bba03542%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jean-Francois James]

As advised by Emily, I've just renewed my ECA. So I'm ready to contribute in a way or another. It may be nice to have a hang out before Christmas Holidays.

[Andy McCright]

Kevin Sutter pointed me to this page for proposing new projects:

https://wiki.eclipse.org/MicroProfile/FeatureInit

Would you all be interested in a web conference later this week?  How about Friday (December 7) at 11am US Eastern Time?  If that works, I can set up an initial meeting to work on the proposal.  

[Jean-Francois James]

Hi Andy, Thank you for the proposal. I have a personal obligation that requires me to leave the office at 5.30 pm CET on Friday (11.30 am US Eastern Time). Would it be possible to plan this web conf  at 10.30 am US Eastern Time? 

[Andy McCright]

Sure.  10:30 am US Eastern Time would work for me - at least in the short term.  If we turn this into a recurring meeting, I may need to find a different time or day.

I'll go ahead and schedule the meeting now.  If that time doesn't work, we can try a different day/time next week.

Thanks!

[Phillip Kruger]

Hi all.

I would love to join, please include me in the calendar invite. Thanks

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a129d659-6f07-4110-9c0a-1c71d48e0864%40googlegroups.com.

[Emily Jiang]

Hi Andy,

Please put the meeting details on the MicroProfile calendar so that anyone who is interested can join.

Thanks

Emily

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/IytkyFSDgKA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAEyd7D45KOPm%3DKKx4rC_Knx81qwh-JAe0iNGTEEzs7rOR7GvFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Andy McCright]

Thanks Emily - it is scheduled on the main MicroProfile calendar - Cesar and David posted instructions for how to access the calendar here:

https://groups.google.com/d/msg/microprofile/sS6PuklsDXI/cg5qZEnQBQAJ

I don't think it is possible to post a direct link to the calendar event, but for anybody who cannot see it, we'll plan to meet at 10:30am US Eastern Time on this Friday, December 7.  We can use my webex ( https://ibm.webex.com/join/andymc ). This is just an introductory meeting, so we may choose a different time or venue for future meetings.

See you Friday!

[Emily Jiang]

Thanks Andy for leading the effort! GraphQL is a hot topic. I am so pleased we are working together to explore in this area.

Thanks,

Emily

[Andy McCright]

I have a proposed agenda for tomorrow's meeting here (will also post in the calendar invite):

https://docs.google.com/document/d/1gb3jirFGrJwDZSbrtnFPVTNjPNe3Y0dUYfm-HkU1c3U/edit?usp=sharing

[Phillip Krüger]

Hi Andy

Thanks this looks great.

A while back I did a small POC on GraphQL on Java EE (Wildfly)

https://github.com/phillip-kruger/membership

I can take you guys through that if you want ?

I've also seen this https://github.com/gcharters/service-styles/tree/master/graphql recently on Twitter, so we can look at that too ?

I still have a few things in my POC that I need to do, like subscriptions, agregation, secutiry and I could not find a nice Java client for GraphQL.

Cool. Chat later.

[Ken Finnigan]

Was there a recording or minutes taken from this call?

Ken

[Emily Jiang]

Hi Ken,

Here is the minutes. IIRC, the call was not recorded.

Thanks

Emily

[Ken Finnigan]

One thing I can't tell from the minutes is what is intended in terms of scope.

Is it just intended to bring in existing GraphQL libraries into MP, or to add something on top?

Thanks

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/82dd0f54-9f4c-48a6-961b-c26c83d4aef3%40googlegroups.com.

[Phillip Krüger]

Hi Ken

(From what I can recall)

There was not anything we want to add that to what exist somewhere in the existing libraries. In fact, the suggestion is to phase the existing features in (I listed a few features that I know about and suggested a version)

At the moment the current libraries is not build around CDI, JSON-P and JSON-B, (So they pull in a lot of libraries) and to get a decent developer experience your need to add more than one library. 

The idea is to standardize this and have an annotation based, easy to use API for GraphQL. (Even if this initially just hide the current libraries)

@Andy @Emily ? Your input ?

Cheers

Phillip 

[Emily Jiang]

Yes, as Phillip said we want to improve the user experience on GraphQL. At the moment, it is just experiment and investigation phrase. Stay tuned.

Thanks

Emily

[Emily Jiang]

doh. I meant to say 'phase' instead of 'phrase'.

Emily

[Jean-Francois James]

From what I've understood, the objective is to define a GraphQL MP API with the following features:

• MP compliant which means no direct dependency outside JAX-RS, CDI and JSON-P, for instance no direct dependency on servlet,
  
• client and server sides,
  
• schema-first (as proposed by graphql-java) and code-first (as proposed by spqr).
  

Following the code-first approach, current implementations proposed by graphql-java and spqr provide a very good starting point but they must be reworked a little to define a fully MP compliant API.

Am I right?

[Jean-Francois James]

I've another question in my mind: should we include the DataLoader in the scope of our work? In my opinion, yes because this is an important part of a GraphQL architecture. There is already a Java implementation we can leverage..

Accessing the data in an efficient way on the GraphQL server-side is a challenge. 

Le dimanche 1 juillet 2018 18:24:12 UTC+2, Phillip Krüger a écrit :

[Phillip Krüger]

Hi Jean-Francois.

I'll add it to the feature list. I agree that it's something we should include.

Cheers

[Jean-Francois James]

I've initialized an inventory of Java GraphQL tools. I was a bit lost understanding which tools does what. Let me know if it useful to share. If necessary I can turn it into any other format.

[Phillip Krüger]

Hi Jean-Francois

This is awesome ! Thanks. I think we should add it to the proposal as an Appendix ? @Andy ? @Emily ?

Cheers

[Jean-Francois James]

Hi All,

Jean-Baptiste Roux from my company, Atos Worldline, will join our group and participate to our meeting tomorrow. He has just signed the Eclipse Contributor Agreement. Jean-Baptiste is very well informed of the GraphQL Javascript ecosystem and can provide a lot of input. Please note, that I will have to leave the meeting at 5.30 pm CET. May be we can discuss a better time slot for me. Regards.

[Andy McCright]

> At the moment the current libraries is not build around CDI, JSON-P and JSON-B, (So they pull in a lot of libraries) and to get a decent developer experience your need to add more than one library. 

> The idea is to standardize this and have an annotation based, easy to use API for GraphQL. (Even if this initially just hide the current libraries)

> @Andy @Emily ? Your input ?

Agreed.  

>From what I've understood, the objective is to define a GraphQL MP API with the following features:

• MP compliant which means no direct dependency outside JAX-RS, CDI and JSON-P, for instance no direct dependency on servlet,
  
• client and server sides,
  
• schema-first (as proposed by graphql-java) and code-first (as proposed by spqr).
  

>Following the code-first approach, current implementations proposed by graphql-java and spqr provide a very good starting point but they must be reworked a little to define a fully MP compliant API.

>Am I right?

Ultimately, I agree with all of this, but it will be a matter of phases.  I think the initial milestone should be to limit dependencies and provide an easy-to-use, code-first server API.  Subsequent milestones should include a client API and a schema-first API.

> This is awesome ! Thanks. I think we should add it to the proposal as an Appendix ? @Andy ? @Emily ?

Yes, great idea.  BTW, the proposal document looks great!  Thanks for updating it!

> Jean-Baptiste Roux from my company, Atos Worldline, will join our group and participate to our meeting tomorrow. He has just signed the Eclipse Contributor Agreement. Jean-Baptiste is very well informed of the GraphQL Javascript ecosystem and can provide a lot of input.

Excellent!  Welcome Jean-Baptiste!

I spoke with Bojan Tomic - he is the principal developer for GraphQL-SPQR, and he will hopefully attend tomorrow's meeting too.  

> Please note, that I will have to leave the meeting at 5.30 pm CET. May be we can discuss a better time slot for me.

Thanks for letting us know.  Would it help to move the meeting back it's original time (30 minutes earlier)?  I think we mainly moved it to the later time for convenience, but I don't think the original time excluded anybody.  We can definitely look for another day and time too - but it looks like there are a lot of regularly scheduled MP meetings...

Thanks, Andy

[JB Roux]

Hello guys !

I'm glad to participate with you to this MP spec ! Hope I will be able to provide useful input :)

[Andy McCright]

The GraphQL meeting is still on for today - remember that we changed the time back to 10:30am US Eastern Time.

Jean-Baptiste, did you get the audio issues worked out?  I can try to start the Webex a few minutes early if you want to try some different audio options before the meeting starts.

I think the main goal of the meeting should be to iron out the remaining issues with the proposal document so that we can make the official proposal at the first general MP meeting in January.

Thanks, see you all in a few hours,

Andy

[Werner Keil]

It's already supported by Jakarta EE NoSQL ;-)

[Phillip Krüger]

Hi Werner, we are talking about GraphQL, not GraphDB. So no persistance. This is similar to REST.

graphql.org

Does Jakarta NoSQL support this ?

[Mehdi Raza]

Hi

I have been hearing that GraphQL has to do something with CQRS and they both are compatible, I dont believe it though.

What do you guys think? If this is true then the initiative should target CQRS as the top level initiative and Command/Query can come inside it using GraphQL etc.

Regards

[JB Roux]

Hello Andy, happy new year !

Regarding the webex audio issue I got, we retried with JF James using the desktop client and it worked fine. So I hope it will do the trick also for our meetings !

Concerning the MP spec, I am planning to create a sample mock project based on the official documentation (https://graphql.org/learn/schema), using the same Starwars use case. I think it will provide us a more complexe exemple to illustrate the annotations. Let's discuss this idea on the next meeting !

[Jean-Francois James]

There is no direct relationship between GraphQL (which is a protocol between a client and a server) and CQRS (Command Query Responsibility Segregation) which is a design pattern to separate the way to run queries (which don't change the state of the system) and the way to run commands (which do change the state of the system). Of course they can be combined together (for instance using CQRS queries to process GraphQL queries and CQRS commands to process GraphQL mutations) but in my opinion they should be kept separated in terms of specifications.

[Mehdi Raza]

I agree with you on separate specifications, the implementation can use GraphQL using separate read and write models.

[JB Roux]

Hi all,

Here is the mock project I proposed earlier: https://github.com/thejibz/graphql-starwars

It's a basic java project (using openliberty atm) that intends to mirror the starwars sample used in the official graphql documentation (Character, Startship, Episode...)

The goal is to share a common datamodel to write the spec examples.

Ofc, it's just a proposal to be discussed during the next meeting.

JB.

[Werner Keil]

Yes, it does, there are GraphDB systems like ArangoDB using GraphQL as a query language, and NoSQL supports that already:

https://github.com/eclipse/jnosql-diana-driver/blob/master/arangodb-driver/src/main/java/org/jnosql/diana/arangodb/package-info.java

Because that "JAX-RS Client" already watered and fragmented what's actually supposed to be done in the JAX-RS Spec, not some less formal pseudostandard, hopefully MicroProfile won't repeat that mistake here. Many people work on both anyway, so having to maintain two different projects or more won't help either of them.

I'm not sure, what the scope would be, there are plenty of Java implementations of GraphQL as such: https://github.com/graphql-java/graphql-java has over 100 contributors, show me a single MicroProfile repo with more than 10 active contributors, thus would it really be the goal to reinvent the wheel, or would it merely by some annotations around GraphQL. Again, the module currently called NoSQL Artemis (we know that name has to change once Jakarta NoSQL is established;-) does exactly that, it is the building block between lower level Diana Drivers and the applications using it.

[Werner Keil]

IMHO a MicroProfile CQRS feature would make much more sense than MicroProfile GraphQL. As mentioned in other parts of the thread, GraphQL is a protocol similar to REST (actually that is more a methodology, not a protocol;-) or SQL. There is little sense and need for this here, at most, MP offers thin wrappers or "glue" combining CDI annotations with underlying specs or protocols. 

The majority of MicroProfile features are centered around some of the most popular Microservice Patterns: https://microservices.io/patterns/microservices.html Config, Failover, you name them, CQRS: https://microservices.io/patterns/data/cqrs.html is also there. I would stick to those and not trying to reinvent what either Jakarta NoSQL or stable and mature GraphQL Java libraries like https://github.com/graphql-java/graphql-java (with Daily Builds directly to MavenCentral!!! https://search.maven.org/search?q=g:com.graphql-java%20AND%20a:graphql-java) already accomplished.

Werner

[Phillip Krüger]

Hi Werner.

I can see from the link that Jakarta NoSQL supports a data store via a driver and that that data store support GraphQL (maybe ? Could not really get enough proof for that). But it does not seem that Jakarta NoSQL Specification support GraphQL. (And I don't think it should).

Please correct me if I am wrong but as I understand:

1) We can use Jakarta NoSQL and the ArangoDB driver and data store and then fall down to implementation details to data store query that data store. We could expose this as an API maybe? This ties us to that data store. Not what we want. In fact we do not want to at all include persistence in our proposal.

2) We can propose to add GraphQL to Jakarta NoSQL Specification. I personally think Jakara NoSQL is already crowded, supporting too many things, and I would rather suggest breaking the different types of stores supported by the specification up into separate specifications (but that is a different discussion)

We have looked at https://github.com/graphql-java/graphql-java and build more than one example using it. We also looked at other libraries that support GraphQL in Java. We still believe it should be easier to create a GraphQL endpoint, and that is what we are proposing. A set of simple, CDI based, easy to use annotations in the same style as JAX-RS that allows developers to create GraphQL Endpoints (via HTTP) very easy. I would guess that if that continue that, at least initially, most implementations would be build by wrapping graphql-java. 

If you are still concerned, please join us tomorrow in our meeting. It's in the MP Calendar.

Cheers

Phillip

[Phillip Krüger]

Agreed. And it's already under discussion here :https://groups.google.com/forum/#!topic/microprofile/FdF-W8zEW34

[Werner Keil]

Hi,

Jakarta EE NoSQL supports Graph type data sources, independent of their particular implementation. Where those (like ArangoDB) use GraphQL, it offers a way to access it, but can't say, if it would benefit from offering a more general purpose GraphQL implementation like  https://github.com/graphql-java/graphql-java. 

Hard to say, what that kind of "glue" or wrapper should look like? As https://graphql.org/code/#java also points to GraphQL Java, it seems like the de facto standard at the moment. And trying to create a Jakarta EE "spec" may be cumbersome (of course there are also dozens of JSON processing libraries in Java alone, so I don't think it is unreasonable to think about it, but that if at all should be done under a real spec like Jakarta EE) so a thin CDI wrapper may not be a waste. The one around JAX-RS contains only half a dozen classes and annotations, which really do belong to the actual JAX-RS spec, here it may be different, unless people (also in your group/call) think, another GraphQL Java implementation was necessary)

Nice to hear about CQRS.

Werner

[Jean-Louis Monteiro]

Hey Werner,

I'm a bit confused with your answer.

I may be wrong, but GraphQL and database query language (NoSQL for instance) aren't really at the same level in terms of architecture, right?

Also, CQRS is again in my mind, different from what's under GraphQL. To me, it makes equally sense to discuss CQRS for MicroProfile than to discuss GraphQL for MicroProfile.

What do you think?

Can you clarify your mind?

--

Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/132c0d6f-0eab-49ca-b6dd-6bd70ec7d6d3%40googlegroups.com.

[Werner Keil]

Hi,

CQRS for MicroProfile is already discussed, so no question or doubt about that.

When querying Graph-based systems, what NoSQL does in that case is very similar, if not identical to GraphQL, so in terms of architecture there are many similarities between what NoSQL does and https://www.graphql-java.com/documentation/master/schema/.

Things are called slightly different and using GraphQL together with a Document-based DB like MongoDB https://medium.com/@aronbalog/spring-boot-kotlin-graphql-mongo-e73f25df6ab9 is something we have not considered so far, but a valid point. 

The mentioned Kotlin/GraphQL solution also uses the "RI" (there is no RI in Java, but graphql-java was modeled after the JavaScript RI) so it's probably best to use that. And if there is anything of value to wrap around, time will tell, if a reusable Jakarta EE annotation could be used by both NoSQL and e.g. MicroProfile.

[JB Roux]

Hello,

If I might add my 2 cents, I would say that one of the strength of GraphQL is to "graphi-ze" systems that are not graph oriented at first. For example, one of the main use case presented over here: https://www.howtographql.com/basics/3-big-picture/ is about merging multiple existing systems (could be REST + SQL + MongoDB + LDAP ...) into a single queriable endpoint. Moreover, you can create link between them (think of SQL joins) by changing the target system as you go deeper in the graph during the query execution. For instance, at Worldline we have made some promising experiments on that for our internals API.

JB

[Werner Keil]

Thanks for the input. Indeed making non-graph aware systems like MongoDB or other document-oriented data sources graph-aware is appealing. A lot of the queries are what makes JNoSQL powerful, check out the slides on SlideShare, e.g. our most recent talk at Java2Days: https://www.slideshare.net/slideshow/embed_code/key/xi4dNpK0RPc9iG?startSlide=8. Or Otavio's CodeOne session: https://youtu.be/Zaiff1pSmc8 (not sure, if the full version is only for attendees, but there should be other places for videos by Otavio and others)

While Jakarta NoSQL may make some compromises to allow a similar experience on some very general elements there are specific ones for Graph-based systems. And if a synergy between the Graph-based variants could be found and a more general purpose GraphQL "glue" (or framework) that would be an ideal situation from a user's point of view. Not sure, if it's possible, but the ways to query elements in the graph are somewhat comparable.

Werner

[JB Roux]

Hello guys,

Shall we create an entry in the Eclipse Microprofile wiki (https://wiki.eclipse.org/MicroProfile) with for starter: the links to this discussion, the minutes and the draft document ? (I can do it if I get a group go)

JB.

Le dimanche 1 juillet 2018 18:24:12 UTC+2, Phillip Krüger a écrit :

[Richard Monson-Haefel]

I'm probably alone on this, but I do not think that GraphQL as glue among disparate systems is going to have broad applicability.  There may be an occasional use case, but those will be rare IMO.  Combining multiple systems into a single query is fraught with issues not least of which is latency and the actual code that binds them together can be very complex and error-prone.

I think GraphQL has a place with NoSQL or as a substitute or complement for REST APIs, but I don't think its compelling as a general framework for gluing disparate systems together. 

what I think is going to happen is that GraphQL will find real use in NoSQL databases and as a substitute for REST APIs, but most attempts to use it as glue for disparate systems will fail.  This is based on my own experience attempting to do this kind of thing in the past with CORBA in the 90's, SOAP in the early 2000's and REST in the last decade or so.  What I've found is that remote interfaces work much better if they are associated with one system rather than trying to aggregate several different systems together.

 Again, I know this opinion is an outlier but felt that I should at least share my thoughts.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/07d1c1eb-ba54-4e90-bbff-2477b109f53b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Richard Monson-Haefel

https://twitter.com/rmonson

https://www.tomitribe.com/

[Ken Finnigan]

You're not alone Richard.

I'm on the fence as to the real world benefit or need for this, but I'm also uncertain as to what it really looks like from an MP perspective.

Right now I'm ok with some exploration around API and an implementation to get an idea of what it is and what the benefits would be.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAF1xDAgEPECoxSJ60-52prpVc_3V__hBsBSDmrswPaKNSksjLw%40mail.gmail.com.

[Richard Monson-Haefel]

Yup. An investigation is important!  Hopefully, my 2¢ adds some value.  

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5EkUzOOWEhc7n_JPmRPGGUKTAd%2B_0zPNu-F0%3DXJKeY0w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Andy McCright]

Hi Richard, Ken,

Thanks for the feedback.  I'm fine with the skepticism - and hopefully our efforts at investigating this technology in the MP space will win your over!  :-)

My view here is that GraphQL is gaining a lot of popularity in the industry - just not (yet) so much in Java.  As GraphQL continues to grow in popularity, I suspect some Java developers will start looking at other languages that offer more rich, first class support - and I think that would be a net loss to MP and the Java ecosystem as a whole.  I think the Java EE community took a similar risk on REST with JAX-RS about a decade ago, and it has totally paid off (I believe JAX-RS is one of the most popular EE technologies today).  I'm a lousy fortune teller, so I won't make any bold predictions about the success of the MP GraphQL project, but I think that to ignore GraphQL would be a mistake.

I would also encourage you both to contribute to the discussions in the project - definitely in the proposal doc, but possibly in the weekly meetings if it works with your schedules.  You both have a lot of experience that would be extremely valuable to the success of this project.

Thanks again!

Andy

[Emily Jiang]

Andy,

I suggest the GraphQL workgroup to start populating the use cases in the MicroProfile sandbox , e.g. problem statement, why GraphQL is the right tool? Why we should adopt GraphQL in MicroProfile community? See reactive streams proposal for reference.

Hope with the constructive doc it will be much clearer on whether it is good thing to adopt GraphQL or not!

Thanks

Emily

[Alasdair Nottingham]

I didn’t think the purpose of the sandbox move was to justify GraphQL work, but to kick start working on GraphQL itself. While a decision will be made later whether that should graduate or not didn’t think the intent was to continue the discussion on whether it was worth looking at or not. 

Alasdair Nottingham

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/55793372-a473-4ef9-89ef-0abae14d2984%40googlegroups.com.

[Emily Jiang]

Basically, getting the justification onto the sandbox will help drive the discussion. It will be much easier to look and then update to address concerns. Once the use cases are clearly specified there, we can all look at the proposal and then vote for going or not going.

Emily

[Andy McCright]

Hi Emily, Alasdair,

Thanks for the feedback.  We have documented some justification for the MP GraphQL project in our own proposal doc[1].  During today's meeting we discussed moving this content from Google Docs over to the sandbox repo (at the same time, we also dropped the initial project boilerplate to get us going).  Phillip owns the action to move the Google Doc over to the sandbox.  If there is anything particular that you would like to see beyond what is already mentioned in the proposal doc, could you let us know?  Or better yet, could you propose a change with your own Issue or PR?  :)  

Thanks again - and have a great weekend!

Andy