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.

There are many different databases to choose from. At some point I would like to use SQLite as the underlying database but for now, I typically use MySQL. I've been working with MySQL for years and I'm very comfortable using it (I'm not in any way an expert, but I know enough to get work done).

There are many different ways to structure a database but I typically think about how the data is going to be used and then figure out what would be the most obvious way to group that data.

A database table is basically a group of data. The web framework I'm building comes with three tables already setup:

• Users
• Password Resets
• Usernames

Generally, when I'm create a database table, I will always include an id column, a created_at column, and an updated_at column. If the column ends in _at, then it is a datetime field.

If a columns ends in _int2 that means the decimal place has been shifted two places to the right so that the data can be saved as an integer. When using that data, the value will need to be divided by 100 to shift it back to the original value. It is simpler to run math operations on integers than to deal with floating point math. I haven't seen anyone else use the _int2 suffix. It is just something I've found helpful. If the data I was using needed three decimal places, I would save it with a suffix of _int3. That last number indicates how many places the number has been shifted.

You generally want to add indexes to a database to speed up the responses, especially when there is a lot of data. There are generally pretty obvious places for adding indexes (like on the relationship ids), however when I'm starting out with a new project, I usually prefer not to add any indexes and only add them as the need arises (when the responses for certain queries start to slow down).

Here is a breakdown of the initial tables built by the system:

Users

• id
• name
• email
• password (hashed)
• data (for any extra data that needs to be saved)
• encrypted (indicates whether or not encryption is being used when saving data)
• created_at
• updated_at

Password Resets

• id
• user_id
• token
• created_ip (the IP that requested the password reset)
• used_ip (the IP that completed the password reset)
• used (whether or not the password reset has been completed)
• expires_at
• created_at
• updated_at

Usernames

• id
• user_id
• name
• primary
• created_at
• updated_at

The tables listed above are the starting point. After examining the HTML pages and the data I'm going to need, I've come up with the following database tables that I need to create:

• Settings
• Categories
• Shared Feeds
• Shared Items
• Feeds
• Items
• Tags
• Colors
• Items Tags
• Auto Ratings
• Default Tags
• Default Colors

Here is a breakdown of how each of those tables are going to be structured in the database:

Settings

• id
• user_id
• name
• key
• value
• editable
• created_at
• updated_at

Categories

• id
• user_id
• parent_id
• name
• show_tags
• show_ratings
• show_colors
• save_ratings
• sort_order
• created_at
• updated_at

Shared Feeds

• id
• real_url
• last_updated_at
• created_at
• updated_at

Shared Items

• id
• shared_feed_id
• title
• url
• description
• type
• published_at
• created_at
• updated_at

Feeds

• id
• user_id
• category_id
• shared_feed_id
• original_url
• real_url
• title
• last_updated_at
• created_at
• updated_at

Items

• id
• user_id
• feed_id
• shared_item_id
• auto_rating_int2
• rating
• archived
• status
• published_at
• created_at
• updated_at

Tags

• id
• user_id
• category_id
• name
• created_at
• updated_at

Colors

• id
• user_id
• category_id
• score
• color
• created_at
• updated_at

Items Tags

• id
• item_id
• tag_id
• created_at
• updated_at

Auto Ratings

• id
• category_id
• word
• use_count
• sum_score
• avg_score_int2
• locked_score_int2
• locked
• created_at
• updated_at

Default Tags

• id
• user_id
• name
• created_at
• updated_at

Default Colors

• id
• user_id
• score
• color
• created_at
• updated_at

If you take a look at the Github repository, you'll see that I've added a migration for each of those tables. A database migration is just a file that tells the database what tables or data needs to be added or set up.

Setting up the database structures is one of the most important parts of building an app so now that we have that in place, the next focus is going to be on connecting everything together.

The design that I created for the site is pretty basic, but it focuses on making everything simple and easy to use. It basically consists of a header with a drop shadow, sidebars, and then important content raised up with drop shadows. The typography is just using the built in sans-serif font of the browser. I prefer to use standard fonts to minimize loading times. The font styling itself could definitely be improved but it is functional in its current form.

I tried to keep the interactive elements within CSS as much as possible. For example, the star rating system and tagging system both use checkboxes, labels, and CSS to achieve the custom styling. The mobile menu and refresh/archive modals uses simple javascript to turn HTML classes on and off. It uses a little javascript but tries to keep it as minimal as possible. There are also some CSS animations that will be used for when AJAX calls are processing that are not currently visible on these design pages.

Below is a list of each of the pages with a link to their hardcoded HTML pages and then next to those links are the styled pages which link to the styled version of the same HTML pages (a few minor HTML changes have been made from the original HTML to make certain items easier to style). The design pages should work both on desktop and mobile devices.

• Main Feed Page: HTML | Styled
• Categories List Page: HTML | Styled
• Add Category Page: HTML | Styled
• Edit Category Page: HTML | Styled
• Edit Color Page: HTML | Styled
• Add Feed Page: HTML | Styled
• Edit Feed Page: HTML | Styled
• Add Tag Page: HTML | Styled
• Edit Tag Page: HTML | Styled
• Add Word Page: HTML | Styled
• Edit Word Page: HTML | Styled
• Settings Page: HTML | Styled
• Settings Add Tag Page: HTML | Styled
• Settings Edit Tag Page: HTML | Styled
• Settings Color Edit Page: HTML | Styled

Now that the design is in place, the next step is to figure out the data structure for the app and build out the database. The building of the data structure for the app will be covered in the next post.

Each of the pages mentioned in the previous post need to become an actual web page. I like to first create the HTML for these pages without having to think about the data and server behind these pages. So when writing the HTML, I "hardcode" the data in these initial page designs, meaning I fake the data for the initial pages so that I can see how it will look.

I also write the HTML without the design in mind. The HTML should be clear and use the most logical tags. Later the HTML may get some minor adjustments to make it easier to implement the CSS but the main goal right now is just to get the HTML written with fake data.

Normally I would build these hardcoded HTML pages in the same location on the site where they will be used and would eventually just switch out the hardcoded fake data with the real data. Because I'm documenting how I'm building this site publicly, I figured I would build the hardcoded HTML pages in a separate location so that they can be fully accessible to anybody reading this blog article in the future.

Below is a list of each of the pages (these pages were originally drawn out on paper) with a link to their hardcoded HTML pages (note that at this stage, the pages will be very ugly).

• Main Feed Page: HTML
• Categories List Page: HTML
• Add Category Page: HTML
• Edit Category Page: HTML
• Edit Color Page: HTML
• Add Feed Page: HTML
• Edit Feed Page: HTML
• Add Tag Page: HTML
• Edit Tag Page: HTML
• Add Word Page: HTML
• Edit Word Page: HTML
• Settings Page: HTML
• Settings Add Tag Page: HTML
• Settings Edit Tag Page: HTML
• Settings Color Edit Page: HTML

Now that the HTML is in place, the next step is adding styling to the pages so that they start to look like an actual app. The design stage will be covered in the next post.

The initial page was fairly messy before I realized I wanted to blog about this process.

The last two pages I tried to draw everything a little cleaner since I knew I would be adding them to this blog post but even those started to get messy.

Usually, when I'm drawing my initial pages and notes, they look a lot like that first page (a lot more messy with notes all over the pages that only I can read).

Now that I have the pages outlined, the next step is to start the process of converting those to code. In my next post, I'll discuss the step of turning these drawings into HTML code.

If you are not familiar with RSS, it is a way to distribute content to your users. For example, this blog has an RSS feed located here: https://www.feedriv.com/rss. If you click on that, it will just look like code but if you copy that link to a feed reader, then you would be able to see the contents of this blog inside your feed reader and you would never need to actually visit this blog.

An easy way to think of RSS is that it is like email for news, media, or any other content that you want to stay updated on. When you check your email, you go to your email inbox and see all the different emails that people have sent you. With a feed reader, you open it up and see all the different content that you have subscribed to.

Although RSS for text is not as popular today as it used to be, one area that has significantly grown in popularity are podcasts. Podcasts are built on top of RSS feeds. Anytime you subscribe to a podcast in your podcast app, you are actually subscribing to an RSS feed.

As a freelance developer, I have often made use of RSS to track potential opportunities. Back when Craigslist was a popular place to post contract jobs, I would subscribe to the Craigslist RSS feed for every major city in the United States filtered for contract jobs. Whenever I had availability in my schedule, I would just open my feed reader and quickly see what opportunities were available.

Eventually Craigslist lost its prominence as a place to post contract jobs and I moved on to other job boards. Eventually, I started using Upwork which allows you to generate an RSS feed off of their job list (you can narrow the RSS feed down to specific search terms and filter criteria).

With Google Reader shut down, I could never find a feed reader that I was fully happy with so to track Upwork jobs I ended up creating my own custom feed reader (it was very ugly and very minimal stripped down for my usage). However, I built a number of helpful features that really gave me an advantage in looking for jobs. I built an automated rating system that would give a rating for each job based off my past ratings. Jobs would be highlighted in green, yellow, or red depending on how I had rated similar jobs in the past.

It also allowed me to track each job that I was bidding on. It was like a feed reader and a CRM (customer relationship management) tool combined together. I could track the status of each of my project bids in my feed reader.

I eventually needed to use the server where I built this tool for something else (and I wasn't using it because my schedule was packed with work). The idea for FeedRiv is to rebuild that tool but make it more user friendly for anyone to use it.

For the first two startups of the challenge (NumbersQ and TwitRiv), I built them privately and then released everything publicly when they were ready. I wanted to do something different for FeedRiv and fully build it in public. Meaning anybody who wanted to could follow along as I build the site and document everything I'm doing.

Depending on when you are reading this, the site might be a mess because it is in the middle of development or it might be fully launched and operating. I will be updating the code on the live production site so during the initial development stage, any part of the site could break or change. Once everything is fully launched, I'll move back to a more traditional development style where initial updates will use a development server.

These blog posts will mostly be quick updates so there won't be a lot of polish or editing going on (they may contain typos, grammar mistakes, etc.). The main goal is to document and share a running list of updates that are happening with the site.

If you have any questions, suggestions, concerns, or feedback, feel free to get in touch with me on my Anthony Graddy Twitter account or by using the DashboardQ support system.

To create a new blog post, simply add a new file to the /storage/markdown/blog directory. The file name should follow a simple format: YYYY-MM-DD_blog-post-titlel.md. The format starts with the date first (YYYY-MM-DD), then an underscore, followed by the title in lowercase with spaces replaced by dashes, and then finally ending with the markdown extension (.md). For example, the file for this blog post is located at /storage/markdown/blog/2022-12-13_getting-started.md.

You can have a draft blog post by starting the filename with an underscore. For example, there is a draft blog post located at /storage/markdown/blog/_2022-12-13_draft-example.md.