This project is the fullstack web portal for GCW M.A Road Srinagar. The objective of this project is to come up with the improved and more flexible system so as to remove the problems with the current system.
The current system has a lot of problems which is faced by the faculty as well as the students of the college, most of the problems include:
Reason For the issuses : Most of the online tools failed to find the reason for the problems in the website but after a huge lot of efforts we came to conclude that the website may not be following the best practices & may be making use of obsolete and outdated api's which are no longer supported, one of which we found is the very earlier version of bootstrap. The page load speed could be increased by the optimization of the code, so that only that much data is being downloaded from the server which a client needs, eg: a client wants to view the website from his phone in order to view the latest notifications, but what current system is doing is downloading the all assets in as much higher quality as possible without worrying about the users. One more issue with the current system is that the routes are not clear eg: user visits the imca department of the college, the route has to be like this website.edu.in/department/imca instead it shows something random.
we may say that there is no way out to go & make all those changes in the current system so that the system may work properly and may perform as good as the websites of other colleges. The only way is to come up with the new system and that is what we have done.
The one word for all the problems mentioned above comes out to be performance, considering which we have choosen the worlds most fastest and popular tech stack out there. If we try to sum up the tech stack in a single word we may say it is JavaScript. This is the technology without which no website can work/interact with the users. No doubt, if a computer system is not capable of doing anything, most probably it will be running JavaScript (just to remind that your browser is running the JavaScript whole day). More about Tech Stact: Exactly this project is based on the JAM stack, which stands for (again JavaScript) API's & MarkDown.
API's have whole lot of definitions among which this one being most popular (it is the way of interaction between two systems) but for our project the API is simply the backend of our project.
The MarkDown is almost everything which is visually present on the users screen or in other terms we can also call HTML as the MarklDown.
Note: More about the technologies used will be discussed later.
Based on the various factors the files and folders have been devided into various categories, broadly we have two categories of files and folders:
The admin folder contains the files associated with admin controls.
And the other files are for so called frontend.
There is one file lib/client.js which makes intraction between admin and other files possible. As the admin folder contains the data which is to be shown in the frontend.
The admin folder consists of two important directories one being the dist folder and the other is schemas folder.
The dist folder contains all the logic as well as the admin page frontend code (where from admin interacts with the control pannel & sends data to the database).
The another important folder being the schemas, where all the database modals are defined.
That is it about the admin directory.
The technology used in this project is famous for code reusability, if we create a project with vinalla JavaScript we need to copy & paste the various code bits mostly in html. eg) One is supposed to create a list of 10 cards in any webpage, this problem has two ways to be solved, one is to control it with JavaScript & another way is to just copy & paste the HTML and that is what most of the developers prefer as it is easier, here come the issue of DRY.
Let me tell you how react.js solves this problem:
Inside our project root directory we have created a folder named components which consists of the codebits to be reused.
First of all talking about the unique file named components/index.js, this is the file which has been used in order to make the import statements clean, even though the code inside this files seems much repetative & messy but it has made the other lot of code cleaner and less repetative.
Some of the code inside this folder is because we didn't want to mess up the logical stuff, & most of the code is for the reusability, eg) we have the navbar which is common to almost all pages of the website, so what we have done is that we created a component of navbar where in we exported this component from the components folder & then importd it where ever required.
What is inside these jsx files?
Yes, exactly you guessed it right. It is js and x, meaning JavaScript and something extra. What is that extra stuff? It is nothing but markdown.
Let's make jsx more simple:
This folder is popular for containing the files which make the interaction between the api's / backend & frontend possible. Since in our project we have to interact between just a single backend so our lib folder contains a single file named client.js
What is inside the client.js file? The client.js file consists first of all with some import dependencies and most important being a constant named client which is an object with properties to recognise the api, these properties are:
Note: More about dotenv later
We can't access the image directly from the database, instead we need to get the URL of image in order to view it in the frontend for which we create & export the image url builder from the client file, which makes it easier to import it from anywhere in the project.
The folder which consists of all the required dependencies as well as those downloaded by the developer. We have installed various dependencies as well as dev dependencies, which can be viewed from package.json such as react, bootstrap, react-portable-text, eslint etc.
Note: More about package.json & these dependencies later.
Some more things to note about node_modules:
This is the folder where we write the first line of code in our project. The next/router makes this folder special. This folder is responsible for whole routing system, the no. of files in this folder determine the number of routes which a project will have. In our case we at the root of our project we have:
and so on...
For moving from one route to another we make use of next/Link which makes sure that the page is not reloded and all the pre downloaded stuff is not downloaded again. Instead the stuff which can be reused are reused such as navbar & footer, as they remain the same throught the all routes.
Inside the pages/faculty we have the index.js file responsible for /faculty route and one more file which is [ slug ].js, this is the file which exactly is used for dynamic routing its route will look like "/faculty/slug" while slug being dynamic eg) for a faculty with code ias the route will look like /faculty/ias and for faculty with code hn the route will be something like this /faculty/hn and so on...
Similar is the case with services & department.
If we look at the content of the files inside the pages folder we will observe that there is something more than what we previously saw inside the components files. That is the corrsponding backend code responsible for the interaction with the database using a database query language GROQ.
Note: More about GROQ later
We have an async function named getServerSideProps() which consists of the GROQ queries and the fetch function, this function returns the data which is then passed on via props & consumed by the frontend.
It is worth noting that almost all the files in the pages folder consume the reusable code which is present in the components folder.
As already discussed above that this is the starting point of the project, when we start the server the first page which is the index.js gets loaded.
Inside index.js we have:
Usually public folder contains the assets which should be accessible everywhere inside the project, even though we can keep those assets anywhere in our project but it is a good practice to keep them inside the public folder.
In this project we have the two folders inside the public folder:
Again you guessed it right, this folder is responsible for containig the style sheets of the project.
We have two types of stylesheets:
Now we are done with the folders & we are left with just a few files in the root directory of the project.
As mentioned before that we will deep dive into the dotenv, now it is right time to talk about it: most often what happens that we would not like that our backend api's are publically avalible and are visible to any consumer. So we often take care of it with the help of credentials. But one more problem has araised with credential based system, i,e where would we keep that credentials as the code will be visible to the user but at the same time we want to interact with the database.
There comes the role of dotenv.
We all know that any operating system consists of the environment variables which are avalible to the system from any where safely & securely. That's the concept of dotenv. These are the variables accessible from anywhere in the project inside the object process.
To access an environment variable named "abc" we do it like this: process.env.abc
One more thing is that if we want to share our frontend code with anyone but we don't want them to access our database, instead we want that they consume their own database then also dotenv file is useful.
Most of the times we need to download the npm package dotenv and then create a file with name ".env" & put all the secure data there.
But in our case we have named it .env.local which is an openion.
As mentioned above we can put anything in dotenv file which we want to keep secure, in our case we have kept a key named token inside dotenv file.
This file is not tracked by the version control system in our case git. Because we sometimes share git code that is why we would not like to keep track of this file from our VCS.
Note: More about git later
The another file next to the dotenv is .eslintrc.json. Linter is a service used in this project in order to check the code for the volunerable errors. which may cause the dangerious issues in production. Even though this file consists of a single line of code but it is very important in order to make sure that our production bundle runs as smoothly as possible.
When we create the production bundle for our project which is highly optimised and compressed, so looking for the errors inside that bundle is huge lot of work. The eslint file checks the code for the serious issues in the dev server mostly in production server during the creation of production bundle before compilation.
We don't want some of our files to be tracked by our VCS (git here), in that case we tell our VCS to not keep track of those files by mentioning the name of those files inside this file.
There are various reasons why we would not like our file to be tracked by VCS, one of which being discussed earlier i,e security, and another reason for this is that some times some files are huge enough like node_modules which may take longer than usual to be tracked.
The config file in our case (next.config.js) is a JavaScript file consisting of some of the configurations for the project. These configurations include:
We already talked about something called depedencies & dev dependencies. These are the support for our code to run. But the dependencies, dev dependencies are installed inside the node_modules folder which we don't share often. But then how the project remembers the dependencies, dev dependencies required by it.
Here comes the role of package.json or package.lock.json. It is a json file which stores the dependencies and dev dependencies with their respective versions, so that if we share this project with anyone, he may be able to view what extra dependencies this project uses & what version.
This file also contains some scripts used to start the development server, to build the production bundle, lint the project manually etc.
One most important thing is contained by this file, that is the information about this project, the name of the project, the version of the project etc.
The documentation is the most important part of the project, most often the documentation needs to be done on the go, i,e for instance we create a page and instantly after its completion we start writing its docs this makes it easier for the devloper to write the docs. Even the developer can mention what things must be done next in order to make the page more better. That way if another developer comes to work on the same page he will understand it much better & will proceed with the things which are more important.
Docs can contain user guide as well. Sometimes it is not easy for a user to know about how the project is working, at that time the user manual comes handy.
That is it about the folders & files of this project
The database system used in this project is a no-SQL document database. In this system we don't have the tables, rows, columns etc instead these things are replaced with the same concept we discussed earlier, that's json. The database modals are represented in the form of json, the data is stored in the form of json, the data returned by the database when we query database via GROQ is also in the form of json.
It is very simple data structure in JavaScript short for JavaScript Object Notation as well as a stand alone entity used almost everywhere in this project. It consists of key value pairs, it can be nested as well, & can store any kind of data such as array, boolean, string etc.. That are the powers of JSON which make it robost enough to be used in the database.
The collections are like the tables in a relational database. We have used six collections till now in this project:
and so on for the faculty, events etc..
For every modal we have the seperate js file to define these schemas. The schemas define the scructure of the data in a collection. The collection consists of various documents & a document is a single data entity of that collection. eg) we have a collection named faculty, it will consist of the various fields such as name, code, department etc. These entries are called as the documents in such a database.
The document modal usually consists of three things:
SELECT * FROM something WHERE i don't know what so ever...
Since we are using the no-SQL database so no to SQL, & yes to GROQ.
There is a popular language to query no-SQL databases known as GraphQL which is very similar to what we are using in this project.
We are using GROQ because of its high speed & powers, The queries written for querying the database with the help of GROQ are very simple & we don't need to hold down the shift key.
eg) if we want to query departments & want to get whole data about that collection it would be done as easily as:
* [_type == "department"]
Yes, exactly it is more simple than you might have ever thought.
But what about some complex things such as getting fixed no. of documents, in decending order based on some criteria such as created at, such query would look like:
* [_type == "notice"]
| order(_createdAt desc)
[0..4]
{
title,
"fileURL":
attachment.asset->url,
_createdAt,
"filter": * [_type == 'department' &&
_id == ^.department._ref]
{
title
}
}
That's enough for GROQ, let's move on.
Whenever someone visits an SPA like this one, they think that it is very easy task to create a page like this. Even though providing the control for the users to alter the data is a lot of work.
Similar thing is with this one. Most of the data comes from the Database which is connected with the admin pannel, the admin is allowed to insert the data, delete the data or even edit the existing data. Which boosts the power of this project like anything.
If we delete the whole content from the database via the admin dashboard, the most of the webpage will be gone & the whole project will look like a simple web page with no content.
Actually what we want to make clear from these lines is that the admin has whole control about this project & nothing has been hardcoded in the code.
According to software engineering analysis, the software project consists of the 20% of initial efforts and 80% of maintainance. But what things are important for the maintainance of the software project.
Here comes the use of VCS. Actually this system consists of the version control tools, so that if we want to add some new functionality we would add that features & label that new code with the new version eg) if we previously had version 1.1 we might move on to the version 1.2 or version 2.0.
But what if adding that functionality caused any issue?
Again VCS comes in very handy, as it keeps the snapshot of the project at any stage we want. eg) we wanted the snapshot before adding the new feature, after adding the new feature we want to go back to that code which we had at previous version, we can easily go back to that version & start from that again.
These are some basic features, there are various other features as well, eg) working with team, contributing to some project etc.
We are making the use of git as the VCS, that's why we previously talked about the .gitignore file.
This project is enough compatible with any VPS / cloud service like amazon web services (AWS) cloud platform or Digital Ocean or linode etc. Even we can deploy this project on a simple computer system, but then we have to keep that system up and running 24 X 7. So that the system can serve the users all time.
Continuous integeation and continuous deployment is the way of adding the new features to the software project on the go. This includes fixing the bugs. We can push our code to the server within no time, which will reflect the changes to the server as well within a minute or so.
And if we push the code which does not pass the linter test the code will not reflect any changes in the server, which is the power of CI/CD.
We can deploy the code with new feature to some beta server, as the larger companies do eg) deploy the code at some domain like (beta.gcw.edu.in) & if most of the feedback from the beta users is positive we push that code to the main server (gcw.edu.in).
There are more other features of CI/CD but for this project that is more than enough.
This project has been deployed on vercel, which is a hosting service especially the tech stack used in this project which makes it more special than how this project whould have been without it.
Most of the things has been discussed earlier but various things are still left:
As we already talked that jsx is the HTML with some extra powers that we can write JavaScript in it with all of its features.
The styling is the most important thing for the users, the better the styling the more attractive a webpage will be to its users.
Unlike in plain HTML the styles can be added in three ways, here we can add the styles in four different ways.
Note: If we write the styles in the jsx file it is little tricky. we can't write something like this (background-color: red;) instead we will have to write it like this ({backgroundColor: "red";})
As already discussed that almost everything in this project is JavaScript, or more precisely ECMAScript. ECMAScript is nothing but the modern approach of writing JavaScript. This technology has been used in this project at the frontend as well as at the backend in the form of node.js. The node.js is not any other language instead it is the runtime for JavaScript, just like we execute the JavaScript in the web browser using its execution engine (V8 for chrome), If we want to execute JavaScript outside of the browser we will use the node.js which internally uses chromes V8 engine. Hence being very fast.
Important: PayPal created their backend using two technologies (Java/spring & JavaScript/node), the results were pretty amazing.
So node is an excellent choice for building highly scalable applications.
Managing the content on the own backend server can be little messy & has a bunch of disadvantages. Considering these things we decided to use some seperate colud platform to manage our content, even though it was impossible to upload the assets like images/PDFs to our own server as destroys everything at the time of production bundle build.
So we tried various services like mongoDB Atlas, cloudnary etc. But all of these had some disadvantages due to which we reached out to one of the robost & fully featured service known as Sanity Content Platform.
This platform allows us not to store just the text data but any kind of data we want to store.
Initially we decided to use the npm as the package manager for this project as it is widely used & is at the top in every documentation. But in recent days, We were unable to download some package via npm which failed to install. Being aware about the yarn package manager at it's speed we thought to install that package via yarn which fortunately successed. That's why we transformed the whole project from npm to yarn.
eg) To create a react app with yarn we would do it like:
yarn create react-app app
and with npm:
npx create-react-app app
There is a very minimal difference between the commands of two but a very much difference between the speeds that they take to install a package.
To install a package in yarn:
yarn add sharp
And with npm:
npm install sharp
How to write the WYSIWYG text & then store it inside the database. Actually we have various ways of doing that, we can store the text as html or we can ask the admin to type markdown, but both of these ways have disadvantages, script tag can be added to html text which may make the app to run the malicious code & every admin can not be comfortable to write the markdown.
So, in this project we have taken care of all those things & have used the best of all solution. That is the portable text. What it does is that it takes the rich text & represents that text in the form of JSON something like this:
{
"h1": "This is simple heading",
"p": "lorem ipsum what so ever",
"bold": "bold text",
"img" {
"src": "https://something.com/image.png",
"alt": "Some example alt text"
},
"h2": "Simple heading 2"
}
Yes, it is also JavaScript.
At the admin end the rich text is converted to JSON like above & at the reverse process is done while viewing the content at the users end.
Something similar to coding & decoding process.
Most of the graphics used in this project has been manually created by us, we could use the ready made graphics from internet but we thought it would be better for us to create all those things by ourselves. These assets include, some of the images, svgs, logos etc. And the assets which we have reused are being enhanced/optimised using the same tools mentioned below.
The tools used for these grapical things include the world's most adoptable & popular tools for grapic designing i,e The Adobe Photoshop & Illustrator.
The pictorial database design has been created with Adobe Illustrator.
Even though the MS Office toolkit has not been used directly inside the project but still it came handy during the creation of synopsis & other stuff like that.
This is the tool which has been used for this project approx for 90% of the work. There is no tool which can measure the power of this code editor, this editor has became the life saver, the extension pack, the intellisence, the integrated terminal, the live preview of this documentation. That's not it, There is no end, but we have to see other things as well.
These are the browsers which we have used lot during the development & even to test the deployed version of this project.
Both of these browsers come with a lot of useful extensions such as JSON pretifier & react dev tools. Which also came handy during the development of this project.
While previewing the mobile view we used to keep the browser window & code editor side by side This thing saved a lot of time as well.
At last we have the tool which we used to create the dev server as well as can be used to create the production server. That is the terminal. There are enough to choose from eg) in windows we can use the powershell, cmd & in mac or linux we have terminal, bash, zsh. Being in windows ecosystem we had only two choices & some thirdparty choices, but I don't leave the things I like, that's why we used ZSH in this journey even being in windows ecosystem.
At the end:
We would like to thank almighty that we are feeling very happy that this wonderful project came to the wonderful end. These things really make difference.
We would also like to thank the person who came up with this concept that there should be a project for the students at the end of their degree program.
And thanks to all the people who supported us in this incredible journey.