DEV Community: Nishant Keshav

Server Driven UI

Nishant Keshav — Mon, 07 Jul 2025 07:03:56 +0000

So, Everyone must be wondering what a server-driven UI is (no, it is not CSS files stored on the Backend Part). Let me explain in detail below.

What is Server Driven UI (SDUI)?

In traditional software Development, whenever we want to push new design or business logic changes in the frontend part, we need to rewrite the whole design as if we want to change the UI/UX of a Payment app, so we need to change the whole structure of the design and business logic. That means rolling out a new App Update and hoping users to update the app(which usually does not happen).

This is where SDUI (Server Driven UI) comes in.

Instead of hardcoding UI elements in the mobile/frontend app, you send UI definitions from the backend (server) in JSONor other formats.

The client app becomes a renderer that reads the UI structure sent by the server and displays it accordingly.

Let's go into a detailed explanation:

Without SDUI (Traditional writing way)
With SDUI (Server-Based)

Server-driven UI (SDUI) is an emerging technique used by companies like Airbnb and Lyft that leverage the server to build the user interfaces of their mobile apps. This opens up new possibilities and addresses some fundamental challenges with native mobile app development. Before we look at how server-driven UI works, let's take a look at how mobile apps are developed today.

Let's see some examples.

When the listing screen is displayed to the user, the app fetches a list of products to display from a server. The list of products, the data, is combined with the UI built by the developer and transformed into a list view.

The Release Cycle

Now let's imagine after launching our listing screen, we decide to add the product's star rating to each row and give a special treatment to sale items.

The logic that determines how the data is presented for each row is built into the app, so in order to make these changes to the user interface, we need to run through a full release cycle. The process looks something like this:

Developers write code to make the desired UI changes.
The UI changes are reviewed by testers.
A new version of the app is submitted to the App Store/Play Store.
Apple/Google reviews and approves it.
Users update to the new version.

For a typical app supporting iOS and Android, the release cycle must be done twice, once for each platform, and generally, we will need different developers for each one. By the time these changes have made it to our users’ devices, we're already looking to make additional changes. In this case, we now want to display featured products at the top of the list in a horizontal scroll container.

Once again, we have to go through the full release cycle to make these changes. Between development, testing and waiting for approval on both platforms, each of these simple changes takes weeks or even months to make their way into the App/Play Store. And even after they've made it into the store, we still have to wait for our users to update to the new version of the app before they will see them.

Each time we release a new version of our app, we have to wait for our users to update to it. Some will update right away, some will take their time, and some won't update at all. This creates a bad user experience.

So what's the solution?

Well, what we can do is that we can write our Web/App designs in such a way that they render according to a JSON response from the server and the designs are stored in the JSON format on the server.

Instead of hardcoding our web or app designs directly into the client, we can build the UI to render dynamically based on JSON responses from the server. These JSON responses define the structure, styling, and logic of the UI, such as buttons, input fields, labels, and layout containers.

The server stores these UI definitions in a structured format (like JSON), and the frontend app simply parses and renders the layout accordingly.

This approach gives us full control over the UI from the server, allowing us to:

Push UI updates without forcing users to update their app.
Personalise or customise UI per user.
Experiment with new flows or features quickly (A/B testing).
Unify UI logic across platforms (Android, iOS, Web) using a shared schema.

Instead of fetching a list of products, the app fetches a list view, which contains a set of row views, each of which contains text and image views with information about spacing, alignment, colour and text.

The app renders the response from the server, and the result is identical to the version using traditional development techniques.

The updates that previously took weeks or months can now be made in days or hours. The changes are made to both the iOS and Android apps consistently, and all users see the same version at the same time.

Challenges with Traditional Native App Releases :

