Architecture

Architecture, like design, is not my favorite part. (One might wonder if I actually have any favorite parts; and if not, why on earth would I decide on software as a career field? All good questions.) Unfortunately, you have to make some decisions about architecture before you start coding, and they have to be good decisions. Otherwise you're going to waste a lot of time going down rabbit holes (trust me, not my first rodeo).

The number one requirement of my site is that it needs to cost me nothing to operate. I'm willing to spend up to $20/year on domain registration, but that's it (see Site History). Which means the only commercial technologies I'm going to be using are the ones that offer a free tier that is sufficient for my needs. Luckily, everything is scalable nowadays, so if I end up using too much bandwidth because my site is inexplicably popular, I can always upgrade.

So, for starters, I'm going to deploy my front-end on GitHub's GH Pages, because it's really easy. It's not immediately clear that I need my own back-end, because a lot of the features I need are offered by free services.

The main thing I need to be able to do is store images. I decided to use Cloudinary, which is a service I heard about on a podcast. It offers a bunch of on-the-fly transformation options in addition to storage. It calculates usage based on a complex algorithm involving storage, bandwidth, and processing, but I've uploaded all my images and played with just about every feature they offer, and have yet to reach 5% of my free-tier quota. So that's kind of a no-brainer.

The other thing I want to do is create and sell derivative products, based on my artwork. There are a bunch of services that allow this via API, and I tentatively chose Printful just because it offers a pretty wide selection of products. (By "derived products," I mean stuff like T-shirts, coffee mugs, and posters with my pictures on them.) Printful allows you to create products ahead of time and then order them via API call, or create products on the fly via another API call. So that's the product API I went with. (At the time of this writing, I'm reconsidering that decision; but let's worry about that later.)

Finally, I want users to be able to contact me. That's kind of a basic feature of websites in general. Sending messages typically requires a server (ie a back-end), but writing a whole back-end just to enable a contact form seems kind of dumb. So I'm tentatively going to try setting up a servlerless contact form using GMail.
So anyway, my starting goal is to build a site that does all the things I want by connecting to 3rd-party, free-tier APIs and then rendering an attractive display using React.

Comments

Post a Comment

Popular posts from this blog

Basically done! (at least on full-screen. except for some issues.)

Image
The full-screen version of my site is essentially complete! Mostly. Except for the Map component, which I don't quite have yet; instead there's just a button that opens the location in Google Maps, in a new tab. Also, I had wanted to use URLs for all navigation, including within the Artwork page; but it turned out to involve a lot of changes, so I put that on pause for now. The mobile version is a different story. Prior to this week, opening the site on a screen less than about 600px would just break the site - totally useless navigation, overlapping elements, etc. I managed to fix that, mainly by just changing all my CSS unit values to vh/vw and %, instead of px or em. But there are still some serious aesthetic issues on mobile devices. Which I'm going to discuss in my next post. So, here is a screenshot from the site, basically as it was when my team and I presented it at GA, as a "post grad" project: And here it is now: Besides looking better, all
Read more

Getting back to it, again

Image
Got a little distracted - apparently there's something going around. OK, so, I put a lot of work into making the site mobile-friendly, which reminded me again why mobile-first is a good design strategy. But not the way I did it, so not really worth crying over now. I started this post a month ago, and then didn't publish it. So now I'm getting back to it again. My default work style is to obsess over one project until I hit an insurmountable challenge or run out of things to try, and then avoid it for a couple weeks. For whatever reason, writing this blog counts as its own project, distinct from actually developing the website. So my blog updates often happen only when the coding has reached a pause. Current Status : site is live and functional, though more could be done.   All the available controls do what they are supposed to do. However, there are some fairly obvious gaps in functionality, such as the ability to buy things directly from my site. That's on account
Read more

Mobile Issues

Image
So, a couple things don't work and/or look bad on small screens. Despite the fact that I finally stopped setting styles using pixels. Which is a remarkably bad practice, but still for some reason a tough habit for me to break. Anyway, here are some persistent bugs with the mobile version of my site: The menu , which now collapses to a toggle button below Bootstrap's medium screen size (which I believe is 768px). However, when you click the hamburger icon (aka the 3 horizontal bars that are the universal symbol for an expandable menu), the menu items are ugly, and also they push the rest of the content down the page. Should instead become a dropdown menu that floats above the page content. So, here's the homepage on my laptop screen: And here it is on mobile (Galaxy S8) - with menu expanded: The Lightbox feature . This used to handled by a complex function in App.js, which got passed as a property to every page so that any image could by magnified. Howeve
Read more