DEV Community: Ayush Kaushik

Spec-Driven Refactoring: What I Learned from Handing an 800-Line Java Monolith to AI

Ayush Kaushik — Tue, 20 Oct 2026 16:41:03 +0000

With AI models and coding tools getting increasingly powerful, it feels developers are stuck in two contradictory narratives:

Developers are finished.

And

AI will not replace developers, but a developer who understands how to use AI will replace one who doesn't.

Between the bold predictions and endless "X technology is dead" Youtube videos, I wanted to see what AI-assisted development looked beyond a greenfield demo.

What would it feel like with a mature codebase with existing behaviour, some questionable design decisions, and most importantly a developer who had to live with the consequences. So I decided to experiment on myself...

Part 1 - Setting Up the experiment

Why a Brownfield Project?

When I explored AI-assisted development, I found TONS of information online. But most of tutorials were focused on greenfield projects.

A greenfield project starts from scratch, giving you the freedom to establish its architecture and structure.

That is useful, but it wasn't what I wanted. The hard part of software development isn't always creating something new. Sometimes it is opening a project two years later and asking:

"Why on earth did I write it this way?"

That was the experiment I wanted. So, I chose one of my first university programming assignments, written when I was still learning object-oriented programming. Having started with C, I was more accustomed to procedural programming, and that experience influenced how I approached the assignment. It is pretty evident from how I originally wrote this assignment:

Link to original source code

The application itself was fairly simple. It was a console-based electronic store application where a user could store and query books and electronics. When the program ended, the catalog was written to a file.

Simple enough.

Except the application had validation rules, product-specific behaviour, search functionality, and persistence to account for. And all of it lived in a single 800+ line God class that drove the entire application. The code worked, but its design left plenty of room for improvement. That made it a good candidate for testing whether AI could help refactor an existing codebase without breaking its behaviour.

What was I Actually Trying to Learn?

I went into the experiment with a few questions:

Does AI-assisted development deliver a meaningful return on investment, beyond simply generating code faster?
How much of my development workflow should AI actually own?
Would AI become the central piece of my programming workflow or would it remain what the name suggests: a Co-pilot (Ba dum tss!)
And, of course: will it replace me!?

For this experiment, I used free tier of GitHub Copilot in auto mode. Mostly because I wanted to measure its usefulness before paying for it. There was another constraint that became increasingly important later.

Tokens

But we'll get to that.

Before I Let AI Loose on the Codebase

Luckily, I had created a README when I submitted the assignment. It documented the application's intended behaviour and gave me something valuable: context. Back then, the README was something I wrote to avoid losing marks. Little did I know I was doing my future self a favour.

Before refactoring anything, I needed a baseline to check whether the application still behaved as expected. I started by looking for seams: places where I could isolate or control parts of the application's behaviour without rewriting the surrounding code.

I learned this concept from Michael Feathers' Working Effectively with Legacy Code. Seams gave me opportunities to isolate behaviour and introduce tests before making larger changes.

Establishing a Behavioural Baseline with Gherkin

I chose Gherkin and Cucumber for my behavioural tests. I'd worked with Gherkin before, although not in Java, so the concepts were familiar even if the setup wasn't. Gherkin lets you describe application behaviour using a simple Given-When-Then structure. Cucumber connects those scenarios to executable tests.

For example, a product search scenario might look like this:

  Scenario: Operator runs the program, adds a book, then searches by name
    Given a new catalog file
    When the operator starts E-Search
    When the operator adds products with:
      | type        | productID | year | name          | price  | authors  | publisher       | manufacturer |
      | book        | 123456    | 2023 | Learning Java | 45.99  | Jane Doe | Education Press |              |
    And the operator searches for products named "Learning Java"
    Then the search result should contain 1 products

The goal was to treat the application as a black box: provide input, observe the output and verify that the result matched the expected behaviour.

Setting up the tests was another task I could have delegated to Copilot. Instead, I watched a tutorial at 2x speed and set up the project myself.

Why?

These tests would become my baseline for evaluating the refactor. I could have asked Copilot to generate them, too, but I wanted to define the expected behaviour independently of the AI doing the refactoring. Otherwise, I risked testing the AI's interpretation of the requirements rather than the application's intended behaviour.

Static Analysis with SonarQube

