Background

Earlier this year, we introduced a new version of Telegram for Mochi, but it came with some new challenges.

Up until now, we’ve been using a single backend system to support all of our services. This approach was taken to ensure a smooth experience for both users and engineers across different platforms. However, a problem arose when it came to the user interface. We found ourselves dealing with two different sets of rules (Discord & Telegram) for how the interface should look and behave. This complexity kept growing as we added new features and concepts. Eventually, we reached a point where it became nearly impossible to maintain consistency between the two platforms. Worth noting that, we also aim to have a Web, Mobile & Raycast versions for Mochi.

To solve these problems and make sure everyone has a similar and easy experience, we realized we need a library that contains all our UI stuff that everyone can use.

But, making this library work on different platforms isn’t simple. It needs to be easy enough for our frontend team to use, also flexible enough to work on all platforms.

Wins

Flatten the learning curves.

You might not know this, but our frontend team only has 2 full-time members who really understand all the business and technical stuff. And we have 3 platforms to take care of. So, we definitely need some extra help from our community through our ‘Bounty Program.’

Luckily, thanks to our shared library, the process is pretty simple now.

Before:

A: Hey, can you help me with this feature?
A: This feature will be on Discord, Telegram, and the website. Here's how it should work on each platform.
A: Make sure to create test files for all the platforms because we make changes frequently.
A: Oh, and please document it somewhere because I might forget.
B: ...

Now:

A: Hey, can you help me with this feature?
A: All you need to do is use a function from a well-tested and clearly defined source.
B: Sure!

Consistency throughout the systems

Dealing with the nitty-gritty details can be quite challenging. Often, we overlook small things like how to display numbers or whether we should add a period at the end of a sentence.

Handling these details on just one platform is tough, and when it comes to managing them on five different platforms, it feels nearly impossible. Our daily meetings are increasingly filled with questions like, “Hey, did you make this change on Discord but forget about it on Telegram?” and vice versa.

After we introduced mochi-ui our focus shifted from dealing with technical issues to more meaningful questions like, “Does this feature actually make sense?” or “Hey, this is a bug report from a user, can someone look into it?” These are the kinds of challenges we are more than happy to face.

Gotchas

Of course, there’s no one-size-fits-all solution, especially on the first attempt. We’ve identified some issues, and we’d be glad to have your hand in addressing them:

• Lack of Local Preview: Currently, we don’t have a way to preview changes locally. The only option is to update the package and check it in our development environments.
• Text-Based Components: Some of our components are still text-based, which could be limiting if we need to use them in web applications.
• Single point of failure: Since ‘mochi-ui’ is centralized as the only implementation, we must ensure it’s robust and fast. Some rendering logic still requires API calls, and we need to find ways to eliminate this dependency.

Final thoughts

This approach is not and never a silver-bullet and may not be appropriate in all cases. However, we believe that this implementation has made our lives a bit less stressful by allowing us to shift our focus to other areas.

This blog post is part of our Mochi Frontend Practices, also check out:

• How we using mock data to fasten our UI development
• Guidelines: How to render currency and profile name
• Applying state machine to switch UI view