My experience building a marketplace with vanilla JavaScript and Afribase during my Students Industrial Work Experience Scheme.
Hello, Earth!
During my Students Industrial Work Experience Scheme (SIWES), I worked on a project called MarkDump, an online marketplace where users can upload products for others to browse.
The idea was straightforward: build a marketplace where people could list their products, discover items, and eventually buy and sell through the platform.
I was the only developer working on it, using HTML, CSS, and vanilla JavaScript for the frontend. For the backend, I eventually settled on Afribase.
It sounded like a straightforward project when I started thinking about the features.
A product form. A product grid. A cart. A wishlist. A database to store everything.
But this was my first time working on something like this, and I quickly realised that knowing how to build individual features was different from putting an entire application together.
There was a lot to figure out, and one of my biggest challenges wasn't even the backend.
It was organising my JavaScript.
Starting with the frontend
I started with the part I was more familiar with: the interface.
I worked on the navigation, hero section, product grid, and different sections of the homepage. I also built a modal where users could enter product details and upload product images.
Gradually, MarkDump started looking like an actual marketplace.
Products had somewhere to appear. The form had somewhere to collect information. The interface was beginning to take shape.
But making a website look like a marketplace and making it function like one are two different things.
I needed to figure out how the product data would be managed, how the form would work, and how products would move from the form into the database and back onto the page.
Then there were other features to consider, such as the cart and wishlist.
Each feature introduced new logic, and I had to think about how it would fit into the application.
That was when I began to appreciate how much thought goes into building something beyond its appearance.
My biggest challenge: organising the JavaScript
This was probably the most challenging part of building MarkDump.
As I added more features, I had to think carefully about where the different pieces of JavaScript should live and how they should communicate.
I didn't want everything sitting in one enormous file with functions doing unrelated things.
I started exploring different approaches to organising my code, including classes, factory functions, and the module pattern.
I created a Product class to represent products and a ProductManager to handle product-related operations. I also worked on a DisplayController to handle rendering products on the page.
Each part had a responsibility.
The product representation didn't need to worry about how a product card looked in the browser. The display logic didn't need to handle every aspect of managing product data.
At least, that was the direction I wanted to take.
The difficult part was figuring out how to make these pieces work together without making the application unnecessarily complicated.
Sometimes, I had to stop and reconsider how I had structured something. Other times, I needed to think through which part of the application should be responsible for a particular operation.
I was learning the concepts while trying to apply them to a real project.
That made the experience different from simply reading about JavaScript classes or factory functions.
Instead of only asking myself what a particular concept meant, I had to ask questions like:
- Does this functionality belong in this class?
- Should this module be responsible for managing the data or displaying it?
- How should these parts communicate?
- Am I making this unnecessarily complicated?
I didn't always have immediate answers.
But I kept working through the problems.
MarkDump taught me that knowing JavaScript syntax and knowing how to organise an application are two different skills.
I'm still developing both, but building this project gave me a reason to think more deeply about the second one.
**
Connecting the frontend to Afribase**
Once I had the frontend taking shape, I needed somewhere to store product data.
I eventually chose Afribase and set up a database table for products.
Afribase is a backend and hosting platform that provides developers with tools such as PostgreSQL databases, authentication, and file storage without having to assemble every part of the backend infrastructure themselves. Afribase
It's also a relatively new platform, currently in beta, which made trying it out an interesting part of my experience. Afribase
I chose Afribase for MarkDump because I needed a way to store product information and retrieve it from my frontend.
I created a database table for products, with fields for the product name, description, price, category, quantity, images, seller, location, and creation date.
Then I connected my JavaScript application to the database.
I tested the connection, queried the products table, and eventually managed to insert a product successfully.
Seeing that work was satisfying.
The product information wasn't just sitting in a JavaScript object anymore. I could send it to the backend and store it in the database.
You can check out Afribase here: https://useafribase.app/.
But getting the database connection working was only one part of the process.
I still needed to make sure the application could save products, retrieve them, and display them correctly.
That meant thinking about the entire flow:
- A user enters product information.
- The application collects that information.
- The data is sent to the backend.
- The database stores it.
- The application retrieves the product and displays it in the marketplace.
Every step matters.
If a product is saved successfully but doesn't appear on the page, something still needs investigating. If the application retrieves the product but the display logic doesn't handle the data correctly, the user still won't see what they expect.
Working through these different parts helped me understand why connecting a frontend to a backend involves more than simply making a request.
The different pieces have to work together.
The records included information such as the product name, description, price, category, quantity, images, seller, location, and creation date.
Then I had to connect the application to the database.
I tested the connection, queried the products table, and eventually managed to insert a product successfully.
Seeing that work was satisfying.
The data was no longer limited to what I had manually created in JavaScript. I could send product information to the backend and store it in the database.
But getting the connection working was only one part of the process.
I still needed to make sure the application could save products, retrieve them, and display them correctly.
That meant thinking about the entire flow:
A user enters product information.
The application collects that information.
The data is sent to the backend.
The database stores it.
The application retrieves the product and displays it in the marketplace.
Every step matters.
If the product is saved successfully but doesn't appear on the page, something still needs investigating. If the application retrieves the product but the display logic doesn't handle the data correctly, the user still won't see what they expect.
Working through these different parts helped me understand why connecting a frontend to a backend involves more than simply making a request.
The different pieces have to work together.
Getting familiar with asynchronous JavaScript
Connecting MarkDump to Afribase also meant working with asynchronous JavaScript.
I had to start understanding how async and await fit into the application and how database operations affect the flow of execution.
For example, retrieving products from the backend takes time. The application needs to account for that before trying to use the returned data.
This became particularly important when working with product-related operations.
I had to think about when data would become available, where I needed to wait for a result, and how the rest of the application should respond.
I was learning these concepts while implementing them, so there was a lot to think through.
What I appreciated was that I wasn't learning asynchronous JavaScript in isolation. I had an actual reason to understand it.
I needed it to help MarkDump work.
And that made the concepts more meaningful to me.
What MarkDump can do right now
MarkDump isn't finished yet, but it isn't just a static design either.
At its current stage, users can:
- Upload products to the marketplace.
- Browse available products.
- Add products to their cart.
- Add products to their wishlist.
These are working parts of the application that I've had to build and connect.
There are also features I haven't completed yet, including:
- User authentication.
- Payments.
- Order management.
- Drops. And the UI needs a bit, more work.
I still have work to do before MarkDump can offer the complete experience I originally envisioned.
I'm mentioning this because I don't want to present the project as something it isn't.
Building an application involves making progress, identifying what's missing, and continuing to work towards the intended result.
MarkDump is still a work in progress, and I'm learning from that process.
The biggest lesson: this was my first time
Looking back, what stands out most isn't one particular feature or a single moment when something finally worked.
It's the experience of working on an application like this for the first time.
Before MarkDump, I could learn a concept, practise it, and move on to the next lesson.
With this project, the concepts started coming together.
I had to think about the interface, application logic, data, database operations, and how everything connected. I had to make decisions about how to organise my code and figure out what to do when something wasn't working as expected.
I couldn't treat each feature as an isolated exercise because the features had to work together.
That was a different experience.
I also began to understand that building an application requires more than knowing which methods to use or how to write a particular function.
You have to think about the structure of the application.
You have to decide where responsibilities belong.
You have to understand how data moves between different parts of the system.
And when something breaks, you have to investigate instead of assuming you know the answer.
I didn't suddenly become an expert by building MarkDump. There are still plenty of things I need to learn, and I know there are better ways to approach some of the problems I've encountered.
But I now have practical experience to build on.
I've had to take concepts I've been learning and apply them to something bigger than an individual exercise.
For me, that has been one of the most valuable parts of the experience.
What's next for MarkDump?
There are still features to build, problems to solve, and decisions to make.
Authentication, payments, order management, and Drops remain on my list. I also want to continue improving the way the application is structured as I learn more.
But I'm glad I took on the project during my SIWES.
It gave me the opportunity to work on something substantial, challenge myself, and discover areas where I need to improve.
Most importantly, it showed me what happens when the things you learn individually have to work together in an actual application.
I'm still learning JavaScript. I'm still figuring out application architecture. And I'm still working towards becoming a better developer.
MarkDump is one step in that journey.
It isn't a story about building the perfect application on the first attempt.
It's a story about taking on something new, working through the challenges, and learning along the way.
And since this was my first time working on a project like this, I'm looking forward to seeing how much better I can make it.
For now, there's still work to do.
Back to the code. ðŸ˜
Yeah, here is a list of Technologies used
- Frontend: HTML, CSS, vanilla JavaScript
- Backend and database: Afribase-https://useafribase.app/
- Live demo: https://deolawage.github.io/MarkDump/
- Source code: https://github.com/Deolawage/MarkDump
Top comments (0)