Freecodecamp: Get Set for our Back End Development Projects - create simpler version for API Projects

[jondcoleman]

I think Clementine is a wonderful starting place for the Full Stack Apps but many users are finding it to be unnecessary and unhelpful for the API projects. They are getting tripped up on things like authentication and MVC patterns, which aren't necessary for the API Projects.

Therefore, I'd like to suggest that the Clementine generator instructions are moved to a new step preceding the Full Stack projects. For the API Projects, either create a different boilerplate or provide none at all.

[jondcoleman]

Maybe some instructions like this instead. This is what I've been recommending when campers come confused about Clementine for the API projects.

• Create a directory named for whatever your project is (e.g. time-server-api)
• Run npm init in the console and follow the prompts to set up your package.json file (most things you can leave as default)
• Run npm install express --save to install express.js and save it as a dependency for your project.
• Add a .gitignore file to your directory which ignores the node_modules folder
• Run git init to initialize this as a git repository
• Create a file in your directory called server.js
• For the API projects you can write all your code in this file. For a starting place I recommend this as a simple example of node/express set up: http://expressjs.com/en/starter/hello-world.html

[supergoat]

I was very confused on how to start after the Clementine tutorial, so jondcoleman's suggestion helped out a lot, so I think it would be useful if you included something like this before Clementine. Thumbs up :+1:

[dshgna]

+1

Additionally, I didn't find Clementine.js a good starting point for the dynamic web projects. Its directory structure is heavily based on Angular. As we are supposed to develop the frontend component with React, a React specific version would be much more useful.

[patricksevat]

I agree with this as well. I got very confused when first encountering Clementine for API projects due to unknown components (Passport and Mongoose). I ended up stripping pretty much everything and working from server.js

[delbertlegg]

+1 I was trying to figure out where I was going wrong before I was pointed in the direction of "modularization" which hadn't yet been really covered. Once I realized I could run the program in the server file, I was squared away. Not necessary to use Clementine.

[erictleung]

cc/ @FreeCodeCamp/issue-moderators

[raisedadead]

I am in favor. But lets hear it from others.

[ghost]

I agree with @raisedadead, I am also in favor :+1:

[ltegman]

I completely agree. By that point in the curriculum students should be familiar with Express and that is the only thing needed to start cracking on those projects.

[jondcoleman]

I'm going to give this a go. There's been rumblings of switching to HyperDev. Has that been decided? If so I can hit two birds with one stone and recommend that for the API projects.

[raisedadead]

Bumping up for comments.
/to @BerkeleyTrue @QuincyLarson and /cc @FreeCodeCamp/issue-moderators

[ghost]

@raisedadead, I think it's a good idea to move... However, HyperDev is still limited in options, whereas c9 is a full linux box. HyperDev is defiantly easier to use, and is cleaner and more intuitive.

[jondcoleman]

IMO c9 makes more sense to teach with but I see the advantage of HyperDev.

[QuincyLarson]

For the API challenges, we could definitely consider HyperDev. It is much, much easier to get started with, and replaces both c9.io (to a large extent) and Heroku (which requires a credit card and excludes a LOT of campers).

If we are going to move away from using Clementine.js anyway (which I agree is too heavy for the API challenges), I vote we move to HyperDev.

We can link to wiki articles that show campers how to use c9.io/Heroku, or dev locally. But HyperDev seems to be a sane default for all of the back end challenges.

@jondcoleman thank you for taking the initiative to submit the PR. What do you think about hyperdev?

[jondcoleman]

Thanks @QuincyLarson

I feel torn about HyperDev - the abstraction certainly makes it easier. There are a few disadvantages to HyperDev in my mind:

• Loss of true git workflow. You can export your project to github but there's no individual commits or standard workflow.
• Non-standard ways of adding libraries. For example, users might get tripped up by the fact that there is no npm install x --save when most guides out there will describe that as the way to install a package.
• Lack of ability to use task runners (gulp, webpack, etc). This wouldn't be a big deal for the API projects but for the dynamic web apps this would be a pain.
• Lack of ability to use generators or boilerplates not specifically designed for HyperDev. Because of the forced project structure this seems be an issue.
• HyperDev is still in Beta so who knows what issues campers might run into.

My opinion would be to stay with c9 for the dynamic apps. For API projects I would lean towards sticking with c9 because the workflow is more "standard" but think it's less of an obstacle there.

[raisedadead]

@jondcoleman thanks a lot for this research, and you are absolutely right, we should not be moving to something, that needs no standard ways of doing stuff. This would confuse beginners, which ironically is the opening post in this thread.

Let's just stick to removing the ClementineJS part and simplify the instructions as suited best with C9.

Thanks a lot, once again.