DEV Community: Ian Bonaparte

Front-End to Full-Stack Journey Part 3: Server Proxies, React and Progress

Ian Bonaparte — Thu, 09 Jan 2025 18:22:05 +0000

I am super proud to be writing a Part 3 of this journey, especially considering the amount of progress I have made since the last update. I was able to focus my ADHD superpowers for a couple of days straight on finishing up a few different courses that helped familiarize myself with writing JSX, and used the momentum to carry myself into learning React. But, being the impatient person that I am, I wanted to see how far I could get in setting up my local environment given the knowledge I've gained with Express, SQL and node so far.

Setting up the Proxy Server

This one was new to me, but I wanted to things "The right way". My app will be making API calls to my SQL database, and I want to have as little client-side processing going on as possible. So, I decided to host my database on a separate server that the client will make requests to, and return to the app. I probably could have kept the database in the client to save this step, but that didn't feel right. Plus, this whole journey is about learning, right?

I installed Nodemon to help here. For those who don't know already, Nodemon is a tool that helps by restarting the Node application everytime a change has been made to the code. This proved to be quite helpful as the trial & error was about to begin.

Getting the server set-up was actually quite easy. I created my server.js file, imported Express & Cors, and declared a variable for my SQLite file. I made a few very basic SQL functions to return all of the teams, all the users, and all of the games played from my database. I then created my app.listen() method to listen on port 8080 (this is important to remember later when setting up the client). This all went pretty smoothly. I did a couple console.log() messages to just troubleshoot some basic stuff, but overall, no big issues.

Here's a look at one of the API functions. This code updates the [teams] array with every user's info, and joins the user's info with their current team's info. So I can access an array from the client later that has all members of the league & what team they are currently controlling.

db.each(
  "SELECT * FROM users INNER JOIN teams ON users.current_team = teams.team_id",
  (error, row) => {
    users.push({
      user_id: row.user_id,
      username: row.username,
      current_team: row.current_team,
      twitch_name: row.twitch_name,
      platform: row.platform,
      school_name: row.school_name,
      team_name: row.nickname,
      team_abbr: row.abbr,
    });
  }
);

Setting up the Client

This is where I anticipated things might get a little tricky. I am still in the process of finishing up my React classes, so I thought I might be getting a bit ahead of myself here, but I had momentum and coffee, so I kept going. I created a separate client folder inside of my project and started a react project. I hit my first speedbump immediately because it was today I learned that create-react-app is no longer the best way to start a React application. After about 30 minutes of Google-Fu, I discovered Vite. To be honest, I don't really fully understand what Vite is besides it's now the best way to get a React project up and off the ground.

My main goal for the night was to create the most basic of basic "Hello World" React apps, with the caveat that I need to successfully access my database that is hosted on the server. For this, I just wanted to list out every user in the User array I posted above.

I am using Axios to fetch a response from my server proxy on port 8080 (the port I set the proxy to listen to as mentioned above) and setting a local array in the client to match what is on the server. Currently, I am just querying and storing the USERS array.

The code below is a basic example of how I am using React useState to fetch a list of all users and their teams. This is utilizing the SQL query I posted above, and exposing that info to the client.

  const [users, setUsers] = useState([]);


  const fetchAPI = async () => {
    const response = await axios.get("http://localhost:8080/api");
    setUsers(response.data.users);
  };

I created a super simple component on the homepage that displays a list of all users and their teams. I will add CSS later, but focusing on functionality now (I love CSS and styling this would derail me for 8 hours).

Each of these names is actually a link to a teams page. I am utilizing React's package to render a page dynamically based on the user that is in the URL.

If the Route path is "/team/:user" (the colon ':' indicates a url parameter), then we are telling React to render the component. The TeamPage component uses the axios fetchAPI to find the USER in USERS where the USERNAME equals the ":user" in the URL. From there we can use this object to return all team info. Right now, I'm just showing the username and their team but eventually this will show records, stats and more!

<BrowserRouter>
      <Routes>
        <Route path="/">
          <Route index element={<Home users={users} />} />
          <Route path="/team/:user" element={<TeamPage />} />
        </Route>
      </Routes>
    </BrowserRouter>

I am over the moon with the progress I have made on this project. I've already gotten further than I thought, with barely any frustrations. The patience I have shown by making sure to study the subject or language before tackling the next step has paid off.

Next, I am finishing my React courses on CodeAcademy because there are still things I don't fully understand that I am currently using (BrowserRouters, UseState, UseEffect) that I want to wrap my head around. I am getting close to an MVP launch! Just waiting for that next ADHD-inspired motivation!

