My Experience Working with the New Tech Stack of Telemed

I recently got the opportunity to be part of a team building tech for the telemed industry, and it was a fresh and new exciting adventure. In the midst of the COVID-19 crisis, to be able to work on a solution that helps hospitals effectively handle the excessive number of patients and make a real difference was a true blessing. Aside from the many talented people I worked with, a part of the excitement came from being able to try out relatively new technology, infrastructures, and deployment tools. In this article, I would like to share some of the experiences working with these technologies as well as the advantages and the limitations in each one.

Vercel

With the tight deadline and quick pace of the project, our CTO made a decision to use Vercel, formally known as Zeit, to ease the deployment process and speed up the development. Vercel uses NextJs, and with it, the deployment to production was as easy as a single command “now --prod”. The deployment could also be done by pushing to a branch, where Vercel would then create a branch specific deployment with the branch name in URL. This helped to quicken the deployment and testing process greatly. Moreover, Vercel uses lambda serverless framework and helped manage scaling the infrastructure effortlessly.

However, since Vercel is relatively new, some of the features were not fully developed. The environment variables in Vercel were managed using now’s secret, thorough command line. Even though adding, removing, listing, and using the secrets worked quite smoothly, it still lacked the function of being able to see the value of a secret and modify its value without having to remove it and then adding a new one again with the same name. Furthermore, unlike the deployments, Vercel does not have the user interface to interact with or modify the secrets. Hence, managing a lot of environments and keeping track of them was quite troublesome, especially when we have over 40 hospitals all with several unique environment variables.

The other drawback was that Vercel only supported one production build. As a result, we had to use branch deployment to support all the hospitals, so we dedicated an extra 40 branches with the sole purpose of just deployment. In this case, we were luckily able to put together a script that eliminated the manual work in deploying to all those 40 hospitals. Therefore, the design of the branch deployment automation helped simplify the process greatly but created a limitation on the ability to create a different build for each customer, which is manageable because of our work around.

Overall, Vercel was a great tool for quick and easy deployment. Even though some of the features are not perfect, Vercel is improving fast and still has many features that I have not mentioned, such as the integration market for tools like log drain and performance monitoring.

MongoDB Atlas

We used Atlas as a cloud database for Telemed. It came with an extensive set of features like an online mongo shell, performance advisor, and snapshots. One feature I found interesting was the ability to do query text search right in the database. Even though search indexing is not as complete as something like ElasticSearch, Atlas search could be set up extremely quickly and did the job quite well for our use case, which was just to search through patients’ names and doctors’ names.

Upstra

Upstra, also known as Eko’s Messaging SDK, is a messaging solution developed under the hood of our company. Since a crucial part of Telemed is the interaction between doctors and patients through a chat, leveraging Upstra for messaging helped to shorten the development time of the app significantly. It was incredibly easy to create and join chat channels and manage real-time events thanks to the Upstra documentation. Now, we are using both the messaging API and webhook to handle system messages and doctor’s shared unread, respectively.

The only limitation we faced for our use case was the push notifications. Since we had a separate mobile app for each hospital because of customer’s request and medical policy, we required push notifications to all of the different appIds. Unfortunately, using only one SDK account to manage the push notifications to all these mobile applications was not feasible, so we needed to have a separate SDK account for each hospital. As a result, we required an SDK API key and SDK account for each hospital deployment. This became a little difficult considering we had to go inside the admin panel to configure the webhook and generate an API token for every hospital. Nevertheless, the SDK team was able to help us set up all the SDK accounts needed extremely quickly, so configuring everything became easily manageable. Overall, I definitely had a great experience working with Upstra.

Conclusion

For this Telemed project, our team was able to leverage a lot of tools in order to shorten development time and deliver good products. Although I did not go over everything we used, such as Jitsi video call, this was a great opportunity for me to share a glimpse of the main tools that helped to make this project possible.