Slower Update Cycle : The time-consuming app release process causes delays in critical updates.
Slower User Adoption : Users need to download and install updates, leading to slower adoption rates for new features and bug fixes.
Platform-Specific Code: Developers must duplicate effort on different platforms(iOS, Android) and maintain separate codebases, doubling the workload. Ensuring a consistent user experience across platforms can also be challenging.
Slow Feedback Loop: Gathering user feedback and making quick iterations is harder due to the slower update cycle and user adoption.

Advantages of Server-Driven UI over Traditional App Development:

Dynamic Updates: Allows for dynamic updates without needing users to download new app versions, eliminating delays associated with app updates.
Uniformity: Ensures consistent user experience across platforms.
Faster Feedback Loop: Empowers developers to stay agile, respond faster to user needs, and deliver the best user experience.
Rapid Feature Rollouts: Features can be rolled out, tested, and iterated quickly from the server side without waiting for app store approvals.

Disadvantages of SDUI compared to traditional UI techniques

Increased Complexity on Backend

The backend must now handle UI logic, layout generation, and dynamic rendering rules.
It turns your backend into not just a data provider but also a UI controller.
Result: Tight coupling between frontend and backend logic, which can get messy fast.

Slower Development for Rich UI

SDUI works great for static or form-based UIs (e.g., settings screens), but:
Building highly interactive, animated, or custom components becomes harder or even impossible.
You lose the benefits of frontend frameworks' powerful component systems (like React/Vue).

More Difficult Debugging

Debugging becomes harder when UI bugs originate from a malformed JSON or incorrect server configuration.
Logs may not always clearly show the root issue, like in traditional UIs where you have direct access to the component tree.

Performance Overhead

More round-trips: First, the app asks for the UI definition, then fetches data.
Increased payload size: UI JSON + data = heavier initial loads if not optimised.
Might need aggressive caching and fallback strategies.

Loss of IDE/Tooling Benefits

With traditional UI development, you get type safety, code completion, previews, and powerful debuggers.
SDUI JSON-driven rendering loses these advantages unless you build custom tooling.

Steeper Learning Curve for Teams

Backend teams need to understand UI structures and rendering logic.

Design Limitations

Pixel-perfect design or complex UI behaviours (e.g., drag-and-drop, advanced charts) are hard to achieve via SDUI.
Often, we need to fall back to a hardcoded/native UI for those.

CONCLUSION

SDUI trades flexibility at runtime for complexity in codebase, performance, and development experience. It's great for use cases like CMS-driven pages, forms, and onboarding flows — but bad for animations, rich interactivity, and rapid frontend iteration.

MY VIEW : USE AT YOUR OWN RISK

You can read here PART-1 and PART-2 how PhonePe integrated SDUI in their Application(Their Implementation is Crazy 😍).

There are Many organisations which use SDUI. I will list out the links below for your reference.

Liked the content? Let’s connect on LinkedIn — I post more stuff like this (and would love to see what you’re building too).

ORMs: The Good, The Bad, and The Ugly Performance

Nishant Keshav — Tue, 24 Jun 2025 15:39:28 +0000

Ever opened your code editor and thought, “Great, another day wrestling with SQL queries and database schemas”? You’re not alone. For centuries (give or take a couple of decades), developers have been banging their heads against the keyboard, translating their lovingly crafted objects into cryptic SQL statements.

Enter the superhero you never knew you needed: ORM (Object-Relational Mapping). Imagine telling your database, “Hey, save this,” and—poof!—The ORM handles the nitty-gritty SQL complexity for you.

Think of ORM as your multilingual friend who effortlessly translates your instructions between you (the code) and the database. No more lost-in-translation moments – thanks to ORM! Come on, let’s dive deeper into the world of ORM in this blog today.

Let’s say you have this object with you:

{
  rollNo: 7 
  name: "Nishant"
  sub: "JAVA"
}

Now, imagine a scenario where storing this object is as seamless as a magical process. Behind the scenes, all the required database operations happen automatically. No need for you to write the SQL queries – YES, this is possible!

This is where ORM steps in!

What is an ORM?

