D288 Back-End Programming is banner number ITSW 3175 and three competency units in the School of Technology. The catalog describes it as building back-end web application components with framework packages, database functionality and web services, which is three subjects braided together. The competency is the join between them: an application whose data model, persistence layer and service interface agree with one another. What it builds toward is the half of web development a user never sees and every user depends on.
The data model decides how hard everything else will be
Back-end work has an order and students frequently reverse it. Entities first, relationships second, then persistence, then the service interface, then the behavior. A data model that mismatches the domain is not a local problem, it leaks into every query, every service method and every response shape, and it is the single most expensive thing to change late.
Relationships are where the modeling competency shows. One to many, many to many and one to one each have an implementation, a direction of ownership and a set of consequences for how records are loaded and deleted. Deciding what happens to child records when a parent is removed is a design decision with real consequences, and it is a question evaluators know to ask.
Persistence through a framework introduces a layer of translation between objects and tables. That translation is convenient and it hides work, which is why the classic performance trap in this subject is a loop that issues one query per item without the author noticing. Knowing that the mapping is doing something rather than nothing is part of the competency, and being able to say when the framework's default loading behavior is wrong for your case is a strong answer to a justification aspect.
Web services are the visible surface. Resources named as nouns, methods used for their defined meanings, status codes that mean what they say, and a consistent response shape including for errors. An interface that returns a success status with an error message in the body is a common defect and an easy one to point at.
Turning scored aspects into entities, endpoints and a word budget
Each aspect is scored separately at WGU, needs a 2, and cannot be rescued by another. Here the translation runs to two artifacts at once: an entity for the data aspects and an endpoint for the service aspects, and every row should point at one or the other before you write.
Budget it out. Suppose nine scored aspects and a document of about 1,500 words. Nine into 1,500 is 167 each. Sort them. Four are implementation aspects where the code and the running service are the evidence, so 90 each, which is 360 and releases about 310. One asks you to justify the data model and its relationships, the central argument, at 350. One asks about the service interface design, at 300. One asks about validation and error responses, 250. Two are lighter, a configuration note and a summary, at 120 each, or 240. That totals 360 plus 350 plus 300 plus 250 plus 240, which is exactly 1,500, with the three argument sections carrying sixty percent of the prose.
Write the endpoint table before any code: method, path, what it accepts, what it returns, what it returns when the input is wrong, and which entity it touches. That table is both your build plan and a large part of your documentation.
Building the back end now?
Send the aspects and the data requirements. You get an entity model, an endpoint table with error cases, and a model write-up.
The endpoint table that keeps a service honest
| Operation | Success response | Failure case that must be handled |
|---|---|---|
| List a collection | The collection, empty array when there is nothing | Invalid paging or filter values |
| Fetch one by identifier | The single record | Identifier that does not exist, answered as not found |
| Create | Created status with the new record or its location | Missing required fields, duplicate of a unique value |
| Update | The updated record, or a no content status | Record missing, or a change that breaks a business rule |
| Delete | A no content status | Record still referenced by a child, decided deliberately |
| Any operation | Consistent shape across all responses | Storage unavailable, reported without exposing internals |
The right column is the one that separates a demonstration from an application. Most aspects about robustness are answered entirely by what happens in that column.
Evidencing a service that has no interface
A back end has nothing to screenshot, so build the evidence deliberately. A request and response pair for every endpoint, captured from a client tool, showing the method, the path, the body sent and the exact response including its status code, is the standard artifact. Include the failure cases, because those are the ones nobody demonstrates and the ones the aspects ask about.
Show the data too. The state of the relevant tables before and after a create or a delete demonstrates that persistence happened rather than that a response was returned. For a course that grades database functionality, that pairing is direct evidence.
On sources, cite framework and persistence documentation for behavior claims, and cite them by version because defaults change between releases. Where you assert something about how the mapping layer loads related records, the reference documentation is the source that settles it, cited in APA as an organizational web source when your program requires it. Any schema or sample data supplied by your course materials should be identified as such rather than presented as your design, and adapted code needs a comment naming its origin.
What clears, and what comes back
WGU records Competent or Not Competent with no letter grades and no ordinary grade point average, and revision after a return costs nothing but time. In a six month flat rate term that time is the whole cost, which is why a back end that starts cleanly on somebody else's machine is worth more than an extra endpoint.
Submissions that pass ship with everything a stranger needs to run them: schema or migration, seed data if required, configuration described, and the exact commands. Their endpoints use status codes correctly. Their error responses have the same shape as their success responses. Their write-up justifies the relationships in the data model rather than listing the tables.
Returns concentrate on four defects. A connection string with a real path or credential hardcoded in a committed file. Endpoints that return a success status while reporting a failure in the body. Relationships modeled without deciding what happens on delete. And an aspect about web services answered by describing what a web service is instead of accounting for the interface you designed.
Seven mistakes that cost D288 students time
- Building endpoints before the data model settles. Every endpoint written against a model you are about to change will be rewritten.
- Ignoring what happens on delete. Cascade, restrict or orphan is a design decision. Leaving it to a default is a decision you did not make and cannot defend.
- One query per item inside a loop. The mapping layer makes this easy to write and invisible until the data grows. Watch the generated queries at least once.
- Committing credentials. Even in a course project this is a habit worth never forming, and it is visible to anyone who opens the repository.
- Testing only the happy path. The failure column of your endpoint table is where most robustness aspects are won or lost.
- Letting the response shape drift. A service that wraps some results in an envelope and returns others bare forces every consumer to special-case it, and an aspect about interface consistency will find it immediately.
- Skipping the seed data. An empty database makes every endpoint look broken to whoever opens your project, and supplying a small realistic data set costs one file.
How we work on this course
D288 support starts at the model. Send the scored aspects and the data requirements and you get an entity design with relationships and deletion behavior decided, an endpoint table including the error cases, an evidence plan showing which request and response pairs to capture, and a model document in the register WGU evaluators read. Reviews explain the structural defect rather than replacing your code, so justification aspects stay answerable in your own words. Where an objective assessment is part of your course, our work is preparation only, and objective assessments are proctored: we never sit or assist during one, and we never ask for or use portal credentials.
Back-end courses are where a rushed data model turns three weeks into six. Planning it properly is what keeps the rest of a six month flat rate term available for everything else on the plan.
Three questions D288 students ask
Is D288 the same as ITSW 3175?
Do I need a front end for this course?
Which database should I use?
Where D288 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.