Anyone can build a boilerplate

Rajdeep Chandra
FAUN — Developer Community 🐾
5 min readApr 26, 2020

--

Hello All!! I hope you guys doing well and today we are gonna look into this repo which I have built few days while working on some cool full-stack projects. A few months ago, I worked on some full-stack projects where I was repeatedly doing the same setup process required to get things started. I was running the same commands over and over again and it was very repetitive. Since I work on Vue and Node a lot my projects go very well with this tech stack. So I thought why not create a starter kit so that people like me can just clone it and focus on their development more than setting up the pipeline, deployment engines, and add-ons.

That’s why I created this Full Stack Boilerplate. It has “VueJS” and “SCSS” on the Front end and “NodeJS”, “Mongoose” and “MongoDB” running in the Back end. For authentication and encryption, I have used “BcryptJS” for password hashing and “HapiJS” for validation and authentication.

Folder Structure:

Well, let us keep the traditional folder structure which is simple to understand and easily distinguishable even when a beginner looks at the structure as below.

Folder Structure

Client- In this folder, we will keep our client-side code i.e VueJS in this case.

Config- In this folder, we will keep our environment and local variables and reference keys such as Private Keys for JWT tokens and SSH keys.

Models- In this folder, we will define the data models of our database schema, where we build our Schema models for every table.

Routes- In this folder, we will keep our API routes and will do our validations required for our different protocols.

Client-Side (VueJS + SASS)

In this folder, we have defined our VueJS files and have reference SASS preprocessor to simplify our CSS definitions. In Vue JS, we have followed Atomic Design Patterns- with this method we can abstract most of our components and easily scale them according to our needs. Since this boilerplate will be used for different use cases so here Atomic Design Pattern is ready to go solution.

We have used Vue CLI for the Vue boilerplate setup in which we have defined our routes with Vue Router. Vue Router gives a powerful abstraction layer where it gives some powerful features like Nav Guards, Programmatic Routing, etc. A glimpse of the Front End folder structure as below.

client-side folder structure

I am not going to go deep into each folder abstraction in this post, I am planning to cover the topic in another tutorial. Let us just run through the structure quickly.

common-components- Holds the Atoms like Buttons, Navigation Bars, Footer, Cards, etc which can be reused over time.

components- Holds the different views of the routes. You can name it as views also. Since in VueJS, we write our template, script, and CSS in one file we don’t have an external CSS file as such so we only have a .vue component and .test.js file.

utils- This folder will hold most of our reusable helper methods and services. Our API definitions, environment configs are all kept here.

utilities

SCSS reference is being done on the global layer in the view layer so that it can be used throughout the project. To integrate SCSS in a Vue project we need to install below packages.

scss packages

And we can use SCSS in our .vue file like this.

SCSS definition in a Vue file

For Unit Testing, we are using @vue/CLI-plugin-unit-jest which is pretty much similar to Jest.

Server Side (NodeJS + Mongoose)

We will be running express with node on the backend and for communication with the node layer, we have setup mongoose connector to talk to the API layer. We have set up a few things such as ‘@hapi/Joi’ validator for object validation required for user authentication and ‘bcryptJS’ for hashing our passwords before saving it to the database.

The below configuration has been made so that any user using this boilerplate can quickly come to know which part of the code is holding each definition.

server.js file

In this ‘server.js’ file we have our required imports required for the below codes. Since we are using imports from .env file we have ‘dotenv’ config which will allow us to import configs from .env file in our local.

Next, we have our route definitions where we can define our individual API routes and after that, we set up our ‘middlewares’.

Let us look at the MongoDB connection string. MongoLab has been kept as default since while deploying our DB we would need MongoLab so it's better to connect to it while we develop our app in our local. If you want you can choose to bind the local MongoDB connection string also but you will have to connect to a cloud DB like mLab while deploying.

So that’s the whole setup which is in store for you guys. Do go and check it out. Try it out and if you build some exciting projects with the help of this do share with me, I would love to see them. I would be covering the deploying to Heroku part in a separate article. Till then keep watching this space for more updates.

Link to the boilerplate:

Thanks for reading! If you have any questions, feel free to reach out at rajrock38@gmail.com, connect with me on LinkedIn, or follow me on Medium and Twitter.

If you found this article helpful, it would mean a lot if you gave it some applause👏 and shared to help others find it! And feel free to leave a comment below.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬.

To join our community Slack team chat 🗣️ read our weekly Faun topics 🗞️, and connect with the community 📣 click here⬇

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

--

--