Behavioural tests weren't enough. They could help me detect changes in tested behaviour, but they wouldn't tell me everything about the resulting code's maintainability or static quality. I also used SonarQube to assess the code. This gave me a second perspective on the refactoring: not just whether the application still worked, but whether the code itself had improved. This was one area where I let AI assist me, and the results were impressive.

Part 2 - The Experiment

Day 1: I had to figure out how to tell AI what I Actually Wanted

This was where things became interesting. I knew what I wanted to improve but I didn't necessarily know the best implementation. That distinction turned out to be extremely important. I started researching how people were structuring AI-assisted development and eventually landed on a spec-driven approach (spec is short for specification).

Instead of telling AI: "Refactor this class.", I would define the desired outcome, the constraints, the behaviour that must remain intact, and the boundaries of the change. Then I would let AI figure out the implementation.

I created a .spec folder at the root of the project and a refactoring section inside it. Each refactoring had a number prefix corresponding to the GitHub issue or piece of work. For example:

./spec/refactoring/1-extract-file-reading.md

Each specification followed a lightweight structure:

Goal

...

Current Implementation

...

Desired Implementation

...

Behaviour to Preserve

...

Acceptance Criteria

...

I kept the format flexible. Not every refactoring required every section and you'll notice that in my rafactoring files as well. Heck, even the file naming was loose, I kept the prefix consistent but the phrase that followed was for humans to quickly understand its purpose.

Template wasn't the core piece. The important part was that I was starting to separate what I wanted from how I wanted it implemented. That was a subtle shift. And initially, I didn't fully understand it.

My first attempts were messy. I was still thinking like a developer who was writing the code myself. I would describe something I wanted changed and then mentally jump ahead to the implementation. But if the point was to have AI perform the implementation, I had to stop doing that. Instead, I needed to become much better at describing the problem. I know this sounds obvious but it wasn't.

The more I worked this way, the more I realized that it was an extension of what I was already doing:

Spending a good amount of time just thinking and defining the problem before implementing it.

If I can't clearly describe what I want changed, how am I expecting an AI model to correctly implement it? This became one of the first major lessons from the experiment.

AI doesn't remove the need for clear and critical thinking. It increases the value of it.

Day 2: I Had to Stop Designing Every Detail

This was one of the strangest parts of the experiment. I had to unlearn the reflex to design the implementation before handing the work to AI. Normally, I'd see a problem and immediately start thinking:

"I'll create this class, move that responsibility there, inject this dependency, change this method..."

Even if Copilot was going to write the code, I was still making all the design decisions. So I started describing refactorings in terms of their intended outcome, boundaries, and behaviour that needed to remain intact. I left the implementation open where I could.

I didn't bother with the traditional "As a user, I want..." format. A concise description and a refactoring specification were enough for the kind of work I was doing. The difficult part was figuring out which details were genuine constraints and which were simply my first idea for a solution.

If I specified every class and method, I was effectively asking Copilot to implement a design I'd already made. If I described the desired outcome and relevant boundaries instead, it had room to propose a different approach. That didn't mean blindly accepting whatever it generated. I still had to evaluate whether its approach made sense.

The challenge wasn't just telling AI what to do. It was knowing what I needed to decide myself, and what I could leave open for AI to solve.

Day 3 - The Workflow Started Taking Shape

As I continued, a repeatable workflow emerged:

This was very different from simply asking AI to write code. The specification became the thing I iterated on. If the AI produced code I didn't like, my first instinct was no longer:

"Let me fix this code."

Instead, it became:

"Did I give it enough information to make the decision I wanted?"

Sometimes the answer was yes: the AI simply made a poor implementation choice. Sometimes the answer was no and the specification was missing an important constraint. That distinction was incredibly useful.

Day 4: AI Was Smart, but It Was Also Gullible

By this point, I'd started thinking about AI differently. Copilot could understand the existing architecture, make changes across multiple files, and implement fairly substantial refactorings. But capability wasn't the same as reliability.

I started thinking of it as a very smart but gullible developer. It could move quickly, generate a lot of code, and propose approaches I wouldn't have considered. But it could also confidently head in the wrong direction if it misunderstood what I wanted.

My role didn't disappear. The work shifted.

Instead of writing every part of the implementation myself, I spent more time understanding the architecture, evaluating design decisions, reviewing changes, and checking that existing behaviour was preserved. I also had to revisit my specifications when they left too much room for misinterpretation. In some ways, I became more involved in the system, not less. I was delegating implementation, not engineering judgment.

Day 5: The Process Finally Clicked

