Build Out The Backend Code
The final step after the database data structures are in place is to write the code to connect the frontend HTML with the backend database. There are usually a lot of debates over which language and framework to use (a framework is basically prepackaged code that is expecting the app code to be in a certain structure). Going into details about the various frameworks available is outside the scope of this post. I typically recommend using something as simple as possible.
Out of all the different languages used for backend programming, I think PHP is probably one of the more beginner-friendly languages. I'm using a custom PHP framework I've developed called MAVOC. It is what is called an MVC (model View Controller) framework. What that means is the code typically flows in a specific pattern.
For MVC frameworks, the code flow usually starts with a routing list, the routing list then indicates that the code should load a specific Controller. The Controller helps "control" what is sent back to the browser. The Controller will usually load a Model. The Model is often used to pull data from another source like a database. The Model allows the data from the database to be in a format that can be easily used in the code. The last step of the Controller is to select a specfic View to use in the browser. The View is basically a template that takes all the data passed to it and outputs the final HTML displayed by the browser.
When you load a URL address, like this blog post page, the first thing that happens is the code figures out which route (or path through the codebase) to take. You can see all the different routes (website pages and website endpoints) available by looking at the routing list: app/settings/routes/web.php
On the web routes page, you'll notice that their is an entry for blog/{slug} and it points to the BlogController post method. When a user loads the web page, the code looks at the routing list and then it figures out which controller method to use. The {slug} value is a dynamic value which can change. Each blog post has a different slug, so the code passes the {slug} value, when loading this blog post. The slug value for the very first post is getting-started. The code then proceeds to the BlogController and passes that slug info. The BlogController can be found here: app/controllers/BlogController.php
If you look at the post function (also called a method), you'll see that it is making use of the Blog model. Normally a model loads data from a database but models can also load data from other sources. In this example, the code is using the Blog::get method to load the markdown file based on the slug. You can find the Blog model here: app/models/Blog.php
The get function in that model is specifically looking for the markdown file that matches the slug. It find a matching markdown file for getting-started in the blog directory: storage/markdown/blog/2022-12-13_getting-started.md
Once the BlogController has the data it needs, the last step is passing that data to the view that is then displayed to the user in the browser. The BlogController post method returns the data which is then passed to the blog post view. By default, the views will match the controller methods.
PHP started off as a templating language (basically a way to take data and dynamically create an HTML file). It has grown significantly from its original roots but it still works well as a templating language. The data from the controller is passed to the view which is basically just a template to output HTML. If you understand basic HTML, then the view file should look familiar. In the middle of the view file, you can see that it is taking the content it received from the Blog model and it outputting it: app/views/blog/post.php
As you can see, when a user loads a page, the code follows the following route: route list -> controller -> model -> controller -> view. Each of the hardcoded HTML that we created earlier needs to be turned into a route and that HTML needs to be converted from hardcoded HTML to a dynamic template.
There is obviously a lot more involved in creating the backend code but creating routes, controllers, models, and views is basically what is involved. It can be a bit tedious at times and you may also run into issues where when you were thinking through everything from a hardcoded perspective, you realize you have to make adjustments when using real data.
If you want to learn more, I think the best step is to actually try it yourself. Try to load FeedRiv on your own server and see how it works. If you have any questiosn or run into any problems, don't hesitate to reach out.