![]() The GraphQL client begins by sending a request containing a GraphQL query, for example: To answer that, I need to provide a little context about how GraphQL works. Given that JSON is such a well specified standard, why would anyone need to implement their own JSON unmarshaler? It’s already implemented inside the encoding/json package in Go standard library. Unmarshaling JSON into a structure is a very common and well understood problem. In this post, I want to talk about something I haven’t covered before: implementing a custom JSON unmarshaler specifically for the needs of the GraphQL client library, in order to improve support for GraphQL unions. I’ve also given a talk (slides here) about the rationale and thinking behind many of the API and design decisions that went into the library. I documented the history of my findings and design decisions made in this issue. Fortunately, at the end of that week, I found that a reasonable client in Go was indeed possible, and pushed a working initial prototype that had most basic functionality implemented, with a plan for how to implement and address the remaining features. However, it also has some more advanced query syntax and features that play better with more dynamic languages, so I had my share of concerns whether a good client in Go would even be viable. GraphQL is strongly typed, which is a good fit for Go. I spent a week on the initial investigation and research into what a Go client for GraphQL could look like. There were GraphQL clients available in other languages, and I didn’t want Go users to be missing out. I also knew that a general-purpose GraphQL client library would be useful, enabling Go projects to access any GraphQL API. My main motivation was wanting to be able to access GitHub GraphQL API v4 from my Go code, which had just come out of early access back then. Back then, only GraphQL server libraries existed in Go. In May of 2017, I set out to build the first GraphQL client library for Go. Of course, as any newer technology, it’s less mature and has some weaknesses in certain areas. It some ways, it offers significant advantages compared to REST APIs, making it an attractive option. It can be used as a replacement for, or in addition to REST APIs. GraphQL is a data query language for APIs, developed internally by Facebook in 2012, and made publicly available in 2015. ![]() This is going to be a long journey, so strap yourself in, and here we go! History of GraphQL Client Library in Go I’ll start with the history of how everything started, build motivation for why a custom JSON marshaler was truly needed, and then describe how it was implemented. For many like me, starting a project is an ever-changing process, and having the flexibility of storing plain arbitrary JSON is a real benefit to move quickly.In this post, I will tell a story of how I had to build a custom JSON unmarshaler for the needs of a GraphQL client library in Go. ![]() On a more general note, my feedback is that Fauna is powerful, I can feel it, but it needs a little polish to make simple use cases actually simple. This greatly reduces productivity and versatility (although an argument can be made for stability and type safety).Īlso, I don’t know what you mean by “ Interfaces” Regarding Unions Types, it could come in handy, But I would still have to declare all possible input types beforehand. Right now I opted to serialize both the form schema and the records as strings, although it’s definitely less practical and useful if I want to operate on those, for example being able to search a specific record by a specific type.įor that, graphql-type-json is looking good. Say a form that has multiple, different, and arbitrary input types for example. In my case, the data is user-generated and can take multiple forms. What I like about storing plain JSON is the versatility it offers. Thanks, great to hear you’ve thought about it. If you could share with us a bit more about your use case, we might identify the most appropriate solution for it in the long term! This would also help us to prioritize the support for Interfaces, Unions and JSON Scalar types. Although Interfaces and Unions are yet not supported, those are definitely in our plans. Those might not be as flexible as a JSON Scalar in certain scenarios, but depending on your needs, those might be just what you’re looking for. Something similar to graphql-type-json.Īlso, since you brought it up in the question, I’m wondering if the use of Interfaces or Unions would be actually the right option for covering your use case. This has come up before, and we were considering implementing a JSON Scalar type for doing so. On the downside, this would mean that, as you already mentioned, any type advantages would be lost in the process. Hey, & say the suggested way of storing arbitrary JSON objects through the GraphQL API at the moment is to serialize them as Strings.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |