The elegant simplicity of the @protocol
By: The
Tags: Open Source, Protocol, Flutter, Dart, Flutter App Development

@anthony: What were the key considerations taken into account before beginning to design and architect the @protocol?

Jagan: We did a lot of brainstorming with Colin and Kevin (co-founders of The @ Company) on this topic and arrived at three main elements: 1) Picking the right technology stack, 2) picking the right abstractions, and 3) most importantly, having simplicity across the board.

Let me elaborate — the @protocol is comprised of two parts: a server (root & secondary) and an SDK. We started by picking the right tech stack. For the root server we decided to go with Dart and Redis, and for the secondary server we went with Dart and Hive.

Once we decided on the technology, we started building the right abstractions for the building blocks (refer to Diagram 1) of the protocol. The main purpose of the root server is to provide a lookup for the host and port address of a given @sign. A secondary server’s responsibility is to execute the verbs that make up the protocol and give a response back to the client. We started with building abstractions for verbs, verb execution verb responses, and core elements of the protocol — in simple terms, we imagined and set up real life scenarios, daily transactions, and data exchanges across the protocol. We have tried to use simple patterns across our code, employing best practices like separating data store access from business logic in order to ensure high cohesion and low coupling across the protocol.

Diagram 1 : Under the hood of the @protocol

@anthony: Why did you bet on Dart?

Jagan: When we did the analysis and research on selecting the right technology for this journey, we wanted a seamless experience for our developer ecosystem. Dart gave us the flexibility to build all our core components (the Server, SDK and applications using the @protocol) on the same framework and technology. Looking back more than one year later, we are so thrilled that we picked Dart.

@anthony: Were there any inspirations behind the design of the @protocol?

Jagan: In my software engineering career, I have always been a huge fan of the “spring framework.” There are several concepts and best practices from the spring framework that we have brought in while designing our secondary server architecture. I have also taken inspiration from Apache Tomcat while designing the different abstractions for the server.

@anthony: While taking on a project this complex, what major roadblocks did you face during the design and architecture process?

Jagan: When we embarked on this journey, there were a few simple roadblocks like coming up with the right abstraction for the “verb” itself, proper encoding and decoding of the incoming requests, etc. However, the biggest challenge was ensuring that we maintain an extremely small memory footprint. Our secondary servers are supposed to be tiny servers with very little memory (4 MB). This is probably one of the biggest technical challenges I have ever faced in my career. But the end result is very rewarding and will hopefully change the way we develop applications and capture data.

“This is probably one of the biggest technical challenges I have ever faced in my career.”

@anthony: In order to keep the focus on ’simplicity,’ did you have to make any major trade offs during the design process?

Jagan : The biggest tradeoff was the time and effort spent in architecting and design to keep things simple.

There were several occasions when we would do a version 1.0 of a module and demo it with the core group of architects and developers. If it was not simple enough to understand, we went back to the drawing board and kept iterating until it felt simple and easy to understand.

We are blessed with an incredibly talented and highly accomplished team of architects working towards the same vision and goal. They always look at everything through the lens of a developer, and if they don’t understand something, then most likely an average developer would never be able to translate that design into code. This process was definitely time-consuming, but in the end it’s time well spent.

“If it was not simple enough to understand, we went back to the drawing board and kept iterating until it felt simple and easy to understand.”

@anthony: Do you wish you had done anything differently? What did you learn from the experience?

Jagan: When we started writing the @protocol, we did not imagine all the interesting and creative ways in which app developers might want to use the protocol. Once we open-sourced the code and started letting the developer community experiment with the technology, it helped us go back and button up parts of the code that could have been designed better.

For example: the notifications subsystem has undergone a big redesign from what we imagined and how the developer community consumed and developed apps.

In software, there is always room for improvement and getting better.

@anthony: Do you have any advice for the developer community on using the @protocol?

Jagan: Once you have an app idea that you want to build on the @protocol, my suggestion is to build a library that contains all of the business logic and solve the data modeling part of the problem first. This process allows an @developer to get familiarized with the SDK and other nuances of the @protocol. I have seen many developers start with the UI/UX before they even know anything about the @protocol, hence losing valuable time in the process. From the different successful apps that we have seen on the @protocol, this approach and process seems to work best.

@anthony: What should the developer community expect in the upcoming releases of the @protocol?

We are currently working on enhanced synchronization of data between the cloud server and the apps, as well as an improved notification system. We are looking forward to releasing them to the developers in the coming weeks.