GunplaHub Update #1 - Intro, Technical Decisions, What's Next

Gunplahub is a free price tracker for model kits called Gunpla.

PS: I plan on making parts of this project open source, except for data (users, action figures, etc).

PPS: This project will be referred to as GunplaHub.

Table of Contents

1) (Current) Intro, Technical Decisions

2) Slugs, Obfuscated Primary Keys

3) Deployment and Serving Images

4) Refactor and Document Often

5) Automation and SEO

Planned Initial Release Features

1) Display Action Figures (/toys/, /toys/:id/)

2) Display Shows/Movies that included these Action Figures (/shows/ /shows/:id/, /shows/:id/toys/)

3) Display Historical Prices (toys/:id/prices)

4) Link these Action Figures to their respective Amazon pages

Technical Decisions

Flask vs. Django

I have experience with Python and a bit of Flask. I find Flask to be good for quick and dirty prototyping-- I was able to serve a .json response of sample data with ~20 lines of code. My first prototype didn't even use a database, it was all static data.

If this was a simple project with a small number of users, with no need for authentication, no mobile clients, no testing, and minimal concern for code organization, Flask would have been ok. For the initial release, the app is just supposed to do is serve some action figure data and query/display action figures that appear in a certain show. Surely, Flask would have been enough!

If I needed to add more functionality, Flask had a bunch of modules available that I could just plug into the project.

I tried going that route, but I realized that I will end up turning Flask into Django. Django has most of the stuff I need baked in already! It would be counter productive to spend time building a framework on top of Flask. I want to spend more time building this app. I also want to get the job done, and done the right way.

I dislike that Flask doesn't suggest me a way to organize my code when I create a project. Surely some Googling would have fixed this problem, but I don't want to spend time on that.

It was evident that a framework that had "batteries included" would be best suited for a project of this complexity. I will be needing authentication (client & user), an easy admin interface, complex permission handling, and a more rigid code organization standard. For these reasons, I chose to start this project with Django.

It's kinda crazy: I feel like I barely wrote any code for this project, most of what I've done is just hooking up different components together.

Web App vs. API

I could have made a web app prototype using Django, ship a beta web app to see out what people think, and be done with the project.

If I went the web app route (pun unintended?), I could just plug in Django Rest Framework, and copy my models over later.

But where's the fun in that?!

Eventually, I want this project to be available on mobile. I also thought it would be easier to just focus on the API for now and think about the frontend later.

I have no regrets designing my API first. I learned a lot about REST, what makes an API RESTful, HTTP requests, and different types of authentication. These are things I use in my day job so I knew a bit about them, but I never felt like I really knew them until I started working on this project.

Django Rest Framework made it easy to implement an API that follows best practices.

Test now vs. Test later

This isn't a startup, but this is a serious project. I'm trying to get this project out as soon as possible, but I'm not afraid of spending a little more time making this project more fun to work with. I'm the only developer (for now), and I don't want to stress about accidentally changing functionality whenever I write code.

I have some tests in place. These tests make sure that I'm serving the correct data (testing an expected response vs. what the consumer of the API receives). During the late nights I worked on this project, tests have served me well by failing when I accidentally ruin something.

Why Did These Simple Features Take So Much Time?

1) I don't want to just build an app for the sake of building one: I want to do things the same way I'd do if this were my day job. That way I could make sure I'm making a product that's grounded on good engineering practices. I'm proud to have setup proper version control, well organized code, and tests on this semi-ambitious project.

2) Prioritizing features is hard! I had a longer list of features I wanted for the initial release, but it would probably take me forever to do all of it before I do a release! It would be amazing to get feedback right away and maybe change priorities once I learn more about my users.

3) I spent time writing features that aren't for the initial release. A lot of my effort was spent on learning about different ways of authenticating REST APIs, reading popular APIs to get a grasp of what's good/bad (ex: I find Instagram's API to be very intuitive to consume), getting OAuth2 to play well with Django (I played with the wrong modules for a long time.. but it's a piece of cake with django-oauth-toolkit).

4) Some data had to be manipulated and massaged manually. There are 800+ rows in my database; a sizable number, but it's a one-off task. About 1-3 new action figures are released every other month, so maintaining this list wouldn't be too bad.

What's Next?

I have features #1 and #2 ready to go. I still have to get to feature #3. I'm thinking about an elegant way of doing feature #4, but I might just resort to looking action figures up one by one.

I'm also at a point where I could prototype a frontend to consume my API. What I'm looking for is a framework that is easy to pick up and lets me write less code. I've only tried the tutorials for Angular and it's been a very pleasant experience so far.

~~And I still haven't decided what to call this project. Oh well ¯_(ツ)_/¯~~ GunplaHub. It's now called GunplaHub.

tags: gunplahub