Design Patterns in Javascript: Facade
When designing an application, is often the case that we have complex procedures to do a specific business task. For example, we may have to fetch data from the database, treat it and show it on the front end. In a general case, we can map some common steps:
- Get the input needed to query the database, for example, an ID;
- Create the specific query for this data;
- Treat the data to match our model;
- Handle any errors or wrong input;
As a developer, we care about how we do these steps and how we handle this data, right? Not always. When working with big systems, it’s difficult to look at big parts of the system all at once. It’s a good practice to handle our project with layers of complexity so that common operations are easier to do with small adaptations. That’s where the facade design pattern enters. The facade will serve as an interface simplifier.
In this article, we’ll see how to implement the Facade pattern in javascript, in order to create a layer between our HTTP calls/data handling and our layout.
Building our facade
We’ll use this public API to build our facade. It's a simple public API, great for testing small implementations.
In this case, how the consumed API works matters a lot to our facade. We have no way of directly querying user information along with posts, so our facade will be responsible to create a layer between getting all needed information (user + todos) and our layout.
In this case, we’ll create a class to hold our facade service, and it’s gonna have three methods: One to fetch the user, the other the todos, and the last to join both pieces of information.
Handling the HTTP calls
When getting a user information, from our facade perspective, we just care about two things: giving in an ID for the user and getting back that user. Plain and simple. But the request can go wrong, the user could not exist, we have to parse the response, and so on. These steps in this scenario should be handled by our facade.
Here, we create a method getUser that uses the id, handles errors generically, and treat the data by returning only the email and name from the response.
Getting the todos should be similar to getting the user.
Now for the full user information, using the getFullUser method. We can join our previous methods, use some synthetic sugar with destructuring assignment, and voilá!
Now this facade can be used to populate our HTML with our information. Since this is not an article on how to manage state, or how to build a view, I’ll lay out a simple demonstration, but feel free to expand this!
Wrap up
As with all design patterns, the value of the facade depends on the application and situation you’re working. A design pattern is situational and should be applied with a reason behind it, not as a default for every project.
A facade in a system that doesn’t require it just becomes another step in doing an operation and thus becomes a nuisance, bureaucracy. A facade is also not recommended in systems with high customization needs. If most of the time you’re trying to adapt your needs to the facade, the facade is not doing its work.
In a complex system, for example, a video converter, a facade is a great tool to simplify work for new developers, and lay patterns in the project. As a developer that wishes to build an implementation to convert a video for a GIF, for example, we don’t care about encoding, file size, bitrate, and other stuff. The important is the input video and the output GIF. There’s also the benefit of reducing the dependency tree, that is, by aggregating all needed code dependencies in the facade and using the facade to do these operations, complexity is lower.
Links
Follow me on medium: https://medium.com/@dgramaciotti
Linkedin: https://www.linkedin.com/in/daniel-guedes-79a05a176/
GitHub: https://github.com/dgramaciotti
Have you liked this article? Give it a like and share it on social networks!
