Manually updated the database for tonight with a database browser for the sake of some progress. I managed to get the new network page, network detail page, and all networks table all working together. Here's a screenshot of my new network form.

This also lays the essential groundwork where I can start to track some IP allocations. At the very least, I want to track the gateway address, DHCP ranges, and static allocations. Then once I have the data, visualize it in a nice way.

I should be able to find Vuetify elements that can visualize and colorize this on the front end.

On the back end, I'll figure out some kind of relationship scheme for this that makes sense.

I'll probably go after the database schema update another day since there might be an idempotent way I can do it.

Without knowing if a tool exists for this, I can:

* read all tables
* for each table
* get the existing definition
* get the class definition from database.py
* add columns as needed

Got that all figured out and now I have two more things on the short-term list, both related to each other.

1, how to return better error codes from API calls
2, how to update a schema in place by adding more columns

I know for 2 I can delete the whole DB file and then it will recreate, but I'd like to preserve the data that's in there. This will only be more important over time as the amount of data grows.

Surely there's a way to detect changes in the schema from database.py and update it. Ref: https://github.com/alongchamps/rack-root/blob/main/backend/database.py

Me: copies code from the new Item page that I posted about recently into the new Networks page.

Also me: why isn't the "Add New Network" button submitting the form and POSTing to the backend like it should?

Also me: tries to make a new Item entry and that also does not POST to the backend, it just does noting.

Well, it did what I (accidentally) told it to do: nothing. Looks like I need to move the Submit button into the form itself to get it to work.

This is why constant testing is essential for this project!

Writing some of the IPAM implementation is probably going to be the hardest part of this project so far, and I haven't even gotten to the device <-> network relationship(s) yet.

So far in my IPAM code, I have checks for invalid IP ranges and uniqueness, though I'm sure I'm also missing some corner cases.

Then on the front end side, I plan to visualize network usage which can include assigned static IPs, DHCP ranges, gateway/router designations, etc.

I'm hoping that coding it as I go through the frontend and backend will help me properly structure everything, figure out which relationships I need to pull in, and establish the design for my API.

I'm also very happy that I have pytest tests to go with my code. I'm writing those every time I add a new section and it pays off.

Ever look at a word for so long it looks misspelled? That's me and the word 'subnet' right now. This should make programming fun.

The goal for Rack Root is to inventory my home lab and learn some web dev (FE+BE) along the way. I'm now at the point where I think I'll have the biggest challenge: IPAM / networking data.

I'm anticipating that this part will be the most complex because of all the relationships. This is also going to test my API and database design skills, to say nothing of the front end design.

At the start, I'm going to need a good IPv4 address handler library, ways to CRUD network segments, CRUD DHCP ranges, assign static IPs to devices, and similar.

I also will have the data to generate visualizations of IP address usage, and plan to do that at some point.

I fully expect to take advantage of things like Vuetify 3's v-card element which should help with some nifty graphical layouts.

Finished the NewItem.vue page for now with a better layout, date pickers for purchase date and warranty expiration, and a placeholder for devices on the network.

My next plan is to start designing the networking piece of Rack Root and figure out which pieces I'll need to put in place. This will include the network zone, DHCP ranges, and subnet mask info. Devices on the network can be DHCP or static which is data I plan to track.

Items will have the ability to use 0..n network interfaces which accounts for things not on the network such as hard drives, single-NIC devices such as laptops, and multi-NIC devices such as network devices. All of that can go into the database.

By the time it's done, I should have the data to generate a pretty good picture of the network layout such as DHCP range utilization and IP utilization. Somewhere along the way I'll need to figure out subnet math, too. Yay.

Now to the new item functionality.

First screenshot shows a summary of test values in the table, and the date is formatted on the frontend so it looks the way I want.

Second screenshot shows the new item page which is definitely still a work in progress. I have a lot of functionality to add to this one, and figure out what layout I want to use for it. I'm using things like v-field, v-textarea, and v-date-picker for these elements. The buttons are of course using v-btn.

The last screenshot shows the item detail page and this design is definitely not final. I'm not even showing the notes or descriptions fields in this view. I really should sketch out some things I want to do in order to use this the way I want.

And now for some screenshots.

First screenshot shows the landing page with basic summaries.

Second screenshot shows the new device type tab on the settings page.

Third screenshot shows another tab I setup for export/import functionality. That one will be interesting to write, for sure.