An ORM is a tool that lets you work with a database using programming code instead of writing SQL directly. You can perform CRUD operations (Create, Read, Update, Delete) by following the ORM's specific syntax to manage data in the database easily.

So, let me take you through an example.

Here's an example of SQL code that retrieves information about a particular user from a database:

SELECT id, name, email, country, phone_number FROM users WHERE id = 20

The code above returns information about a user's name, email, country, and phone number from a table called users. Using the WHERE clause, we specified that the information should be from a user with an ID of 20.

On the other hand, an ORM tool can do the same query as above with simpler methods. That is:

users.GetById(20)

So the code above does the same as the SQL query. Note that every ORM tool is built differently, so the methods are never the same, but the general purpose is similar.

Now, coming back to the Original Example

For instance, if you have a student object with properties like student ID (rollNo), name, and subject (as given in the image above), you collect these values. All these things are available in the object format, in the variables format. Subsequently, to store this information in a database, you employ a SQL query.

INSERT into student values (07, ‘Nishant’, ‘JAVA’);

So, most of the people would execute the query given above to add the student details to the students' database.

Every interaction with the database involves SQL queries. Whether you're inserting data into a table, fetching information using a select query, or updating records with an update query, SQL is at the core of these operations. This means that as a developer, you need to have a good understanding of SQL.

Imagine you have some data in your program, like an object, and you want to save it to a database. Normally, you would write SQL queries to do this, which can be a bit tricky. But what if you didn’t have to write those SQL queries yourself?

Instead, you just tell the system, “Save this object,” and it takes care of everything for you. Behind the scenes, the system automatically turns your object into the right SQL commands and saves it in the database. You don’t see or write the SQL, but it’s still happening(kind of magic, right?)

Your DBMS only works with SQL queries, so you can't say there's no SQL. There is SQL, but you, as a programmer, are not directly writing it. However, you have tools/libraries that assist you in managing this process, ensuring you don't have to manually write the SQL queries.

These techniques are called ORM techniques, which stand for Object Relational Mapping.

You incorporate this technique between your framework and any programming language and your database.

Basically, you are actually talking to ORM, and this will store the data in the database. Who is responsible for making the SQL queries? This ORM! You don't have to do anything.

But is it possible? Can we just save the data in the database by using the object? The answer is YES!.

Let's consider how we create an object in JAVA.
(If you are asking why Java, because I am a Java developer😏.)

In Java, you require a class to create an object. This class serves as your design blueprint.

Let's say if you talk about students, you will create only one student class, and you will have multiple objects.

class Student { 
    int rollNo;
    String name;
    String sub; 
}

Imagine you have a classroom with 20 students. For each student, you will have a distinct object. Each of these objects will have a unique roll number, a different name, and possibly a different or common subject of interest.

When considering creating tables in a database, think of it as having a box with multiple columns and rows.

At the beginning of the application, you don't have any data; you just have the column structure. You might have a "roll number" column, a "name" column, and a favourite “subject" column.

🔢 Roll No	🧑 Name	🎯 Subject
🟢 01	Rohit	🐍 Python
🔵 02	Jani	☕ Java
⚪ ..	..	..
🔴 20	Saira	#️⃣ C#

We are basically trying to relate object-oriented concepts with database concepts, and that is what is called Object-Relational Mapping. Okay, so you don't have to do anything as a programmer.

When we talk about Java we have HIBERNATE, if you talk about Django which uses Python, which has an ORM built in, if you talk about GoLang it also has GORM, if you talk about .NET also has Entity framework, if you use Nodejs or any Javascript runtime you have a lot of options like Drizzle, Prisma and Sequlize.

Mainly, you use this technique in between, and you say Hey, technique, this is my object. Save that in a database, and it's done.

