Building a project is great. You learn a lot, you make friends, and hopefully, it helps to solve a certain problem for certain people. But behind every project, there is a story of how it comes to reality. Today I'll tell you a story where my friends @j_lo857 and @dinasso1 and I built Gfree ( a gluten-free community ).

Back in the spring of 2018, we started learning web at my university, it was a fresh air from the algorithms and math. I started experimenting with CSS, a lot of it, my friend noticed my passion and suggested maybe we should do a project together.

First Try

With no skills in design, just the web fundamentals (HTML, CSS, JQuery) and the ambition to learn React, it was time for my friend and I to build a project. My friend @j_lo857 took on the role of the backend developer and started learning firebase. On the other hand I started prototyping couple of mockups thinking it'll be an easy task. Little did I know that designing a good interface is a whole different skillset. Let me show you the first prototypes

Everything is screaming for attention, It's a mess. I realized that summer that I needed to improve my design knowledge and that's exactly what happened. I spent that summer learning the design principals and experimenting. Gfree has been in the shadows for a few months due to university.

University

2018 is my bachelor year, I had to focus on my studies. I improved a lot, all the stuff I learned during summer gave me huge confidence. Actually it was overconfident. We still discussed Gfree, we decided the user flow for writing stories and recipes. During the end of the first semester holidays, we made another try. This time we decided to jump into code directly. How hard can it be? it's an interface and some dynamic content. Here is the result.

Since I didn't design, things got out of control, it was hard to keep things consistent. Also my overconfident in my React skills drove me blind, there is more to the Javascript world than React.

The code became very complex, this was an eye-opening, front-end work isn't easy. It still requires all cs things I learned. It's not just HTML and CSS.

We learned that we need to design the interface, design the system. Create a management framework to follow. It was a lot of work we decided to delay it till we finish university.

During that year I meet a new friend, he's was interested in working with us, and so it was. Also, we all got our computer science bachelor's, good times.

Building Gfree

2020 has been such a year, fortunately, we managed to get a freelance job. We learned a lot and we finally were ready to work on Gfree fulltime.

We designed the system behind Gfree, we made sure we have concise requirements, and the same shared model between the frontend and backend. This wiki came handy in keeping the project consistent.

UI/UX Design

@dinasso1 and I worked on the UI/UX design. We first started by choosing a color palette. It has to convey calmness for users, that was our main goal.

In Figma, as naming convention, we chose color+shade so for primary color, we had primary100 -> primary900 and primary is the darkest variation of the color. This came very handy in the development.

For Typography we built a system with Inter font.

The naming convention in the typography system also came very handy. It made the development of the UI more robust.

This is how the design file made by two newbie designers

I'm proud of the job we have done, it's not perfect and probably never will be. This how we learn, from our imperfections amiright ?

Frontend

One of our website requirements was SEO, and client-side react isn't suitable for that case. We also need Opengraph previews. NextJs solved those issues, and its routing system made everything super intuitive. NextJs is so awesome it requires its own article ( maybe next one ?).

When it comes to CSS, it depends on preference, we like styled-components so we used it. On top of it, we used xstyled. It made our life 10 times easier. Remember the naming conventions we had in Design. We could use it directly in styled syntax with xstyled.

import { styled } from "@x-styled/styled-components";
const Button = styled.button`
  background-color: primary100; /* This is awesome */
  ${h100}/* This how we used our typography system*/
`;

Frontend Stack: NextJs, Styled-components/xstyled, Typescript, Redux, Formik, SlateJs.

State management

For state management, we went with Redux. But if you have used it before, you'll know it has a lot of boilerplate. More code, more things to maintain. Fortunately for us, I've experimented with Rekit before and I loved the way they architected their redux code. A bit of googling led me to the Ducks pattern.

Ducks pattern is a modular way to organize your redux code, it has a few rules.

1. MUST export default a function called reducer()
2. MUST export its action creators as functions
3. MUST have action types in the form npm-module-or-app/reducer/ACTION_TYPE
4. MAY export its action types as UPPER_SNAKE_CASE, if an external reducer needs to listen for them, or if it is a published reusable library*

You can learn more about it here.

While this pattern made reading and managing the code easier, we still needed a way to generate the code as Rekit did.

We tried a code generation tool called Hygen. It did work fine for generating code. But when it comes to updating code, it didn't work. Hygen relies on regular expressions to update the code, it's hard to work with it when you format your code with prettier. It was unpredictable.

So I searched for a way to update the code using AST, here I come across Babel. Babel is huge, I used this awesome handbook to get familiar with it. It took a while but I'm proud of learning it.

Learning AST unlocked a lot of new doors for me. I can write a Babel plugin. I can even create my own custom Eslint plugins if needed. The deb tool I built: Redux Generator

Components architecture

Our solution is a bit hybrid, we took what we liked from different concepts.

Atoms define the components that have one and only one task. (Button, Headings, Fields...).

I've made this concept explaining each Layout component.

I noticed repeated layouts across many components, I think we could add Patterns (the composition of layouts components ). That for sure will reduce some of the boilerplate.

We try our best to not use margins within non-layout component styles. We only use margin in the Layout components. What may look like a small non-significant change to you, actually removed many undesired CSS bugs.

Backend

Things in the backend were straight forward. Controllers handling database queries. Authorization middleware to handle signing and signup operations. Endpoints handling requests from the frontend.

Backend stack: NodeJs, ExpressJs, PassportJs, MongoDb, Jest → For testing.

For DevOps, @j_lo857 took care of hosting and file storage solution.

Lessons Learned

Building a project is no easy task, it requires thoughtful and consistent execution. Trying to cut things off just to speed up has the complete opposite effect, it slows the project drastically. It also leads to technical debt, we learned this the hard way. Hacky solution may meet the requirements now but for sure will introduce many challenges in the future.

What's next for the project

For the project, we need to discuss marketing strategies, we also have many features in mind. This is our learning playground. We will experiment with new features regularly.

For friends and I, this project allowed us to prove that we can build things. Getting a job after graduation as a junior developer is a hard task, and this pandemic made it even. Hopefully, this project shows our competence and enthusiasm.