Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Wojtek Trocki
    @wtrocki
    so I went towards - hey let's let people to do makeExecutableSchema and come with their many use cases that core might not need to handle
    in fact the more I see current code the more I like it - it is clean and concise and doing what it should be doing so..
    still happy to do the changes, but do not want to drop something that will break things or degrate state of the entire library
    @Alan-Cha hope that is ok..
    I personally lean towards Apollo GraphQL as they have more robust execute method implementation
    Alan Cha
    @Alan-Cha
    To be honest, I don't have a great understanding of how dataloaders work. I know that @ErikWittern has some experience and he even used it for some demo for OtG. I think his main concerns are for how the requests should be cached (e.g. how long should they be stored). I will also ask him to join the conversation!
    For the time being, feel free to submit a PR with whatever you have, even if it is in a broken state, so that we can talk about it! :smile:
    Wojtek Trocki
    @wtrocki
    Perfect!
    Wojtek Trocki
    @wtrocki

    Hi @Alan-Cha @ErikWittern

    I have been experimenting with generators for the last 3 days.
    Generated Swagger definition based on existing node.js API server we have in our of our products and it generated OpenAPI definition.
    Then used OtG to generate GraphQL schema inside the express.js application.

    What I got is that now I can have dynamic GraphQL API based on the Restfull API.
    The entire experiment is kinda pointless in terms of real production usage because:

    • Generated resolver layer is calling rest endpoint instead of middleware behind it
    • There are some small things missing during translation so I needed to manually tweak both OpenAPI and GraphQL schema to make it functional
    This leads me to my final target which is generating OpenAPI definition from the GraphQL Schema and use openapi-generator
    my target is to use common service middleware to access data from API and Database so then it will not differ if someone exposes REST or GraphQL - they can do both
    curious if you guys are interested in the cases like above or they are outside the scope of the OtG
    Alan Cha
    @Alan-Cha
    @wtrocki Hey! Thanks for sharing again!
    Yeah, I can see how this is a common use case for our tool. Either using an existing OAS or generating one using a tool to create a GraphQL interface using OtG.
    Alan Cha
    @Alan-Cha
    I don't completely understand your goal
    Could you maybe explain your thoughts?
    Wojtek Trocki
    @wtrocki
    My goal will be to have code generator tool for server that will work with Rest and Database as datasource. Generator should work with inputs like database schema, OpenAPI spec and GraphQLSchema. I have all figured it out and now building universal, performant and secure data access layer that can be used for both rest and graphql middlewares.
    I'm doing this in free time to build https://graphback.dev
    Wojtek Trocki
    @wtrocki
    graphback will generate actual files for schema, resolvers and database so devs can tweak implementation or correct bugs in migration tool
    Wojtek Trocki
    @wtrocki
    not sure if coincidence or blessing but OtG does subset of what I'm trying to do very very well. I'm happy to contribute and help maintaining it
    replace /migration tool/input processor like OtG
    Wojtek Trocki
    @wtrocki
    @Alan-Cha @ErikWittern
    Is there any way I can map ID's from openAPi to ID
    I saw an option that can map UUID to ID
    but in real scenarios id's can be just strings that are only known as ID's because they have some label
    Wojtek Trocki
    @wtrocki
    ok.. I have solved this problem by building mapping objects.
    This also allows to build composite ID's and funny thing is that default resolvers handle that auitomatically so no need to have any change in OtG
    Alan Cha
    @Alan-Cha
    Sorry I wasn't around to help!
    @wtrocki You mentioned that IDs are only known to be IDs if they have some label. We have the idFormats option which allows a user to make reference to a specific (possibly custom) ID format. We thought that this would be sufficient stand in for a label.
    Wojtek Trocki
    @wtrocki
    no worries. This is open source. You are very very helpful and supportive
    I was more.curious if I can help or contribute to lib but there is no way to resolve this problem in comprehensive way
    Over the last days I went very deep into otg and openapi and really admire how this library solves some of the tough problems. Problems that are outstanding are simply hard to solve without some crazy tradeoffs. Good job
    Alan Cha
    @Alan-Cha
    Ah thank you!!! This is very kind of you to say!!!
    If you would like to help contribute to the library, that would be greatly appreciated! It doesn't matter how big the contribution. You've already made a few already!
    If you would like some direction on what to look into, we can talk some of the most critical features or issues that we foresee... Happy to discuss OtG and other efforts in the GraphQL space anytime.
    Wojtek Trocki
    @wtrocki
    yeah.. sent email to Alan.cha1@ibm.com