DEV Community: Abdul Samad

Devcycle Commerce - Live Sale and Simulation

Abdul Samad — Mon, 23 Dec 2024 07:58:13 +0000

This is a submission for the DevCycle Feature Flag Challenge: Feature Flag Funhouse

What I Built

I had the aspiration to build an application with a genuine use-case of feature flags rather than a replacement of backend. This application is a theoratical blend of various services.

The first-person view is of a CEO/Sales-Admin of a medium size fashion startup who are organising a single day sale of, say, New Year Eve. The company has made presence in around 6-7 countries and planning to have the sale in each of them on the specified day.

The application has overall 4 components, the frontend and backend serve their usual purpose, while a dashboard is plugged with them, that gets data in the form of metrics, clicks, usage and other terms of the sales data world. The dashboard is supposed to be used by the Sales Admin of the company who can then use the various features of dashboard to make informed decision about the correct flags for the application. A simulation mimicking the same is present on dashboard.

A schedule is created on the dashboard based on timezones of various countries to activate the sale variable only when the eve arrives in their timezones.

For the countries that now have an active sale, various actions can be performed from the dashboard based on insights and metrics.

I have deployed the website, with different combinations of variations in different country. I have also deployed the dashboard separately.

Use Cases

For ex, lets say company get the complaint that the experimental chatbot is using rude language. The admin can then toggle the chatbot variable off.

Or The products being recommended on recommend page are not being picked in cart and even leading to mid-process abandonment, then recommend-page variable can be turned off.

Suppose, that after reaching cart (any layout - sheet or page), there is high cart abandonment due to high total cost, then the admin can increase the shipping-waiver level that will be utilized on both frontend (to display the promotional banner of waiver) and backend (to calculate the discount on shipping).

There is the chance to have different variations for different countries based on historical metrics and one of the benefits of the data structures that I have used to store and track the state of devcycle.

Feature Flags

The application consists a total of 5 features and 7 variables.

The variables are as follows and affect specific parts of the UI and backend

sale-status (frontend, backend) states whether sale is active in the current user region. A prerequisite for other flags.
sort-strategy (backend) variable contains the strategy for sorting the categories order on home page and the order of products in them. For ex. "profit" strategy would display first the category and products with maximum margins to the company.
recommend-strategy (backend) variable also has the same values of strategies but it is used when recommending products to the user on recommend page. For ex. "stock" would mean that encourage the user to buy overstocked items. recommend-strategy and sort-strategy are part of same feature with variations such as profit-aggressive and stock-aware.
chatbot (frontend) variable toggles an experimental ai chatbot on the website, developed just-in-time for the sale.
cart-page (frontend) variable toggles the new experiemntal cart layout which involves a dedicated cart page rather than currently-used sidesheet.
recommend-page (frontend) variable toggles an experimental recommend page before the cart page. It only works when cart-page variable is true hence part of the same feature called cart-interface on devcycle.
shipping-waiver (frontend, backend) variable specifies the degree of waiving off of shipping fees. Products on the website have free shipping, in-house shipping and third-party shipping. Banners are toggled on the UI and cart layouts (both sheet and page) about the promotion.

The entire reference of all features/variables/variations is available on both website and dashboard.
The website features the current variations and variable values used in that region.
Since dashboard is for admin, it features the current state for all countries at one place.

Dashboard

On the dashboard, there is a control pane and simulation pane. The control pane is like the devcycle platform custom-built for the application. The simulation pane gives an opportunity to experience the use-case of this application in first person. It mimics insights and metrics that may well be there in a company and a control flow that can be played with as long as the timer runs.

Simulation

The dashboard has the control pane which is like custom-made devcycle dashboard and a simulation pane.

A simulation mimicking the scenario of live-sale is added to the dashboard with carefully-made flow control of what may actually come in real experience.
The game utilises charts and a stream of queries (or insights) which provides actionable suggestions like changing the feature flag to enhance the customer experience.

