Module 1 feedback

[louisrli]

1 Introduction to Backend

Looks fine to me.

1.1 Beginners guide to Node.js and NPM

• Beginner's in title (apostrophe)
• " In simple words, Node.js is nothing but JavaScript running on the server-side, and it's awesome." Although I know you explain this later in a brief history, a short dependent clause like "on the server-side, rather than in the web-browser" might be helpful. I find that Node can usually be explained in one sentence by contrasting the fact that we usually expect JS on the client-side.
• "You will learn more about the keywords mentioned in this code block throughout this module." Perhaps consider bolding the keywords in the paragraph above this?
• One of the images is broken on Github above "NPM and Packages", though not sure if that's just GH and not Canvas.

1.2

• Is there a formatting error here? "What are we doing in these lines? -- The"
• Looks fine to me

2 HTTP and REST

• Maybe I missed it, but I feel like headers are being shown without really explaining what a header is (in this section: "If the server is able to locate the path requested, the server might respond with the header:". Even a brief explanation would suffice
• broken image under What is HTTPS?
• I find the inclusion of a brief explanation of private key and public key a bit out of place in this section and breaks the flow a bit, could be deferred until the auth/security section. A brief explanation of why pure HTTP is insecure would suffice
• "In fact, all communications that occur over HTTP occur in plain text, making them highly accessible to anyone with the correct tools, and vulnerable to on-path attacks." What is on-path? This sentence probably won't make much sense to a student.

2.1 Diving into REST APIs

I feel that the breakdown of requests and responses might actually be too detailed. The harm in this is that students might think they need to know all these details about requests and responses, which you don't -- in practice you just need to understand that a request/response has a bunch of key-value pairs in different places, and then it has a body (basically I'd base this off APIs like Express etc that let you access parts of the request).

All the stuff about encodings and stuff seems quite extraneous to me; I'd consider slimming down this section and moving a lot to "additional reading." IMO introductory texts should not aim to be a comprehensive reference.

For example, I've never heard of things like absolute form, authority form, etc, and as far as I know we are almost never, ever dealing with raw request/response in practice.

2.2 Testing APIs with Postman

Looks fine

3 Introduction to Express.js

• "The middle part of the code (the three lines starting with app.get('/') shows a route definition" Consider putting some other examples of routes here: like /books or something, just because / isn't really an illuminating example of what a route is

3.1 Meme website

• might need additional explanation of SSR or further links, esp. if people are coming from react background
• Otherwise assignment seems fine

3.2 Meme API

• Assignment seems to reference /meme/1 and /memes, I might be mistaken but I recall that you would just have one endpoint (either singular or plural). Not one of each.

4 API Best Practices

• I would add some articles or at least try to explain some general programming concepts like "information hiding" or "abstraction", as an abstract understanding of these will be helpful to both coding and API design (any type of architecting in general). It also helps to put a name on some of the ideas. They don't need to be explained in-depth but perhaps as further reading.
• I like the fifth point a lot about good error codes, I would add a sentence or two about how working at a company inter-team is about good "communication", and if you are a backend developer, then you want to make your teammates' lives easier (perhaps prompting the student to remember the pain of an error code that they couldn't understand -- it's a tough situation)

4.1 Server-side validation

• "Validation can mean a lot of things" this is a really long paragraph -- consider breaking it into two or more parts
• you may also want to mention that a backend can have multiple clients (and actually I would also put this in the best practices -- for example sometimes people design APIs thinking about a web client only, but in a larger app you'd have to handle potentially many platforms hitting your API)

4.2 Validation practice

• "Sucessful" - typo
• I would suggest emphasizing not to write their own validation of emails and to find one or a package, as generally it's not encouraged to write your own regex or make assumptions about what is or isn't a valid email

5 API Documentation

It's good

5.1 API practice

It's good

Overall module looks pretty good.

[louisrli]

sorry submitted it a bit early since I didn't trust the auto-save functionality -- should be completed now