MP GraphQL Project Repo

[Andy McCright]

Hi All,

At the January 8th meeting we decided that the MP GraphQL project should begin work in the sandbox repo, with the understanding that it would eventually emerge into a standalone project (i.e. not part of the next MP 2.X umbrella release).

Since then, we have had weekly discussions, built an API, built multiple compatible implementations, started the spec document (based on the very detailed project proposal document), and started work on the TCK.  At this point, I think we are ready to move into our own project repository.

If there are any questions about the project, I would recommend (1) reading the proposal doc, (2) watching Phillip's screencast, (3) experimenting with my sample and prototype based on OpenLiberty (it has super heroes in it!), or (4) replying to this thread.

If it makes sense, I would be willing to demo my sample/prototype at the next community hangout, but I would like to get the ball rolling now on the new repo.

Thanks!

Andy

[Emily Jiang]

Thank you Andy and team on the great progress made on GraphQL!

+1 on the repo creation! microprofile-graphql as the repo name?

Thanks

Emily

[Ken Finnigan]

You mentioned multiple implementations.

Other than OpenLiberty who has an implementation in progress?

--
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/a657bc4f-42ca-44f9-be7d-e44d0fcdb202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy McCright]

Hi Ken,

You mentioned multiple implementations.
Other than OpenLiberty who has an implementation in progress?

Phillip has a prototype [1] built on Thorntail (I believe he is moving it to Quarkus) and Jean-Francois has built a POC implementation[2] that works with Payara and OpenLiberty - though his implementation is packaging the GraphQL libraries with the app.

As a side note, KumuluzEE also has a Java-based GraphQL implementation [3], though it is not based on the MicroProfile project that we've been working on.  Phillip reached out to the Kumuluz folks, and they are interested in the work we're doing, but so far have not participated in the community.

[1] https://github.com/phillip-kruger/membership/tree/microprofile#microprofile-graphql-proposal

[2] https://github.com/jefrajames/spqrdemo

[3] https://github.com/kumuluz/kumuluzee-graphql

[Ken Finnigan]

Andy,

Took a quick look at [1] and [2], they both appear to be using Servlets as the base for exposing the endpoints. Not sure about OpenLiberty as I haven't seen the code.

Does this proposal require Servlet spec to be added to MP platform?

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2e1e19ba-eb3a-4845-bd42-dc8b9e59ad08%40googlegroups.com.

[Andy McCright]

Ken,

There is no requirement in the spec for using servlets, but it certainly makes the implementation easier thanks to the graphql-servlet library.   Technically, it should be possible to provide an implementation without using servlets, but it would require building a new transport layer.

The OpenLiberty prototype implementation is currently only on my personal fork/branch [4] - and it also uses servlets.

Hope this helps,

Andy

[4] https://github.com/andymc12/open-liberty/tree/graphql

[Ken Finnigan]

Thanks for the information Andy.

Right now I'm a -1 on this moving to its own repository.

For me, one of two things needs to happen to move this forward:

1. An implementation exists that doesn't rely on Servlets, but existing MP specs (ie. JAX-RS).
2. A wider MP discussion is had about adding Servlet spec to the platform, so that implementations can be based on Servlets instead.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c648c69e-ace1-4a42-9dc0-777976ea2ffb%40googlegroups.com.

[Phillip Kruger]

Hi Ken, Andy

Should be easy enough to use jax-rs, I'll have a look at that.

Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4naa%3DX1ny7AoYKHoOKsAP_55tp2fUYpkoBBCYeu8yMmg%40mail.gmail.com.

[Alasdair Nottingham]

I don’t agree that a requirement to move forward should be to prove you can implement the graph ql proposal on JAX-RS. I think if the API exposed servlet,

and I can’t see that it does, that would be a more concerning development, but implementations should be at liberty to decide how the link between the 

http traffic and the application components work. Servlet is a valid choice, many of us have implemented JAX-RS on it, and some have not choosing Netty instead.

What is next, we need to prove that the reactive messaging support can be built on JAX-RS?

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4naa%3DX1ny7AoYKHoOKsAP_55tp2fUYpkoBBCYeu8yMmg%40mail.gmail.com.

[Ken Finnigan]

Not all implementations include the full gamut of Java EE/Jakarta EE specifications.

If MP GraphQL can not be implemented by anyone without relying on Servlet spec, then that's a problem because it breaks the definition of the MP platform.

API requirements are important, yes, but if an implementation can not be done without incorporating other specifications that are not part of the MP platform, what's the point in defining a set of specifications for the platform?

FYI, Reactive Messaging isn't implemented on the Servlet spec, so it's not an issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A13B3B98-21E5-4BD0-BC30-00A8152CB498%40gmail.com.

[Alasdair Nottingham]

There is a difference between saying “can you prove this is possible on something other than servlet” and “you have to do it based on something already in MP, you have to do it on JAX-RS”

I also think it is unfair to gate something getting into a repo as a first class spec proposal. It might be reasonable to make the request prior to the spec finalizing, but I don’t think Andy is asking that. I think this has done more than any other specification has had to do to get a repository.

I don’t see how your point about reactive messaging is relevant. It might not be in servlet, but it isn’t any more based on things already in MicroProfile than the graphql proposal.

