Sept. 2, 2022, Alex Babeanu
As the flow of information seems to forever increase worldwide, it is no surprise that the API economy is doing very well. A 2021 survey by RapiAPI revealed that 63.5% of its respondents used more APIs in 2020 than in the previous years, and this trend isn’t slowing down. A recent poll by PostMan shows that more than half of most organizations’ development time is spent on APIs. Of course, 89% of executives will invest more in APIs over the next 12 months (87% of CEOs, 86% of CIOs, and 93% of CTOs)… APIs are the place to be!
The absolute requirements of interoperability and composability mean that organizations must now build their systems from many small building blocks that can be interconnected in many (sometimes complex) ways. This explains the rise of technologies such as Service and Data meshes, as well as GraphQL, which provides the consumers of those APIs with much more flexibility in how they access the underlying data.
The rise of GraphQL is particularly spectacular. Used by only 6% of developers in 2019, it is now used by an impressive 28% of developers worldwide. Although REST APIs still constitute the bulk of the APIs out there, their usage declines (89% usage, down from 92% last year).
Yet the GraphQL specification is often misunderstood. Its strength lies in the fact that it provides a graph layer on top of any data source backend, even non-relational ones such as document databases. It can also combine several heterogeneous data-sources into a unified schema, hiding the underlying complexities from its clients. Making Relationships explicit is the key here, and that’s the part so often overlooked by most blogs I’ve seen so far on the subject. There’s a reason why GraphQL is called “Graph” QL after all! Nevertheless, GraphQL has its pitfalls, and we will address some of those below.
In any case, as interoperability increases, so does data complexity. The more systems that become connected, the more complex the data they need to handle; specifically because of the increase in the number of relationships that link these data points together. And making those relationships explicit, in particular visually, does help in tackling that complexity. This increase in complexity probably explains the rise of Graph Databases usage in the past 10 years.
The sweet spot in managing data complexity through APIs is therefore to prefer a technology stack and architecture that leverage these trends. That is, to adopt GraphQL with Graph Database backends.
Challenges
So what are the challenges any organization typically faces when adopting these new technologies?
Learning Curve
The first is the learning curve and the lack of expertise.
All aspects of this graph universe come with their own vocabulary and best practices. The learning curve can be steep in particular when it comes to learning GraphQL and all of that “graph stuff”. Experts are rare, and expensive. Wouldn’t it be nice if there existed an intuitive, no-code, drag-and-drop style graphical platform that would help in getting developers up-to-speed fast?
Dev time
The second is time and ROI.
In 2022, 51% of organizations' effort (so far) was spent on developing APIs. Consequently, 67% of developers spent a quarter or more of their time working directly on APIs. That is a lot of time and effort, a lot of investment dollars (let us know if you can find actual $$ figures). In any case, it takes 70% of organizations anywhere from one day to one month to create and deploy an API in production.
Where does this time go?
63% of API Development time is spent designing, coding, debugging, documenting and publishing the APis. That is basically the core of any developer’s work. Wouldn’t it be nice if there existed a tool that could do all of these things and consequently drop development time down to mere minutes (and hence dramatically reduce development cost)?
Documentation
Documentation is a particular concern, as it’s the #1 problem facing new APIs adoption. Imagine if there was an API platform that generated all this documentation automatically.
Security
Last, but not least, and in fact most importantly, security.
There are a variety of risks when it comes to exposing APIs to the world at large, and in particular GraphQL APIs. How can you secure access to all these types, and ensure that no-one brings down the whole system by running 1 single query that fetches everything? What if there was an API platform that enforced security OOTB?
How do we succeed with GraphQL then?
Some advice:
Firstly, adopters should first discover and understand the questions that their clients will ask from their APIs. That step is critical. GraphQL and the designs of Graphs in general, start with the questions expected to be asked to the system.
Next, ensure that these questions are relational in nature. GraphQL is particularly well suited for those queries. For example, questions such as “who works with Alice?”, “Where is that device located?”, “Who owns it?”, “Who has access to this bank account?”, etc. If not relational, then the use of GraphQL for that API may be excessive…
Build your schema based on those questions. The model should be the best one to answer the questions.
Then, minimize risk by protecting the API. This includes authentication (identifying who intends to use it), and authorization (once authenticated, what can they do exactly? Can they actually access the data they’re requesting?). Although the field of Identity and Access Management (IAM) is wide and deep, a minimum level of expertise is required here, especially if your APIs are external facing.
Additionally, it is possible to bring down a whole system by running a single, well crafted GraphQL query. In order to avoid Denial Of Service (DoS) attacks (accidental or not), one can’t rely on the typical Requests/Second (or similar request-based) metric. Instead, throttling should be done through carefully evaluating the cost of every query or mutation and ensuring it doesn’t exceed a pre-configured maximum. This is not an easy task… In any case, only “reasonable” queries should be allowed to run. Wouldn’t it be nice if our API platform did that automatically OOTB?
Finally, consider using a GraphQL Platform that not only implements best practices, but also considerably speeds-up your time-to-market by providing the features above Out-Of-The-Box. In short, focus on your business case, and let the platform deal with the details of the plumbing.
How can 3Edges help you?
3Edges is like a multi-tool that can piece together all your varied furniture. It’s a complete SaaS platform for building GraphQL APIs backed by graph data, fast and securely. It solves all the problems described above. It lets you focus on and realize your idea, like driving your car without having to worry about how your pistons work.
3Edges can:
Dramatically reduce your time-to-market and your development costs.
Increase your ROI.
Reduce risk and ensure you always use best practices.
Increase developer productivity and enjoyment.
Some of its features:
Intuitive drag-and-drop style Graphical GUI for intuitive modeling.
Generation of fully usable GraphQL APIs (Schema, Documentation and Resolvers), all automated, without having to write any code - yes, the documentation too.
Auto-deployment your GraphQL APIs to the Cloud (ours or yours) through a single click. Yes, no need for DevOps either!
Monitor the usage of the API with OOTB Prometheus metrics.
Enforce maximum query execution costs OOTB, thus ensuring no one API call can “Bring down the system”.
Provide ways to easily load data through the API it generates from CSV files.
3Edges can considerably speed-up the API development time of your organization, while at the same time ensuring best practices for GraphQL, throttling, deployments and reliability.
Signup today for free, and turbo-charge your GraphQL development!