Development
MERN Stack Career Program
MongoDB, Express, React, and Node as one application you can explain.
MERN Stack Career Program builds one application across MongoDB, Express, React, and Node. You will see how a screen, an API, and a database share a feature. JavaScript and a first React course will make this much easier. The result is a project you can describe in an interview without inventing the parts.
Course syllabus
01. One notes app, four jobs
- How the four pieces talk
React, Node, Express, and MongoDB, each with a job.
- The app is a saved note
A person writes a title and a note, then sees that note again after a refresh.
- Create and read come first
Update and delete wait until create and read already survive a refresh.
- The browser is the client
It shows screens and sends requests, and it does not own the notes.
- Node runs the process
The process stays up and listens for those requests.
- Express is the route map
A method and a path land on one function you wrote.
- MongoDB holds the notes
Each note is a document with the fields you chose.
- Draw the path before code
Screen, request, route, document, response, then the screen again.
02. The feature on paper
- The sentence this feature must match
Add a title and a note, refresh, and see that title on the list.
- The fields you will store
A title, a note, and the time the note was saved.
- What this pass leaves out
No accounts, no sharing, and no extra fields you cannot explain.
- The happy path written down
A valid title goes in, a document is saved, and the list shows the title.
- What an empty list should say
A person with no notes sees a sentence, not a blank page.
- A blank title is a failure
The server rejects it, and the screen says which field failed.
- A length limit you can point at
You pick a maximum, and the server enforces that maximum.
- Who the feature is for
One person using their own list on one machine, for this pass.
03. Node starts the process
- A folder for the API
The server lives in its own directory, apart from the React app.
- A start script you can say
One command runs the file you will edit.
- A process that listens
It starts, binds a port, and waits.
- The port from the environment
The number comes from a variable, with a default you can read in the file.
- A health route
GET /health returns a short text so you know the process is up.
- Restart after you change the file
Stop the process, start it again, and hit the health route.
- Read the server error in the terminal
The stack trace stays there, and the browser only sees a failed request.
- Node is not drawing the list
React will render the notes, and Node will answer the API.
04. Routes for one feature
- Express routes for one feature
List, create, and read one note, as three routes with names you can say.
- A router mounted at /notes
The handlers live in one file and attach under that path.
- GET /notes returns the list
The handler loads documents and sends them as JSON.
- POST /notes inserts one note
The handler reads the body and asks the database to insert.
- GET /notes/:id returns one note
The id comes from the path, and a missing document is a 404.
- Method and path together
POST /notes is a different request from GET /notes.
- One handler does one job
The list handler does not also create a note.
- Call the routes before React
Use curl so a screen bug is not confused with a route bug.
05. Status codes and JSON
- JSON in and JSON out
The server parses a JSON body and sends JSON back.
- The four status codes you will use
200, 201, 400, and 404, each tied to a case you can point at.
- 201 returns the saved note
The body includes the document, including its id.
- 400 when the body is the wrong shape
A missing title, or a title that is not text, fails here.
- 404 when the document is absent
The route ran, and that id was not in the collection.
- Do not send the stack to the browser
Log the error on the server, and send a short message.
- Say the response is JSON
Set the content type so the client parses data, not an HTML error page.
- Send once, then return
The handler writes one response and does not write a second.
06. Validation the server owns
- The server checks the title
Blank, the wrong type, and over the length limit all fail in the route.
- Trim before you judge the title
Spaces alone are not a title.
- The note may be empty
A missing note becomes an empty string you chose to store.
- Ignore keys you did not define
Extra fields in the body do not become new data.
- One function for the rules
Create calls it, so the rule cannot drift into a second copy.
- The message names the field
Say that the title failed, not only that the request was bad.
- The form is not the check
A request can skip the form, and the route still rejects a bad body.
- Write the rules beside the function
Required title, trimmed, and under the limit you picked.
07. The note document
- MongoDB documents
A note is one document with a title, a note, a time, and an id.
- The database address stays on the server
The connection string comes from the server environment.
- A collection named notes
This feature uses one collection, and other shapes wait.
- _id is the identity
You use the id MongoDB assigns, and you do not invent a second one.
- Store the time as a date
createdAt is a date, not a display string built in the database.
- Save and return the same shape
The fields you insert are the fields the list route sends.
- A document you can recite
Title, note, time, and id, and nothing you cannot name.
- What the document does not hold
No password, no role, and no price.
08. Queries for the list
- Find the notes
The list route reads the collection and returns those documents.
- Sort by createdAt
Newest first, so the order is a choice you can defend.
- Find one by id
Turn the path parameter into an ObjectId, and handle a value that cannot convert.
- A bad id is 400
The id was never valid, so this is not a missing note.
- Insert returns the saved document
Send that document back so the client has the id.
- The list and the insert share a collection
Both talk to notes, and neither writes somewhere else.
- A posted note is the note you read
The title in the GET matches the title in the POST.
- Look in the shell after a POST
The document is in the collection, not only in the HTTP response.
09. React screens for the notes
- React screens for that feature
A form to add a note, and a list that renders what the server returned.
- Title and note in component state
The form holds the fields until the person submits.
- The list starts empty
State is an array, and it fills from the response.
- Fetch the list when the screen opens
GET /notes runs on mount, then the JSON becomes state.
- Submit sends the current fields
The handler posts JSON and waits for the response.
- Put the saved document on the list
Use the body the server sent, or refetch, and do not invent an id.
- A page for one note
The route param is the id, and the page asks the API for that document.
- Form, list, and detail stay separate
Each component has one job you can name.
10. The path of one save
- From click to database
Submit, validate, insert, and render the document that came back.
- The function that runs on submit
It reads state, sends JSON, and branches on the status code.
- The route that receives the click
POST /notes, the same route you already called with curl.
- The insert
One document, limited to the fields the checker allowed.
- The response the list uses
Id, title, note, and createdAt.
- The title on the page matches the document
What you read on the screen is what was stored.
- Refresh still shows the note
The list came from the database, not from memory in the tab.
- Say the hops in order
You can narrate screen, route, check, insert, response, and screen again.
11. What the browser must not decide
- The browser does not decide what is stored
The route chooses the fields, and the form only proposes them.
- A hidden button is not permission
If the route allows the request, the screen cannot take that back.
- The database URI never reaches React
The bundle and the page source do not contain the connection string.
- The form does not assign a role
If a role exists later, the server sets it.
- The client does not choose _id
The id in the list is the one the database returned.
- A form warning is only a courtesy
It can speak early, and the route still rejects a bad body.
- The server message wins
When the API returns 400, the screen shows that message.
- A request you can forge
If curl can create a note, the UI was never the lock.
12. Loading, empty, and failure
- A line while the list loads
The screen says the request is in flight.
- No documents is not an error
The empty sentence is a real state.
- A network failure leaves the form filled
The request did not return, and the typed note stays put.
- The 400 text sits by the title
The person can see which field the server rejected.
- The detail page says the note is missing
A 404 means that id is not a document.
- A 500 is a short sentence on screen
The detail stays in the server log.
- Disable the button while the save runs
One click sends one POST.
- Do not clear the form when save fails
The person can fix the title without retyping the note.
13. Edit and delete
- PATCH is its own route
PATCH /notes/:id changes a note, and it does not reuse POST.
- The edit screen loads the document
The fields start from the saved title and note.
- PATCH uses the same title rules
A blank title still fails with 400.
- The list shows the updated title
After a successful PATCH, the old title is gone.
- DELETE removes one document
The id must match, and the response says that note is gone.
- Ask before delete
A confirm step so one stray click does not remove the note.
- Leave the detail page after delete
That id would now 404.
- Editing a missing note shows 404
The document was already gone, so the form does not pretend to save.
14. Walk the files
- Walking through the project
Server entry, routes, validation, the database, then the React screens, in that order.
- Where the port is read
The environment variable and the listen call.
- Where the title is checked
The function POST and PATCH both call.
- Where the document is inserted
The one call that writes to the notes collection.
- Where the list is fetched
The effect in the list screen.
- Where the error text is kept
The state that holds the message from the server.
- File names that match the feature
A person can find notes routes and the notes screen without a map.
- Accounts are a later feature
You can name them, and they are not mixed into this one.
15. Explain the feature
- Four sentences for the feature
What it stores, which routes, which screens, and what the client does not decide.
- Draw browser to database and back
React sends the request, Express handles it, and MongoDB stores the document.
- Point at the blank title
The check, the 400, and the message beside the field.
- Point at a failed list request
What the screen says, and what it does not invent.
- Where the id comes from
The database assigns it, a bad id is 400, and an unknown id is 404.
- Where the connection string lives
On the server, and not in the React bundle.
- What you left out on purpose
No accounts in this feature, and you can say why.
- Add a note and refresh
The title is still on the list because the document was stored.
Lecture videos stay with the course. Playback for enrolled students will open once payments are available. Video links are not published on this page.