3 Jun, 2022 | 3 min read

What I Learned from Building a Cloud-Native Frontend App for Asgardeo

  • Theviyanthan Krishnamohan
  • Job Title - WSO2

Photo by Pixabay

The world is progressing fast, especially when it comes to the tech industry. In the past, JavaScript was child’s play, condemned to lend some semblance of programmability to web pages. Today, it is taking us to space. At the start, WSO2 Identity Server was a fledgling identity solution reposed in your on-prem servers. Today, we are launching it to the cloud.

Asgardeo has been a great achievement for our team. Breaking boundaries means changing the way you think, questioning your perceptions, and radically overhauling the way you work. While this is not easy, the paradigm shift is inevitable. After all, it is mandated by time. You struggle, stumble, feel like an imposter, persevere, persist, and eventually, you prevail.

Developing Asgardeo has been a humbling and educational experience. There were many learnings to take en route to the finish line. Here, I share some of what I learned from conceptualization to realization.

Get Ready to Get Bored

One of the major problems I faced while developing the Asgardeo Console app was getting so used to the visual design of the frontend application, to the point that I became bored of it. I feel it is customary that at some point during the development of a frontend application you start questioning your own design choices.

This is very natural and I am pretty sure most developers go through this. While the feeling is tough to digest, I found it allowed me to take a hard look at the initial designs and rejuvenate them. After all, subjecting your designs to skepticism can only make them better.

However, it is also important to remind yourself that it is in our human nature to find things boring once we become familiar with them. Just because the application’s design does not excite you anymore, it does not mean a user would feel the same when they first get to use the application. This is why you must conduct usability tests on your visual designs from time to time.

Even though you should not completely disregard this feeling(which is largely negative), you should also make sure you do not wallow in it. As a rule of thumb, whenever I found something unappealing, I took a hard look at it. If there was anything that I could change, I went ahead. If not, I moved on reminding myself that it was only a natural feeling.

This taught me an important lesson; the need to be mindful. Being aware of our cognitive biases, and being mindful of their ramifications in our design and development, is important to provide our users with a great user experience and peace of mind. Here, being mindful of the innate human nature of boredom allowed me to stick to my guns when I realized that there was little to improve on my designs.

The Union Between UX and Frontend

By now you would have already started to wonder why a frontend engineer would bother about UX designs. Well, this was my second lesson.

It is easy to think of UX as a separate field in the industry that designs the products and hands them over to the developers. In reality, that might not be the case. I do not like the concept of handing over the designs to the development team at all. There are two main reasons for this

Even though big businesses that work on several different products might be able to afford to have a dedicated team of UX designers, mid-sized businesses that develop one or two products cannot afford to have too many UX designers. Therefore, frontend engineers will have to invariably don the hat of UX designers.

While you might argue that an engineer should not be expected to do UX designing, I vehemently disagree. I believe that good engineering is always a product of good UX thinking. It is impossible to engineer a solution without understanding the user’s pain points. Take ballpoint pens for instance; László Bíró engineered the ballpoint pen because he was sick and tired of having to refill fountain pens often. There you have it. Good UX thinking is at the heart of great engineering.

The second reason is that designs evolve. I do not think you can ever settle on a design and call it the final design. There will always be new thinking, fresh perspectives, and of course several light-bulb moments.

So as the design evolves, the development cannot just wait. In other words, there is no end to the UX process. The development process has to hitch a ride with the UX design process and go through several iterations. Designing, development, and testing all become a part of an iteration. This is an unending process. Being perfect is not a state; it is a process.

Progressive Revelation

The truth never reveals itself at once. This philosophy is very much applicable to frontend engineering. At times, it is easy to become overwhelmed by many different design ideas and plans; so much so that you do not even know where to start. Often, you would be so consumed by the design phase itself that it might seem like there is no end in sight.

It is important to understand here that the human mind is a motherlode of ideas. The more you keep looking for new ideas, the more you will find. So you must choose something and start somewhere. You do not have to do everything at once. Just start with a viable idea and start implementing it. Then you can revisit and revise designs iteratively.

I usually come up with the designs for a feature, discuss them with my team, revise them if needed, and then start implementing them. At times, the designs were incomplete. Initially, I fretted over it. But gradually, I learned that things can be fixed on the fly.

Often, you will find that a solution to a design problem can be found when you try to solve a design problem in another feature. At other times, you will find it during a new round of discussions. 

