In our previous article about K(L)IEN architecture, you read about the N-layered approach Kien follows when developing software. In this article we would like to go a little more in depth with you about the User Interface layer.
The User Interface is that which the end user gets to see. Originally this layer did not contain any logic or calculations and was just a visual representation of the data returned by the server. All heavy lifting was done on a powerful server. However, the problem with this is that even if you have a powerful server, when 1.000 users request something from that server at the same time, the application would still be slowed down to a snail pace. It is therefore better to do some of that lifting at the client side, which will result in the work being distributed on many computers instead of just one powerful server. This will give us a more smoothly running application.
For example, you would like to let the user convert a date to a week number. You could send the date to the server, let it determine the week number and then sent it back where it is displayed to the user. But you could also just calculate the number at the client side, which makes it easier for the server. All (final) data validations and database operations should still be done at the server, but the smaller operations can easily be done at the client side. The downside to this is that the client’s computer needs to be a little more powerful, but nowadays this should not be an issue anymore.
Because of this, the User Interface is not a simple interface layer anymore, but an application on its own. Therefore, we would like to separate the code there from our interface as well. By doing this we could reuse the code for a view that is made for a browser and a different view made for an Android app, for example.
There are several frameworks that support this. At Kien we have chosen to use Angular (not to be confused with AngularJs).
Angular is a front-end framework developed by Google. This framework separates the code into modules. Each module can have several components that each have a view (template). Communication with the server is handled with services, so generally a module has one or more services that are used by the components. The beauty of this setup is that it is easy to reuse parts and if you work in a team, each team member can focus on its own module or component.
For example, most projects need a user system. In Angular you would develop a module for this that can be easily reused for multiple projects. You would end up with a UserModule. That module would have several components, like a “login”, “registration” and “management” component. Each of these components implements the necessary logic for these views and a reference to a template to display this. There would also be a user service in which a login, registration and CRUD (Create, Read, Update, Delete) calls are implemented that communicate with the server. Each component would then have access to this service and can use the correct call.
In short, Angular provides Kien with:
Scalability: Angular is high performant for all sizes of usages and the code is easy maintainable by a few programmers or for huge teams.
Reusability: by developing in components it is easy to reuse components in different projects or even within the same project.
Flexibility: because each component/module is a project on its own, the code is quite flexible. Changes can easily be made without breaking the entire application. By separating the view we can also easily create different views for different platforms, without redeveloping the underlying code.
Structure: it is a clearly defined structure which will result in a more unified code structure. This in turn results in an easier maintainable code base.