Front-End to Full-Stack Journey Part 2: SQL & SQLite

Ian Bonaparte — Fri, 20 Dec 2024 21:48:15 +0000

In sticking with holding myself accountable on my journey, I am happy to be writing part 2. I've been quiet this past week or so because I am focusing on actually learning what I want to do, instead of just diving head first into the project and getting lost in tutorials. I am hopeful that my patience will pay off.

Code Academy

I took advantage of Code Academy's free courses and completed "Introduction to Backend Programming" and "Learn Node.js Fundamentals". This felt necessary for me as I've done React projects and other node projects before, but I never actually understood what I was doing with node. These courses definitely helped give me the basic understanding that I need. My brain has always worked in a way where I need to understand the why of something for it to click. I can't just be told what to do, my brain needs to understand the implications for it to fully set in for me.

I actually enjoyed these so much that I took advantage of the current holiday 50% off deal and signed up for a year. I love the way they lay the material out into chunked-up sections and give you exercises to test your understanding. It is a seriously great and intuitive learning tool. The phone app is also excellent. You can replace some mindless scrolling with some flash-card content on whatever topic you are attempting to learn. I'm not even sponsored or paid, but I highly recommend everyone check it out.

Express and Middleware

In my google queries of "How to connect React component to SQL database", I learned that I need another technology on top of Node & React. I also finally learned what the "E" stands for in certain stacks (MERN, MEAN, etc.) and why so many different frameworks are needed.

So, with my newly acquired Code Academy account, I have been taking Express courses to keep up with my new-self. I have completed about 50% of the "Learn Express" course and already feel confident and ready to tackle the next part of my College Football Dynasty project.

SQLite Queries

On a more boring front, I have imported almost all of the data from our Google Sheets (see previous failed attempt at using Google Sheets as a database). I am proud of how clean the tables and data looks (so far).

I have also been learning SQL on the side, and trying to fully understand the best way to join my tables and extract the data I need for my project. I am confident I can learn this on-the-fly as it makes sense, I just need to understand the syntax better.

My crowning SQL achievement at the moment, is that I was able to extract one team's total Wins, Losses, In-Conference Wins, and In-Conference losses from 1 specific season. I have one giant table for every match played in the league with columns for teams, scores, game-types (playoffs, reg season etc). This is what my query looked like and what it returned:

SELECT COUNT(CASE WHEN (home_id='53' AND home_score > away_score) OR (away_id='53' AND away_score > home_score)THEN 1 END) AS Wins,
COUNT(CASE WHEN (home_id='53' AND home_score < away_score) OR (away_id='53' AND away_score < home_score)THEN 1 END) AS Losses,
COUNT(CASE WHEN game_type LIKE '%Conference Play%' AND ((home_id='53' AND home_score > away_score) OR (away_id='53' AND away_score > home_score))THEN 1 END) AS Conf_Wins,
COUNT(CASE WHEN game_type LIKE '%Conference Play%' AND ((home_id='53' AND home_score < away_score) OR (away_id='53' AND away_score < home_score))THEN 1 END) AS Conf_Losses
FROM matches

Probably pretty simple SQL but it did wonders for my confidence that I am going to be able to extract the data that I actually need for my site.

Up Next

I am going to continue through my Express course, and then I will officially start the project. I just want to display a dynamic list of all the teams and members part of the league to get started. I will build functionalities and team pages from there! I feel like once my environment is set-up and I have the confidence to pull the data I need, the site will be built quickly as my expertise is with HTML/CSS.

Front-End to Full-Stack Journey Part 1: Planning My Attack

Ian Bonaparte — Tue, 10 Dec 2024 17:46:02 +0000

I have been meaning to be more active with a dev blog, and was recently inspired by Kevin Powell's podcast to start blogging more. Thanks Kevin!

I have been running a College Football 2025 Online Dynasty with a group of a dozen or so friends since the game released back in June. We've been having a blast and are on our 3rd season. One of the major downfalls of the game, though, is that the in-game stats, trophies, and rewards are seriously lacking. We have a discord channel and a Google sheet that we use to keep a record of results and long-term stats. This is fine, but the web-dev in me saw this as a great opportunity to make a really cool website.

Historically, this has always been a downfall for me. I am what some may refer to as a "Front of the Front-End" developer. I specialize in creating accessible HTML mark-up and functional CSS (and client-side JS). I know what's possible with technology, but typically always struggle in making all of the pieces fit. Not this time, though! I am creating this blog post to hold myself accountable and to share my struggles, learnings and knowledge with the world.