Local

The website is deployed with my account credentials and various countries have various variations demonstrated.

Navigating to different countries will give a different combination of feature flags and can be checked on "Flag State" dialog button

Both website and dashboard can be setup locally and information is on the readme page of repo.

Demo

Website: https://devcycle-commerce.vercel.app

Dashboard: https://devcycle-dashboard.vercel.app

My Code

Repo: https://github.com/mr-loop-1/devcycle-commerce

Additional Prize Categories

API All-Star: Awarded to a project that shines by making full use of the DevCycle API— showcase creativity and capability through effective integration!

My DevCycle Experience

I heard about feature flags for first time through this hackathon itself and right after learning about them, I realized how such on-the-go onfiguration was needed in many places of my past projects.

The inspiration to built this app came from the sale flag only, that it can be scheduled for different timezones which was something I thought backend would have a hard time at since it involved showing a different UI too.

This project was the first where I made my own context and reducer in react. It also has the most complex state management by far that I have written. The first time I have visualized data using charts and learnt a lot about reacharts library.

This is also the first time I have made a game, let alone making it playable and I am quite happy with the way it turned out to be.

I look forward to have more interaction with Devcycle's software and community.

One thing I liked about devcycle dashboard is the powerful API and the readymade hooks that made the integration very seamless.

I also realized that need of conditional flagging where my recommedn-strategy variable is only relevant when recommend-page is true. I will submit this feature request after finishing the app.

Challenges

I am happy that I was able to navigate through the various APIs and create a way to mimic the dashboard while keeping up with the complex data structures used to set and update feature flags for various time-zones. The biggest challenge was to update the target after storing the variation_ids.

The biggest time-consumer was the self-development of both apps from ground up as I wanted the app to behave a specific way.

Simulation Panel

The dashboard was planned to involve a 1-minute simulation of a live sale, with players playing as the sales manager of the website and changing feature flag variations based on live insights from various sales teams and metrics.
I will try to complete the panel very soon, even if it doesn't get evaluated as I already have the components made and need to piece together the flow of the game.

I added the simulation panel.

Images

The architecture of the application system

insights on dashboard simulation

Live Flag state

Separate Cart Page with Full Discount banner

Normal Cart Sheet with same banner

products with varying degree of discounts

insight history in simulation

Reference of all features

Pinata Filesystem and PinDrop

Abdul Samad — Mon, 14 Oct 2024 06:53:26 +0000

This is a submission for the The Pinata Challenge

What I Built

Pinata Filesystem and PinDrop acts as a layer on top of Pinata's storage system that allows users to organise and visualise their files using folders and sub-folders.

It provides an interface and at the same time extends the features of Pinata. The users can associate files with folders, as well as do most of the general functions like creating, deleting and downloading files and folders.

Inspiration

I had instantly decided to make a fast private file sharing system right on first day of hackathon since it is something I myself needed. But the idea had to be dropped since their was too much to be done.

Fast forward to 1 day before deadline, I thought about leveraging the feature of groups. I could make use of a relational db to create a heirarchy through self-references and make it a full-fledged platform to store and organise files.

Thankfully, with no-sleep development constantly for 24 hours, I present the first version of Pinata's own filesystem.

Pindrop folder

There is a feature called PinDrop (inspired from AirDrop) that I have ideated which is supposed to be a go-to folder that is present by default in the system when a user registers.
This folder is special in that it doesn't have sub-folders, instead a user can simply push and stack files and retreive them later. This is supposed to be for instant file shares between the user's two devices. It can even have its dedicated service and routes going forward.

Demo

https://pinata-fs.vercel.app/

https://github.com/mr-loop-1/pindrop

Overview

For Future

The best thing about the database is that nothing about actual files is being stored. It is only a hierarchical representation of groups.
Currently it may seem redundant as the app asks for jwt and gateway on register but I got to know through discord that new auth provider is being developed and with that integrated, the app would be completly detached from actual user data.