Well, it's been a month or so since I've posted so here's what I've changed/learned about.

It was easier for me to use DateTime than Date, even if I just want to hold a Date field. I also started to really build out some of the more dynamic functionality.

Device types can now be defined on the setting page, tab 1 and I'm using a modal textbox that pops up when you go to add a new item. All that needs is a name so a model makes a lot of sense for that.

When making a new item, the device types are pulled over dynamically and displayed as human-friendly names in a drop down. In the code and going to the back end, it's all using the ID. This field is also nullable in case the device type gets deleted, it won't throw as many exceptions.

I also wrote up the item detail page, though both the new item page and item detail page tell me that I need better UX design / more layout experience. This stuff isn't easy!

Finally on the design side of things, I've added a couple dynamic boxes to the landing page that show how many items and device types are defined. This is another part of the site I'll work to design more as I go.

I'm sure I will find something that looks good and functions the way I want – I just need to get there. And I can tell by where I am now that this project will keep me busy for as long as I want it to.

Finally got the foreign key relationship working between a single inventory item and the device types table! I had some of the right code with relationship() but I have to give @bignose the credit for pointing me in the right direction. In the Pydantic data model, for an ItemResponse, you tell it that the field deviceType is of type DeviceResponse.

SQL Alchemy then will do a join for you as long as you put .join(DeviceType) on your query and populate the deviceType field with a JSON representation of the row.

Then you can pass that data to the Vue front end, tell it to render deviceType.name, and it will pull that out of the JSON response.

The image below with JSON in it was provided by Carbon. I'm surprised they didn't put any kind of credit/logo/"Generated with" message on there.

Another 50 lines of code and now I have a new device dialog box that will pop up, ask for the name, and behave as expected. Submitting the form will send the data to the backend to make the device type. Clicking outside the dialog or cancel will make the dialog go away.

I also discovered that the field will retain the data that's in it, until it's cleared. I chose to only do this on submission and handled it in the javascript.

This update also gave me some practice with the v-model functionality in Vue where it goes between the HTML <template> tags and javascript contexts.

I appreciate that with Vue/Vuetify, I'm able to do that whole Settings page dynamically and I did this in under 50 lines of code. Of course I'm heavily relying on imports and all the libraries underneath, but this just makes it so easy once you know how things work and which levers to pull in order to adjust appearance.

I was able to work on this layout and even add tabs to it in just a couple of hours.

Tonight's short update - I added a new table to the database to store device types, associated HTTP GET all device types, HTTP POST create device type, and a settings page in the app with tabs to view the device types.

This gave me more practice in laying out pages in Vue/Vuetify, using classes to control the layout, height, width, etc.

My next update has to be more focused on the backend and testing since I don't have that many tests going on there now.

Below is a screenshot of the table as it stands now and I'll link to the frontend in my latest commit here: https://github.com/alongchamps/rack-root/blob/main/frontend/src/pages/Settings.vue

One last update: I added icons to make the navigation bar slightly better than plain-text. Here's the all items page showing the one record in the database:

So far, I've made the navigation bar, imported that to all the pages, made a home page, made a page to show all inventory item detail, and when you click a row in the item table, it takes you to the detail page.

I also added a default route for a 404 and worked to make my paths in the URL consistent between the frontend and backend.

Next up will be writing more of the backend code to delete an inventory item, editing an inventory item, and defining more of the back end types that I need.

I will probably start poking around with relating tables together by making a 'device types' table and associating that field in the 'inventory' table over to the 'device type' table.

Then I can make a settings page where I show all of those device types and give the user options to manipulate them. This /feels/ like it belongs in a settings page of some kind, but I suppose I could make a case that it needs its own path in the navigation just like /items.

I finally have a functional foundation on which to build the front end for Rack Root. For some reason when I was working on it the past few days, the front end code was not cooperating. I reinitialized the project, copied in my existing (previously functional files) and the frontend would just complain about invalid javascript.

According to Visual Studio Code, everything looked good. I copied the relevant javascript out and it still looked good, no syntax errors. According to my console, there was a javascript error at the end of the </script> tag in the .vue file.

Whatever it was, I re-typed the relevant bits/pieces of my code, checked everything incrementally along the way, and got it back to working again.

Now I can start to write more of the back end code, get it all tested, write the front end to go with it, and so on. Repeat until 'done' ;)