By around Day 5, the process had started to feel natural. I was getting more comfortable breaking refactoring work into smaller changes and giving Copilot enough context to implement them without prescribing every detail.

Something interesting was happening: the codebase was getting smaller, while the documentation was growing.

The giant EStoreSearch class, which had originally contained a lot of responsibilities, was gradually being broken apart. Meanwhile, the specifications documenting each change and the reasoning behind it were piling up.

I didn't want that documentation to become another thing I had to maintain manually. With help from AI, I worked out how to organize the project's specs and documentation into a Docusaurus site. I then set up GitHub Actions to build the site and publish it to Cloudflare Pages whenever changes were made.

Live Documentation

The code was becoming simpler, and I was building a clearer record of how and why it was changing.

One of the biggest benefits wasn't just having AI generate code faster. It was having to make my understanding of the system explicit—and leaving behind documentation that I could use long after the experiment.

Link to refactored code

What didn't go according to plan

The Token Limit Problem

Remember that I was using the free tier of GitHub Copilot. That meant I had to be selective about what I delegated.

In theory, I could ask AI to analyze the entire codebase, explain the architecture, implement a change, review its own work, and explain every decision. In practice, that wasn't always worth the usage or the time. Sometimes, fixing a small mistake myself took ten seconds. Explaining it to Copilot, waiting for another response, and reviewing the change could take several minutes.

AI doesn't need to be involved in every step of development.

I started weighing the cost of delegating a task against the cost of doing it myself. That wasn't a failure of AI-assisted development. It was part of learning where the tool actually provided value.

AI is a tool. It doesn't get bonus points for being involved in everything.

Context Became a Problem

As I became more comfortable with the workflow, I started paying more attention to the context Copilot used. I had old README files, outdated documentation, and remnants of the original architecture sitting alongside specifications describing the intended changes.

Some documents described how the system used to work. Others described how I wanted it to work. Without a clear distinction, they could give the AI conflicting signals.

I began cleaning up outdated documentation and thinking more carefully about which files should be treated as authoritative. A specification describing desired behaviour serves a different purpose from an implementation note, and historical documentation shouldn't automatically be treated as current guidance.

I was learning that documenting a project wasn't just about recording information. It was also about making clear which information to trust, and for what purpose.

Garbage context can produce garbage decisions just as easily as garbage code can.

My Tests Caught What Copilot Missed

Even with specifications and a defined workflow, Copilot didn't always get things right. In one instance, I had explicitly documented the behaviour that needed to be preserved and the boundaries of the refactoring. Yet Copilot still produced a change that failed to account for an expected behaviour. When I questioned it, it acknowledged that it had missed the relevant documentation.

I reran the prompt, and it produced a correct implementation on the next attempt. But the more important part of this experience wasn't that Copilot made a mistake. It was that my independently written end-to-end tests caught the regression before I merged the change.

I didn't have to rely on Copilot to recognize its own mistake. I had an independent way to verify the behaviour That was the value of establishing a behavioural baseline before starting the refactoring: I could evaluate the result against expected behaviour instead of simply trusting that the generated code looked reasonable.

Keeping the Specs in Sync

There was another trade-off I hadn't fully anticipated: the specifications could become stale, too. As the refactoring progressed, I had to keep the code and specifications aligned. If I changed an implementation detail without changing the intended behaviour, the specification might remain valid. But if I wanted to change what the application actually did, I needed to revisit the specification as well.

That added discipline, but it also introduced friction. I couldn't write a specification once and treat it as permanent documentation. It had to evolve alongside the code.

The process also made me more deliberate about behavioural changes. Rather than quietly changing what the application did while refactoring, I had to recognize that I was changing the expected behaviour and update the specification accordingly.

The specification wasn't just a way to guide the implementation. It became another part of the system I had to maintain.

So, Did AI Replace Me?

Partially, yes.

AI took over parts of the work I used to do myself. It handled boilerplate, navigated the existing codebase, and turned well-defined specifications into working implementations. Tasks that would have required me to write every change by hand could now start with a conversation and a specification.

But I still had to decide what was worth changing, what behavior needed to be preserved, and whether the generated code was actually an improvement.

And the more I used AI, the more I realized something: getting code written was only one part of the job.

The harder part was understanding the system well enough to know what to ask for, giving AI the right constraints, and having independent ways to verify its work. Even my specifications became something I had to maintain. I wasn't simply handing work off; I was taking responsibility for a different set of decisions.