tech stack

server: expressjs, knexjs, mysql, hosted on railway
frontend: vite react, tailwind, hosted on vercel

Overview

The first greetings are the login/register pages. During registration, a valid pinata jwt and gateway url need to be provided. But it will never be exposed on client side and only for server operations.
This is the root folder mounted at "~/". All other folders are supposed to derive from here. In pinata, this group is created when a user first signsup.

Supported file types can be added using the Add File button in any folder. The file then gets added to the folder's group in pinata

Similarly, except in pinDrop folder at root, new folders can be created anywhere.

Clicking on a folder will navigate to it, a back button has been provided to navigate to previous folder. For navigating to root, remove the id param from url.

Files and folders can be deleting using the button provided on right. pinDrop folder can't be deleted, as is root.
Files can be opened in new tab using the download button provided. This is done through signed urls with expiry of 1 minute.

My Code

https://github.com/mr-loop-1/pindrop

instructions to run locally are provided. Please report any bugs/questions in comments or github issues.

More Information

Please ensure

Folder names can't contain spaces
Duplicate files/filenames can't be uploaded even in different folders as on pinata they are stored together

Way Forward

downloading multiple files and whole folders
currently delete feature of folder leaves files in subfolders dangling. i am yet to implement the query in knex as well as Pinata's sdk for recursive deletes.
some bug fixes and field validations
Currently, it requires user to manually provide jwt and gateway of their pinata accounts. I want to integrate the future pinata oauth provider to the app.

Metro Rail Path Finder

Abdul Samad — Thu, 13 Jan 2022 22:53:26 +0000

Overview of My Submission

I made an Express application which basically calculates the path from one station to another in a particular city's Metro rail map.

It connects to the database on Mongodb Atlas. My database has collections based on maps of different cities.
The express app passes the User-preferences over to functions that query the database to find the route.

The app is very easily scalable, as to add a map, one only has to add a new collection in the database (containing Station names etc) and one option in the "Map Select" drop-down.
Everything else, including the functions and the drop-downs are designed to get updates from the database itself.

Here is the link to my Github repository.

Submission Category:

Choose Your Own Adventure

Link to Code

mr-loop-1 / metro-path-mongodb

My Mongodb Atlas Project for Devto+Mongodb Hackathon

metro-path-mongodb

Note: The Mongodb database may refuse to connect sometimes. I am finding a fix for that

This is a Metro Rail Path Finder app I made for Dev.to + MongoDb Atlas Hackathon. It sources its data from Mongodb Atlas Database.

Technology Used: Expressjs, MongoDb Atlas

To run the app

Just make sure that node and npm are installed and

npm start

And it will be deployed on http://localhost:3000/users/details

The calculation may get slow for longer paths.

View on GitHub

Screenshots

Additional Resources / Info

Technology Used: Express, Mongodb, Atlas
Contact: iabdulsamad1412@gmail.com

Writing your first Client-Server Program Quickly!

Abdul Samad — Thu, 04 Nov 2021 06:32:28 +0000

Your College Professor asked you to prepare a basic client-server program for the networks lab next week or maybe you are yourself starting Socket programming, what's better than writing the first program and learning along that.

The quick theory

what is a socket ?

well, its (an integer and) a file descriptor through which we do our desired communication.

what does communication looks like ? (important)

Server - Bind()s socket to an address and port, this socket then listen()s for incoming, then accept()s the incoming request (from client).

Client - Connect()s your socket via local address and port for a listen()ing socket to accept().

what happens after connect() and accept() ?

accept() returns a new socket to be used for communicating to that particular accepted client.
In client side, the same socket used to connect is used to communicate.
now you can send() and recv() from both sides.

What is the first thing that you need? Headers!
We will be using the following

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>

Lets build both sides one-by-one

Server.c

