March 2021

GET Requests

Coming from a non-traditional software engineering background (meaning I didn’t finish a college degree in computer science, or go to a bootcamp), I’ve had to piece together things from disparate sources of information.

I feel like this has largely worked for me, and has meant that I have a different, sometimes better, approach to certain aspects of development.

Unfortunately, I sometimes find out that I’ve got a huge blindspot in an area.

My initial experience with HTTP requests left me with the impression that GET requests are used to get information, and POST requests are used to pass information to the server.

For a variety of reasons, I’ve mostly needed to work with POST requests up to this point, but I do remember an instance where I was working with Google’s translation API, and I was shocked that making a call to translate some text was a POST call rather than a GET call. After all, I was requesting information (a translation) from their service.

As it turns out, there is a lot more going on there than I’d initially realized. GET requests are meant to be cacheable, and idempotent. Because of this, it is generally bad form to pass information in the request body. Everything is supposed to be contained in the URL…which in turn creates a limit in the number of parameters you can pass because there is a limit to the length of the URL that can be passed via a get request (~2,000 characters).

Google needed to be able to pass translation requests with more than 2000 characters to them. Additionally, they don’t want common translations to be cached and then served out to multiple customers. They want to be able to charge each individual customer for each translation, no matter how common the translation is.

There are likely other factors, but those two alone pretty much ensured that using a GET for that translation endpoint was a bad idea.

I found this medium post really helpful if you want a more detail explanation.

Converting Database Objects via JSON (part 2)

My last post discussed using a toJson method/static for converting the result from a database call. I’ve used that to make sure that sensitive information (like a hashed password) isn’t return to users as the result of an API call.

Today I ran into another unexpected bit of behavior. For some reason, I thought that the toJson method/static was just changing the string that was returned when JSON.stringify was called.

As it turns out (at least with Sequelize when working with Postgres), it actually changes the underlying object and then produces the corresponding JSON string for the changed object.

This tripped me up because I was trying to debug something, so I logged out the object, and then promptly saw a bunch of other stuff break because the subsequent logic was looking for the user object to have a password, but the object that had been returned from the database no longer had a password.

This is a good reason for jumping into the debugger rather than using logging statements. That was never an option in ServiceNow, so I’ll have to dust off those skills and get back into the habit of using the debugger instead of just using log statements.

Converting Database Objects via JSON

I’ve spoken before about the two Andrew Meads Udemy classes I took a couple of years ago. That was where I was introduced to the concept of establishing a toJSON method or static on a database object.

In the class, we used the toJSON method to remove the password from the object. That way we could be sure that what was returned to the user after an API call wouldn’t have the password on it.

That meshes well with one of my pet theories, which is fixing stuff in the right spot. By putting the logic on the database model, then you don’t have to remember to strip it out each time you return a user via an API call.

I’ve used this now with Mongoose/MongoDB and Sequelize/Postgres

Recently, however I ran into some unexpected behavior. I needed to do some complex logic around a group of records returned from the database.

My approach was to create a new object with some additional information on it for each record that had been returned and then add the database object to this new object. The logic all worked splendidly, but when I converted the new object via JSON.stringify for logging purposes, a bunch of information was logged out that I expected to be removed via my toJSON method.

Apparently, when you add a database model/object to another object, stringifying that new object doesn’t take advantage of the logic defined on the model.

I went back to the logic and instead of creating a new object, I just attached additional information to each record I got back from the database. That did the trick quite handily, and I still get the advantage of the toJson method declared on my database model, so that is the pattern I’ll use going forward.

Update

Apologies all round. My posting schedule has gotten really irregular, but I can share the reason now.

Back in July, I had a manager at one of the big tech companies reach out about the possibility of joining her team. I let her know that I was very much interested, but that I wasn’t prepared yet for the kind of white-boarding interviews that her company used for vetting candidates.

This led to a roughly 6-month process of reviewing data structures and algorithms as I prepared for the interviewing process at her company. When all was said and done with preparing and interviewing (~8 months after she first reached out), I failed the final round at her company, but got offers from 4 other tech companies of varying sizes.

The process has been exhausting, and between that and maintaining my performance at my job, there wasn’t much time left for anything else.

I’d like to say that being done with interviewing will mean that things will calm back down, but I suspect that I’ll have to put in some longer hours to get up to speed with my new job.

Be that as it may, I’m going to try to get back to a more regular schedule.

Here’s to hoping.