Xfoil's architecture evolution

We started with a fairly basic 3 tier architecture consisting of a SQL DB, a backend in JAVA and ReactJS frontend. We initially designed our backend layer using gRPC framework. This worked fine for all clients that needed to talk to our DB except for our dashboard in ReactJS (browsers don't support gRPC format natively, more on this later). To support our frontend client, we had to write another backend layer in JAVA using REST.

Things were going great until we got to a point where we started experiencing bottleneck in development. Anytime we needed to implement a feature in dashboard, we would finish the development for UX but due to backend team being overloaded, the frontend team would sit idle until the backend team implemented the APIs. Since the frontend team had minimal to zero JAVA experience, asking them to code the APIs was not an option. So there were 2 options that were available to us at that time

1. Hire more backend folks
2. Make frontend team totally independent from backend

We went with option #2 (well we did hire more backend developers but it took time). We setup another backend layer in nodejs using graphQL, which was easier for the frontend team to understand and own. So the bottleneck issue was resolved and our development velocity picked up. And we were able to deprecate the REST layer written in JAVA.

Things were going great with the nodejs setup until we started seeing code duplication as the same queries that needed data in graphQL were also needed in gRPC layer. Also a general lack of expertise in nodejs meant that we couldn't explain why our db pool connections were growing. Things reached a fever pitch when we decided to implement caching to improve performance and realized that we would have to write the same logic in nodejs and JAVA. So not only did we have code duplication in SQL queries but also in code across multiple stacks.

After some research, we found out that we could use ReactJS to talk directly to our gRPC backend using envoy proxy. So after initial prototype, we put in the work to convert all of our code in ReactJS that was talking to node backend to talk to JAVA backend. And we eventually deprecated the nodejs layer.

Conclusion

Now some might argue that we could have avoided all of this effort or that we are back to the initial problem of frontend team getting blocked because the backend is in JAVA but I don't agree and here's why

• We gained experience in A/B deployment and successfully deprecated a technology in favor of a new one all the while making sure our PROD faces zero downtime
• The frontend team became comfortable in getting their hands dirty in JAVA code base so they are no longer "blocked" when delivering a feature
• All of these decisions were made quickly and executed with speed without any bureaucracy impeding the development as experienced in a mature company