int main() {
    int sockID1 = socket(PF_INET, SOCK_STREAM, 0);

A stream socket has been created in PF_INET(internet) domain.

Now, we have to bind our socket to an address and port. But, the bind() function asks for one struct (of sockaddr type) that has all that info. Instead we pass it sockaddr_in casted to sockaddr because it is more specific to our needs.

struct sockaddr_in addrPort1;
addrPort1.sin_family = AF_INET; // sets IPv4
addrPort1.sin_addr.s_addr = htonl(INADDR_ANY);
addrPort1.sin_port = htons(5200);
//htonl - host to network long, htons - host to network short

We filled the structure. Here, INADDR_ANY automatically fills a default Ip address since we don't want to bind it to particular one.

5200 is the port number that we will be using. You can use your own (make sure it is not reserved) (use the same in client).

if(bind(sockID1, (struct sockaddr *) &addrPort1, sizeof(addrPort1))==-1) {
    printf("\nBind Failed to Port 5200\n\n");
}
else printf("\nBind Success to Port 5200\n\n");

Binded the socket, returns -1 if fails.

if(listen(sockID1, 10)) {
    printf("Listen Failed\n\n");
}
else printf("Listening...\n\n");

Now we are ready to accept an incoming request (connect() from client).

struct sockaddr_in client_addr;
socklen_t len = sizeof(client_addr);

int sockID2 = accept(sockID1, (struct sockaddr *) &client_addr, &len);
printf("Accepted a connection\n");

This is interesting. The only thing accept() needs from our server is sockID1. client_addr will contain info about the client it accepts and will be filled on function call.

This returns a new socket (sockID2) for us which will be used for sending and recieving from the client.

The last step.

char msg[50];
int countR, countS;

while(strcmp(msg,"Close\n")) {
    printf("To Client : ");
    fgets(msg, 50, stdin);
    countS = send(sockID2, msg, 50, 0);
    if(!strcmp(msg,"Close\n")) {
        break;
    }
    printf("From Client : ");
    countR = recv(sockID2, msg, 50, 0);
    printf("%s", msg);
}

Try to understand this yourself. countR and countS are there for error handling (send and recv give -1 on error). Sending or recieving the word "Close" is the exit condition.

What are we trying to do? First message to be sent by server. Client then recieves it and sends something. Server then recieves it and sends ...........

Finally

    close(sockID1);
    close(sockID2);

    printf("\nSocket connection Closed\n");

    return 0;
}

Without scratching heads, lets move to client.c

Client.c

After the headers

int main() {
    int sockID1 = socket(PF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addrPort1;
    addrPort1.sin_family = AF_INET; //sets to IPv4
    addrPort1.sin_addr.s_addr = htonl(INADDR_ANY);
    addrPort1.sin_port = htons(5200);
    //htonl - host to network long, htons - host to network short

This is same, because connection also requires the specifics of where and via-what to connect.

if(connect(sockID1, (struct sockaddr *) &addrPort1, sizeof(addrPort1))) {
    printf("\nConnect Failed\n\n");
}
else printf("\nConnected via Port 5200\n\n");

Nearly identical to bind(). Right. But remember, it complements the accept() function in the server side.

char msg[50];
int countR, countS;

while(strcmp(msg,"Close\n")) {
    printf("From Server : ");
    countR = recv(sockID1, msg, 50, 0);
    printf("%s", msg);
    if(!strcmp(msg,"Close\n")) {
        break;
    }
    printf("To Server : ");
    fgets(msg, 50, stdin);
    countS = send(sockID1, msg, 50, 0);
}

I hope its easier to see the logic now.

    close(sockID1);
    printf("\nSocket connection Closed\n");

    return 0;
}

Done.

Move to the directory. Split your terminal. In one, run the server, then on other run the client. Happy connection !

I have tried to keep it as short as possible and only explain the things relevant to a first program.
Questions & Suggestions are welcome.