Hypothetically, consider a social photo platform - each pic gets its own url, this page contains the image, text about the image, buttons for the user to click, related pics, and some user-specific elements (maybe notifications, etc.).
There are different ways of going about the frontend. In each case, elements specific to the logged-in-user and the related images get fetched via api calls and are rendered client side.
For rendering the rest of the page -
1. Everything is rendered client side - one can use a single page application to handle the routing. The page structure stays the same, and new image uri's and the associated content are fetched via api calls.
SEO is a priority, so pure client side rendering is suboptimal.
2. Server side rendering for each page with NextJS or even Express is another option.
3. Another way is to do a static export in something like NextJS - which will generate separate html files for each image.
4. Now my thought is to skip all of that and go old school with sed/awk. We'll have a template file with all the styling elements and placeholders for the image uri and its description, etc. Then a script iterates through a list of values (queried from a database) specific to each image (img source URIs, description text, etc.) and uses sed to replace the placeholders in the template file and output a separate html file.
Each file has the same javascript to load the user-specific components.
Every time someone adds a new image, the script runs with the uri of the image and the description, etc. as the variables passed to it, and adds a new html file in a flat file structure.
These "variables" are stored in a database. So whenever we change the "design" of the page, we repeat the same process again - regenerate each html file.
The flat file structure will run into limitations, which is solvable with a directory structure. Nginx remains performant with large numbers of files.
Right now, we use NextJS with a mix of server side rendering and static pages, so it is all good. But I have been wondering about achieving something similar with more rudimentary (and performant) tools.
There's not too much additional work involved - templatizing the html file is straightforward, and this won't be difficult to script.
What's good and bad about this?
There are different ways of going about the frontend. In each case, elements specific to the logged-in-user and the related images get fetched via api calls and are rendered client side.
For rendering the rest of the page -
1. Everything is rendered client side - one can use a single page application to handle the routing. The page structure stays the same, and new image uri's and the associated content are fetched via api calls.
SEO is a priority, so pure client side rendering is suboptimal.
2. Server side rendering for each page with NextJS or even Express is another option.
3. Another way is to do a static export in something like NextJS - which will generate separate html files for each image.
4. Now my thought is to skip all of that and go old school with sed/awk. We'll have a template file with all the styling elements and placeholders for the image uri and its description, etc. Then a script iterates through a list of values (queried from a database) specific to each image (img source URIs, description text, etc.) and uses sed to replace the placeholders in the template file and output a separate html file.
Each file has the same javascript to load the user-specific components.
Every time someone adds a new image, the script runs with the uri of the image and the description, etc. as the variables passed to it, and adds a new html file in a flat file structure.
These "variables" are stored in a database. So whenever we change the "design" of the page, we repeat the same process again - regenerate each html file.
The flat file structure will run into limitations, which is solvable with a directory structure. Nginx remains performant with large numbers of files.
Right now, we use NextJS with a mix of server side rendering and static pages, so it is all good. But I have been wondering about achieving something similar with more rudimentary (and performant) tools.
There's not too much additional work involved - templatizing the html file is straightforward, and this won't be difficult to script.
What's good and bad about this?