I am a passionate software developer who like complicated problems and creativity.
In almost any web application there is some set of values that are used on both backend and frontend parts. The typical case is REST API endpoints paths list which backend uses to route API requests and frontend uses to make backend API requests. Sometimes there are some user input validation values that are used at the same time in frontend and backend input validation. Or some other values like numerical ids, localization strings or even your Web-application name.
Of course it would be nice to set all double-used constants in one place only as it follows DRY principle and helps to avoid inconsistencies — for example when some of these values are changed only in one part of Web-application and do not meet the same value in its another part.
How can we share values between application parts? Well, there are different approaches. Shared values might be:
- Declared in one piece of code that is included in backend and frontend parts
- Placed in a shared configuration file
- Provided to frontend by a special backend API that returns shared value
Let’s review each of listed approaches in more detail.
Declaring constants in one piece of code for both parts
Sharing configuration file with constants values
It seems to be very similar to the previous approach but there are additional peculiarities here. Firstly, both parts of the application should be able to read configuration file format, for example, YAML. Secondly, the configuration file should be accessible for both application parts.
This requires placing the configuration file at some publicly accessible resource like application public assets folder. But it isn’t very clear architecture — why a YAML file is placed in assets with? It also increases potential attack area and requires additional code to parse configuration file
Backend constants API
Code generation approach
The injection of shared values in the frontend code variables scope can be done in a couple of ways:
- global shared values definitions — not the most elegant solution as those shared values constants will pollute the frontend global namespace
- put shared constants definitions into a global class — which is more elegant
- put shared constants definitions into a class and injecting it into the frontend with some kind of Dependency Injection technique — a bit overengineered implementation for my taste
- put some shared constants into a state management pattern stuff like Redux — seems to be the same idea as putting in a global class
On the other hand, code generation on Web-request is easier to implement as it is enough to have reflection mechanism in the programming languages used by backend in order to get shared constants values defined in some part of backend code. For example, I use this approach in my phpconst2js library and it works perfectly.
So we discussed different approaches to sharing constants between Web-application backend and frontend. And as often happens in engineering there is no ideal solution — each of those approaches has its pros and cons.
Create your free account to unlock your custom reading experience.