That's how they do it. So they write all the queries for you. Behind the scenes, if you check, they create a select query. So if you say, "Hey ORM, I have this roll number and can you give me the data for it?" basically, we use some, let's say, GET methods. In this case, it will fire a SELECT query. When you say save, it will fire an INSERT query. When you say the data is already there, it will fire the UPDATE query. And what if you say you want to delete? It will fire the DELETE query. So everything will be done by your ORM technique.

Basically, this is happening behind the scenes,

The term “Relational” in ORM refers to the Relational Table in the Database. The database can be SQL, MySQL, PostgreSQL, etc. The term “Object” refers to the Object of a class. And finally, the term “Mapping” refers to the mapping between these two.

It maps the fields from the Student class to the columns of the Student Table.

For example, the ID from the student class is directly mapped to the ID column from the student table. So we can directly create objects of the student class and store them in a student database table. Basically, we don’t have to write SQL statements to insert the record into the student’s table. We can use ORM to directly map objects to the relational database table.

Pros of Using ORM:

One of the significant advantages is the time saved for programmers.
ORM techniques handle query generation, reducing manual SQL coding.
You write less code when using ORM techniques than with SQL.
ORM techniques are built to eliminate the possibility of SQL injection attacks.

Cons of Using ORM:

Complexity Limitations: As projects become more complex, some ORM techniques may lack features for executing complex tasks. Customised queries might be necessary.
Performance Debate: There's an ongoing debate about the impact on application speed. ORM might slow down the application slightly, especially when compared to manually optimised SQL queries. However, the difference might just be a fraction of a second. But when we talk about scale, those seconds matter a lot.
Debatable Speed: While ORM aids faster development, there's a debate on whether it slows down runtime performance. In performance tests, the difference is often minimal but may be noticeable in milliseconds.
Customised Queries: ORM allows for customised queries. In Java, for instance, JPA supports JPQL or HQL, resembling SQL but adapted for object-oriented structures.
Developer Experience: If you're experienced in writing optimised SQL queries, using ORM might seem less efficient. ORM techniques have their query-building methods, which may not align perfectly with manual optimisation.

Why ORMs Are (Supposedly) Your New Best Friend

You Don’t Have to Speak SQL All Day
Look, SQL is great if you enjoy typing the same mind-numbing queries until your soul leaves your body. ORMs let you talk to your database in your own programming language—no more ancient incantations required. Just ask for what you want, and the ORM will fetch it (usually).
Faster to Build Stuff (Allegedly)
Because you’re not wrestling with SQL every five minutes, you can actually build features. More time for actually building features, less time questioning your life choices at 3 AM because you misplaced a semicolon. Progress!
Makes Your Code Look Neater
ORMs keep your code looking like a well-organised closet, instead of a pile of SQL socks thrown everywhere. When you revisit your project after a month, you might even remember what you were doing. Miracles do happen.

But Wait... Here Comes the Fun Part

Sometimes It’s Slower Than You’d Like
ORMs are like that friend who insists on taking the scenic route to the grocery store. Sure, you’ll get there eventually, but I hope you weren’t in a hurry. If your app gets popular (hey, aim high), be prepared for some performance “surprises.”
Magic Can Be Annoying
ORMS do a lot for you automatically, which is awesome—until it’s not. It’s like having a helpful roommate who does your dishes but somehow breaks your microwave in the process. Thanks, I guess?
Not Great for Fancy Database Tricks
ORMs look at your complex SQL requirements like a teenager asked to do calculus. Sure, they’ll try, but you’ll probably end up doing it yourself anyway. Sometimes, you just have to roll up your sleeves and write the SQL by hand, like a real adult.
Performance Issues

