Closed andymc12 closed 4 years ago
According to Andy, the code made it into beta release 190011
We should have a guide for this feature. Please file an issue at https://github.com/OpenLiberty/guides-common/issues for us to track.
@gkwan-ibm, FYI.
Guide issue opened at: https://github.com/OpenLiberty/guides-common/issues/423
ID issue opened at: https://github.com/OpenLiberty/docs/issues/1515
FAT Test Summary opened at: https://github.com/OpenLiberty/open-liberty/issues/9319
Beta Blog Post opened at: https://github.com/OpenLiberty/open-liberty/issues/9703 (already published - GA blog post should include more details)
This feature is basically new APIs for Liberty which do not have any user interface. The feature only enables access to data. If someone created a user interface to display that data, then it would be the developer of that interface to ensure it is compliant with accessibility standards. Nothing in this feature would prohibit or block a developer from generating a display that would be accessible. Accessibility compliance requirements are satisfied, approval granted.
STE is available at https://pages.github.ibm.com/WASL3/site/STE/WAS/mpGraphQL-1.0/ (IBM only)
Serviceability Approval Comment - Please answer the following questions for serviceability approval:
WAD -- does the WAD identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?
Yes
Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team). a) What problem paths were tested and demonstrated? Partial results on error in query/mutation b) Who did you demo to? DevNexus attendees and IBM Community (webcast replay) c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3? Yes
SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. a) Who conducted SVT tests for this feature? Brian Hanczaryk b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3? Yes
Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.
WASWEB L2 and WAS-JAXRS L3
FWIW, I've also added a server dump introspector that will print the generated schema, metadata, etc. that should also aid in diagnostics - these are described in the STE.
@andymc12 did you guys demo the potential problems and their mitigations that you described in the UFO? It seems like those are non-trivial things that we need good assistance to help users with.
@donbourne Yes - some of the potential problems and mitigations were part of the IBM Community webcast. The bulk of the serviceability features are described in this video, "Supporting MP GraphQL 1.0" which is available from the STE web site.
Demo'd on https://ibm.ent.box.com/notes/661030999031 (link to recording coming soon)
Translated NLS files are merged in PR https://github.com/OpenLiberty/open-liberty/pull/12227 - waiting for merge to master before requesting Globalization approval.
Andy and I discussed the info for witers to document. He provided the info in this issue: https://github.com/OpenLiberty/docs/issues/1515. Approving.
Blog post blurb for GA:
Open Liberty officially supports MicroProfile GraphQL. This allows users to write "code-first" GraphQL applications putting clients in control of the data they receive. Join the growing landscape of GraphQL adopters and write your first GraphQL application today! Use this sample to get started.
More info in this blog and in this webcast.
Note that the blog link currently points to the draft site, since the blog is not yet live
Longer blog post blurb for GA:
Open Liberty officially supports MicroProfile GraphQL. This allows users to write "code-first" GraphQL applications putting clients in control of the data they receive. Use annotations like @Query
and @Mutation
to turn POJOs into HTTP-based GraphQL endpoints. Those query/mutation methods can then return existing entity objects and the client can specify which fields it is interested in - reducing network bandwidth and client-side processing.
Here’s an example:
@GraphQLApi
public class MovieService {
AtomicInteger nextId = new AtomicInteger();
Map<Integer, Movie> movieDB = new HashMap<>();
@Query("movieById")
public Movie getMovieByID(int id) throws UnknownMovieException {
return Optional.ofNullable(movieDB.get(id)).orElseThrow(UnknownMovieException::new);
}
@Query("allMoviesDirectedBy")
public List<Movie> getAllMoviesWithDirector(String directorName) {
return movieDB.values().stream()
.filter(m -> m.getDirector().equals(directorName))
.collect(Collectors.toList());
}
@Mutation("newMovie")
public int createNewMovie(@Name("movie") Movie movie) {
int id = nextId.incrementAndGet();
movie.setId(id);
movieDB.put(id, movie);
return id;
}
}
This will create a GraphQL application with two queries ("movieById" and "allMoviesDirectedBy") and a mutation ("newMovie"). This will allow a client to execute a query like:
query {
allMoviesDirectedBy(directorName: "Roland Emmerich") {
id, title, actors
}
}
and see a result like:
{
"data": {
"allMoviesDirectedBy": [
{
"id": 1,
"title": "Independence Day",
"actors": [
"Will Smith",
"Bill Pullman",
"Jeff Goldblum",
...
]
},
...
]
}
}
Liberty’s GraphQL APIs were developed within the MicroProfile community and has broad industry support. The implementation is based on SmallRye GraphQL. Liberty’s GraphQL feature goes beyond the MicroProfile specification and adds support for metrics collection, authorization checks, and request/response logging of query and mutation methods.
Next week, we will be releasing a blog post with more details on how to use MicroProfile GraphQL in Open Liberty. Until then, check out this sample to get started - and join the growing landscape of GraphQL adopters and write your first GraphQL application today!
List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)
Instructions:
TARGET COMPLETION DATE Before Development Starts or 8 weeks before Onboarding
[x] POC Design / WAD Review Scheduled (David Chang) or N/A. AHA Feature marked.
[x] POC Design / WAD Reviewed (Feature Owner) or N/A. AHA Feature marked.
[x] Complete any To-Do's from the POC Review, and create a new TO-DO in the AHA Feature for the "Design Approval Request" and assign it to Ian Robinson. Leave the date blank. (Feature Owner)
[x] Design / WAD Approval (Ian Robinson) or N/A. AHA Feature marked.
[x] No Design / No WAD Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A. AHA Feature marked.
[x] AHA Feature has link to Github epic or issue. Github epic has link back to AHA Feature. (Feature Owner or Backlog Subtribe PM).
[x] SVT Requirements identified. (Epic owner / Feature owner with SVT focal point)
[x] ID Requirements identified. (Epic owner / Feature owner with ID focal point)
[x] Create a child task of the epic entitled "FAT Approval Test Summary". Add and fill in the template as described here: https://github.ibm.com/was-liberty/WS-CD-Open/wiki/Feature-Review-(Feature-Test-Summary-Process)
TARGET COMPLETION DATE 3 weeks before Onboarding
[x] Identify all open source libraries that are changing or are new. Work with Legal Release Services (Cass Tucker or Release PM) to get open source cleared and approved. Or N/A. (Epic Owner). New or changed open source impacts license and Certificate of Originality.
TARGET COMPLETION DATE 3 weeks before Onboarding
[x] All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)
TARGET COMPLETION DATE 2 weeks before Onboarding
[x] Implementation complete. (Epic owner / Feature owner)
[x] All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
[x] Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)
APPROVALS with TARGET COMPLETION DATE 2 to 1 week before Onboarding
Prereq: You must have the Design Approval or No Design Approval on the AHA Feature.
[x] Accessibility - (G Scott Johnston). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
[x] FAT Liberty SOE - (Kevin Smith). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
[x] Globalization (Sam Wong - Liberty / Simy Cheeran - tWAS). Translation is complete or N/A. TVT - complete or N/A. Approver adds label focalApproved:globalization to the Epic in Github.
[x] ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
[x] Performance - (Jared Anderson). Performance testing is complete with no high severity defects or N/A . Approver adds label focalApproved:performance to the Epic in Github.
[x] Serviceability - (Don Bourne). Serviceability has been addressed.
[x] STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
[x] SVT - (Greg Ecock - Cloud, Brian Hanczaryk- APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.
TARGET COMPLETION DATE 1 week before Onboarding
[x] No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
[ ] Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
[ ] Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)
NOT REQUIRED FOR A FEATURE
[x] OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
[x] WDT - (Leonard Theivendra). WDT work complete or N/A.
Related Deliverables TARGET COMPLETION DATE General Availability
[x] Blog article writeup (Epic owner / Feature owner / Laura Cowen)
Design Document: https://ibm.box.com/s/eb5e4vreamdbvdrfddt3sge6l3awbry6 Aha! Feature: https://bigblue.aha.io/features/API-31