How to Pitch GraphQL to your CTO
Understanding the Business Needs
Unless you are working at a startup or a technology agency, it is unlikely that you, as an engineer, get to make the decisions regarding how your team solves problems with technology. Over the last couple of years, GraphQL has been growing in popularity. Part of the reason why GraphQL is gaining popularity is because we are getting better at explaining the problem that a solution like GraphQL solves.
Over the next few posts, I will share with you the strategy I had used to get GraphQL approved as a technology by not just the CTO and various directors of technology for a Fortune 500 company, but also by VPs, CTOs and CEOs for use at various startups. This is a rather generic approach to presenting technology so this may be used for more than just GraphQL.
Understand the Problem You Are Solving FOR THE BUSINESS
Often, we get wrapped up in how fresh a technology solution is and not on the problem the technology is designed to solve. There is a difference between experimenting with a new library, language or framework and proposing it for the development of software for a business, especially an established business. If you cannot make a business case to bring in a technology solution, no matter how large or small, you might as well not even try.
New technology will always first add complexity before your team or company reap any of the rewards. Make sure your business case is solid. Do not expect to tinker with a framework over the weekend and bring it to your team on Monday, explaining how you now have to
“Ember all of the things”.
This is about developing a business case for GraphQL. Here are some example discussion points to build a business case for GraphQL.
Massive JSON responses.
JSON is the structured data format of the 20th century. RESTful APIs are known to serve JSON but at times with no reservation. Over time, APIs are added to or scarily modified. New fields are introduced, perhaps, sometimes filtered via query string parameter, but generally API responses are not getting any smaller.
Gzip, good for transmitting — does little for the client runtime.
Commonly in discussions about the size of our API responses sometimes, Gzip comes up. Gzip is a compression process that keeps data super small as it is transmitted over the wire. That compressed content is then unpacked and loaded into the memory of the client for use by the client code. What we tend to forget is a client needs to parse these objects into memory and prepare them for use. Depending on how much data is being transmitted, heap allocation could become a dangerous issue.
Logging API responses.
This may seem silly, as why would we want to log our API responses? For an enterprise level company, it could be tremendously powerful to get a sense of the communication between different software. Without good control over your data, logging may not be possible. Logged API responses allow for the further development of robots and machine learning to help you better understand common errors, messages and the most important content your users are consuming, in the absence of a front end entirely.
Typically, we rely on third-party services to help us understand what our customers are seeing and when. Clever use of logging technology can yield a much clearer picture of our business.
Maintaining backwards compatibility while servicing many clients.
Backwards compatibility issues occur when the API wishes to make a change to its interface. It cannot be avoided when the interface is dictated exactly by the API and not the client software. Native mobile applications (at least built natively) struggle with this, since they rely on users to download the latest version of the application from the app store. Since application downloading is not enforced by the platform, mobile clients are bound to the decisions made with each and every release.
Overly complex code bases and modeling.
Good orchestration of middle tier services help keep client software lean, flexible and disposable. Client software needs to do as little as possible to represent the data for the business. When too much work needs to be done to shape the data for use on any given client, the software suffers from bugs and inconsistencies.
Introducing new data sources and scatter gather.
Orchestration services can allow you to detach the sources of data from client software. This is tremendously powerful for a business. Many times, teams of engineers spend weeks migrating their software over to a new version of a REST API. Ideally, engineering teams should not have to do this again. If major changes require this type of work, it needs to be planned and communicated clearly.
API integrity and security.
By blindly sending all possible properties from an API source to a given client, the risk for abuse of data increases. Bot attacks and crawlers are looking for APIs to scrape and if these abusive users are able to discover an API, they are typically getting more than what your client software is showing on the page.
API documentation.
Great engineering teams do a great job using automation and tools to help keep their APIs in check. However, this is not always an easy sell, and the lack of common tooling leaves the consumers of the API at the mercy of the engineers writing it.
Inconsistencies.
Inconsistency of types for client software can lead to unexpected results. Take a boolean for example. Many times we see booleans represented as the type STRING. In JavaScript, non-empty strings are considered “true”. If a programmer writes the code:
if(’false’) {
console.log(‘foo’);
}
the console.log will execute.
API inconstancies also make it more difficult to create UI components that can be used in different softwares. Inconsistent interfaces require interface code to validate that the received properties are in fact the type expected for the work that can be done in a predictable manner. Some may argue that it is fine for client software to deal with this, but consider the additional work that each piece of client software built across each public API property that is consumable, and it becomes an expensive proposition.
API shape does not reflect what is needed by a client.
API shape is a term used to describe the design of a piece of structured data intended for use by another application. Typically, the API interface is not designed for any particular client but simply provides named properties for another system to consume. Clients of these APIs are mostly required to reshape the structured content on the fly to prepare it for their own software. This work adds risk to software that is built against it.
Conclusion of Part I
So, there you have it, some thoughts around some common and generally expensive problems businesses tend to have when it comes to building and maintaining APIs. The takeaway here is that we are trying to present problems for doing business today in a way that helps us understand what we are looking to change about the work and frame what improvements will be expected.
Take a moment and find where these provided business cases can apply to your situation. In the next post, we will discuss how GraphQL helps us improve upon these general problems.
Get software done with EcmaStack!
We would love the opportunity to chat with you.
hello@ecmastack.com
Are you a contractor passionate about building software with the newest tech? Reach out to us at hello@ecmastack.com.
We are always looking for great minds, passionate about:
· SSR techniques
· Boilerplate Development
· Open Source Development
· React/React Native/Redux
· GraphQL
· Golang
· Node.js
· Electron
· Web components ( polymer )
· Angular 2
· Ember
· Vue
· High Fiving!!!
Build software, not websites.