I started this experiment wanting to understand how useful AI could be at refactoring an old codebase. I came away with a better understanding of how I wanted to approach software development itself: define the problem, make the intended behavior explicit, change one thing at a time, and verify the result.

AI did take work off my plate. It also made the quality of my thinking more consequential.

It didn't eliminate the need for an engineer. It changed where I needed to be one.

But with that being said, I would still manually program for recreational purposes just because I enjoy doing it. Sure, it may not be the most efficient use of my time because what I would spend programming 4 hours may be done in a couple of minutes or even seconds. But its the act of actively being involved in writing code, compiling, running it and seeing that it worked gives a great feeling which does get lost when AI takes over some of the steps.

I was most efficient when I was performing spec driven refactoring but had most fun when I wrote the tests myself.

Safely Collect User Feedback with Cloudflare Workers + Slack

Ayush Kaushik — Sun, 28 Sep 2025 21:21:33 +0000

TL;DR → Don’t expose API keys in frontend. Instead, use serverless functions (Cloudflare Workers) to safely handle user feedback and add a layer of security against bad actors.

So... I Revisited My Portfolio

You know that feeling when you revisit your old projects and wonder what you were thinking? Yeah, I had that moment while reviewing my portfolio site (React + GitHub = Professional Portfolio Website)

Upon reviewing my existing work, I discovered a glaring security risk! I injected Firebase API keys into the react app to push user feedback directly into Firestore... with no read and write restrictions.

This meant anyone can read/ write to my FireStore without restriction. Moreover, I wasn’t really notified when new feedback was submitted, so I missed out on important messages.

My goals were to make following improvements:

Remove security defect and receive notifications.
The new solution must be low cost/ free since this is a hobby project.

Let's get to work 👷‍♂️🏗️

Remove the vulnerable code

I ripped out the Contact me section. That's where I initialized Firebase app instance and exposed API keys via good old REACT_APP route to a vulnerable Firestore instance. I also deleted the firestore project so the credentials embedded into my code cannot be misused.

Key learning: Never inject sensitive data into frontend code

Explore options for Serverless functions

To securely handle user feedback without exposing API keys, I explored serverless functions.

Since this is a hobby project, I wanted a free solution. I started exploring different options and stumbled upon CloudFlare Workers which offers up to 1000,000 invocations per day source.

Honestly, if my portfolio form ever reaches that many feedback or collaboration requests, I’d consider it a great problem to have — and only then would I think about paying for extra capacity. 💵💵

**Or if a bad actor decides to run a Denial of Service attack on my function then I'll use up my daily request limit and will have to wait for the limit to reset.

Workflow

So, the game plan is, the Contact me form submission invokes a serverless function that receives request, verifies the data and perform the required action. Thus, the sensitive keys remain on the server-side only, not visible to the user, making them much harder to compromise.

Cloudflare Worker Setup

Full guide

You can also checkout my code for contact-worker: Contact Worker Source Code

For testing, I followed this article to perform behavioural tests on my function locally before I could really deploy it for the world to use: Behavioural tests with vitest

To deploy the worker, I used GitHub workflows and passed the required keys via secrets.

You can checkout my workflow file: GitHub Workflow

With the backend ready and deployed, you can modify the Frontend to send requests to the function.

⚠️ Ensure your serverless function handles preflight requests. Without this, CORS may block requests from the browser. You can check how I handled it here: CORS Support

Pass all the credentials via Dashboard as secret

Go to Cloudflare Dashboard > Compute Workers > Workers and Pages > Select the worker you deployed > Settings > Variables and Secrets

Define all the secrets here.

The benefit of defining secrets instead of environment variables is it doesn't get overwritten when worker is redeployed via GitHub workflow. The wrangler.toml file doesn't take precedence.

Setup Slack bot and Channel

To relay message from worker to slack, we will need a slack bot. There are tons of tutorials and videos online about the setup. Here is the one I followed: Send Message to Slack with a Node.js Script

Again, you can reference my worker implementation to understand how I enabled it.

Result

Front end contact form

The submission process remains the same. The difference lies in how the request from frontend is handled and responded to.

Message received in Slack channel

Benefits of this approach

With Cloudflare workers, I have increased visibility into where the requests are originating from so I can promptly respond to bad actors and block them if required.
I have more control over kind of data I accept, any malicious data can be stopped at worker before relaying it to Slack as a message.
Credentials are stored as secrets so bad actors will have a hard-time deducing them.

