Like any technology conference, there was plenty of silliness and humor to be had as companies sponsoring the event vied for your eyeballs and did anything and everything they could to get attendees to watch their product demos and presentations.
All in all, it was all done in good spirits and we learned a few things from the event at hand that we felt we wanted to share with our readers and customers.
Here are the highlights
There were some really interesting talks that I wanted to cover before I discuss what we learned.
Rust is growing in the GraphQL space
There’s a race to see which language might one day replace Java, and though that statement has been made multiple times across many decades and it’s still here and still strong, it was interesting to learn about how Rust doesn’t need garbage collection in the same way other languages do and why, also the number of available Cargo packages is minimal which provides a great opportunity for those looking to get their SDK’s out to users in that ecosystem.
Authorization is a bit more complicated in GraphQL
With REST you can limit administrative access, for example, at the path level in order to avoid getting too complicated in your roles strategy, since GraphQL is one API path to rule them all so to speak. Auth tends to get a bit more complicated and you cannot escape providing user and access roles at the data level in order to avoid invalid access to secure information.
Reddit optimized mobile delivery in a big way
While moving away from a monolith Reddit was able to migrate into a single GraphQL service which then migrated into a Federation of services. This means they could scale better and most importantly they were able to make their mobile application more real time by reducing updating payloads to the bare minimum necessary to reduce traffic while still supporting retries.
Web3 is live and well in GraphQL
Since the industry is relatively new we’ve seen a large amount of new technology related adoption within the Web3 space and GraphQL is no different. The Graph Protocol which is made by The Guild and allows folks to easily convert blockchain data into valid GraphQL output impressed us a lot.
Walmart API was re-implemented in 14 months using GraphQL
One of the most impressive of all of the talks in my opinion was the fact that Walmart completely redid their mobile apps and website as well as backend infrastructure in 14 months using GraphQL to seamlessly transition from their old legacy monolith over to a Federated supergraph endpoint.
Here is what we Learned
As we spoke with conference attendees the one question they all had for us is why would they want to give their customers a self branded GraphQL SDK? They were wondering in what ways we could top the good work done in both Apollo Client and The Guild, and how we could possibly support @stream and the just announced @defer?
Being able to support any and everyone of your GraphQL customers in any language they already work in with a library branded to your company and the work that you are doing is crucial for any company creating a business out of their own API’s through their SDK’s.
Branded SDK’s help control the end user experience
The GraphQL community is primarily focused on giving users a great Web and Mobile Experience which is mostly a client to server prerogative and they already do an amazing job with that. But we at liblab believe that most companies can benefit from GraphQL by opening up access to their API to everyone including server to server communication due to the decreased payload and thus bandwidth benefits GraphQL brings to the table.
Federation and the Supergraph is how Apollo and many in the industry see this sharing of resources problem being solved in the long run, a decentralized set of API services all sharing data and resources using the Apollo Router and it’s server side magic and we don’t disagree with this approach in principle. However, there will always be customers who stand outside of the industry and just want something that works in their language and chosen framework.
Everyone has API customers that maybe don’t want to use or learn GraphQL themselves and it’s critical to give them options that meet them where they are at. Using a liblab generated GraphQL SDK gives those customers an option that just works without them needing to know any GraphQL.
The need for Multiple Language Client’s Support
By supporting GraphQL client SDK’s natively in any and all languages we build, we ensure your GraphQL API has the furthest developer reach possible. Whether your customers use Python or Java for example, they won’t have to settle for handling request and response themselves. They can also benefit from some of the features we already support across all of our generated SDK’s including built in retry strategies and error handling. We also generate models and interfaces based on schemas that are already properly defined to work with any language.
Now that’s not to say that we won’t support optionality when it comes to the languages that already have great clients such as choosing Apollo during SDK generation with an option for both Typescript and Kotlin generated SDK’s as an example. But our goal is to generate an SDK that goes above and beyond what the industry expects so as we roll out feature changes across all of our SDK generation, our GraphQL generated SDK’s will benefit from the optimizations and improvements.
Custom Queries will help streamline onboarding
The further you dive into GraphQL the more you realize just how powerful it is for customers, yet the complexity of formulating some of larger or more complex queries was a pain point some at the conference had experienced. When we pitched customers our idea of custom queries, they loved the simplicity of pre-writing some of their more complicated GraphQL queries in an easy to handle set of functions for their less advanced customers to use.
As we design generated GraphQL SDK’s for customers, we still want to give them methods and room to play with and experience all that their GraphQL API has to offer, yet simplifying the onboarding of customers in a way that met the customer where they were at while at the same time expanding their horizon into what’s possible was pivotal for many.
Conclusion
At the end of the day the industry is still new and the direction that Federation, Supergraph and eventually the Global Graph will take us is unlimited. At liblab, we believe in helping our GraphQL API customers to meet their customers where they are already at and help usher them into that new future in the simplest and cleanest way possible.
Help us do that by signing up for our Beta Program and providing us with a copy of your schema. We’ll generate an SDK for you to review and all we ask is for feedback on what we are doing and how you eventually want your GraphQL SDK to look like for your customers.
