Structuring a Web Application
Explore how to design and build a scalable web application structure using Deno. Understand key architectural principles, business logic development, and creating HTTP endpoints, preparing you to organize applications for growth and maintainability.
We'll cover the following...
Structure and scalability
When starting an application, it’s important that we spend some time thinking about its structure and architecture. That's where there this section will start: by looking at the backbone of application architecture. We’ll have a look at what advantages it brings and align ourselves with a set of principles that will help us scale it as the application grows.
Then, we’ll develop what will become the application’s first endpoint. However, first, we’ll start with the business logic. The persistency layer will follow, and we’ll finish by looking at an HTTP endpoint that will act as the application’s entry point.
Application architecture of Deno
When we’re using tools that are low level and delegate many decisions to developers, such as Node.js and Deno, structuring an application is one of the big challenges that arises.
This is very different compared to an opinionated web framework, such as PHP Symfony, Java SpringBoot, or Ruby on Rails, where many of these decisions are made for us.
Most of these decisions have something to do with code and folder structure. Those frameworks typically provide us with ways to deal with dependencies and imports and even provide some guidance regarding different application layers. Since we’re using the raw language with a few packages, we will take care of the structure ourselves in this course.
The frameworks mentioned above can’t be directly compared with Deno since they are frameworks built on top of languages, such as PHP, Java, and Ruby. But when we look at the JS world, namely at Node.js, we can observe that the most popular tools used to create HTTP servers are Express.js and Kao. These tend to be much lighter than the frameworks mentioned above, and even though there are also some solid complete alternatives, such as Nest.js or hapi.js, the Node.js community tends to prefer a library approach more than a framework one.
Even though these very popular libraries provide a good amount of functionality, many decisions are still delegated to developers. This isn’t the libraries’ fault, but more a community preference.
On the one hand, having direct access to these primitives lets us build applications that are very well-suited to our use cases. On the other hand, flexibility is a trade-off. Having a lot of flexibility comes with the responsibility of making numerous decisions. And when it comes to making many decisions, there are many opportunities to make bad decisions. The hard part is that these are normally decisions that drastically influence the way a code base scales, and that’s what gives them such importance.
In its current state, Deno and its community are following an approach that’s very similar to Node.js on this framework-versus-library subject. The community is mostly betting on light and small pieces of software that are created by developers to fit their specific needs. We’ll evaluate some of these later in this chapter.
Starting here and throughout this course, we’ll use an application structure that we believe offers great benefits for the use case at hand. However, don’t expect that structure and architecture to be a silver bullet because we’re pretty sure such things do not exist in the software world; every architecture will have to keep evolving as it grows.
Instead of just throwing in a recipe and following it, we want to become familiar with a way of thinking—a rationale. This should enable us to make correct decisions further down the road with one objective: writing code that is easy to change.
By writing code that is easy to change, we’re always ready to improve our application without much effort.
Purpose of an application
Applications are created to fit a purpose. It doesn’t matter if that purpose is to support a business or a simple pet project. We want it to do something. That something is what makes the application useful.
This might seem obvious, but it’s sometimes very easy for us, as developers, to get so enthusiastic about a technology that we forget that it’s just a means to an end.
As Uncle Bob, Robert C. Martin, says in his Architecture – the lost years talk, it’s very common for people to forget the application’s purpose and focus more on the technology itself. It’s very important that we remember this in all the phases of application development, but it’s even more critical when we’re setting up its initial structure. Next, we’ll discover the requirements for the application we’ll be building throughout the remainder of this course.
What is our application about?
Even though we truly believe that business logic is the most important thing in any application, in this course, the case is a little different. We’ll be creating an example application, but it will just be a means to reach the main goal: learning Deno.
However, because we want the process to be as real as possible, we want to have a clear objective in mind.
We’ll build an application that will let people create and interact with a list of museums. We can make this clearer by listing its features as user stories, as follows:
- The user is able to register and log in.
- The user is able to create a museum with a title, description, and location.
- The user can view a list of museums.
Throughout this journey, we’ll develop APIs and the logic to support those features.
Now that we’re familiar with the end goals, we can start thinking about how to structure the application.