The Beginnings
I’ve posted previously about this project and posted a link to the repository. And if you had seen it, you’d agree, it was pretty rough. It was all for my own use and there was no expectation of doing more with it. It was very stream of consciousness. The planning was to open a text editor and just write what I wanted it to do.
And it… worked. But as time moves on, the list of sets in it gets larger and larger. The page has more and more to load. So inevitably, things need to change.
Architect of My Own Sins
There’s a reason no one advocates for stream of consciousness development. It’s not tidy at all. All of the “front-end” stuff was basically slammed into a single HTML file. All the CSS and Javascript just inlined in the appropriate tags.
The back-end was a little better. Things were separated a bit. The services were located in one file, the scraper in another file, a common file between them to define the data model. But the service file still hit the database directly and I’m not even sure it’s actually using the model file.
Gotta Keep Them Separated
So I’ve begun teasing apart the pieces. I took the CSS and JS out of index.html and put them in their own folders. I’m planning on putting all of the back-end stuff in either a separate folder entirely, or as a subfolder of the main site folder. As a separate folder, it’ll keep the front-end stuff completely clear of the back-end stuff. As a subfolder, it’ll be contained, but it’ll still look like it’s part of the site. It feels more like an aesthetic choice at this point. But the choice I make here will probably how I make this choice for other similar projects.
Under the Hood
Then there’s the matter of the code itself. There’s a semblance of order to the chaos, but at the end of the day, apathy kind of won out. “This is for me and no one else will care” is a good way to get to “good enough”.
I’ve already started with the front-end portion. Like I’ve said, I’ve already broke out the CSS and JS. I’ve also added pagination to both the front and back ends. But this already is an issue. Because previously, all of the sorting and filtering was done on the front-end. The entire list was loaded, so there was no need to tap the service to do any of that. We could do it live.
So this is where I’m at. I’m now in the lego.py file, trying to think about what I’d do if I had known in advance what I was doing now. I’m going to break things and hopefully put them back together again.
The first bit I’m working on is here:
if __name__ == '__main__':
#Discover request being made
if 'REQUEST_METHOD' in os.environ:
if os.environ['REQUEST_METHOD'] == 'GET':
formdata = cgi.FieldStorage()
if 'action' in formdata and formdata['action'].value == 'check':
RunSingleRequest(formdata)
else:
RunGetRequest(formdata)
elif os.environ['REQUEST_METHOD'] == 'POST':
RunPostRequest(json.load(sys.stdin))
You can almost recreate the git log from this block. The first method was RunGetRequest, followed by RunPostRequest, and later I realized I wanted to do a third thing and added that as well. However, now we’ll be getting in several requests. We need to make this something a little not as haphazard.
Define is Fine
Basically, I need to define all the various actions and come up with a structure. Now, this is all very bare bones, so I’m not going to worry about getting this to be REST compliant. Yet? But we see on the sixth line of the code above where we have the GET request look for an “action” parameter. We’re going to just go with that. Expand that so that all of our requests come out to the format of { action: 'action', 'parameters': [] }. With POST, that’s easier, we can just pass it as JSON from the client. With GET, we’ll have to create the JSON from the query string.
Then once we have that, we can essentially process all requests in the same manner.
Same BatChannel
That’s about where things are at the moment. As things develop, I’ll put more of my thoughts down.