Welcome to the first (and hopefully not the last) devlog of Iskor! I started this blog mainly to prevent the degradation of my writing skills caused by excessive LLM use. The sharing of my app's progression is just a nice byproduct of it xD.
Introduction
Like virtually all applications, Iskor started as an idea. I observed tens of thousands of students apply for both the DOST-SEI Undergraduate and JLSS Exam, and they are even willing to pay for review centers. My market research revealed that only a couple of exam/review SaaS are dedicated to these types of exam. Hence, this signaled a large and underserved market with a lot of potential. So as a DOST Scholar myself and someone who knew full-stack development, I took it upon myself to build Iskor.
I started this project at the beginning of August, and plan to deploy it as a full-fledged product on the first week of November with beta-testing and question-bank filling at least a month before the undergraduate exam, scheduled Nov. 14-15. 2 months.
In the past few weeks, I focused on implementing features on the components that I am familiar with.
Stuff I Know
Frontend
I decided to go with Next.js for my frontend because it pre-renders your website, allowing webcrawlers to access my site and do SEO magic. In addition, it also has essential features such as file-based routing, server-side rendering (SSR), and is also relatively easy to understand thanks to my past React experience.
I also utilized TypeScript since it is essentially a strongly-typed JavaScript. It checks types and detects errors at compile time, adds more complex data types such as interfaces, and works well with Next.js.
As for the website itself, I have created the landing page, a resource page to view all covered topics with externals study site recommendations, the sign-in/sign-up page, and the exam page itself which emulates a real test paper. It supports SVGs, excerpts, images, LaTeX equations, and shared-media questions.
Finally, I have also dabbled on AI-assisted coding, where I studied proper prompt engineering and utilized Antigravity CLI to create reusable components. I make sure to review its proposed changes before approving them, since I don't want this app to be a black box of vibe-coded slop.
Now, since Next.js has built-in API routes that essentially serve as the backend, it would be obvious to use that, right?
Backend
I have no problem diving into complex things, as long as it helps me move forward with my goals. One of them is someday working in FinTech. In order for me to land a dev role in that industry, I must be able to utilize the technologies they use.
Enter Spring Boot. Spring Boot is Java's modern framework for building enterprise web apps. It massively reduces the initial boilerplate code Java has been associated with using auto-configuration and is, at its core, a batteries-included framework.
Aside from the listed pros, Spring Boot has also benefited my development process in more ways than one. For instance, its embedded Tomcat servers allowed me to run the application in a .jar file, making it easy to build and containerize. Moreover, its strict enforcement of SOLID allowed me to ingrain these development principles into my thinking. Here is how:
- Single-Responsibility Principle (S) - each class is a layer that handles a different function (controller classes for endpoints, service classes for business logic etc.)
- Open-Closed Principle (O) - each function can be added a feature through annotations
- Liskov Substitution Principle (L) - not implemented that much yet, but the backend does not use a deep inheritance hierarchy that causes LSP problems.
- Interface Segregation Principle (I) - functions to be used in the service layer are the ones explicitly defined in the repository layer.
- Dependency Inversion Principle (D) - utilizes constructor injection to create the dependency first before providing them to the services and controllers.
Even after realizing how verbose still this framework is, I do not regret choosing Spring Boot as this app's backend. Next layer: the database.
Database
Fortunately, this is one of the components of the app where I do not need to learn anything particularly new. I chose to use PostgreSQL because of its high data integrity (ACID compliance) and its extensive support of both relational and semi-structured data like JSON, which would become essential for future features.
I have created the schema for the website, applying normalization and indexes to reduce data redundancy and improve read speed since the app would be read-heavy.
For hosting, I opted to use Supabase for prototyping and initial development. Its wide range of tools has made making database edits seamless. Although helpful at the start, Supabase does get expensive as I start to hit the free plan limits. Hence, I plan on migrating to Amazon RDS once this app is complete in order to support more users and get a glimpse on how RDBMS works on production.
Getting my Feet Wet
Aside from those three foundational layers, I have also started getting my feet wet on the other important parts of software engineering.
Authentication/Authorization
Security is one of the most essential features of an application, especially in this new age of unsecure, vibe-coded app fever. While Spring Security exists, I ultimately decided on using Clerk to handle user authentication/authorization because I believe it is much better for a reputable third-party to handle real user data instead of an amateur rolling his own auth.
With that being said, I have implemented a functional sign-in and sign-up feature using Clerk's built-in components. However, I have yet to secure my API endpoints using JWT and implement other security features such as RBAC and rate limiting.
DevOps and CI/CD
For the past few months, I have been learning Docker on the side in order to make sure that my applications run on any server. I have learned how to build an image from a Dockerfile, spin up containers using docker compose, and learned the best practices on creating and managing these containers.
This week, I also learned how to use GitHub Actions to setup a workflow that automatically builds the backend image and upload it to DockerHub. Although, I plan on refactoring the pipeline to build the .jar file on the runner itself before inserting it into the image to save build time.
Plans for Next Week
I probably would be a lot more time-constrained next week due to classes starting again, so I decided to put my focus on one thing at a time. Hence, I plan on implementing RBAC and securing my API endpoints first using Clerk's JWT and Spring security, along with finalizing the infrastructure Iskor would utilize in production.
Top comments (0)