Developer’s Diary 1: Good Networking
It's been almost two weeks since I started working on the Dobrý Networking app. I've spent most of my time studying and analyzing the project. At the beginning, I felt pretty lost. It took me a while to get a sense of direction and get into the developer mindset. Lately, I've mostly been working on applications that are already in development, so I haven't had to make important foundational decisions. It's been a while since I’ve come across something that's completely in its early stages.
I joined the project at a point where several key decisions had already been made, and I've been building on that foundation.
Constantly Evolving Technology
The main technologies we'll be building on include React.js as our primary framework and Next.js, which is built on React. Next.js will provide us with the backend functionality we need and will ensure fast performance for the application in the future through server-side rendering of components. For the database, we'll be using MongoDB. This choice of technology is ideal for me. While I have solid experience with React, that's where my expertise ends, so I'm looking forward to exploring Next.js and MongoDB.
Beginnings with Laid Foundations
After reviewing the UX and UI mockups, I’ve got a good sense of what the app is supposed to do, and I’ve dived into the work.
First, I went through the already-written code. The event creation functionality is in place, including the API, the first database schema, and a UX screen. This part seems pretty straightforward, and although I haven’t reviewed it in detail yet, I don’t think many things will need to change there.
The second larger part involves user login. The code for this is also written. We’ll have several login options, including the now-standard method of logging in via Google and almost every social network I can think of. The second method is log in via a magic link sent to the user’s email. I’ve never implemented either of these methods before, so I’m hoping it will be easier than the traditional username and password verification. Conceptually, I hope I can just send a request to the appropriate link, all the magic happens outside my hands, and then I get back a verified user and just store that they’re logged in. Currently, I have no clue how this code works.
When You Don’t Know Where to Start, It’s Best to Start at the Beginning
I first tackled the database. While an experienced architect might not need a schema, I decided to dive into it. I chose to use dbdiagram.io, which is great because I can write a text-based schema, and the program generates the diagram for me. The downside is that in the free version, other users can only view the diagram, and I’ve had instances where my diagram disappeared from my account. With ChatGPT's help, creating the model was easy. It took a bit to teach it the format I needed, but once we got the hang of it, the process went smoothly. Besides not having to manually list all the attributes, I used ChatGPT as an intelligent "rubber duck," which was incredibly helpful. The schema is now complete—nothing groundbreaking, but it’s a solid reference point. The schema is accessible, and I’m open to any feedback.
After finishing the database, I worked on the routing for the app. Next.js handles this elegantly, where routing mirrors the folder and file structure in the app. This means I don’t have to go back to a central place in the app to write the address I want and then create functions for it. I struggled initially with the fact that in Next.js, there are two places responsible for routing: one controls the front end and linking between screens, and the other handles API addresses. This caused some confusion at first. ChatGPT contributed to this confusion by repeatedly insisting that files in the frontend routing don’t need to be named “page,” even though I kept pointing out that the documentation says otherwise.
This is the current status, and I’ll provide further updates in a week or two.