Bleeding edge of technology

Starting our project from a blank page, we chose to use only the best technologies available, but this came at a cost. Now, nearly a year behind schedule, we reflect on the decisions that led us here.

Choosing the Right Tools

Our technology stack was selected to maximize future flexibility, scalability, and energy efficiency while dealing with the variety of environments (Linux, Windows, MacOs, Android, IOS). This translates into:

  • 1. No-SQL databases, as we know that our data needs will evolve. The flexibility they offer allows us to adapt without major overhauls and provides great efficiency for our non relational data.
  • 2. Elastic Clusters as scalability was paramount: our system can handle increased load seamlessly despite running on private infrastructures as we forbid the use of public clouds due to privacy concerns.
  • 3. Avoiding High-Level Languages: while Python is popular and straightforward, when we can, we still use alternative languages to achieve better performance and efficiency. We have not found an alternative to Javascript yet though.

Coté bases de données, le No-SQL s’est imposé car nous savions que le modèle serait amené à grandement évoluer au fur et à mesure que la solution mature. MongoDB (https://www.mongodb.com/) par exemple permet cette flexibilité sans le besoin d’un ORM (mapping objet-relationnel).

Que ce soit au niveau software ou bases de données, les clusters doivent être élastiques pour une croissance sans dépendance envers les clouds publiques que l’on s’interdit pour des raisons de sécurité des données.

From gRPC to QUIC to WebTransport

The concept for gRPC was brilliant—an efficient, cross-language RPC framework. However, reality hit hard. The library lagged behind on Windows clients, and compiling it proved cumbersome. In addition, gRPC hadn’t transitioned to QUIC, leaving us with a tough decision after investing countless man-days.

Next up was QUIC—the protocol underlying HTTP/3. We were thrilled with its potential. But, as with any new technology, there was a learning curve. Swift support on MacOS posed unexpected challenges. Still, we persevered, knowing that the benefits would outweigh the initial struggles but then we hit the wall of the infrastructure.

We struggled with HAProxy with its limited QUIC support, in particular in the back-end. So in order to keep our security and load balancing functions of the reverse proxy, we migrated to binary over HTTP3 which has been more immediately supported.

But in order to keep the multiple bidirectional channels support, we needed to add a layer of WebTransport which was not mature enough either, so we reverted to a proprietary binary format over QUIC with an in-house load-balancing solution.

For our binary serialization protocol we selected Colfer and that was for once painless. Most recommended! We only need a version for swift but decided we could live without for now.

Lessons Learned

In hindsight, we might have optimized too early. But for many great projects, if we’d known the difficulties ahead, we might have hesitated. The journey itself—filled with challenges, victories, and late nights—is to be appreciated.

Are we followers, sticking to the safe trail, or adventurers seeking innovation’s thrill? Well, let’s just say we’re standing firmly in the latter camp. The road less traveled may be rocky, but it’s where we find our stride.

Every startup’s path is unique and while we can’t offer a one-size-fits-all solution, embracing the journey—mistakes and all—is like for other experiences, the most important.