The implementation will also be improved incrementally. Something that might seem so unflattering at the beginning will take shape with time, and will inevitably become a fully-fledged feature 

UX Evolves

As I mentioned earlier, designs are always evolving. My advice is to not become too attached to a feature that you have developed. In the frontend, nothing is permanent. This includes the application as well!

We started with one developer portal application. Then, that developer portal was cleaved into an admin portal and a developer portal. Then, we thought it should be one application and combined these two applications and named it the Console app. One became two, and two became one again. Welcome to the world of frontend development!

This can be frustrating for some, but it is the reality. Do not expect things to ossify. There will always be new ideas that come up. New research will exhume new insights. So you must be always ready for change. The general wisdom “if it ain’t broke, don’t fix it” does not apply to frontend.

Familiarity Hampers Empathy

When you become familiar with a user flow, you will eventually restrict yourself to a predictable pattern of user interactions. In addition, you will also become oblivious to the user’s pain points.

For example, in one of the forms in our application, we had a textbox to allow users to enter a URL. We then had a text button to allow users to add that URL to the list of allowed origins. The URL is useless without adding it to the list of allowed origins. However, we had gotten so used to clicking the button that as soon as we entered the URL, we failed to realize that we could automatically add the URL to the list of allowed origins.

We only realized this glitch when we tested this flow with a new user. So this was an important lesson for us. When you develop and test applications, you will eventually start breezing through the flows. And this knowledge will make it difficult to empathize with a new user. The only solution, in my view, is to test your application’s usability from time to time.

Cruise Control vs. Power User

Our on-prem product was extremely customizable because we wanted the product to cater to a diverse set of users. In other words, we did not have a particular end-user.

When developing an application for the cloud, we need to know the end-user. This means that you need to abstract out a lot of the features to provide a simple and hassle-free user experience. Our philosophy changed from building a heavily customizable product to building a heavily customized product.

For example, we preconfigured a lot of the settings based on user personas in the cloud application, whereas we allowed users to configure them in the on-prem product. This allowed us to provide a great user experience to our end users.

However, I must admit it was not perfect. There were times when we wanted a user to have the option to adjust a setting while also ensuring that it was abstracted away from the main user flow. We accomplished this in two ways.

First, we created a simpler creation flow and allowed additional configurations in the edit view. So if a user wants to create an application quick and fast, they can just canter through the application creation flow. If another user wants granular control over certain settings, then they can do so in the edit view.

Second, we hid advanced settings from the screen by default. This allowed for a simpler and straightforward UI. Power users can access the advanced settings by unhiding the settings.

More Tests, Fewer regrets

When developing the on-prem product, we had the luxury of being lax on testing. This is because we did not have to do continuous development and integration with the on-prem product. The generally available version of the product would only be released at the end of the development lifecycle.

However, in the cloud, your code changes are continuously pushed to the cloud. This means, there is no more room for buggy or half-baked code. So I had to test my implementation manually and run automated end-to-end tests to verify that my changes were in order, and that they didn’t break anything else in the application.

This took a bit of getting used to, owing to the process I was already used to. But by breaking builds and crashing applications in the cloud, I eventually coerced myself to ensure that the code I was pushing to the cloud was stable. That was a big learning curve.

Asgardeo has been a fascinating journey for us and it will continue to remain so. Just like the product itself, I realize I have also gone through several changes myself. My thinking has changed, my workflow has evolved, and the development process has taken a new turn.

And the most exciting part is yet to come. My greatest excitement is in knowing how real users feel about the actual product and iterating the designs based on their feedback. It will be a whole lot of fun to start revamping the features that you built from scratch, knowing that it would improve the user experience.

In a way, you could say the biggest challenge is also yet to come. Developing a cloud application from scratch is only a tiny part of the application’s life. I know I will eventually end up spending more time maintaining and improving it than I did developing it.

Come what may, this experience has been so fulfilling that it has only made me look forward to the future. Here is to more designs, discussions, iterations, usability tests, code changes, and the consequent improvements to the product!

    If this sounds interesting, we encourage you to try out the early adopter version of Asgardeo, an identity as a service (IDaaS) solution that enables developers without security expertise to easily embed customer identity and access management (CIAM) features into their apps within minutes.

    You can also follow us on Twitter or join the IAM4Devs community. Alternatively, if you’re looking for an enterprise-grade, API-driven, open source solution that can manage millions of user identities without spiraling costs, please check out WSO2 Identity Server.