What did we even use computers for before the Internet!? How much is your smartphone or laptop worth if you have zero Internet connectivity? What good is a web application without a database? Which is more important, the language or the architecture? The actors or the writing? These… are all questions… but one wouldn’t have a job without the other. Still, a web application needs a strong database layer but with abstractions to hide the raw SQL inside the code. So, we need to pick a database solution as carefully as we choose the programming language. True, that is, if we aren’t talking about the solution for our father’s VHS rental store and its single register (been there before!)
Don’t Spare the Database Layer
As a developer, the idea of Object-relational mapping (ORM) is about decoupling the low-level semantics of data storage and retrieval from the application code. An ORM abstracts database functionality inside your code just like a templating system abstracts HTML or JavaScript in your code. Everyone’s favorite, Stack Overflow, has a really good posted definition of ORMs along with the pros and cons of using one in a project. While you’re there, also check out Stack Overflow’s latest questions tagged [Rust] – maybe you can help someone out!
The ORM tools handle a big responsibility in app development. The Diesel crate has taken on this task for my sample app here at the beginning. With Rust and Diesel both being so new, I need to cut these tools some slack, but I also desperately want them to be fairly mature for the benefit of the language.
Sample Web Application Goals
Let me explain my concept for this sample app first – it likely won’t ever get finished, but that’s ok, it gives me something to practice with. A friend (check out his Kindle book, Seeing in the Dark: A Guide to Night Photography) and I came up with this idea over 10 years ago when we were scouring the local 200 mi radius for great places to shoot photographs. My 500px profile is filled with them – nearly all landscapes, I don’t do portraits or models.
Our idea came to be known as PinpointShooting.com (which isn’t a website yet, duh). Photographers could sign up for free and, using a Google Maps interface, indicate the best places to get some terrific shots. Some might be obvious, but there are some hidden places out there to spice up your photography.
Handy tip: a photograph is often more interesting because it was taken from an angle or a hidden spot that no one else has picked. That way, your picture doesn’t look so much like a “touristy postcard.” That’s a reason photography books tell you to kneel or lay down or climb on things to take a picture. In fact, anything to change the normal viewing angle. What’s more boring than seeing a photo of a flower from 5′-6′ above? That’s the angle we see ALL the time, just walking around! Plus, that’s why photographers often refer to it as “making a shot” rather than “taking a shot.” There’s art involved above pressing the shutter release!
Back to the Database Chat
Anyway, enough about that – I need to store some data!! I’m sure this will expand and evolve, but this is what I’m thinking for tables so far:
- Users – to store the free user profiles, passwords, email address
- Locations – to store the address and/or lat/long of the good spot to shoot from that a user has shared
- Photos – by users to store the pictures (or links to pictures) taken from a location in the database
- Ratings – by users of the locations they have been to and if the agree
- Likes – by users of the photos uploaded or linked to
- Visits – to the location linking together a User/Location when they share a good spot, or a User/Photo when they upload/link one, or a User/Rating when they leave one
I start the DB design with some Enum types inside Postgresql. Most of these tables are going to have a status field with just a few possible choices. The enums turn out to be something that Diesel doesn’t seem to handle well (yet). In fact, I found a crate because of that fact. Wait… I take that back… I found 3 crates. Diesel-derive-enum has, by far, the most downloads, so I download that one. However, I only fooled with it a short time before I gave up. This is just a silly practice app, so I will switch to charfields. Well, they don’t work right away for me either, and it is getting late. I’ll just use some varchars which I already have a ton of.
Diesel Database Migration Tool
Diesel has a database migration tool to allow your project to record (and store in the repository) the entire path of changes the database undergoes during the product lifetime. It seems that tool name may have come from Rails – or there are only so many synonyms to choose from. I have used (and beat my head against) Sqitch and I’m just becoming aware of Skeema. Database schema management turns out to be a somewhat complex and fragile flow when you work with over 100 other developers in a fast-moving codebase. Because of the field issues I had (and because this project is ONLY me and is just starting), I reset my database to start over several times. In the end, I have a successful compile of the above DB structure abstracted into my code.
Diesel, btw, has a wonderfully impressive website to introduce you to the available functionality. I use the DBIX::Class module (often referred to as DBIC) with Perl, and it is as complicated as DB queries can become! But those are mostly the exception; DBIC generally abstracts the SQL nicely into some OO code to get me the data I need from the database. Most importantly, the Diesel Getting Started Guide is a great introduction to what using this crate is like. Plus, in addition to the normal crate API-style documentation, there are several other guides – some diving deep into the mechanics and benefits of Diesel.
I need to really get into some code to see how Diesel will be, but I have high hopes from what I’ve seen so far. A systems programmer (which I’m not) probably has far less need for the tools and add-ons that I’ve been playing with these past three posts. However, for big-scale web application development, most of these are key requirements!
More to come…
I hope all of these tools continue to develop with the pace of Rust itself, and I hope to get good enough with Rust that I can help out with some of the modules in the future! Once again, here’s the repository link to my code (at whatever state it exists when you read this post). I expect to have more to share about the PinpointShooting web application soon.
Edit: Meanwhile, go check out this fantastic post that looks at using Rust on both the front-end AND back-end of a web application! Web Assembly is hot right now, so this is a great read!
The post It’s Not a Web Application Without a Database appeared first on Learning Rust.
Top comments (0)