Routing, Flashy Progress With Logs & Express Sessions

Yesterday was another productive work day on GFT! I finished out my goals for the week of re-implementing all of the routes I’d done before the migration-gate setback, and also setting the app up to collect data from an API programmatically (I’d been doing it manually in Postman up until now for testing). I also added in some helpful flash messages into the front end.

Planning Routing

One thing that has helped a lot in working on the app is planning. I guess that should go without saying!? But it’s something I thought about way more than I actually did, while now I’m seeing the benefits of actually doing it.

I already wrote about planning the database (that helped hugely) and this week I’ve focused on planning and organizing all of the routes that will exist in the app. This app will have a lot of routes—at least more than any other app I’ve created so far—and sometimes I was even confusing myself about what things are, and where they should go.

My solution was to create a document listing all of the routes, and my status creating them, for example:

ENDPOINT	METHOD	ROUTE FILE	DESCRIPTION	DONE?
/	GET	global	Home page if (!user) login/sign up links	X
/	GET	global	Home page if (user) landing page	X
/login	GET	global	Auth0 authentication	X
/callback	GET	global	Auth0 cb auth function	X
/logout	GET	global	Auth0 log out function	X
/profile	GET	users	Auth0 display user profile	X
/admin	GET	admin	READ admin dashboard
/club	GET	club	READ all club	X
/club	POST	club	CREATE new show	X
/club/new	GET	club	READ new show form
/club/:id	GET	club	READ single show with gig count
/club/:id	PUT	club	UPDATE single show	X
/club/:id	DELETE	club	DESTROY single show	X
/club/:id/edit	GET	club	READ single show edit form	X
/club/:id/gig	GET	gig	READ show’s gig
/club/:id/gig/new	GET	gig	READ new gig form	X
/gig/:id	GET	gig	READ single gig
/gig/:id	POST	gig	CREATE single gig
etc….

So far my app has 7 categories (i.e. route file groupings), and each time I’ve started a new one, I plan out what the routes will be before writing any code. Doing so, I’ve been able to work through questions (like, should a gig go on its own route or be a nested route? What makes sense for the user? Vs what makes sense for keeping this organized? How does the club & gig database relation play into this?) before getting too far with any code…it’s an improvement over how I was working before!

Maybe some of this sounds really obvious, but figuring it out mostly on my own, I guess I have to work through these things 😅

API Integration, Express Sessions

I also officially integrated the API into my app YAAAAAAAAY!! 💃💃 It was really lame to be doing it manually before—I would call the API in Postman, reformat the output, save it to a file, and then write a function to persist the data, then delete the function. Super inefficient! I guess it worked for just testing the data (all I’d been doing until now), but this won’t really work in the long term.

Now I can just press a button and it pings the API, goes through my database to filter out any data that is already there, reformats the remaining payload to fit my db schema, and then persists the new information to my database.

I wanted to add a confirmation/review step in the middle of this process so that the site admin can see what’s going to be updated before the data is persisted. That means using 2 routes instead of 1 to call the API and update the data. After trying a few things, I discovered that you can use a session to hold data in the app across several routes.

For several reasons, it seems like doing so in memory is not best practice for apps in production, but I haven’t figured out why yet? I’m only holding data long enough for the user to confirm its accuracy, and then clearing it from the session memory once the data goes into the database. Several articles (like here and here) allude to the fact that I shouldn’t do this, but for now, and until I find a better solution or advice, I’m going with it! Hopefully I’ve done enough to avoid memory leakage and having the app store too much temporary data.

Flash Messages

I also got flash messages implemented using connect-flash. Flash messages are the little, temporary messages that might appear in a little bubble after completing an action (i.e. ‘Gig was successfully created!’). I used this package a while back in a tutorial I’d done and looked to see if there was anything more up-to-date, but couldn’t find anything. I’m guessing it’s because the popular thing now is not to do server-rendered apps at all (at least not in the way I’m doing), so there’s not as much being written about this more recently. But anyway, connect-flash still works great, so not complaining!

For future reference there were some grumblings about it not really being supported or maintained though, so this is something to keep in mind for future.

Logging 101

Now I’m implementing logging for the app. A lot of the app’s actions are already logged to the console (thanks Sequelize!), but once I started working with the API and especially with that two-step data sync, there were times in setting it up when I realized it would have been really helpful to also see in the console which HTTP requests are being made, response codes, etc. I got a glimpse of this not too long ago so now’s the time to finally get it going.

Research: there are SaaS products like Rollbar and Sentry (which I’ll reluctantly admit I only know about due to podcast advertising!!) that have made a business out of doing this. Otherwise, for Node apps the most popular logging tools seem to be morgan and winston. Morgan seems to be specifically for logging HTTP requests which is all I need at the moment, but Winston seems like it can expand to do quite a bit more in production, so I decided to go ahead with that from the beginning. I found some good articles like this one and this one and this one.

Then it seemed a lot like over-complicating things for what I actually need right now! So Morgan it is. I just added two lines to my ./app.js file:

const morgan = require('morgan');
app.use(morgan('dev'));

And now I can see what routes are being hit and when in the console.

I can see the value of saving the logs to a file in production, or logging more information even in the dev environment, but for now I’m good with this!

Up Next

Keep working on the app!