Open APIs

 View Only
  • 1.  GraphQL TMF Open API Support

    TM Forum Member
    Posted Apr 05, 2024 02:40

    Hello All,

    Seeking assistance from anyone experienced with GraphQL for Resource Inventory, Location, etc., which aligns more closely with TMF Open API.

    I see something define in  TMF 630 but not concrete information similar to TMF 639

    Regards

    Sanjay Vyas



    ------------------------------
    SV

    ------------------------------


  • 2.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted Apr 05, 2024 03:47

    Hi Sanjay

    We haven't really addressed using GraphQL with or alongside Open APIs.

    Perhaps @Florin Tene has some insights, as the lead for the design guidelines?



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted Apr 08, 2024 03:44
    There was a project at TMF to create a customer profile API using GraphQL, but it was abandoned.
     
    GraphQL excels with large, complex, and interrelated data sources and operates through a single URL endpoint. In contrast, REST utilizes multiple endpoints in the form of URLs to define resources.
    I see no compelling reason for TMF to develop GraphQL APIs. They should focus on providing dedicated REST APIs for various domains (Order, Party, Resource, etc.).
     
    You're better off handling it yourself. That's what we do with Apollo (Open Source).


    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 4.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted Apr 08, 2024 04:21

    We did do some work on Topology Discovery across multiple inventories  and considered using Graph QL on REST APIs but found it did not have the fully expressiveness we needed for our use cases. 

    TR283 Business Requirements for a Multi-layer Topology Discovery Service v1.0.0

    which stiches together topology graph views across multiple databases ( Use cases include impact analysis of floods affecting line plant in specific locations on services and customers, and can be used of linking technology domain inventories e.g. physical and logical inventories. I

    We developed a Component Suite Profile including  TMF 686 Topology Discovery API which is close to completion awaiting approval of the  Conformance Profile  profile.  

    TMF920A Topology Discovery Service Management API Component Suite Profile v2.0.0

    We have several agreed improvement to TMF 686 in the back log which are awaiting beta version publication . These include using some recent  IETF extensions to  JSON Path that allow for finer grain directives and queries.
    Work is being carried out in the ODA Production and modelling team within  ODA Components and Canvas team

    TMF686 API allows one to represent a graph in a REST Resource collection i.e. a sort of Digital Twin, but note that we simplified the graph model proposed in TMF920A in the published API  . We will correct (simplify)TMF920A when we update it for the next version of the TMF686 API to include the backlog items (mostly directive and query enhancements).



    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 5.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted 28 days ago

    I would see value in adding GraphQL as a tool in TM Forum toolkit. I see it as complimentary to having REST APIs (and Async APIs). Our TM Forum guidance should also reflect best-practices for its use: It is not a replacement for REST and its use is limited to Engagement Management domain interactions where we want to empower developers to be responsive and agile in building our customer experiences. @Steve Harrop - do you have any comment?



    ------------------------------
    Lester Thomas
    Vodafone Group
    ------------------------------



  • 6.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted 27 days ago

    The challenge with using GraphQL is that it requires the existence of a GraphQL Type system describing the service offered. It would be an interesting exercise to try and autogenerate GraphQL Schema from the Open API data model, which exists in the form of a collection of JSON Schemas in a repository and made available publicly through OAS files.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 7.  RE: GraphQL TMF Open API Support

    TM Forum Member
    Posted 25 days ago
    Edited by Steve Harrop 25 days ago

    Hi,

    Yes - we (Vodafone) are investigating the use of GraphQL as a layer above TMF APIs in certain circumstances, as an alternative to the Composite API's like Customer360.

    We would use it for data retrieval in the last-hop to a (typically but not exclusively) mobile presentation layer where (for example) an initial dashboard view needs to collate information from multiple sources like "Hi [Steve]1, your data use this month is [15.2Gb]2 out of your [30Gb]3 allowance, your current spend is [£6]4 with your next bill due on [25-Jan]5. [You are due an upgrade]6 Click here for offers" etc.

    1. TMF632-Party: Individual.preferredGivenName
    2. TMF677-UsageConsumption: ConsumptionSummary.bucket[name="data"].remainingValue
    3. TMF677-UsageConsumption: ConsumptionSummary.bucket[name="data"].reservedValue
    4. TMF678-CustomerBill: CustomerBill.remainingAmount
    5. TMF678-CustomerBill: CustomerBill.nextDueDate
    6. TMF637-ProductInventory: Product.productTerm[].validFor.endDate

    Making all these TMF API calls from a mobile client over a radio network while the customer is watching their first app page load where "every millisecond counts" is obviously not a good-look. A specific BackEnd-For-Front-End API can fix this, but is statically bound to the dashboard content. GraphQL might give us a flexible alternative, with a carefully orchestrated query optimisation for maximum concurrency (eg: there is no dependency above between the results of UsageConsumption and ProductInventory - so the calls can be made in parallel) and caching strategy (eg: I expect my usage consumption to be changing by the minute, but my first name has not changed in decades).

    As a bonus I might also want the GraphQL resolver to intelligently optimise the backend TMF API calls, to call UsageConsumption with ?fields=remainingValue,reservedValue and CustomerBill with ?fields=remainingAmount,nextDueDate - so that I only make one call, and only return the minimum content possible.

    I made a brief pitch on this topic at TMF-Accelerate a couple of years ago and (I believe) it was well received - as in "This could be interesting, tell us more if you make progress". We are now making progress in a PoC and I could probably give an update at this year's TMF-Accelerate (February 2025) if there is a relevant slot. There may be feedback from this exercise back into TMForum assets (eg: production of GraphQL-schema, or best practices for dealing with (say) RefOrValue, pagination and other TMF API design patterns).

    ---
    PS: I am acutely aware that I am using "top of my head" ConsumptionSummary/CustomerBill examples in front of Vance in a public forum - and so laying myself open to ridicule :-)



    ------------------------------
    Steve Harrop
    Principal Integration Architect
    Vodafone Group
    ------------------------------