My checkbox towards becoming a better developer/programmer

- Don't get too comfortable: Whether it’s with a language, framework, or any other technology, try not to get too comfortable by either finding more information to get better using the tech or considering something new.
- Learn the basics: Once you understand the basics i.e how your language work under the hood, using any framework or library based on it becomes easier, for example learning the basics of Javascript will help you with using its frameworks like Vue, React, Angular e.t.c. and understanding core HTTP request-response cycle helps a long way using any backend technology.
- Take a break but with caution: We are not clocks, learn to take a break every now and then to regenerate and avoid stress, would advise though that it's not too long, so you don't have to relearn a lot when you return.
- Share your knowledge: As much as possible whenever you have the opportunity to, share what you know it helps a long way to have a better understanding.

large_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

medium_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

small_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

thumbnail_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

xlarge_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

xsmall_tim-gouw-1K9T5YiZ2WU-unsplash.jpg

tim-gouw-1K9T5YiZ2WU-unsplash.jpg

How to get better as a developer/programmer

Let's start with a little background. Just like you probably do, I love to develop things for the web with up to 5 years of experience as a backend developer using  PHP, Laravel, Elastic search, Docker(even though it's not a backend technology), and 3 years as a frontend dev, working mainly with Vue as my framework of choice (for the sake of the length of this article I won't get into why I chose Vue over other nice frameworks out there).

I recently took on a new job where part of my responsibilities includes the development of a web app and collaborating with the API development, and since the API is Node JS I have no other option than to finally give in to learning how it works.

So as anybody will do, I went ahead to Udemy and obtained a Node Js course, about 20% into the course I noticed something, apart from the fact that they were basically teaching how the web works, I actually understand everything being taught, then it finally came to me what I have been seeing all over the internet about Node Js, its simply put javascript running server-side, since I know javascript, it all makes sense now.

After that discovery, I stopped the course and decided to learn by trial *(btw I wrote an article about how to leave the tutorial hell here*) instead, by building a simple API as that is what I will be doing most, from there, actually writing API went pretty smooth with help of documentation and articles on the internet. Then I went ahead trying two frameworks (Express and Fastify) for the same project.

Here are some of the things I noticed in the course of development especially in comparison with where I am coming from. 

- On the language level, Node is quite cleaner than PHP thanks to javascript, though that might be from my preference for javascript over all other programming languages.
- When it comes to speed, Node JS is faster
- PHP in my opinion is more powerful so if your project needs a lot of processing in the backend you might want to opt for that
- On the framework level, with the most popular frameworks available in both languages, Laravel, and Express, Laravel unlike Express is opinionated meaning it encourages you to follow a particular structure while express gives you the freedom to structure your application the way you want to. With that comes some disadvantages too though because if you are not careful things can get really messy so I checked some examples online of how people structure their apps. This repository was especially helpful: https://github.com/santiq/bulletproof-nodejs/

With that I was up and running with node, I know there is still a lot to learn but I believe the basics have been covered.

This is simply evidence or an answer to the popular question "Which language should I learn first?", It doesn't really matter what you begin with as long as its not some really old one, just get started with one you find convenient to learn basic programming principles from which you can then port/move to other languages as you wish.

large_african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

medium_african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

small_african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

thumbnail_african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

xsmall_african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

african-american-coder-employee-programming-busine-2021-12-09-02-41-56-utc.JPG

My experience moving from PHP to Node JS in one week

At Sparc agency, we were faced with the challenge of how do we implement oauth2 flow for one of our software, there were a few options to choose from:

- Make use of authentication and authorization as a service like Oauth0
- Write our oauth2 server with available packages like Passport for Node JS or Passport for PHP
- Use an open-source Identity solution as Ory provides.

If only the time of development were to be considered then Oauth0 would be the best choice out of the three where using packages like Passport will come last, but that was not the only concern here, so we ended up going for the last options using Ory Hydra for oauth2 and Kratos as an identity provider as our business need required a bit more flexibility also it was important that we manage our user's list in our database. 

The next challenge was then to find implement it with our stack:

- Express JS backend.
- Cockroach DB database.
- Nuxt JS login and consent screen.

Since there were not many examples on the internet yet with this kind of setup, we went back to the drawing board and came up with this:
![IMG_4936.jpg](https://slaknoah.nyc3.digitaloceanspaces.com/IMG_4936_56708761c6.jpg)
I will assume you are familiar with some oauth2 terms, and how it works, but just to refresh memory some of the terms used in this article are:

- Client: The client is the app that is attempting to act on the user’s behalf or access the user’s resources. Before the client can access the user’s account, it needs to obtain permission. The client will obtain permission by either directing the user to the authorization server or by asserting permission directly with the authorization server without interaction by the user.
- Authorization server: The authorization server is what the user interacts with when an application is requesting access to their account. This is the server that displays the OAuth prompt, and where the user approves or denies the access request. The authorization server is also responsible for granting access tokens after the user authorizes the application.
- User: The resource owner is the person who is giving access to some portion of their account. Any system that wants to act on behalf of the user must first get permission from them.
- Authorization Code: An authorization code is returned to the client after the authorization step, and then the client exchanges it for an access token.
- Access Token: An access token is the string used when making authenticated requests to the API. The string itself has no meaning to the application using it but represents that the user has authorized a third-party application to access their account.
- API: The spec refers to what you typically think of as the main API as the “resource server.” The resource server is the server that contains the user’s information that is being accessed by the third-party application.

Now, let's go through the flow:

The client initiates an oauth2 flow to the /oauth2/auth endpoint of the authorization server - Ory hydra, here the oauth2 CSRF cookie is saved which would be used later by hydra, the hydra redirects to our express backend service with the hydra_challenge, the backend service serves as an interface between Kratos our identity provider and hydra. Here I will split the flow into 3 assumptions:

- **The user is not logged in to our service and didn't ask hydra to remember their oauth2 consent**: [A]The backend service makes gets the login request info from hydra using the hydra_challenge, since the user isn't logged in and haven't previously asked hydra to remember their consent decision, we redirect the user to the login screen, this is where Kratos comes in, but before redirecting to Kratos browser login flow:
    - We generate and save an hydra_login_state session
    - Using Kratos ability to receive a return_to URL: which is the URL to return to after successful login, we set the return_to URL to our backend service with the hydra_login_state and challenge as a query parameter
    - Then we redirect the user to the Kratos /self-service/login/browser URL with the return_to param set to the URL generated in the previous step
    
    [B]Once the Kratos server receives this request it creates a login flow and saves the return_to URL to the database, Kratos then redirects to the preconfigured login screen which can we a SPA or SSR app, in our case we are using a Nuxt app which renders the login screen based on the flow-id (You can read more on how Kratos login screen is rendered here https://www.ory.sh/kratos/docs/self-service/flows/user-login/ ), here is important to submit the form instead of making an AJAX request though it might be possible to use AJAX it doesn't make sense here since there will be a redirect anyway. Once the user is logged in, Kratos returns to the return_url previously set also with a **set-cookie** header including the ory_kratos_session cookie - this tells the backend service who is logged in.
    
    [C]Now the backend server does another check, where it needs to check if a user is logged in(and they are because there is a Kratos session cookie available) also it looks for the hydra_login_state in the query and checks it against the one in the cookie that was saved on the first hit before redirecting to Kratos, if they are same and the user is logged in, we ask hydra to acceptLoginRequest with the using the challenge, and the user from Kratos session.
    
    [D]Next action would be to redirect to the hydra URL returned by the request, here hydra ensures the cookie set at the beginning of the flow is still set it then returns to the preconfigured consent URL which is the backend service again in our case, here we get the consent information with the consent_challenge provided, if the user hasn't previously asked hydra to remember their consent decision, we redirect to our Nuxt app consent screen with the challenge, client, user, CSRF token(generated using csurf package) and requested scope.
    
    [E]The Nuxt app renders the consent screen, the user authorizes the client, where we can use AJAX request, to our backend service with the granted scope challenge and CSRF token, we ask hydra to acceptConsentRequest, hydra returns the client's callback URL set by the client, with the authorization code, we then redirect back to the client app where the client can then exchange the authorization code for the access token and refresh token (if applicable) and get user info or perform other operations on our API using the access token.
    
- **The user is logged in to our service but hasn't previously asked hydra to remember their oauth2 consent: [A]**In this case the flow starts as before but on fetching login request with the challenge provided, hydra detects the user is logged in as was set previously and returns the consent URL as the redirect URL, if not ( i.e they are logged in to our service but haven't consented to the client oauth2 request) the backend service performs the three steps in [A] of the previous point to generate the Kratos URL, and once Kratos receives this request it detects a valid session cookie that the user is logged in, so it doesn't bother rendering login state, it just redirects to return URL, which is the backend service URL that includes the hydra_login_state and hydra_challenge as before.
    
    [B]From here the flow continues from [C] - accept login request, then [D] - initiate consent to [E] - accept consent request, of the previous point.
    
- **The user is logged in and had previously asked hydra to remember their oauth2 consent:**
    
    With this, the user wouldn't experience any page redirect on clicking login with our service. The flow is the same as the [A] of the previous point since the user is logged in, but is different when it comes to the consent step.
    
    Once the backend service is hit with the request it performs [C] from the first point which is to accept login request but when its time to perform [D] hydra detects the user had previously checked the remember consent option, so we can skip consent, we accept consent request and redirect back to the client app with the authorization code where the client can then exchange the authorization code for the access token and refresh token (if applicable) and then go-ahead to get user info or perform other operations on our API using the access token.
    
    And that pretty much wraps it up.

large_fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

medium_fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

small_fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

thumbnail_fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

xsmall_fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

fingerprint-authentication-2021-08-26-19-52-29-utc.jpg

Setting up production-ready ORY Hydra and Kratos oauth2 flow using Nuxt js for rendering login and consent screen

## The Problem

Recently, at the company where I work, we faced the challenge of building a marketplace solution that could scale and support vast traffic. It’s for a niche market, but the specifications and requirements are quite similar to already available solutions like Vinted, eBay, or Depop. These platforms have established reputations, and the goal for the company was to bring all sellers in their industry together to trade in one place.

## The Goal

For the Minimum Viable Product (MVP), there was quite an extensive list of features and capabilities expected, including:

- Onboarding customers and sellers with full payment provider setup
- Product listings
- Product approval flow via the super admin
- Fast search and product discovery
- Cart-to-checkout flow
- Buy now option
- Offers/product negotiation flow
- Messaging between seller and buyer
- Order management and shipping
- Return flow
- Notifications throughout the system
- Opt-in or opt-out of certain features like offers and returns

## Selecting the Tech Stack

As this blog focuses primarily on backend technology, I will keep the discussion limited to backend stacks.

Based on project needs and our proficiency in Node.js (Typescript), we selected it for backend API development. The main question was whether to write the API from scratch or extend an existing solution.

Weighing the two options:

- Writing the system from scratch (using NestJS) provides full control, allowing us to add features like messaging directly into the system while avoiding unnecessary bloat.
- Using an existing solution, like Medusa JS, a highly extensible e-commerce platform, allows us to leverage a battle-tested e-commerce flow and only extend it for custom logic and additional marketplace-specific features. However, this comes with the tradeoff of unused features that are not needed by the marketplace.

## Decision to Use Medusa

In the end, we decided to pick Medusa for the following reasons:

- Written in Typescript
- Uses ORMs we're familiar with (TypeORM)
- Highly extensible and customizable
- Well-documented
- Modular architecture in V2 (coming soon), which helps address the issue of unused features/modules
- Great developer adoption and support

The rest of the tech stack was decided based on Medusa, as it integrates seamlessly with many existing adapters.

## Selecting the Database – PostgreSQL

PostgreSQL is the primary supported database for Medusa. We initially tried CockroachDB but encountered issues with certain data types, so we opted for the recommended PostgreSQL, which we set up using Google Cloud SQL.

## Implementing Authentication

Medusa comes with built-in authentication, but we needed social authentication (at least Google). Fortunately, there is a [Medusa plugin](https://medusajs.com/plugins/medusa-plugin-auth/) for this, which made it easy to set up. We just needed to configure Google credentials and environment variables.

## Writing `medusa-plugin-marketplace`

This being the third marketplace I’ve built with Medusa, I’ve come across things I wished were essentially plug-and-play to transform a fresh Medusa installation into a basic marketplace. So, I decided to consolidate these elements and publish them as a public plugin: [`medusa-plugin-marketplace`](https://www.npmjs.com/package/medusa-plugin-marketplace).

It includes the following features:

- Multiple store support in the Medusa store model
- Store-specific scoping for:
    - Products
    - Orders
    - Shipping options
    - Invites
    - Users
- Store roles and permissions
- Middleware to prevent cross-store actions
- Advanced Stripe module with marketplace logic:
    - Application fee support
    - Payment splitting (e.g., shipping fee goes to the marketplace Stripe account if it handles label printing)
    - Payment split handling on returns
    - Customizable payment intent and capture behavior
    - Stripe account onboarding widget on super admin
- Order cart splitting for multiple stores
- Support for filtering public products by store ID

The plugin is still a work-in-progress, and more work is needed to make it customizable to user needs. Please [give it a star](https://github.com/Slaknoah/medusa-marketplace) to support the work.

## Cache Service – Redis

Medusa supports both in-memory and Redis caching via plugins. For production use, Redis is recommended, so we opted for Redis.

## Event Listeners and Storage

We implemented the Redis event module for Medusa, which is essential for listening to certain events and triggering actions, such as:

- Deleting products or variants when the quantity is updated
- Sending notifications (more on that later)
- Removing products from the search index upon deletion
- Syncing product categories upon option updates
- Updating offers when orders are completed, etc.

## Fast Search/Product Indexing with Algolia

We implemented Algolia search but found that the existing module wasn’t customizable enough for our business needs. Since our products are volatile and constantly deleted once out of stock, I wrote a custom Algolia search module for Medusa. This reduced the payload saved in the index. Although this approach comes at a cost with increased search traffic, it allowed us to get the MVP to market quickly. However, we are considering switching to Meilisearch in the future due to the costs associated with Algolia.

## Choosing Google Cloud for Hosting and Solving Issues with Storage

We opted for Google Cloud App Engine to deploy the backend because of its scalability and integration with other dependencies like the database and storage. Though documentation for deploying Medusa to App Engine is scarce, setting it up was straightforward with the right IAM configurations and a continuous deployment setup using Cloud Build.

For file storage, we used Google Cloud Storage and wrote a custom Medusa file module to access public and private buckets. There was an issue with Medusa’s hardcoded `/uploads` folder (App Engine only allows writing to `/tmp`), so we patched it to resolve the issue.

## Notification Orchestration System – Novu & Bird

Notifications are a key part of the project. Our requirements included:

- Email notifications
- Push notifications
- In-app notifications
- Digest or delayed notifications
- Phone OTP SMS

To meet these needs, we opted for a notification orchestration system. We chose Novu due to its open-source availability and affordable pricing (compared to Knock). For push notifications, we used Expo Notifications, but we encountered issues integrating Bird (formerly MessageBird) with Novu, so we wrote a custom module to handle authentication codes while Novu handles the rest.

## Implementing Offers

Another requirement was enabling price negotiation between buyers and sellers. This involved actions like:

- Accepting an offer
- Rejecting an offer
- Making a counteroffer

We stored offer histories and used custom carts to redirect buyers once offers were approved. Notifications were crucial here since offers expire within a set timeframe.

## Messaging with Censorship

For messaging, we initially planned a simple email-like system, but the scope expanded to include:

- Messaging between buyers and sellers
- Instant message delivery
- Read receipts
- Message notifications
- Hashing of sensitive information like phone numbers, email addresses, and credit cards
- Censorship of banned words

## Error Reporting with Sentry

We used the Medusa Sentry plugin for error reporting. More details can be found in the [documentation](https://medusajs.com/).

## Shipping Provider for Printing Labels: Shippo

The requirements for shipping included:

- Basic support for fulfillment by sellers
- Automatic generation of shipping labels
- Support for multiple providers
- Customizable shipping prices via the super admin

Although Medusa has a plugin for Webshipper, we opted for Shippo due to its free entry and great documentation. Since there wasn’t a good Shippo plugin for Medusa, we wrote a custom integration, allowing us to customize workflows like setting fixed shipping prices.

## Product Approval

During the early stages, we needed a product approval flow where the marketplace could review products before they went live. Fortunately, Medusa offers these statuses out-of-the-box, so we just needed to implement filtering with Algolia and build a custom UI for super admins to review products.

## NB

This is just a surface level look at how the system was created and the reasoning behind certain decisions without going into detail of how to implement certain features, if you require more information regarding building out these systems or questions feel free to reach out via email.

small_medusa content.png

thumbnail_medusa content.png

xsmall_medusa content.png

medusa content.png

Creating a global production ready marketplace with Medusa JS

In the last ten years, full-stack development has changed a lot. From an out-of-the-ordinary responsibility for developers who could handle both backend and frontend tasks to becoming an industry standard, it has indeed been a strange journey.

Today, being a full-stack developer means more than juggling two sides of an application. It is about mastering many technologies in an array and adapting to the recent trends by following best practices. Let's dive into how the evolution of full-stack development came to be, what recent trends are setting the pace for it, and what is considered best practices for every full-stack developer to have in their toolkit.

## From Specialization to Generalization: A Journey

Full-stack development began to gain pace when the tech industry especially startups in the early phases realized they needed versatile developers who could do it all: build the frontend, manage the backend, and even take care of infrastructure. Earlier, developers were either backend-focused, being masters at languages like PHP or Python, or frontend-centric, working with HTML, CSS, and JavaScript. But as web applications continued to get increasingly complex and interactive, strong was the need for developers to be able to switch between both worlds comfortably.

It meant that the shift in demands required developers to do more than know multiple languages; they had to understand the entire ecosystem, from databases to deployment pipelines.

## Full Stack Development Trends

Following are some of the key trends to shape the future of full-stack development:

1. **JavaScript Dominance**
    
    JavaScript strongly positions itself as a core language for a full-stack developer. With Node.js handling the back end and systems like React, Vue, and Angular dominating the front, JavaScript is the glue that stitches modern web applications together. As I found out during my transition from PHP to Node.js, if you know your JavaScript, you are ready for nearly everything on both client-side to server-side development. Other great languages include: JavaScript, Python, Ruby, Java, PHP etc.
    
2. **API Driven Architecture**
    
    API-first development is more on the rise. RESTful APIs and GraphQL have become common go-to solutions for creating scalable and flexible web services. APIs can power interactions between the frontend and backend, affording developers even more ways to craft modular applications. This leads to a more decoupled architecture in which the evolution of both frontends and backends becomes independent of each other, a critical feature for scalability.
    
3. **Cloud-Native Applications**
    
    Cloud-native development, with AWS, Azure, and Google Cloud leading from the front, becomes one of the essential skills that every developer should master. The developers need to know a thing or two about microservices, containerization-hence Docker and Kubernetes and serverless computing to create scalable and cost-efficient applications.
    
4. **Jamstack and Static Site Generators**
    
    Jamstack has redefined the way we think about web applications. Allowing for a complete decoupling of frontends and backends into static files, APIs, and JavaScript empowers better performance and security. Static site generators like Next.js and Gatsby are on the rise, allowing developers the ability to deliver super-fast websites with very light server management.
    
5. **Performance Optimization**
    
    As the web grows increasingly complex, performance optimizations have become a prime concern. A full-stack developer today needs to be efficient at optimizing either backend performance-thinking about query optimization or caching strategies, for example, with Redis-, or frontend assets, thinking about lazy loading or minification. Smoothening the load time and escalating the application so that it could scale efficiently are no longer optional; it's expected.
    

## Best Practices Every Full-Stack Developer Should Follow

With the rapid evolution of the art of full-stack development, a focus on best practices really pays off in terms of staying productive and pitfall-free. Here are some core practices:

1. **Modularity of Code**
    
    Well, working modularly and reusing code is very critical for full-stack development. A well-organized project with clear separations between different components reduces complexity and enhances the ability to collaborate. In back-end frameworks like Express.js, for example, a need exists to structure your routes and middleware well to keep things organized.
    
2. **Version Control and Continuous Integration**
    
    A very important thing would be to integrate version control into your workflow, which in this day and age is basically the use of an industry standard like Git. That can be coupled with CI/CD pipelines so that testing, integration, and deployment are automated. Tools that would support such a process include Jenkins, Travis CI, or GitHub Actions, which simplify the process or at least ensure that every single change you push is as vetted as possible before hitting production.
    
3. **Focus on Security**
    
    Security is not an option; always secure your application from every level that can be done, from HTTPS to proper authentication mechanisms, OAuth, JWT, and proper sanitizing of user input to avoid XSS or SQL injection. Knowing the most common security pitfalls saves you from building weak applications.
    
4. **Scaling Considerations**
    
    In full-stack development, scalability should be a concern for every developer. It basically means building an application that would handle increased traffic, data, and features imposed on it. If it's about building APIs or managing databases, think about load balancing, database replication, and efficient query handling.
    
5. **Documentation and Communication**
    
    You are not writing software in a vacuum. Documentation helps other people understand your code, and it maintains it for the long run. Comment on your code, have meaningful commit messages, and document your APIs. Tools like Swagger can ensure that API documentation is clear.
    

## Conclusion

The role of a full-stack developer keeps changing with the changes in the technological world. It's all about understanding new trends that come up, such as API-driven architecture, cloud computing, and performance optimization. At the same time, however, one should not be able to forget that best practices include code modularity, security, and scalability to make a person battle-ready for modern web development challenges. Adaptability and learning in themselves are at the core of full-stack development. The sharper you keep these skills, the more successful you will be in this ever-evolving field.

Full-Stack Development Evolution: Trends and Best Practices

large_Full-Stack Development Evolution: Trends and Best Practices

medium_Full-Stack Development Evolution: Trends and Best Practices

small_Full-Stack Development Evolution: Trends and Best Practices

thumbnail_Full-Stack Development Evolution: Trends and Best Practices

xlarge_Full-Stack Development Evolution: Trends and Best Practices

xsmall_Full-Stack Development Evolution: Trends and Best Practices

Scalability is the magic word every developer and startup founder talks about but often struggle to achieve. The process of building scalable applications requires making the right architectural and technological decisions from the outset. In my journey building **Nexaloom** and **Rareboots Marketplace**, I’ve had my fair share of learning experiences—both successes and challenges. In this article, I’ll walk you through key lessons learned in building scalable applications, covering architectural decisions, tech choices, and practical steps to ensure your application can handle growth.

## Lesson 1: Start with the Right Tech Stack

When you're setting out to build a scalable application, the choice of tech stack can make or break your project’s ability to handle future growth.

### **Choosing Node.js for Nexaloom**

For [**Nexaloom**](https://www.nexaloom.co), an appointment scheduling and business management software, the need for rapid development and scalability was obvious from the start. I decided to go with **Node.js** for the backend, primarily because of its non-blocking, event-driven architecture. Node.js has a reputation for handling a high number of concurrent connections, which is exactly what [Nexaloom](https://nexaloom.co) needed as it scaled to serve multiple businesses and users simultaneously.

Another win for Node.js is the **JavaScript ecosystem**. With JavaScript running on both the front-end and back-end, it allowed for a unified development process, reducing context switching between languages. This also meant that I could easily onboard new developers, as JavaScript remains a common denominator among web developers.

### **Choosing Medusa.js for Rareboots**

On the other hand, when building **Rareboots Marketplace**, I had a different set of challenges. Rareboots needed a robust e-commerce platform that could handle multiple sellers, extensive product listings, and high traffic. Instead of building everything from scratch, I chose to use **Medusa.js**, an open-source e-commerce framework built on Node.js.

Medusa provided a solid foundation for the marketplace with built-in support for core features like cart management, order handling, and even Stripe integration. But here’s the important part: it was **extensible**. Medusa allowed me to extend functionality, particularly in areas like custom product filtering, handling marketplace-specific logic, and advanced payment flows. This saved a lot of time in development while still keeping the codebase lean and modular.

## Lesson 2: Database Architecture Matters

It’s tempting to throw everything into a single database and call it a day, but that’s a surefire way to run into scaling issues later. For both Nexaloom and Rareboots, I had to carefully consider how data was stored and accessed.

### **Choosing PostgreSQL for Structured Data**

In both applications, I chose **PostgreSQL** as the primary database. PostgreSQL shines when it comes to handling relational data at scale. It’s also highly versatile, allowing for complex queries, transactions, and data integrity, which was critical for both Nexaloom’s appointment data and Rareboots’ marketplace transactions.

In Nexaloom, for example, we deal with a lot of user-generated data—appointment schedules, client profiles, and payments. The data relationships are clear, so relational databases made the most sense. Moreover, PostgreSQL’s ability to handle large datasets with proper indexing ensured that as the platform grew, the performance didn’t degrade.

### **Caching with Redis**

Scaling isn't just about the database itself but how data is accessed. For frequently accessed data, caching can significantly reduce load on the database. In Rareboots, where certain product searches and recommendations were repeatedly requested, I implemented **Redis** for caching. This made a huge difference in reducing latency and improving user experience as the marketplace scaled up.

## Lesson 3: Modular, Microservice-Based Architecture

### **Monolith vs. Microservices**

When Nexaloom first started, the application was monolithic—a single codebase handling everything from user authentication to appointment scheduling. This was fine for the initial stages, but as we grew, it became clear that managing this single large application was going to be a nightmare.

Enter **microservices**.

Moving to a microservices architecture allowed us to decouple features and services into independent modules. For example, we separated the appointment scheduling logic from user management. This approach not only improved scalability but also made it easier to deploy updates independently without affecting other parts of the system.

In Rareboots, I adopted a hybrid approach. Some core services, like the checkout and payment processes, were split into microservices, while the core product listing and management were kept together in a more modular monolithic style. This allowed for flexibility without overcomplicating things too early.

### **Communication Between Services**

One important lesson in microservices is that you need an efficient way for services to communicate. For both Nexaloom and Rareboots, I used **message queues** for inter-service communication, specifically **RabbitMQ**. This ensures that as traffic scales and services need to communicate asynchronously (e.g., handling payment confirmation or sending out email notifications), the system can handle the load without bottlenecking.

## Lesson 4: Scaling the Frontend

### **Component-Based UI Development with React**

Both Nexaloom and Rareboots needed responsive, scalable UIs. **React** was my go-to choice because of its component-based structure. Components are reusable, easy to maintain, and can be rendered dynamically based on the data flowing in from the backend.

For Nexaloom, this meant creating reusable components for things like the appointment calendar and client profile forms. As the platform grew and more features were added, React’s component reusability allowed for quick iterations and updates without rewriting the entire UI.

### **Server-Side Rendering for Performance**

For Rareboots, scalability was not just about handling traffic but also about performance. As an e-commerce platform, every second counts when it comes to load time, and a slow experience can mean lost sales. To ensure optimal performance, I implemented **server-side rendering (SSR)** using **Next.js**. SSR allowed us to serve pre-rendered pages to users, reducing the initial load time and improving SEO, both crucial for marketplace success.

## Lesson 5: Don’t Ignore DevOps and CI/CD

When you’re building an application that needs to scale, having a solid **DevOps** pipeline in place is crucial.

### **Automating Deployments**

Both Nexaloom and Rareboots required frequent updates, and manual deployments simply weren’t feasible. By setting up a **CI/CD pipeline** with **Jenkins** and **GitLab CI**, we were able to automate builds, run tests, and deploy code to production with minimal downtime. This allowed us to push updates faster without breaking the application or creating unnecessary bottlenecks.

### **Monitoring and Scaling with Kubernetes**

As both applications started handling more traffic, I introduced **Kubernetes** to manage containerized services. Kubernetes allowed us to scale individual services up or down based on demand, making sure we never over-provision resources. It also helped in managing deployment rollbacks in case any issues arose in production.

## Final Thoughts

Building scalable applications requires careful planning, the right tech stack, and a deep understanding of how your application will grow. With Nexaloom, I learned the importance of modular architecture, and with Rareboots, I gained firsthand experience in building marketplace features at scale.

Here’s the takeaway: Start small, but design your application with growth in mind. Whether it’s choosing the right database, splitting your services into manageable parts, or caching frequently accessed data, every decision you make early on will impact your ability to scale later. Keep learning, keep iterating, and don’t be afraid to make adjustments as you go.

large_Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

medium_Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

small_Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

thumbnail_Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

xsmall_Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

Building Scalable Applications- Lessons from Nexaloom and Rareboots  .png

Building Scalable Applications: Lessons from Nexaloom and Rareboots

Technology is transforming nearly every aspect of our lives, and public transportation is no exception. As cities grow and populations increase, the need for smarter, more efficient transit systems has become more pressing. The future of transit technology lies in innovations that not only improve operational efficiency but also enhance the overall passenger experience. In this article, I’ll explore the key innovations shaping public transport, drawing from my own experience building **TOST**, a transit management system for US-based operators.

## The Current Landscape of Public Transit

Before diving into the innovations, it’s important to understand the challenges that public transportation faces today. From outdated infrastructure to inefficient route planning, many cities struggle to keep up with growing commuter demands. The result? Increased traffic congestion, unreliable schedules, and a poor user experience.

**Traditional transit management systems** have long relied on manual processes, leaving little room for optimization. However, with advancements in technology, we’re now seeing a shift towards more intelligent systems that leverage real-time data, automation, and even artificial intelligence (AI) to optimize every aspect of the journey.

## The Rise of Intelligent Transit Systems

### **1. Real-Time Data and Predictive Analytics**

One of the biggest advancements in transit technology is the use of **real-time data** to make decisions on the fly. In the past, passengers relied on static schedules, and any delays or changes would leave them stranded without alternatives. Today, real-time data allows transit operators to dynamically adjust routes, notify passengers of delays, and even reroute vehicles to optimize traffic flow.

With **TOST**, one of the key challenges was ensuring that transit operators had access to real-time data on routes, vehicle locations, and driver statuses. By integrating **GPS tracking** and using **General Transit Feed Specification (GTFS)** data, we were able to give operators live updates on their fleets. This information enabled more efficient route management, reduced delays, and allowed passengers to receive up-to-the-minute updates on their journeys.

**Predictive analytics** takes this a step further by using historical data to anticipate and solve problems before they occur. For example, during peak hours or bad weather, the system can predict potential delays and proactively adjust schedules or dispatch additional vehicles to avoid disruptions.

### **2. AI-Powered Route Optimization**

Public transportation has long been burdened by inefficient routing. Traditionally, routes were static, designed based on outdated traffic patterns and passenger demand. But with advancements in **AI** and **machine learning**, transit systems are now capable of dynamically optimizing routes based on real-time conditions.

During the development of TOST, we implemented algorithms that continuously analyzed traffic patterns, passenger flow, and other variables. This enabled transit operators to adjust routes on the fly, avoiding traffic bottlenecks and reducing overall travel times. The result? Faster, more reliable service that passengers could count on.

In the future, we can expect AI to play an even bigger role, with systems that learn from passenger behavior and adjust routes accordingly. This could lead to **on-demand public transportation**, where routes are not fixed but instead adapt in real-time based on where passengers need to go. Imagine a bus that changes its route throughout the day to meet demand more efficiently — that’s the direction we’re heading.

### **3. Smart Ticketing and Payments**

Another major innovation in transit technology is **smart ticketing**. Gone are the days of paper tickets and cash payments. Instead, we’re seeing the rise of **contactless payments**, mobile apps, and even **QR code-based ticketing systems** that make it easier for passengers to access and pay for transit services.

When working on TOST, one of the first things we looked at was integrating digital payments into the system. We worked with several payment providers to introduce **mobile wallets** and **contactless cards**. This not only sped up the boarding process but also reduced the operational burden of managing cash payments.

Looking ahead, **blockchain technology** could further revolutionize the way payments are handled in transit systems. Imagine an entirely decentralized system where users pay for rides using cryptocurrency, and all transactions are securely recorded on a blockchain ledger, eliminating fraud and reducing transaction fees.

### **4. Autonomous and Electric Vehicles**

It’s impossible to talk about the future of transit technology without mentioning **autonomous vehicles** (AVs) and **electric vehicles** (EVs). AVs promise to reduce human error, improve safety, and provide more consistent service, while EVs are paving the way for greener, more sustainable public transportation.

Many cities are already experimenting with **autonomous buses and shuttles**. While we’re still some time away from fully autonomous public transit systems, early trials have shown that AVs can dramatically reduce operating costs and improve reliability. In TOST, we began laying the groundwork for future **AV integrations** by building a flexible platform capable of interfacing with autonomous vehicle fleets as they become more mainstream.

At the same time, EVs are quickly becoming the standard for transit fleets, thanks to their lower operating costs and reduced environmental impact. Many transit agencies are transitioning to electric buses, which not only cut down on emissions but also reduce maintenance costs compared to traditional fuel-powered vehicles. The future of transit will undoubtedly be powered by electricity.

### **5. The Role of IoT in Transit Systems**

Another exciting development in transit technology is the integration of **Internet of Things (IoT)** devices. IoT allows for the seamless connection of vehicles, infrastructure, and users, enabling a more connected transit ecosystem. For example, **smart sensors** on buses and trains can monitor everything from vehicle health to passenger occupancy, providing valuable data that can be used to optimize operations in real-time.

In TOST, we incorporated IoT devices to monitor vehicle conditions and track driver performance. These sensors provided valuable insights into fuel efficiency, engine health, and even driver behavior, allowing operators to proactively address maintenance issues and improve safety.

In the future, IoT devices will likely play a larger role in creating **smart cities**. Imagine traffic lights that communicate with buses to extend green lights during peak hours or smart bus stops that provide real-time information to passengers based on vehicle locations and expected arrivals. These advancements will lead to a more connected and efficient urban transportation system.

## Final Thoughts: The Road Ahead

The future of transit technology is bright. With innovations like real-time data, AI-powered route optimization, smart payments, and the rise of autonomous and electric vehicles, public transportation is on the cusp of a major transformation. The work we did with **TOST** showed me firsthand how impactful these technologies can be when implemented thoughtfully.

For transit systems to truly evolve, it’s essential to adopt a holistic approach — one that integrates technology into every aspect of operations, from vehicle management to passenger experience. It’s not just about solving today’s problems; it’s about building the foundation for a smarter, more sustainable transit future.

Public transportation plays a critical role in shaping the cities of tomorrow, and the innovations we implement today will define how we move in the future. Whether you're a developer, a transit operator, or simply a commuter, we all stand to benefit from these advancements.

======Human

Technology touches every corner of our life, and public transportation doesn't stand out as an exception to this. With growing cities and their populations, the demand for smarter and more efficient transit systems has gone from urgent to very urgent. The future of transit technology needs to rest in innovations improving not only operational efficiency but the overall experience of the passengers. I'll outline the main developments that shape public transport in this article by drawing from my own experience in building TOST—a transit management system for US-based operators.

**The Current Landscape of Public Transit**

Before discussing the innovations, let's briefly understand what challenges are faced today by public transportation. From aged infrastructure to inefficient route planning, many cities struggle to keep up with the demands brought on by growing commuters. The result? Increased traffic congestion, unreliable schedules, and a poor user experience.

Until now, the traditional type of transit management systems is usually done manually, with hardly any room for optimization, but now with the development of technology, the shift to an intelligent approach through the use of real-time data, automation, and sometimes even artificial intelligence has become more common in optimizing every last detail of the journey.

**The Rise of Intelligent Transit Systems**

1. **Real-time Data and Predictive Analytics**
    
    Probably one of the biggest evolutionary changes in transit technologies is using real-time data to make decisions on the fly. In contrast, previous passengers relied on static schedules where delays or changes meant they were left with no alternatives. Today, with real-time data, operations can dynamically shift routes, warn passengers of any delays, and even reroute vehicles to optimize the flow of traffic.
    
    With TOST, one of the very important challenges was how to provide real-time data to transit operators on routes, vehicle locations, and the status of drivers. We integrated GPS tracking and utilized data from the General Transit Feed Specification so operators could receive live updates about their fleets. This allowed for better route management, reduced delays, and the ability for passengers to be informed right up to the minute about their journeys.
    
    Predictive analytics goes a step beyond by anticipating the problems before they happen by making use of historical data to solve them. For example, predictive analytics could predict possible delays during peak hours or bad weather so that the system may proactively adjust the schedules or deploy more vehicles to avoid disruption.
    
2. **AI-Powered Route Optimization**
    
    Public transportation has always been plagued with inefficiency in routing. Conventionally, the routes were static, devised based on outdated patterns of traffic and passenger demand. However, with the rise of AI and machine learning, transit systems are now capable of dynamic re-optimization of routes depending on real-time conditions.
    
    During the development of TOST, we implemented algorithms that were in constant observation of traffic patterns and passenger flow, among many variables. What that did was allow for quick changes to routes in order to avoid traffic bottlenecks, decreasing overall travel times. The result? Quicker, more reliable service that passengers can rely on.
    
    In the future, AI will play an even more important role: systems will learn from passenger behavior and adjust routes accordingly. This may even lead to demand-based public transportation, where routes change in real time depending on passenger needs. Imagine a bus changing its route during the day to meet demand better—that's where we're heading.
    
3. **Smart Ticketing and Payments**
    
    Another major innovation in transit technology allows for smart transit ticketing. Gone are the days of paper tickets or cash payments, as contactless payment systems, mobile apps, and even QR code-based ticketing systems make it easier for passengers to access and pay for services.
    
    One of the early considerations when working on TOST was integrating digital payments. We worked with various payment providers to introduce mobile wallets and contactless cards. This not only accelerated the boarding process but also reduced the operational headache of managing cash payments.
    
    In the future, blockchain might further disrupt how transit systems handle payments. Imagine a decentralized system where users pay for rides via cryptocurrency, with every transaction recorded on a blockchain ledger, securing it from fraud and reducing transaction fees.
    
4. **Autonomous and Electric Vehicles**
    
    It is quite impossible to talk about the future of transit technology without referencing AVs and EVs. AVs promise a reduction in human error, improved safety, and more consistent service, while EVs are leading the charge toward a greener, more sustainable public transportation environment.
    
    Many cities are already experimenting with autonomous buses and shuttles. While we remain a long way off from fully autonomous public transit systems, early trials have shown that AVs can dramatically reduce operating costs while improving reliability. Starting with TOST, we laid the groundwork for future AV integrations by providing a flexible platform to interface with autonomous vehicle fleets as they become mainstream.
    
    Meanwhile, EVs are fast becoming the norm in transit fleets because of lower operating costs and environmental benefits. A host of transit agencies are converting their fleets into electric buses, which not only reduce emissions but also have lower maintenance costs compared to traditionally fueled vehicles. The future of transit will undoubtedly be electric.
    
5. **Role of IoT in Transit Systems**
    
    Another exciting development in transit technology is the integration of Internet of Things (IoT) devices. IoT allows for wireless connectivity among vehicles, infrastructure, and users, creating a more integrated transit ecosystem. For instance, smart sensors on buses and trains can monitor vehicle health and passenger occupancy, providing valuable data to optimize operations in real time.
    
    With TOST, we installed IoT devices on vehicles to monitor conditions and track driver performance. These sensors can track data such as fuel efficiency, engine health, and driver behavior, helping operators address maintenance issues proactively and improve safety.
    
    In the future, IoT devices will make up larger components of smart cities: traffic lights could extend green lights for buses during peak hours, or smart bus stops could provide passengers with real-time arrival information based on vehicle locations. These developments will lead to more connected and efficient urban transit systems.
    

**Final Thoughts: The Road Ahead**

The future of transit technology is bright. Innovations like real-time data, AI-powered route optimization, smart payments, and the rise of autonomous and electric vehicles will usher in a new era of public transportation. The work we did with TOST showed me firsthand just how impactful these technologies can be when implemented thoughtfully.

Transit systems need to adopt a holistic approach, incorporating technology into every facet of their operations—from vehicle management to passenger experience. It's about solving today's problems while building for a smarter, more sustainable transit future.

Public transportation will shape the cities of tomorrow, and the innovations we set in motion today will determine how we move around in the future. Whether you're a developer, transit operator, or commuter, we all stand to benefit from these advancements.

large_The Future of Transit Technology- Innovations Shaping Public Transport.png

medium_The Future of Transit Technology- Innovations Shaping Public Transport.png

small_The Future of Transit Technology- Innovations Shaping Public Transport.png

thumbnail_The Future of Transit Technology- Innovations Shaping Public Transport.png

xsmall_The Future of Transit Technology- Innovations Shaping Public Transport.png

The Future of Transit Technology- Innovations Shaping Public Transport.png

The Future of Transit Technology: Innovations Shaping Public Transport