As enterprises move into a new era of content-as-a-service, digital transformation and moving into the marketing cloud, a pressing issue remains: How to go about closing the chapter of legacy solutions and code, otherwise known as technical debt.
The nature of companies that have been in operation for a while is the variation in the technologies, implementations and services they use. Processes evolve, priorities shift and directions change, leading to is a messy sprawl of different standards and services. This is often accompanied by lack of proper documentation, often made even worse if the individuals who put the code together are no longer at the company.
This is technical debt: once an organization is faced with the issues above, it is extremely difficult to deal with them via the traditional methods of fixes such as clumsily stacking on new features using workarounds and hacks. Patchwork and gradual evolution of a colossal, unmodernized system spirals into overwhelming layers of fixes piled on fixes. It’s about as feasible as trying to plug every new hole that appears in the rotting hull of an old boat, when the reasonable solution is to introduce a new hull that supports the entire structure.
Having so many fragmented services and standards — new and old — incurs huge productivity and financial losses from countless hours wasted on just making things work. This unsustainable practice of creating makeshift solutions drives systems further down the route of unnecessary complexity.
The proper way of immediately addressing the problem is to scope down key services, components and processes used in your organization’s workflow. Simplify the total number you have to deal with and modernize anything that seems outdated.
Stamping out technical debt and disarray in services is a longer-term goal that will take more planning and effort. By the end, you’ll be rewarded with a cleaner, more efficient workflow for your developers. Your newly agile organization will be in a significantly better state to transition to more modern ways of working and create digitally transforming experiences for customers — improving your bottom line.
GraphQL works well because it is data-layer agnostic and allows querying of multiple data sources from a single endpoint, which frees your development stack from the confines of the database it was built around. In a typical business scenario, where a company may have several apps and sites with varying platforms and external services, this feature lets users access data from all of those places from a single source, like a modern content management solution such as Contentful.
It also facilitates client-side applications to get the data they want. This is a big deal when it comes to heavily nested data — common in organization-level development. For example, a main project will have sub-projects, and then assets under every sub-project, and so forth. GraphQL provides the ability to retrieve the specific fields needed and resolves queries via an asynchronous function (which is only executed if that field is requested) .
This provides two benefits: The results from a query are returned in easily-parsable JSON, made even better because results also match the queried fields in the same order. Another benefit is speed — by only providing the data you ask for, GraphQL’s smaller payloads improve efficiency and can speed up load and processing times substantially.
GraphQL makes it substantially easier for developers to both code and document. GraphQL uses schemas, which are strongly typed and predictable. Responses are delivered in JSON, in the exact same order as queries, and only with fields that were asked for in a query. This results in a manageable and organized way of working with code and data.
Documentation needs are eased significantly as well. In the worst case scenario where you don’t have enough resources to document fast enough, GraphQL’s readability is vastly superior compared to just about everything and can be easily picked up by any developer. In a more positive scenario, this readability lends itself to support existing and new documentation that your teams create, resulting in increased clarity from both the code and the surrounding documentation. This allows you to optimize production speed for both resources, ultimately increasing developer velocity as a whole.
As with many projects that venture into new territory, kicking off the initiative to build a GraphQL-based project when you’ve never done it before can be a daunting thought. But the results are worth the effort as your organization will become more modern and nimble, able to develop bigger projects more efficiently, and more responsive to changes and new technology in the long term.
The good news is that GraphQL, with its flexibility and agnostic nature that doesn’t chain itself to a specific data-layer or programming language, allows step-by-step deployment and change. This is highly beneficial for businesses, which would normally refrain from venturing into uncharted development territory and migrate everything there shortly after, by allowing an initial, smaller migration of services to working with GraphQL. Initially decoupling one or two projects from being tied down to a specific stack, language and/or database creates a great proof-of-concept for your development team’s ability to modernize everything else in your organization.
The same applies even once your organization has fully adopted GraphQL, since any additional features and projects or data points can be added on easily and natively — a refreshing change from the peripheral steps and implementations needed to make additions to a traditional running system. With so many great reasons to do it, it’s no wonder an increasing number of big names are adopting GraphQL.
Contentful supports GraphQL as a first-class citizen and believes in its utility in modernizing the way enterprises manage their content. Begin your digital transformation by freeing yourself from legacy CMS and traditional stack ropes — try GraphQL with Contentful today.