The N+1 Query Disaster:
You load 100 users and want their posts. Naive ORM code hits the database 101 times (1 for users, 100 for each user's posts). Your app crawls like it's running on a potato. This happens ALL THE TIME to developers who don't understand what their ORM is doing.
Lazy Loading Death Spiral:
ORMs love lazy loading - sounds efficient, right? Wrong. Access one related field outside your main query context, and boom - another database hit. Do this in a loop and watch your response times explode.
Query Generation Stupidity:
ORMs generate SQL that would make a DBA cry. They often SELECT * everything instead of just the fields you need, create unnecessarily complex joins, and miss obvious optimisation opportunities that any human would catch.
Memory Bloat:
ORMs load entire objects when you might just need one field. Want just user emails? Too bad, here's the full user object with profile pictures, settings, and everything else eating your RAM.
1. The "It Works on My Machine" Problem:
2. Your ORM query runs fine with 100 records in development. Deploy with 100,000 records, and suddenly everything times out. ORMs make it easy to write code that doesn't scale.

These aren't "microsecond differences" - they're "why is our app taking 10 seconds to load" disasters that kill user experience and cost companies real money.

That's the performance reality most ORM tutorials conveniently skip.

So, Should You Use an ORM?

If you’re new and want to build stuff fast without selling your soul to SQL, ORMs can be a lifesaver. Just remember: sometimes you’ll have to peek behind the curtain and deal with the mess. ORMs are like autocorrect—incredibly helpful until they decide you meant “duck” when you clearly typed something else entirely.

By now, you must have had a clear idea of ORM. However, understanding ORM on a theoretical level is just the first step. To know the practical aspects of working with ORM, you can try working with it by using it in some of your projects.

Liked the content? Let’s connect on LinkedIn— I post more stuff like this (and would love to see what you’re building too).

Serverless Architecture

Nishant Keshav — Thu, 24 Apr 2025 19:08:46 +0000

Serverless: It's Not 'No Server'!
You’ve probably come across the term before—Serverless. But don’t let the name mislead you. While it sounds like there are no servers involved, that’s not exactly true.

Serverless doesn’t mean servers don’t exist—it means you, the developer, don’t need to manage them.

Servers are very much a part of the process. Your application code still needs to run somewhere, and that “somewhere” is a server. There’s no magic that makes code run out of thin air.

The real advantage of Serverless is that it takes the burden of server management off your shoulders.

You don’t have to set up, maintain, or deploy servers. Instead, you get to focus entirely on writing your application logic, while the infrastructure is handled for you in the background.

Difference between Serverless and Non-Serverless

Imagine you're working as a backend developer. A large part of your job is building APIs — whether it’s RESTful or GraphQL-based.

You’ll typically write code that handles backend logic. This code could be written using any language or framework: Node.js, Python, Java, Spring Boot, Golang — whatever suits the project.

But once you’re done writing your code, it has to run somewhere — and that somewhere is a backend server.

In a traditional (non-serverless) setup, you're responsible for setting up that server, deploying your code to it, and keeping it running. The server is something you have to manage directly.

Let’s take an example of Amazon and understand.

Let me tell you this beforehand so that you won’t get confused, Serverless isn’t related to Amazon AWS or anything. It can be in any cloud provider. Microsoft also provides, Azure! For this example, we are taking AWS.

Let’s take AWS and spin a server inside it. In terms of AWS, we call it EC2. EC2 might sound scary to you right now but it’s just a service which provide virtual machine. Now we have to configure this virtual machine.

So let’s say, I figured out that my website doesn’t have much traffic as of now so I’ll be taking 2GB RAM with 500GB Storage.

Now will spin up the machine with the desired configuration which will execute our code in this particular machine.

Do you see any problem in this process? NO right!

What’s happening here is, that there is a server in this case and I am responsible for managing the server.

By managing the server I mean, how much RAM and storage has to be fed to the server, all of this is managed by me.

One more thing to notice here is that the charges here are based on per hour.

Assume Amazon is charging 0.02$ per hour. Thus, this machine will run 24 hours a day and 24 x 30 x 0.02 is my monthly cost.

💡 In a nutshell, here we have a server that is constantly running, whose configurations are handled by me and there is a certain amount of charge that has to be paid.

But what about up-scaling and down-scaling?

Let’s say during some months, huge traffic comes to my website. What will do in the case of Amazon will make some Auto Scaling Group (ACG).

Let me tell you ACG in layman's terms: It means that I’ll tell Amazon to give my EC2 instance 6GB RAM and 100GB Storage. Thus, for the time traffic will be high, the rate will automatically increase.

But the catch here is, on a minimum level who is managing the server?

It’s me who is managing the server. From scaling to code deployment, and configuration I’m managing all of it. Since it’s an EC2 machine, firstly we have to install NodeJS in it and then will have to install Linux and all of it.

Since we can say that, in a non-serverless architecture we have to take up a server, configure it, install an Operating System inside it, install all the libraries inside it, and take care of all the deployments, scaling up and scaling down is also my responsibility and billing is done per hour.

What happens in Serverless?

**
All you have to do is write the code. You don’t have to worry about the underlying infrastructure that’s running your code.

In terms of AWS, there is something known as AWS lambda.

What you have to do is to give your code to Amazon. Now Amazon will decide, what OS has to be given, how much RAM, and how much Storage has to be given? Your only concern will be to write the code.

The rest of the things like deployment, up-scaling, down-scaling, managing the underlying infrastructure, etc. all this is done by Amazon.

This particular thing is called serverless because you don’t actually have a server here. All you have is code and you’ve deployed it. All the management of the server is done by Amazon.

Now you might wonder what’s the benefit?

It took all the control away from me. The control to configure my machine the way I want.

But the difference lies here!

Let’s say I have a website and my backend is running on EC2, on a non-serverless architecture, and at this time my website has zero traffic on it.

Even though I have zero traffic but my servers are still running (24×7) to be able to serve user as they come.

But when we come to serverless, here billing is done in terms of invocation.

Let’s say the rate here is $0.001 per invocation. What happens here is the code isn’t running 24x7.

Suppose we have some code, and an API is attached to it. Initially, our code will be in SLEEP state and it’s not running. What happens here is, when a user comes and makes a request i.e. calls the API then only the serverless service will start my code.

At this time, it’s in the START state and then it will execute the code line by line and return its output as a response and it will again go back to the SLEEP state.

Whenever the user requests, the code is invoked, and it is from that invocation the billing is done i.e. in a month how many times it has been invoked.

The benefit here is that, if my website has zero traffic then I don’t have to pay even a single penny because at that time my website, server isn’t running at all.

Another important difference is in up-scaling and down-scaling.

Serverless can up-scale and down-scale on its own based on the traffic.

Suppose your site automatically gets 1000 users.

Now your single code cannot handle those 1000 users, thus what serverless will do is it will scale your system horizontally i.e. it will make multiple copies of your code so that it can cater to 1000 users and when the user traffic goes down it will get back to normal.

The other benefit is CDN. Serverless platforms help us run the same code in different regions so the latency is as low as possible, since the region that is selected is near the user.

This benefit is predominant as you don’t need to scale your system on its own!

Now let’s talk about why you should be interested as a developer in Serverless?

The idea is basically to run the backend code without having to update, create, and maintain a server.

Pros
The major benefits from a developer’s side (being able to build a full stack site without having to worry about other stuff!)

No server maintenance
No Provisioning: Enhances developer productivity and reduces operational costs by managing server tasks, enabling greater focus on app development.
No monitoring: Facilitates DevOps by eliminating the need for developers to specify infrastructure and streamline processes.
Low cost: Operational costs are minimized as cloud resources are paid for based on usage.
Low maintenance
Easy to scale.

Cons

Lack of control over server-side logic and infrastructure may limit flexibility and lead to vendor lock-in.
Cloud provider constraints can affect customization.
Switching providers may require system upgrades to adhere to new specifications.

By now, you must have had a clear idea of Serverless, from its meaning to working. In a nutshell, Serverless computing abstracts server management, allowing rapid, event-driven scalability and cost-efficient deployment, ideal for modern, dynamic applications.