Back in the days, this is how web applications are usually designed. We have the typical web application instance that connects to the database directly.
Typical MVC (model-view-controller) structure where the model contains the business logic (SQL queries mostly) while the controller acts as the dispatcher to the view. Nothing wrong here really. However, in the long run, this will be troublesome when scaling. Let’s see what are the pros and cons of this.
Pros:
- Fast development and deployment
- Good for small projects
- Cheap setup
Cons:
- Web application instance will receive high amounts of traffic
- Hard to scale the instance
- Hard to maintain for complex applications
Just more on scalability and maintenance. What could go wrong, you say? A lot, actually. Here’s what I would recommend that could be a starter guide on how you would structure your web application setup.
As you can see, I assumed that my web application will have a mobile version of it. Well, not required but something to look into as well. Take note, this is not only pertaining to a mobile version as it could be another web application as well. Let’s look what makes this different from the previous setup.
Here, you’ll see that we have three (3) layers: Web App, API, Database. Basically, the API is where all your business logic (usually queries) would reside so the only function of you web application is to dispatch data from the API to your view. Why do the business layer needs to be separated from the web application? Simple, separation of concerns.
We want to allow each function to have their own functionality so they are not dependent on one another; inter-dependency. At the same time, the API instance could be scaled through the ELB (elastic load balancer). This will be handy if you have multiple web applications connecting to the API as you do not want that to get overloaded.
Pros:
- Scalable
- Easier to debug
- Can group teams to focus on either back-end development or front-end
Cons:
- Expensive
- Overkill for micro projects (Ex: blog sites)
- Complex setup and multiple deployment steps
With this structure, I would then use:
- Laravel for the web application back-end with a grain of VueJS on the front-end plus a spice of SAAS for the styling
- Lumen for the API service or another Laravel (though Lumen is more appropriate in this scenario as it is built for API use)
- MySQL for the database.
Bonus Point: You could also setup memcache for caching.
There you go, a typical architecture for building small-medium applications that’s scalable and easier to maintain compared to the old-school setup. Still using the old one for your project? Better think twice now.