Keeping Track of Data

I created a Google Sheet that was accessible to myself and other members of the league with columns for opponents, scores, and other individual game-specific data. A quick google query showed that there is a Google Sheets API available that I could leverage to pull data from the sheet into a website! How much simpler can you get? Simple is something I'm championing throughout this project. Not only because I don't want to overwhelm myself, but because I'm creating a relatively static website with the audience of maybe 20 people tops.

However, after 10-12 hours of wrestling over the course of the past month, I have learned that this Google Sheets API is not as simple as I'd have hoped. It at least has the extra challenge of being less popular than other options, so there isn't a ton of Stack Overflow-esque troubleshooting for me to do. All of the troubles I was running into felt extremely unique and difficult. I also made the mistake of following a YouTube tutorial to get the project set-up initially, which skipped over some Node.js set-up stuff that I'm relatively uncomfortable with. And, on top of that, for some reason I decided that this was a great time to leverage React, which I'm by no means an expert in. Basically, I bit off more than I could chew. I realized I needed to chunk up my battles to make this project more manageable for myself.

SQLite

After deciding that Sheets was not going to be the answer for me, I did some research into what the best options for light-weight databases. I am not knowledgeable in this area at all. I took a SQL class in 2018, but have not had to use it even one day in my day-to-day life. I found lots of articles and Reddit threads of people suggesting SQLite for small projects. This seems perfect for what I am trying to accomplish.

I knew I needed to design my database and determine what kind of tables and columns I'll need to create the components I want. I basically want to make a copy of any league's website you'd see (NHL.com, MLB.com, etc.). I did a quick search and found https://dbdiagram.io/. I played with this tool and was able to design a basic database for my site. I found this tool extremely valuable for myself as it let me get familiar with SQL commands and jargon without actually having a database yet.

With confidence high from setting up this diagram, and believing that I think I actually understand what I'm trying to do (Remember, I am an SQL-newbie), I fired up SQLiteStudio (GUI for SQLite) and got started. I input all of the data for my user, teams and conference tables. With the help of w3schools I was actually able to run an SQL query that returned data from 3 separate tables! Great success!

SELECT users.username, teams.school_name, teams.nickname, conferences.conference_name
FROM users
    INNER JOIN teams
    ON users.current_team=teams.team_id
    INNER JOIN conferences
    ON teams.conference=conferences.conference_id

Up Next

This was my success of this past weekend. I was pretty excited to be able to ideate, design and architect this basic database with very little friction. Up next, I am going to try to understand Node.js a little better so that I can work on using JavaScript to actually use this data on my web project. I've used Node.js before but have little to no understanding of what it is actually doing. I plan on doing some tutorials and running through w3schools to help me here before I jump feet-first into this.

Thanks for reading and feel free to share any resources you think might help me along the way!

Designing and Developing an EA NHL 23 App for my Club Team

Ian Bonaparte — Wed, 16 Aug 2023 04:57:09 +0000

I am trying to build up a portfolio of personal projects, so I am attempting to take a stab at creating a React App that is using the EA NHL API to keep track of information on my club team.

EA has an API that people can use to look up recent game results, member stats, and club information. This immediately made me want to design a site for my friends' club team. I went straight into Figma and had a blast designing a navigation, a scoreboard like you see on major league sites (MLB, ESPN, NHL, etc), and a rosters page. The more I use Figma, the more I learn how much I enjoy UX/UI design.

After finishing a couple of wireframes, I decided to get to the dirty work of building my React app. I am using Vite to host the server locally. I had to go back and re-watch some tutorials to get my new app up and running, but ultimately it was pretty easy. I was good to start coding my homepage within 15-20 minutes of googling and watching videos. This is always my least favorite part of starting a new project.

Wanting to dive right into working with the EA API, I began styling the scoreboard. I used hard-coded data to get the HTML structure and CSS just right before spinning wheels on populating the component with live data.

Once I started testing my API calls, I immediately ran into an issue with CORS authorization. After some Google-Fu, I downloaded a Chrome extension that helps suppress these errors while working in a local dev environment. But, my errors didn't end there. It turns out, that even though you can enter the API calls into your browser and get the JSON printed out, EA does not allow unauthorized API hits from personal apps and sites.

To get around this, I manually copy & pasted the JSON into a local .json file, and am hosting it in the same folder as my app. The Recent Games API only returns the most recent 5 games, but it was enough to get started. The API actually returns an impressive amount of information. My long term plan is to build a "master" JSON file where I can add a new file every week or so to build up a database of all recent games. Manually uploading is going to be the way to go for now, I don't think EA will ever make the API fully public.

