How to implement the perfect web application?

While doing research for our new startup ROQ Technology, we saw a lot of approaches to building web applications. Some of them worked well, and some of them did not. In this article, I want to summarize the best practices and then give you specific instructions on how to build the perfect web application.

So what is the best approach to building a great application?

According to my experience, you'll get clean and lightweight architecture when you

Let's go one by one 👇

Implement a monolith

Full-stack, monolithic applications are easier to understand and manage than ones where the front and backend are developed and deployed independently. And for sure, it's much easier to deal with compared to a service-based approach. Interestingly engineers sometimes find arguments against this lightweight approach. They may argue that it will be slow or difficult to handle large teams or that there is no separation of concerns. In practice, both arguments aren't relevant for most applications simply because there are no large teams and no super high complexity that requires a complex architecture. But what's relevant is that you can have fast development cycles.

The best way is to think of your web application as one thing. Of course, some code will run on the client side, and some will be executed on the server side, but it's still one single application.

One programming language

There is the old wisdom to always use the right tool for the right job. Forget it! Mixing multiple programming languages will add massive complexity to your application and significantly increase team-internal coordination efforts because single engineers won't be able to realize features end-to-end. In addition, you have to take care of the additional libraries and frameworks introduced by each language. Therefore one of the biggest drivers for increased productivity and clean architecture is to use only one programming language.

Mono-repository

You will naturally use only one repository if you use just one application implemented using one programming language. However, even if you decide to realize separate "frontend" and "backend" applications, you should still put them into the same repository.

Using multiple repositories introduces a lot of overhead to your IT organization. Features will be developed in several branches. Branches and PRs will span several repositories, resulting in mixed states and broken workflows. For this reason, I recommend using a mono-repository and utilizing tools like nx.dev to organize it, even if it takes some initial effort. That's one of the prices to pay if you decide to build multiple applications.

Don't be dogmatic

The three principles will work in most scenarios. Of course, you shouldn't apply them dogmatically. I recommend using them as your "default" approach and checking if there are good reasons to do it differently. For instance, when you build a web application and a mobile app, there is no point in making a single app and placing them into the same repository because of the different release cycles.

Two ways to start

I want to present two ways how to achieve the three principles pragmatically.

On the client side, there is only one programming language, Javascript. Therefore it's reasonable to use it for your entire web application. You can do so by using Next.js, which offers more than just adding server-side rendering and routes to React. It also has an /api endpoint, a built-in way to implement a Rest-API. The code is executed on the server side, and therefore it's a good place for business logic and querying databases using SQL. This approach won't suit complex applications, but most apps aren't that large. When all you need is a way to apply CRUD actions and some additional logic, this will get the job done. Of course, Next.js isn't the only way to satisfy all three principles using Javascript. There are other advanced frameworks like Meteor and Redwood. However, Next.js seems to be the most popular. Therefore, our open-source Kickstarter is based on Next.js (+ PrismaORM). It's a good starting point for your next project. Check it out on our Github here.

If your team is more familiar with server-side languages like PHP or Ruby, you can still build dynamic websites using an "HTML-over-the-wire approach". Hotwire enables developers to react to browser events solely on the server side. When a user interacts with the page, an event is sent to the server, which re-renders the necessary part of the page and sends the updated HTML back to the browser. The Javascript on the client side then uses this updated HTML to update the corresponding part of the page without refreshing the entire page.

Whatever approach you choose, in addition to the core technologies and architecture, you'll also need essential features like a smooth signup process, secure social login, real-time notifications, user interaction through chats, file sharing, and others. My company ROQ.tech provides all of this as fully-functional UI components and APIs. You can seamlessly integrate them in just hours. Feel free to contact me in our Community Slack. I am always looking for good discussions about web technologies.