Note: None of the code contained in this post will help you complete the Exercise Tracker project; it’s for explanatory purposes only.
TL;DR - (excerpt from below)
A full stack app for regular users would have (hopefully) a really nice looking front end with a sweet UI. I don’t believe that this is what you’re supposed to build for these projects. I believe what you’re supposed to make is an open API. The project landing page should have excellent documentation for those who would consume your API. Also included on your project home page should be some UI samples that show how, say, a frontend developer might use your API. If you decide to go all the way and build an application for regular users, it’s fine to link to it from the project home page.
When you begin the Exercise Tracker project, or any of the ‘APIs and Microservices’ projects, you’ll be given a set of folders and files, which include a project home page view. The view is often given as views/index.html. This page contains the API documentation (quite minimal) and one or two UI examples. Many, if not most, who complete these projects seem content to just use these project home pages as they are. Some will provide their own unique stylings. Many, if not most campers (I was guilty of this myself), however, just take it that it’s enough to fill in the backend logic when they go through these projects for the first time, without really understanding what they’ve built.
If you are someone who’s just getting started with these projects and you aren’t really sure why you’re building these APIs and Microservices, hopefully the following explanation will give you some clarity.
Consider the Exercise Tracker project. You’re given a working example (“https://fuschia-custard.glitch.me/”), and you’re expected to (according to the fCC project page) “Build a full stack JavaScript app that is functionally similar” to it. Since the frontend example is already given in the project directory, most campers get right to work putting together the backend code necessary to produce the required outputs.
Outputs that are rendered as JSON objects.
This should be your first clue that you should be thinking beyond just filling in the backend code. Certainly, you have created a full-stack app (well, if you don’t change the home page view, you’ve technically borrowed the frontend, but why quibble at this point?), but who is this app for?
It couldn’t be just for regular users; how many of your favorite apps output only json responses?
A full stack app for regular users would have (hopefully) a really nice looking front end with a sweet UI. I don’t believe that this is what you’re supposed to build for this project. I believe what you’re supposed to make is an open API. The project landing page should have excellent documentation for those who would consume your API. Also included on your project home page should be some UI samples that show how, say, a frontend developer might present the data you supply with your API. If you decide to go all the way and build an application for regular users, you should link to it from the home page.
So, again, your application provides an open API for other developers to consume. If they’re hot-shot frontend developers, they might use your API to make killer applications of their own. Of course, this isn’t likely to happen with your Exercise Tracker API, but we’re just talking basic principles here, so…
For example, imagine an aspiring frontend developer who wants to use the Exercise Tracker API to build their own application, which they’ll call “Fitness Keeper”. To test things out, they build a simple, boring UI that allows users to sign up to use the service provided by the fCC example (“https://fuschia-custard.glitch.me/”)
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css"
integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
<title>Fitness Keeper</title>
</head>
<body>
<div class="container">
<div class="row justify-content-center">
<form class="col-4" id="myForm" >
<h3 class="text-center">Fitness Keeper</h3>
<input id="username" name="username" type="text" class="form-control mt-3" placeholder="Enter your name">
<input id="submit" type="submit" class="form-control mt-3 btn btn-warning">
</form>
</div>
</div>
<div class="container mt-3">
<div class="row justify-content-center">
<h4 id="success" class="d-block"></h4>
</div>
<p id="eyedee" class="d-block text-center"></p>
</div>
<script src="index.js"></script>
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"
integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo"
crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js"
integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1"
crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js"
integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM"
crossorigin="anonymous"></script>
</body>
</html>
index.js
var form = document.getElementById("myForm");
form.onsubmit = function(e) {
e.preventDefault();
let x = form.username.value;
var xhr = new XMLHttpRequest();
var url = "https://fuschia-custard.glitch.me/api/exercise/new-user";
xhr.open('POST', url, true);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.onload = function () {
let json_data = JSON.parse(this.responseText);
document.getElementById("success").innerHTML = "Congratulations, " + json_data.username + "! You are now registered at Fitness Keeper.";
document.getElementById("eyedee").innerHTML = "Your user ID is: " + json_data._id +"."
form.reset();
};
xhr.send("username="+x);
};
If a new user, Kelly Logan, wants to register, he just enters his name in the input field and presses the submit button.
And, instead of a boring json response, he gets a slightly-less-boring text response.
So, if you finish the Exercise Tracker project and leave it as an application that provides an open API (which, again, I believe you should), at least now you know (if you didn’t already) how another developer might consume your API. And, if you are leaving it this way, you might want to (You probably should) provide your own documentation on how to use your service. And, when you do, think of the various kinds of developers who might consume your API, particularly ones who aren’t really familiar with the backend and don’t want to struggle to figure out how to use your app.
In short, sell it.