Dev Journey Introduction
Boot Camp Weeks 1 & 2
JavaScript Foundations
Backend Block
Frontend block
Final Project Phase
Hello there 👋 and welcome back. Backend block with Northcoders was one of the most challenging three weeks of my life, but it did stand to prove that as Dave would say: "The click is inevitable".
Last few weeks in a paragraph (or two)...
June is always an awesome month in our household, 🏡 but this one was particularly special. My youngest daughter was born in the middle of June, so we normally have a big celebration weekend 🎉 for her birthday and father's day; this year we had a family outing to the park. 🛼 My Mum had a BIG birthday this year too, so parties were commonplace, although thanks to restrictions, they were quieter than we would have liked. June is also the month in which the garden starts to bear fruit. 🍓 This year we have made peppers our main crop 🫑 and I have been experimenting with complimentary planting (basically if it goes well on the plate together, it probably grows well together). Thanks to this new strategy, this year's crop is looking like the best yet, including the biggest, most productive chilli plants i have ever seen! 🌶️ So excited for the next few months, when we can start eating some of our hard work. 🥘
What 3 weeks of backend taught me...
Difficult can be fun. I always knew i was likely to favour frontend. In general I think a lot of us 'artistic types' probably do. We are used to seeing or at least experiencing some kind of shiny, polished resolution to our work. So when backend began with a maze of files and new concepts, it was no surprise I found it challenging. Two weeks in and I was still struggling to make my way out of the maze and imposter syndrome was inevitably looming. We were assured by a previous Northcoders cohort, that it would get better, but that seemed very unlikely! Only a week later after setting up an api, as predicted, I was flying through the maze of files with ease and a new fan of backend was born. I may find it more challenging, but the sense of satisfaction at the end was very strong.
A server is an app! I always though of a server as being a huge computer, the kind you see in 'Ocean's 11' or some other heist movie. Always living in its own dedicated, super cooled environment, accompanied by a host of flashing lights. In fact, a server is just an app, which allows you to interact with with a database effectively 'serving' up the data so it can be viewed or used. This concept was driven home by the fact that on day one, my humble laptop was acting as database, server and client. Using HTTPS to create a server on our machine, which was serving up data from our SQL database created using Postgress, and serving up requests to our 'client' using Insomnia. It was confusing at first to be fulfilling all three of these roles from one machine, but eventually I got used to it.
Express is popular for a reason. Express JS is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications (in their own words). Basically that means you can do all the same things as HTTPS servers, but it has been made a lot more simple, with many of the repetitive blocks of code handled 'under the hood'. For example, lots of time and many lines of code are spent 'stringifying' code so it can be sent as a string and 'parsing' at the other end to convert back to JS. This is one of the wonderful things Express can do for you, but don't forget that Express by its own description is 'minimal', so if you forget "app.use(express.json());" at the top of the file, this feature won't work.
MVC can make your head hurt. MVC (model, view, controller) is a way to organise your server by splitting it into separate sections and files, grouping together the functions which have a similar role. In backend, we would largely be concerned with the M & C parts of MVC. Controllers, which are functions who have access to the client side request and resolve. These functions take a client request, then route that request to the appropriate model and upon receipt from the model, send the data back to the client. And models, which are the functions that take a request from a controller and extract the required data from a database. The first few days of MVC were really challenging as the server starts to break out into dozens of files, which are challenging to keep track of, especially when you still aren't quite sure what many of them do yet! This was the first time that i had to deal with days of consecutive imposter syndrome, but I can assure you, that after several days of negotiating your server, you will begin to understand exactly what it is doing.
SQL isn't as 'friendly' as JS. After months of becoming intimately acquainted with JS, I have become used to how forgiving it is as a language and how helpful it can be with errors too. If error chasing is your thing, then JS is your best bud! If you have lovely separated files and a well organised server, a JS error will (most of the time) point you to exactly where your error lies, even down to the line on which it happens. SQL, however likes to make you work harder with helpful messages like 'ERROR near ;'. Thanks SQL! You would think that a language which is so particular about its syntax, would be more error friendly, but no such luck! If in doubt, chances are you missed a semi-colon. There is plenty of fun to be had with SQL though: Merging tables was particularly interesting and SQL presents you with some new puzzles to overcome.
Is it a bird? Is it a plane? No it's Supertest! A really useful NPM package that allows you to test an endpoint behaves as it should. Using Supertest whilst building a board games API really confirmed the value of TDD. My API is pretty simple and only a work in progress, but even still has loads of files and quite a few endpoints. The test suite is huge, but it gave me absolute confidence that there would be no issues upon hosting. Although hosting for the first time wasn't without its own error chase, that was only a setup issue. The API behaved exactly as it should thanks to Supertest!
Errors can't be too specific. One of the most exciting things for me about building my API was getting the chance to write an error message. I know it might sound really strange, but having been on the client side of error messages for so many years, the idea of writing my own was very exciting. I started off with the best of intentions towards my fellow devs: Write really specific error messages that tell you exactly what was happening. Seemed like a great idea! Then a slightly different error was caught by the same block. "No problem, I can just make the error message slightly less specific", I thought. By the fourth time I had to refactor my error message to make it less specific, I realised "not found" or "bad request" might have been better to start with.
Coming up in part five...
Frontend block. We finally get to make things look pretty. 🤩 Which will be better... Flutter or React Native? It's the battle of components vs widgets.
Top comments (0)