The typical web application is built using a few different technologies to accomplish the goal of serving up a web page/application to a user. This process usually involves having client-side rendering code and a server-side logic processing, which allows for communication with a database or return data after intense calculations; something that would be very expensive to do client-side.
What Benefits Can You Expect?
This overlap of client and server brings with it a few new exciting possibilities when designing and implementing features and logic into the application.
One of the biggest is the idea of code reuse between client and server which allows for a reduction in logic redundancy that has been needed in the past. If you needed to have logic data validation on both the server and client-side to maintain the integrity of your application during a transaction, this can now be performed using the same code that is called from multiple places.
Being able to move the code between different sides of the app allows developers to optimize efficiency of functionality by giving them the ability to see which would be better for performance without having to write the same code twice and test it. Using this type of application architecture also provides the ability to easily use server side page rendering which, if used correctly, can increase the speed which the page loads compared to the client side DOM rendering that has been used previously.
What are the Drawbacks?
The main issue is the fact that this concept is relatively new. Because of the unfamiliarity, there may be negative aspects that have not been fully realized; but that is a potential danger in using any newer technology.
Another issue is that while being able to move code between the client and the server is interesting, it makes writing some of the logic difficult since it could be run on both. For example, if there is logic that needs to communicate with the database that used to typically only be viewed as server-side code, now this code could be executed on the client-side. That logic would need some tweaking since there would be issues like the client not having access to the node.js packages that allow for that communication.
A third, and important issue to keep in mind, is the visibility of data. This is because the server/client separation previously helped build a barrier. Exposing sensitive data is a real and growing problem in today’s world, and removing that barrier could make it easier for a developer to accidentally expose the client to data that they shouldn’t be able to access. While this architecture can be exciting to developers, be sure to assess the needs of your application to determine if these issues could be deal breakers.