With the database choice all figured out, the two remaining pieces are the front end technology and the back end technology. I mentioned before that I want to use Angular on the front end for a couple reasons. First and foremost, it’s the new technology being introduced in my professional life, so I want to become familiar with it. Secondly, it seems like a competitive, modern framework. The “other” contender seems to be React + supporting software. React is constantly gaining popularity, so it definitely seems like a valuable thing to be familiar with, but I imagine I’ll already be overwhelmed using something I’m marginally familiar with.

If I actually manage to get anywhere with this project, perhaps I’ll revisit it and try out React and related technologies to see how they go. My intention is to have the front end completely decoupled from the back end, so perhaps there will be an opportunity to play with multiple front end technologies.

So.. Angular it is! I’ll do up a minimal Angular application to try and start sorting out the end to end interaction and get something to actually look at and play with.

The Plan

Starting from the ground up, the absolute basics that are required are:

Bare necessities:

• Development infrastructure set up
  • database – should be easy to set up
  • server – a big ol’ question mark right now
  • client – the Angular CLI pretty much handles this
• Development environment for both the server and the client
• Deployment story for the whole application

While a lot of this can be accomplished in a vacuum, it’s always nice to have something tangible to drive it. Not only is it more satisfying, but it often shows mistakes that otherwise would have been glossed over if there were no real content being used. For example, how do you know your configuration for linking your server to the database really works unless you have an actual call from the server to the database?

First feature

For the style of web application I intend to make, one of the fundamental pieces will be authentication and authorization. Users have to be able to sign up, sign in, sign out, and delete their account. The users access also has to be heavily restricted if they’re not signed in, and slightly restricted if they are signed in – e.g. they’re not an administrator, so they can’t see system settings. Almost regardless of what the web app ends up being and how it ends up looking, user management is a key piece. Where better to start? This will also span the whole stack, so it makes for good motivation to get moving.

Client side:

• Ability to sign up users
• Ability for users to sign in
• An indication of whether a user is currently signed in or not
• Functionality to block users from accessing certain pages
• The client side piece of session management

Server side:

• Add users
  • Store usernames
  • Store passwords The Right Way
• Delete users
• Log users in
  • Determine whether provided username and password are correct
  • Server side piece of session management

I’m sure I’ve missed some things, so I’ll add them as I go.