Anyway, I just got the basic "bones" of my scoreboard component laid out, and fully populated with data from the API/local JSON file. While not overly impressive, I am proud I was able to get here myself.

I am posting this as a way to keep track of my progress on this project and hold myself accountable. I am hoping that by the end of the month I can have the full-site up and hosted on a real domain!

7 UX Design Concepts for Front End Developers

Ian Bonaparte — Fri, 28 Jul 2023 21:07:07 +0000

If you’re reading this, you’re most likely a fellow front end developer. We all became developers because we tend to gravitate towards objective, structured & logical problems with real, tangible solutions. We have a reputation of maybe not being the world’s greatest designers, but I believe that to be rather unfair. You could argue that nobody uses the web more than us. Whether it be researching the solution to a complex coding problem, catching up on our hobbies, or just shopping for day-to-day items.

By having every part of our world so immersed in the digital world, we inadvertently become experts in the domain.

I will never forget the first time I worked with a professional UX designer. They made the comment to me that I have an incredible eye for UX design, and probed if I’d had any pro training or certification. I haven’t, but I joked that I was “raised by the internet”. I was a child in the late 90s who was always on GeoCities, creating pages for whatever my obsession of the week was. Then I matured into a teenager where I was editing the CSS of my myspace page to do so many cool things that nobody else’s page could do.

By being terminally online, I picked up on a lot of stuff that is foundational to being a good UX designer, and take it for granted as common sense. I think most front end developers are similar, and it’s time that we embraced that.

After years of contributing to work projects as what I refer to as “UX consultant”, I decided to enroll in an actual UX design course, to get some professional training under my belt to lean on, because I don’t know how far “being a child of the internet” is going to take me.

Here are the key UX concepts I learned:

1. Design for Humans

The first thing you need to understand when designing a new page or experience, is that you are designing for humans. This may seem obvious, but it is important to realize. Understanding there is a human being on the other side of the screen means you understand that:

We make emotional decisions

Our brains are wired to act and make decisions based off of emotions. Fear helped us evolve to the apex predators we are today, and today fear still plays an important role in decision making (fear of Missing out, fear of losing money, fear of breaking). It’s important to understand this, but not to rely on this, or else you might wander into Dark Pattern territory.

We make decisions unconsciously

Our brain has two systems of thinking. System 1 is very fast, and almost automatic. If I asked you what 2+2 is, you will most likely answer “4” immediately. You didn’t think, count or have to visualize anything. You just know that the answer is 4.

The other system, system 2, is slow & deliberate. It takes effort. It makes us tired. If I asked you what 456 divided by 94 is. You would not be able to reply with an answer as immediately as you could before. You would most likely have to get a pen and paper, and see if you remember how to do long division.

We’re lazy

Our brain wants to use system 1. It will do anything it can to avoid using system 2, including just getting the heck away from the problem altogether. I think you can see where this knowledge will come in handy when related to UX.

2. Avoid Dark Patterns

Even if you haven’t heard the term, I can guarantee you’re at least familiar with dark patterns. Dark patterns are UI elements that are specifically crafted to trick users into actions they might not otherwise do. These are easy to avoid so long as you actually think of your user’s experience.

Think of how you would feel when buying a car and you recognize your salesperson trying to pull a fast one on you. You would immediately be put-off and jeopardize the chance of you going through with the sale. The same applies to you and your software or web experience. If user’s catch on that you are trying to trick them, you are going to hurt not only the current conversion goal, but your business as a whole.

Sure, these dark patterns might give you an immediate lift in conversion and could argue that they “work”, but not at a cost. Consumers are generally cynical, smart and spoiled for choice. They can and will go elsewhere, and all it takes is one disgruntled Google review to potentially sway hundreds of future potential customers to goto a competitor.

Not only are dark patterns unethical, but they’re ultimately horrible for business.

3. Content is King

If you’re familiar with SEO, you’ve heard this phrase countless times. But when it comes to UX, content is your biggest seller. After all, what is a beautiful wireframe without a beautiful product or idea to sell?

When you think of UX, you probably think buttons, wireframes, and signup forms. You’re not wrong, but UX goes beyond that. In order to be a good UX designer you need to know how to put yourself in your customer’s shoes. What are reasons they might not convert? You need to identify and address these objections and risks your customers might have to ease their mind that they’re making the right choice.

