An interview with Atsign’s lead architect Jagannadh Vanguri
“Simplicity is the ultimate sophistication.”
These are the words of Leonardo Da Vinci, who is widely considered one of the most diversely talented individuals ever to have lived. Centuries later, these words continue to resonate with us every day, especially in the world of technology and software engineering. Simplicity is often forgotten while trying to solve business problems with software and code, resulting in high costs and frustration for developers.
Meet Jagannadh Vanguri, an avid badminton enthusiast, travel buff, and prolific reader who also works with Atsign as the lead architect of the atProtocol. Hailing from Hyderabad, Telangana, Jagan loves technology and is passionate about software design and architecture.
I caught up with Jagan on his journey and experience with the design and development of the atProtocol.
@anthony: What were the key considerations taken into account before beginning to design and architect the atProtocol?
Jagan: We did a lot of brainstorming with Colin and Kevin (co-founders of Atsign) 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 atProtocol 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 atSign. 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.
@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 atProtocol) 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 atProtocol?
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 atProtocol, 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 atProtocol?
Jagan: Once you have an app idea that you want to build on the atProtocol, 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 atDeveloper to get familiarized with the SDK and other nuances of the atProtocol. I have seen many developers start with the UI/UX before they even know anything about the atProtocol, hence losing valuable time in the process. From the different successful apps that we have seen on the atProtocol, this approach and process seems to work best.
@anthony: What should the developer community expect in the upcoming releases of the atProtocol?
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.
Anthony Prakash (anthony@atsign.com) leads Developer Relations and Strategic Partnerships for Atsign.
Atsign is the creator of an open-source, P2P protocol for the Internet that enables developers and enterprises to handle personal data based on trust and permissions. Check out our GitHub repo.