If you had said “do we have proof this doesn’t require servlet to work” then I’d have sympathy, but you didn’t. You said it has to be proven to be implementable on JAX-RS and that is what I take issue with.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5VkOFPjz%3DrDm_065V7WCcnH9nx1GDT8WMpE32SD3pawg%40mail.gmail.com.

[Ken Finnigan]

I actually said "An implementation exists that doesn't rely on Servlets, but existing MP specs (ie. JAX-RS)"

I didn't say "you have to do it on JAX-RS". I simply indicated JAX-RS was the most likely candidate if you wanted to do an implementation on existing specs in the platform.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/C85D14B8-DE3E-42F0-993A-410FE4ADD29C%40gmail.com.

[Alasdair Nottingham]

You did. The latin i.e. stands for id est which means “in other words” which is different from e.g. exempli gratia or for example. In this case you are saying “what I mean is prove it can be implemented on JAX-RS”, whether you meant it or not I can’t tell. In any case There is no ‘existing spec’ for receiving http traffic in microprofile. JAX-RS is the closest, but even that doesn’t say it how that connection works, and that was deliberate.

My reaction here is not to your desire to see a non-servlet implementation be possible (I actually agree), it is with the assertion it can only be valid if on top of JAX-RS, it should be just as viable on top of netty, or any other http stack and the fact that we seem to be setting a standard for GraphQL getting a repo that no other spec is being expected to meet to do a spec release.

Alasdair

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

[Andy McCright]

FWIW, I did some googling and found a few Netty-based transports for GraphQL.  For whatever reason, they don't seem as popular as GraphQL-servlet - the Kotlin library, Ktor as a possible exception.  There are also some implementations that work with the SpringBoot netty starter.  

So it is definitely possible for the transport layer to work sans-servlet - sorry, I just had to use the Latin "sans" there.  :-)

Thanks, Andy

[Alasdair Nottingham]

Sorry to burst your bubble but sans is a middle english loan word from old french. The latin was sine. 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6e2f98b6-1188-4390-bbc6-2d2621831864%40googlegroups.com.

[Emily Jiang]

Let's go with English:o

From my observation, Andy, Phillip, James, etc have done a lot of investigations and awesome work to this spec, which is more than other repos have ever demonstrated. We should not raise the repo creation bar as we like. The work demonstrated so far warrants its own dedicated repo.

We should vote for the repo creation. I still have my +1 on the repo creation.

Thanks

Emily

[Ken Finnigan]

I've used i.e. and e.g. interchangeably for decades, thanks for enlightening me.

Maybe I'm being too restrictive, but I've always understood the base specifications of the MP platform to indicate that you can develop all specifications of MP with these specifications as a base. Therefore, my concern with MP GraphQL was whether it can be implemented on a specification other than Servlets that IS part of MP already. If it can't, maybe that indicates we need to consider adding Servlet spec to the platform.

It's possible I'm conflating concerns around implementation with API dependencies, but it seems somewhat disingenuous to have one set of dependencies for the APIs, but to implement the specifications you need more Java EE/Jakarta EE dependencies. For instance, saying MP platform doesn't depend on Servlet spec but that a specification can only be implemented with a Servlet spec, to me, gives a false impression as to what dependencies are required by MP. It's almost like we're hiding any bloat by saying it's not an API dependency.

Emily, all I've done is provide my feedback as per [1].

Ken

[1] - https://wiki.eclipse.org/MicroProfile/FeatureInit

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/8387AD02-2D6C-48C7-BDD4-E0E56621F9C8%40gmail.com.

[Emily Jiang]

Ken,

I understand your feedback. However, it is more suitable to the question "Can we release MicroProfile GraphQL", as per Alasdair's comments.

We discuss on the value of exploring Graph QL. Is it useful etc? If it is, let's create a repo and agree on api etc. Take LRA for an example, even though some people are not sure how to implement it, but the repo creation was not blocked as such, so that the implementation issues can be discussed further down the line or maybe the spec will be optional, etc.

Emily

[Ken Finnigan]

I'm removing my -1 for repo creation as I am the only one with this concern and I don't want to hold things up, and on the expectation that this question will be discussed and resolved through the meetings and in particular in relation to how a TCK would operate.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/eee47dcd-8530-488b-828b-22f78542b052%40googlegroups.com.

[Emily Jiang]

Thank you Ken! I think the obvious name for the repo is microprofile-graphql. Thoughts?

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/B5r_rYa3jL0/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/CAKeeVe5%2BbXV8eQuRtRo0NZXrBhsQ7xpRcJxbzWQEcAMEkWDVGw%40mail.gmail.com.

[Andy McCright]

Thanks Ken - we'll plan to discuss the servlet dependency issue at this week's GraphQL meeting (Friday).

+1 to microprofile-graphql

[Andy McCright]

It has been 72 hours with no -1 votes (other than Ken, who retracted it).

I have requested a new repo ("microprofile-graphql") with Bugzilla bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=545908

Thanks!

Andy

[Andy McCright]

The new repo is now available at:  https://github.com/eclipse/microprofile-graphql

We'll be moving stuff over from the sandbox shortly.

Thanks all!