To do this, focus on benefits before you dive into features. Sure, this model car might be bigger, but what does that do for the customer? Tell them that they can fit more supplies, or accommodate large family trips easier. Sell them on the idea of why your features help them before you start selling the feature itself.

Make any risks that come with your product worth taking. Is your product higher priced than most competitors? There’s not a lot you can do about that, the price is the price. But what you can do is tell the potential customer why your product is more expensive. Sell them on the idea that your product is higher quality, or lasts longer, or offers more peace of mind.

4. Don’t Make Me Think!

Perhaps the most famous quote in the UX universe, but also the most accurate. Anyone using your software or website should never have to think about what they expect when they interact. It should be abundantly clear at all times what any button, widget or scroll will do when users engage. If a customer has to stop for even a second to think “Wait, what is this button going to do?”, then you’ve already lost.

Humans are lazy, and we want to let our brains run on autopilot. Use familiar designs when designing for higher conversion. The last thing UX designers want to do is increase a user’s cognitive load. Less is more when it comes to impactful UX. Let the content speak for itself and make use of good visual design to make it obvious to users where you want their attention to go.

5. Optimize for Speed

For us developers, this should be the most relatable point in this list. Pages that load slow will not convert well, and that is just a fact. You could have the world’s greatest page from a UX perspective, but if it takes 15 seconds to load, then it is not going to matter. It is just a fact that page performance has a direct impact on conversion. For every 2 seconds your page takes to load, conversions drop by 4%.

For quick-hits to increase your load speed, take a look at the following areas:

Speed up imagery

Use JPEGs or other web optimized filetypes to reduce page size.
Use a CDN
Host images on a CDN so that correct sizes are being delivered intelligently. No need to load a 2600px wide image to a customer visiting from an iPhone 8.

Optimize CSS and JS

This a topic for an entirely separate post, but check out this blog about optimizing your CSS and JS for faster load speeds.

Watch out for your use of web fonts

Marketers and designers love pretty fonts, but they take a little bit to load. Make sure that you at least have a ‘default’ web font to load in case the desired font is taking a bit to load. The faster the content paints on the screen, the better the user experience.

6. Make Content Scannable

Most users who land on your page are not going to read every word. And even if they did, you want to make sure everything is easy to read and digest. In order to do this, you need to make sure you create a content hierarchy. You can do this by chunking your content up

Title (Must have)
Summary
Headings
Sub-Headings
Section Copy (Nice to know)

Using the list above as reference, the top item, “Title”, needs to be the biggest and easiest to read part of any content-chunk. Users should immediately understand what the section is about and be able to decide if they want to learn more instantly. As users scan down, the visual importance of the copy should reduce. A summary can be larger than your normal copy font-size, but still nowhere near the title. Crafting your content in such a way will make it easy for users to scroll and stop where something might catch their interest, then, as you “catch” users, you can feed them the details without overwhelming their cognitive load.

It’s also important to note that humans read in an “F” shaped pattern. Meaning, the first line we read, we’ll most likely read almost all the way. Then, we might skip a line or two, read half of the middle, then just scan down the left hand side until the next thing grabs our attention. Knowing this will help you when you are creating your content hierarchy.

7. Test Early, Test Often

Last but certainly not least, we are going to talk about testing. Testing is the most important part of the design process. As developers, you may only be familiar with A/B testing, but there is actually testing the can be done before anything is even built or deployed.

Types of Design Testing

The Five Second Test

Create a wireframe, show it to a co-worker, friend or shareholder for only 5 seconds. Ask the user what they thought the main point of the page was. A lot can be learned here. Your goal is to make sure that the main point of the page is easily picked up on by anyone within 5 seconds of seeing the page.

First Click Test

Create a wireframe, and ask user’s where they would click in order to complete a certain task. For example, if you created a wireframe for a Product Display Page, ask a user to click where they might go if they wanted to add it to their wishlist. Obviously, this should help you as the designer understand where users are looking for certain elements and if your design does a good job of being intuitive.

Eye Trackers

Ideally, your main CTAs and conversion goals should be where people’s eyes are naturally looking. You may think that is an impossible thing to keep track of but there are actually a good amount of free tools out there that can help simulate an actual eye-tracking test using AI.

As a front end web developer - UX has always been of interest to me. I love learning more about it, and the psychology of why people behave the way they do online. I hope this article inspires other developers to learn more about UX, because none of it is really too complex and pretty basic when it all boils down. Us developers need to give ourselves more credit when it comes to design because I think a lot of these things come naturally to use, as everyday users of technology.

I hope you enjoyed my first post!