Future improvements

Rate limiting is a paid feature provided by Cloudflare so I will need added protection against DDOS attacks. I will come up with my own rate limiting design to handle such cases (if they occur).

Hope this article gave you some insights into security practice and technologies used!

Feel free to comment below if you have more ideas on improving my strategy and feedback 😊😊

Introducing NeighborsNetwork: Your Neighborhood’s Social Hub Built on Wix!

Ayush Kaushik — Sun, 27 Oct 2024 03:17:24 +0000

This is a submission for the Wix Studio Challenge: Community Edition.

My Community Platform

Platform name: NeighborsNetwork 🏠

In today’s digital age where everyone is digitally connected, I always wondered why shouldn't we have a dedicated digital space for neighborhoods to thrive! So, I came up with the idea of NeighborsNetwork 🏠.

My aim is to create an inclusive online platform where residents of a community can connect, share information, and engage effortlessly. I will showcase how Neighbors Network was built using WixStudio, highlighting its key features and design choices.

Key Features:

🗣️ General Forum
A digital bulletin board where HOA admins and members post community-wide updates. It includes but not limited to announcing improvements, new regulations, or events. The General Forum keeps everyone in the loop.

🌐 Community Circles
An informal space where members can create and join interest-based groups, connect on shared interests, and collaborate on projects or events. I pre-created some groups like gardening circle and neighborhood watch group but you can try it out yourself and create more!

📇 Resident Directory
A directory for residents who wish to be reachable by their neighbors.

💬 Members Chat
A one-to-one or group chat that allows members to send messages to each other.

🎉 Local Events Management
NeighborsNetwork lets members create, manage, and sign up for community events. So if you're planning neighborhood barbecue, holiday gathering, or volunteer event, create an event and let your neighbors know about it!

Secure, Simple Navigation
Just like how other famous social media platforms prioritize security, NeighborsNetwork is built with security in mind. Only registered users can access the platform, ensuring a private experience for the community.

Demo

Home | My Site

anonprogrammer305.wixstudio.com

Home Page:
NeighborsNetwork is secure by design, preventing access to any pages without proper login.

Simple Navigation Menu:
Only essential menu items are displayed, ensuring a simple, intuitive navigation experience for all users.

General Forum:
A dedicated space for important announcements from HOA admins to all residents, fostering open, formal discussions.

Community Circles:
Residents can create and join interest-based circles to meet and interact more casually.

Event Management and Signup:
Members can organize, view, and sign up for local events with ease.

Members Chat:

Development Journey

Velo APIs

GeoLocation API: Most of the heavy lifting was done by no-code apps anyway but I did find some unique use cases for Velo API. First is the GeoLocation provider API. I utilized it to find users location and show them their current weather based on it.

I created a custom GetWeather method in public directory which contacts an open source weather API and based on the location collection from WiX API, I was able to get the correct weather. This becomes handy when users are trying to plan an event and want to see what the weather might be like!

Animation API: I learned how to animate logos and built a small zoom in and out animation for the logo on main menu bar. It is very subtle since I didn't want to distract user's attention from site by becoming too intrusive.

Wix Apps

I'll be honest, if I were to design all the features from scratch then I would've made this submission next year 😂

What I liked about Wix Studio are the wide collection of apps which require simple installation and minimal setup to become production ready.

I have listed all the apps and their usages below:
Wix Members Area: I used this to manage user accounts, login and signup. Before knowing about menu page permissions, I tried to programmatically add the permissions. But it also allowed me to show specific pages based on user's login status.

Wix Groups: I used this for building Community Circles. When I was planning to build the Platform, the idea of managing community and posts seemed daunting at first. But I was able to quickly get it up and running with this app.

Wix Events and Tickets: I used this for Events page. This is again a very feature rich app and I was able to create recurring events with ease as a demo.

Wix Chat: I used it for members only chat feature. At first, I thought this feature only allowed site visitors to send message to the admin. But it went above and beyond and let me securely add a chat feature which only works once user logs in.

Wix Forum: I used it for the main General Forum section. I didn't need to make much changes here as it already included features I required from get go.

Wix Blogs: I used it along with forums to allow users to create and post blog articles.

Wix Logo Maker: I used the AI feature to build the logo.

React + GitHub = Professional Portfolio Website

Ayush Kaushik — Thu, 26 Nov 2020 05:12:32 +0000

