Draftbit is a web application with a frontend — the Builder that users interact with — and a backend — the hidden services and database that stores data and “does stuff” behind the scenes. Most users will be at home with this paradigm as it mirrors how they are building a mobile frontend within Draftbit and backend using any of our supported services like Xano.
Continuing down the path of Draftbit’s backend architecture, our servers run Node.js and use the Apollo Server framework to serve up GraphQL requests to the frontend; this is a fairly popular and conventional setup for building GraphQL backends. However, we also need to deal with the older and more ubiquitous HTTP REST requests to other services that our backend communicates with — all of which are not directly part of the frontend/backend communication cycle. Until recently, we used the “batteries included” framework, hapi, for backend HTTP REST requests. Essentially, hapi provides simple abstractions for getting up and running without having to write a lot of boilerplate code (hence, the term "batteries included".)
However, as Draftbit has grown, the need for a more “lightweight” (aka lacking the batteries included convenience) HTTP REST server has arisen; this is a common pattern with all technology stacks as the nuances, options, and implementation details of how technology works at scale change over time. With hapi, it was easy to get up and running earlier on in the company. But now, Draftbit requires more fine-grained control over it’s REST services. So we transitioned to the Node.js industry standard, Express.js — specifically choosing the apollo-server-express version, which combines the best of both worlds (GraphQL + HTTP REST).
We now now have access to countless packages written for Express.js, more fine grained controls in our middleware, and a wealth of documentation to fix, troubleshoot, and expand our services with this framework. This should make it much easier to grow and maintain our backend services regardless if they require GraphQL or REST ... ultimately making it easier for us to add more features for users, which are on our roadmap.
