Pushing Fintechs Forward with GraphQL

June 1, 2022

3-5 minutes reading time

The past few years have seen the rise of “fintechs”: technology companies seeking to disrupt the financial services space. If you’ve been following the sector, you may have noticed an explosion in the number of businesses and their corresponding valuations. The world has been captivated by the potential that these companies offer.

And with good reason: most financial institutions have been around for many, many years, and run on some very old technology. Newer technology can often give these institutions the opportunity to move forward faster and more flexibly, in order to more efficiently and scalably meet the needs of their clients.

However, replacing a tech stack requires a lot of time, money and risk: all things massive institutions can be hesitant to take on due to the cost, uncertainty, and difficulty in doing so. 

This is part of the reason why brand new fintechs, built on the latest technologies and starting the process from scratch with no incumbent architecture to replace, are able to take the world by storm: they are in a position to make this decision from the get-go and build for both efficiency and scale. 

So why, in a world that prides itself on innovation in so many other industries, are some fintechs still using technology older than many people working on it?

To understand - we have to first dive into what a tech stack looked like that long ago.

RESTful APIs

In the year 2000 (yes…22 years ago!), the standard of RESTful APIs was created by American computer scientist Roy Fielding and his colleagues. The goal was to create a standard that allowed any server to talk to any other server in the world. 

Before this, the only widely used standard was SOAP API, which was known to be overly complicated and difficult to write (and despite that, can still be found in use today!). The RESTful standard took a few years but, quickly became the gold standard for public API usage. By 2005, there were 150 public APIs using the standard, which grew to over 2,500 by 2010. The success of the RESTful standard was due to its simplicity compared to its older brother, SOAP. 

There were a handful of different and intuitive request types, like GET, PUT, POST and DELETE. These requests were great for developers, as it was tightly knit to the developer view of data object management, specifically; how to read and write from a database. 

For example, I can make a GET request to fetch a user from the API, which would fetch the full user object from the database, or I can make a PUT request to update a post. This was great for the 2000s, where full stack development (comprising both front and backend development) was almost a requirement. 

But now, developers are specializing in either frontend or backend, and offering a public API is commonplace within established fintech businesses. This is where the need has emerged for APIs focused on more abstract, business use cases rather than data driven endpoints. GraphQL meets this use case perfectly.

GraphQL

GraphQL was initially created in 2012 by Facebook, later open-sourced in 2015 and is now overseen by the GraphQL Foundation. I won’t go into all of the pros, cons and functionalities of GraphQL (PayPal has a really good article that goes in-depth into this) but, it really shines in its queries and mutation structure. 

Instead of the API being an almost 1-to-1 replication of how the data is managed, it is possible to create easily documented, business-use-case based queries (fetching data) and mutations (changing data). In addition to these basics, there are amazing tools out there like the ones offered by Apollo, a major piece being the Federated Schemas and Gateway, which allows for a very simple way to join GraphQL schemas across microservices.

Some of the most successful fintech companies have introduced public API docs using GraphQL; including Braintree and Shopify

Despite the successful endeavours of these big players, there are still major businesses, like Square and Stripe, not budging from their RESTful structures. Which begs the question…why not? 

These companies may be using GraphQL internally, but there is some resistance to shifting to it for their public APIs. There are some likely reasons for this resistance: 

1. “If it ain’t broke, don’t fix it” 

Some businesses will simply avoid making changes in order to keep up the working (for now) status quo.

Simply put, this idea is totally against the idea of revolutionizing and modernizing the financial industry. As tech companies at the forefront of change in the financial world, we should also be at the forefront of the newest technologies. 

At OneVest, we went all in with GraphQL, despite it being new for many of our developers, which leads us to our next point:

2. “GraphQL is fairly new: not every developer knows how to develop on top of it”

A lot of the time, this ideology comes from those who make the architectural decisions for the business. The argument stems more from what they feel comfortable using, rather than how the actual developers feel.

It can keep these types of businesses hanging onto legacy technology or more challengingly: team members, who hold all the knowledge for how the tech stack works. Conversely, it can also make it more difficult to hire fresh talent when the old ones move on.

At OneVest, all our developers were easily able to pick up GraphQL, and once using it for a few weeks, were able to easily see its massive advantages.

3. “Partners using our public API’s may not know how to use it” 

This is one that has probably the most weight; especially for organizations working with many external partners and vendors who are operating with similar tech stacks. 

Once we consider the simplicity of GraphQL, however, it quickly becomes a moot point. If there is trust in public developers using RESTful APIs, then using a newer, cleaner and more simple API structure should not be an issue.

OneVest has also found that when speaking with our partners, they are impressed and - dare I say - excited, to use this new technology, as they are mostly using API’s like REST, or even SOAP…

Conclusion

Technology moves quickly and it can sometimes be difficult to keep up; let alone pivot entire tech stacks within an organization, and even more so when money is involved.

But, if we never made the effort to move forward with technology: we might all still be using flip phones and getting Clippy to help us write documents.

As fintechs, we should be making an effort to adopt new technologies like GraphQL, lest we end up like the industries we’re trying to disrupt; with a whole new wave of fintechs shaking us out.

Our development philosophy at OneVest is always looking forward, and always wanting to improve on what already exists, so if you are interested in working with us, check out our careers page.