tldr; I have documented how to use ReactJS, SCSS, and GitHub to quickly build and host your portfolio website.

I believe that a portfolio website is an incredible way to showcase your skills and creativity. So to get inspiration for my portfolio I did what most people would do, started digging through different programming subreddits 😛

After looking at countless portfolios, I found some neat examples. However, as I started building my website, I realized that there were so many aspects and requirements that I didn't plan beforehand:

Where to host the website (for free)?
How to make it responsive with different screen sizes?
How to organize information?
How to make it self-updating (partially)?
How to add images to my project?

Most importantly how to organize the content so you could not only build the website but extend it as you add new and exciting projects to your list of accomplishments 🚀

This motivated me to document my website building process from start to finish and hopefully, it'll give you some ideas to start your own portfolio website.

Pre-requisites

GitHub account
CSS experience as it'll help you to grasp SCSS faster
ReactJs knowledge
Dropbox account for image hosting

If you need help with any of the above, I have linked some resources and video tutorials below 🤝

Step 1: Setup React Project
Step 2: Setup GitHub Repository
Step 3: Setup dropbox for hosting
Step 4: Organize Components
Step 5: Styling with SASS
Step 6: Deploy for free

Step 1: Setup React Project

Run the following command to create-react-app:

npx create-react-app portfolio

This will setup the complete react project with all the required files. To run your development server, run the following command:

npm run start

Usually, your server opens a tab on your default browser and runs the application on http://localhost:3000

Awesome! Now lets set up our repository so we can use GitHub pages to host our website and keep our work someplace safe 🔒

Step 2: Setup GitHub Repository

Setting up the repository is pretty straight forward. Make sure you flag the repository as public since it'll be needed for hosting.

Follow this link for setup.

Now link it to the React project that we set up locally. Using terminal, cd into the project and enter:
git init

Now, get the link for your newly created git repository and enter the following command (replace the URL with your repository URL):

git remote add origin git@github.com:username/new_repo

This will connect your local portfolio instance to a remote repository. At this point, you can start pushing your code and we'll utilize the gh-pages npm package to build and deploy the portfolio website on GitHub pages.

If you have any questions, please feel free to comment below and we can figure out any issues 🙂

Step 3: Setup Dropbox for hosting images

You can totally skip this step if you are planning on using a different method for hosting images. I was trying to find something free and stumbled upon an efficient way of using dropbox for creating a publicly accessible URL for my images.

Here are the steps:

Log into your dropbox account
Create a new folder
Now upload your images in this folder

Click on the ellipsis as shown in the image and click share:

A pop-up will appear with a sharing link at the bottom. Leave it to default options ('anyone can view') and copy the sharable link.

We're almost there, now if you enter this link in a new tab, you'll notice that the image is opened in dropbox viewer but we need a raw image that could be used on the website.

https://www.dropbox.com/s/shdjsdhjsdjshdsjh/0.jpeg?dl=0

In the shareable URL replace ?dl=0 with ?raw=1 and visit the link again. You'll notice its actual raw image being displayed! 💃

You can upload as many images and use their links in the <img> tag of your react application to render images in your portfolio!

Step 4: Organize Components

I used the following directory layout to organize the components and styles:

src
│
└───components
└───constants
└───context
└───pages
└───styles

components: This directory contains components specific to each page/ view
constant: The information that remains somewhat similar unless small changes are required is placed here. For example, I placed constant information for experience in the following format:

export const EXPERIENCE = [
    {
        "workTitle": "",
        "description": [],
        "timeline": "",
        "image": "",
        "company": {
            "name": "",
            "link": ""
        }
    },
    {
        "workTitle": "",
        "description": [],
        "timeline": "",
        "image": "",
        "company": {
            "name": "",
            "link": ""
        }
    }
]

I organized data into JSON to render this information easily in the presentational components.

context: All the context files were organized in this directory. One of the main reasons I used React context hooks is to prevent the need for passing information (props) from parent to child to grandchild to great-grandchild..... 🥱😴

* I used to pass information from one component to the next when was a rookie, but this made data handling in my projects a nightmare. Instead, I have now started using context hooks. For a formal explanation follow this link

* Now that you have read about context and how it's used, I'll show you how I used it to make my program self-updating in the next section.

pages: I used this directory to organize main views of the website - such as projects, experience, contact me, etc. So this is a large container that holds presentational components.
styles: Since I used SCSS for styling, I created different files that hold information to style the functional components.

