Skip to main content

Deals You Can't Miss

1 Year Subscription

GraphQL FAQs

  1. Is GraphQL a DB? No! For graphDB checkout options like ArangoDB, OrientDB, Neoj, DGraph etc.

  2. Is GraphQL an interface to Graph DB? No! Think of it as a parallel to REST or SOAP way of exposing your APIs.

  3. Is GraphQL a replacement for REST? It may or may not depending on your business context.

  4. Can GraphQL co-exist with REST? Yes!, it sure can.

  5. Does GraphQL have good tooling support? There is good tooling support to get you onboarded and get going. There needs to be more though, say for example, support in defining your GraphQL schema.

  6. Has GraphQL got supported libraries in my language platform? Checkout for list of libraries by language, for client-side support and server-side runtime support. And there are also much more goodies in there to explore and experiment with.

  7. Is there a big picture view of GraphQL landscape that I can see? Do checkout

  8. Is GraphQL better than REST? That depends on the metrics you are looking out for.

  9. Okay, how does GraphQL shine better over REST? Some of the things include,

    1. Simpler API grammar if that pleases you, GET for read operations and POST for write operations.

    2. Adopts better with need for "Evolutionary APIs", mitigating the need for upfront thought on "Versioning APIs" as contracts. This is a super cool thing that this Agile world of development desperately needs to fight its competitors.

    3. API to ask what you want explicitly and get just that and no more. This could mean better performance on both client-side and server-side.

  10. What are the areas where REST shines over GraphQL? Some of the areas include,

    1. Unlike GraphQL, REST needs no additional infrastructure. REST is fluent API that best leverages HTTP protocol to gain maximum mileage. Bow to Roy Fielding for this!

    2. Caching comes for free and easy with REST. This is relatively harder and needs additional infrastructure.

    3. Good part of the world has gone past heavy-weight SOAP to adopting light-weight REST which is the defacto-standard for the entire toolbelt and ecosystem. GraphQL made its presence known resulting in increased "reference-implementation" libraries across language platforms. How this will unfold beyond this hype is yet to be witnessed..

  11. Constructing and maintaining the GraphQL Schema on the server-side with Express.js isn't looking easy for me. As the graphql schema size grows, fitting the schema within the back-ticks is maintenance pain for me. There is not expand/collapse of parts of stringified schema after all. Also, absence of intellisense for this stringified piece is a pain in refactoring schema definitions. Am I missing something? You are not alone here, is the only consolation I have for you at this juncture. I have the same pain and I alleviate it a bit by modularizing the schema to separate files and use string interpolation in the schema definition file. This alleviates some of the said pain points. But absence of intellisense during development is a pain in the back making me question if I'm witnessing "graphql pop-culture" or genuine strengths of it. I'm still experimenting and so this opinion may change and will be updated as I learn.
  12. Not all fields are relevant to all consumers of my API either for the reasons of security or business context. Take for instance, the password field in the User isn't required beyond the signup or password change functionality even for the very user and is breach of security for others to get even the hash of it in their context in fetching Users. Is there a way I can customize this behavior in GraphQL? That's a great question and I'm yet to figure it out. But do hope there is a way out for this, as this is a very basic criteria, after all. My reference API would be Github API, for this.
  13. Given that the API's exposes the fields, would it end-up being too rigid for Public APIs where you don't own the client/consumer app? Sorry, I don't have an answer for this one. Github can't be taken as a reference case for this, so I'd have to look out for a business case likely in the B2B space where different clients demand different needs from an API.
  14. I see a myriad of ways to building GraphQL APIs for consumption and unsure how one is different from the other and if I am missing something. Am I? As I see it, you will still be an early adopter of GraphQL, given the state of evolution that it is in today. Thus, your choice of platform could determine if you are taking SDL-first or code-first approach to development. And then your choice of runtime, could determine how you design and build your schema, how you implement your resolvers (if you know what it is in the graphql context), etc. Doing a PoC with some of the popular options will help you determine what best fits your team context.
More would be added as I experiment with GraphQL and have more conversations in this space. Stay tuned..

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t