You don’t have to be in the software industry for very long before a company stops supporting or investing in a product.
If you are reading this, it is likely that you heard about Progress software and their Kinvey product. Progress mentions a write-off for the Kinvey acquisition in their 10-K (fiscal year ending November 30, 2021), but the sun-setting actually started in 2019. All Progress Kinvey customers must address a migration in the immediate future.
For anyone looking to replace Kinvey with a low-code solution or backend platform, 8base is often considered a replacement for Kinvey, Firebase, and similar platforms.
In this article, we provide an overview of the biggest difference between Kinvey and 8base, which is GraphQL. We then outline additional comparisons and contrasts in the last section.
A Dated Stack: REST versus GraphQL
GraphQL—More Value for the Customer Experience
GraphQL Improvements for Developers—Fetching
GraphQL Improvements for Developers—APIs
GraphQL Improvements for Developers—Code
GraphQL Improvements for Developers—Docs
Other Comparisons between Kinvey and 8base
.jpg)
Via Crunchbase, Kinvey was founded in 2010 and acquired by Progress Software in 2017. Its stack is largely 12+ years old, which is a long time in the software industry. Newer platforms, based on newer tech, are much more advanced. Hint, 8base is only a few years old.
To that point, Kinvey puts REST APIs at the core. 8base puts GraphQL at the core.
To understand the concept of REST versus GraphQL, history helps. GraphQL was originally built inside Facebook in 2012 and open sourced in 2015—this video provides a great background. In 2018, it was moved to the GraphQL Foundation—a part of the Linux Foundation.
As of 2022, the community has significant maturity. Over the past few years, MANY well-known software companies have started providing GraphQL interfaces in addition to their REST APIs, e.g., Salesforce.com, Microsoft, AWS, Google, and GitLab. Also, many companies have put GraphQL in their stacks, such as PayPal, Walmart, Netflix, and more.
We can reasonably say GraphQL has reached a high level of adoption for good reason.
When GraphQL was invented, one of the problems it set out to solve had to do with expediting improvements to the customer and user experience.
With it, product managers and front-end engineers don’t have to wait for back-end engineers to update REST APIs or build new ones. Let’s say a new UI is designed that requires new data to be exposed. This means back-end engineers must get involved, and agile iterations on the UX slow down. This is the exact problem Facebook faced when they invented GraphQL.
This isn’t the case with GraphQL and 8base. Once GraphQL is in place, front-end engineers can rapidly iterate through designs in a more agile way. GraphQL represents the concept of “one API to rule them all,” meaning that you can access the data you need in one endpoint. If a new UI needs a new dataset, there just isn’t the same amount of heavy lifting. GraphQL was truly designed for modern application development, where we access more than one data source to paint a UI.
“GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.” Source: graphql.org/learn
This allows product managers and front-end teams to get to market faster, with less cost and headache. We’ve all heard this mantra before, but it is true.
In addition, GraphQL improves how data is accessed and manipulated.
When fetching with REST, you generally make multiple requests, in multiple trips, across multiple API endpoints, and to multiple servers. In contrast, GraphQL operations can provide multiple resources in one request, i.e., one trip. It can also cross one or many APIs and systems, including SQL and NoSQL data stores.
In many ways, the 8base backend is basically a big GraphQL API. Once a request comes in from a client app (UI), our GraphQL layer splits the request (acting as a light wrapper to existing APIs or microservices), executes queries across sources, collects the results in a stitched together fashion and presents them to the client. Again, “one API to rule them all.”
If you request parent-child-grandchild data structures from GraphQL, it is still one request from the client application. If you request and join two different tables from two different systems, it is still one request from GraphQL. And, if you request data across five tables and three systems, it is still one request from GraphQL.
To elaborate, developers typically massage, manipulate, and discard data before presenting it to the UI. Back-end developers create serializers, controllers, and models again and again. GraphQL turns complicated data requests into clean, simple calls and reduces friction. You just don’t have to do as much work.
With GraphQL, you don’t over-fetch data—like a whole table or a whole record at a time instead of just a few fields. Similarly, you don’t under-fetch, leaving you to query again. You also don’t have to jump through hoops to manipulate data (more on that below). You get the exact bits you need—in the exact shape you requested it in—regardless of the source.
Let’s call this a substantial and valid time saver—but it also improves application performance while reducing cost and complexity.
With 8base, as soon as you create a table in a single click, the system automatically creates the GraphQL schema and CRUD plus Subscription operations. The GraphQL API includes operations for query, mutations (create, read, update, delete, destroy, restore), and subscription operations as well as arguments for filter, sort, skip, order, sort, paginate, search text, group, aggregate, calculate, and more. Developers don’t have to reinvent the wheel with every project—we are talking about being “more DRY.” Tons of heavy lifting is automated here. Without sounding like a sales pitch, it can reduce development costs by 25-50-75%, depending on the scenario.
As additional tables are added to 8base, the GraphQL engine is updated. You can also integrate external data stores or APIs and expose them in the GraphQL layer. In concept, a catalog of APIs is born inside 8base and evolves, while maintaining a standard method of access. In addition, 8base was designed to allow any JavaScript or TypeScript developer to get up to speed rather quickly. Front-end devs add a lot of horsepower to their toolbox.
Again, GraphQL makes life much easier here.
GraphQL addresses errors presented by various data types—because it is strongly typed. This is a key reason why people say, “GraphQL ends up acting as a universal translator.”
In addition, 8base offers custom functions. You can deploy custom API endpoints (Webhooks), CRON job functions (Tasks), resolvers (GraphQL operations), and triggers (Websockets).
These are all backed by the same robust access to underlying data structures via GraphQL!
From an 8base backend coding perspective, “everything is possible” using JavaScript or TypeScript code that runs in a Node.js V14 container. A developer familiar with JavaScript or TypeScript—which 12M+ are—can quickly start the customization of 8base backend workspaces.
Importantly, documentation is built into GraphQL as a core tenet.
Most REST API specifications stop getting updates and are quickly dated. Then, Swagger and other documentation tools show up, helping to maintain some sense of shared knowledge across teams. This certainly helps, but it has often been after the fact—after coding happened.
With GraphQL and 8base, all documentation is automatically created and updated every time a table and field is added or updated. The documentation adds all the fields available for all operations. The documentation becomes a rather deep reference (like 5+ clicks deep) right away. This means developers can avoid spending time on documentation. It documents the API as you model tables and relationships. Perhaps more importantly, it reduces headaches for those who come after the first dev effort—and we’ve all been in “the abyss of no documentation” before.
Ever wished documentation was a first-class citizen? It is in 8base.
There are other unique and common capabilities when comparing 8base and Kinvey. Of course, this quick run-down is our perspective:
At the end of the day, we believe developers can be more productive with a GraphQL layer in the stack—this ultimately makes lives easier and customers happier.
This is why GraphQL is a core part of the 8base architecture and why we focused on it so much in this article.
There are many good articles comparing GraphQL to REST, and here are a few examples worth reading—How to GraphQL, Medium, and Hacker Noon.
Try the 8base back end for free or sign up for the front end “App Builder” beta.
Visit 8base Academy
Visit 8base Documentation
Visit the 8base Community
Visit the 8base homepage
We're excited about helping you achieve amazing results.