Step 4: Styling with SASS 💁‍♀️💁‍♂️

Very Important: Always design for mobile-first, You'll thank yourself later!

The reason why I decided to switch to SASS from CSS:

It became very difficult to manage and organize the CSS code as the project size increased
I was failing the DRY (Don't Repeat Yourself) principle as the number of components increased since they used the same CSS classes with minor changes.

SASS is a preprocessor scripting language that is compiled and interpreted into Cascading stylesheets. Here are the benefits that I found:

I was able to split the CSS code into more meaningful files and import them into a single index.scss file
I used variables to define values for colors, font-size etc. in the index.scss and used it in other files. This helped me to quickly make changes since there was a single point of change now.

Best part, It forced me to plan out how to style my components and follow the DRY principle. For example, I used _Layout.scss, _Card.scss where I defined the common layout which was used in different views.

I would highly recommend reading the documentation

Step 5: Deploy our Portfolio

I was finding a way to deploy my website to GitHub pages and came across this post written by Ibrahim Ragab.

Hence, I used the gh-pages npm package to deploy the application on GitHub.

** Important: I created my website without react-routers, so if you are planning to add different pages, you might need to make changes to gh-pages configuration accordingly **

Install the gh-pages npm package as a dev dependency: npm install --save-dev gh-pages
Update your scripts in package.json to add two more key-value pairs: predeploy and deploy

Test out if our react-app deploys as expected. npm run deploy

This will build our react application and deploy it on the public GitHub repository under gh-pages branch.

Now go to your remote repository and go to settings and scroll down all the way to ** GitHub Pages ** section. You will see the source dropdown. Select the dropdown and choose gh-pages branch to serve the latest built code to your GitHub pages.

If you go to the link, the website should be visible. Now, you can work on your website locally and redeploy it to add new updates.

** Make sure you push your work to one of the other branches **

How to make your website self-updating?

I am sure as you learn new skills and create new and exciting projects, You would want to update your website to showcase these projects. What if I told you, your website will automatically update itself to show your new projects and articles 👽👽

Here's how I did it for mine:

Showcasing GitHub projects:

GitHub has (API)[https://developer.github.com/v3/] that can be used to extract different information about our public repositories (in JSON format). I created a ProjectContext file that accesses the projects endpoint using a GET Axios request. Then I passed down this information via the ProjectProvider. The functional component takes this data, loop through it and display is nicely using SCSS style:

Showcasing Dev.To Articles

Same as GitHub API, DEV.to also has an API that can be used to brief details about an article. I created another context file and provided information to my functional components.

Resources

Firebase Auth + React

Ayush Kaushik — Sun, 11 Oct 2020 21:36:32 +0000

Hi! I recently learned how to enable authentication in my React application via Firebase. The process is somewhat straight forward once you connect the dots but it took me some time to find those dots and connection :p

So I thought to myself, why not document it so you can also enable authentication in your application! :)

I would really appreciate your feedback to improve this post. Lets get started:

Step 1: Setup Firebase Project

Before integrating Firebase into our React project, I'll go over configuring a project in Firebase for Authentication. Go to Firebase and click on Go to console button on top right corner.

You'll be redirected to your list of firebase projects. Create a new project. I'll name mine "test".

After entering a suitable name for your project, click Continue and you'll be redirected to enable Google analytics page. It's up to you to enable/disable this as it does not affect our setup.

Now wait for Firebase to perform its magic and setup your project...

When the project is ready, we'll be redirected to the project console. On the sidebar, you'll see a number of menu items:

Select Develop menu item and you'll see a list of sub-menu items:

To enable authentication, we'll need to setup a sign-in method. Click on authentication menu-item and you'll be redirected to Authentication page. Click on Sign-in method and you'll be directed to the sign-in tab:

You'll notice that all the sign-in methods are disabled. We'll enable Email/Password method for our React application. When you scroll down, you'll notice the Authorized domain section where you can add domains for oAuth redirect.

and thats it! we have setup our project but how will we connect this project to our React application?

Glad you asked, that'll be done by fetching the configuration details. Before we do that, we'll need to setup a web app in firebase.

Step 2: Setup Firebase Web-App

To setup the web app, we'll need to go to homepage of our console, click on the Project Overview menu-item in the side-bar.

In the main dashboard page, select the </> button as highlighted below:

Clicking on this button will slide-in a window with title: Add Firebase to your web app. I'll name mine test-app. If you would like to use firebase for hosting your application, you can check the box. However, I'll not cover that step in this post.

When you click on Register app button, you'll be presented with two script tags containing important configuration that'll help us to connect the firebase project to the React application.

It'll look like this:

<!-- The core Firebase JS SDK is always required and must be listed first -->
<script src="https://www.gstatic.com/firebasejs/7.23.0/firebase-app.js"></script>

<!-- TODO: Add SDKs for Firebase products that you want to use
     https://firebase.google.com/docs/web/setup#available-libraries -->

<script>
  // Your web app's Firebase configuration
  var firebaseConfig = {
    apiKey: "XXXXXX",
    authDomain: "XXXXX",
    databaseURL: "XXXXXX",
    projectId: "XXXXXX",
    storageBucket: "XXXXXX",
    messagingSenderId: "XXXXXX",
    appId: "XXXXXXX"
  };
  // Initialize Firebase
  firebase.initializeApp(firebaseConfig);
</script>

Perfect! Now we have the necessary credentials needed to enable firebase authentication in our React app. Next up we'll configure our React app.

Step 3: Enable Firebase Auth in React App

I'll skip over the steps where you have done create-react-app, created your application and can do npm run start to get it running.

We'll start with installing the firebase package. Use the terminal to go inside the root directory of your react app and type following:

   npm install --save firebase

Step 3a: Setup .env file

Create a .env file and place it in the root directory of your React project. Important: Make sure you have added the file in .gitignore since the content of .env file is confidential.

REACT_APP_API_KEY=XXX
REACT_APP_AUTH_DOMAIN=XXX
REACT_APP_DATABASE_URL=XXX
REACT_APP_PROJECT_ID=XXX
REACT_APP_STORAGE_BUCKET=XXX
REACT_APP_MESSAGING_SENDER_ID=XXX
REACT_APP_APP_ID=XXX

The value of these keys is the configuration data that we collected from step 2.

Step 3b: Create Firebase Component

Create a component named Firebase.js that will be used to initialize our Firebase instance.

import firebase from "firebase/app";
import "firebase/auth";

const config = {
    apiKey: process.env.REACT_APP_API_KEY,
    authDomain: process.env.REACT_APP_AUTH_DOMAIN,
    databaseURL: process.env.REACT_APP_DATABASE_URL,
    projectId: process.env.REACT_APP_PROJECT_ID,
    storageBucket: process.env.REACT_APP_STORAGE_BUCKET,
    messagingSenderId: process.env.REACT_APP_MESSAGING_SENDER_ID,
};

firebase.initializeApp(config);
export const auth = firebase.auth();

Step 3c: Utilize Firebase auth via React Context

React allows sharing of data globally among component tree via context. We'll create an Auth context component that'll handle all the functions related to authentication: Sign-in, Sign-out and Sign-up

import React, {createContext, useEffect, useState} from 'react';
import {auth} from "../components/Firebase";

export const AuthContext = createContext(null);

export const AuthProvider = (props) => {
    const [userState, setUserState] = useState(null);
    const [authPending, setAuthPending] = useState(true);

    const signIn = (username, password) => {
        return auth.signInWithEmailAndPassword(username, password);
    }

    const signUp = (username, password) => {
        return auth.createUserWithEmailAndPassword(username, password);
    }

    const signOut = () => auth.signOut();

    useEffect(() => {
        return auth.onAuthStateChanged((userAuth) => {
            console.log(userAuth);
            setUserState(userAuth);
            setAuthPending(false);
        })
    }, [])

    if (authPending) {
        return (
            <div style={{
                display: "flex",
                alignItems: "center",
                justifyContent: "center",
                height: "100vh"}}
            >
                <div>Authentication in progress</div>
            </div>
        )
    }

    return (
        <AuthContext.Provider value={{
            signIn: signIn,
            signUp: signUp,
            signOut: signOut,
            userState: userState
        }}>
            {props.children}
        </AuthContext.Provider>
    )
}

Now we need to provide the global data and functions via AuthProvider.

This is our index.js file:

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./App";
import {AuthProvider} from "./context/AuthContext";

ReactDOM.render(
    <React.StrictMode>
        <AuthProvider>
            <App/>
        </AuthProvider>
    </React.StrictMode>,
    document.getElementById("root")
);

That's it! Now you can use these functions in your application for authentication.