You are browsing as a guest. Sign up (or log in) to start making projects!

LeadGen

  • 4 Devlogs
  • 8 Total hours
Open comments for this post

1h 8m 8s logged

DEVLOG #4

I reformed the Signup API flow and also made the Login endpoint.

The new signup API flow goes something like this:

PAGE-1:

  1. Enter full name
  2. Enter email
  3. set password
  4. Submit button
    when submit button is clicked, we query /users/check-email to check if the account already exists. If account exists, the API simply returns a status_code=400, detail="email taken" else it returns {"available": True}.

PAGE-2:

  1. Set Username
    When submit button is clicked, we query /users/check-username to check if the username is available or not. If username is already taken, the API simply returns a status_code=400, detail="username taken" else it returns {"available": True}

PAGE-3:

  1. Choose if signing up as a business or as an individual.

PAGE-4:

  1. Set team name if applicable.

Finally, we have all the required data and data validation to make a new user so we can POST to /users to make a new user. Now, I had to think about this a bit because what if a there is a scenario that while a user is still making their account, they enter a username and go to the on-boarding step with the team name entering and all that stuff. And meanwhile, another user also enters the same username and creates the account by finishing the on-boarding before the first user who has the same username but did not create the account yet? when the user who is currently on on-boarding finishes all the steps, the server errors if there is no second data validation with all the collected data. Hence, I added validation of username and email in the second step too so that this case is handled correctly.

I also made the simple login endpoint which takes the email and password and validates the user and their hashed password. I am planning to keep the login a single page and hence there are no live validations I need to make. Thus, everything lives in a single /login endpoint.


Next Steps

I am also wondering that in the API response, I do not signify anywhere that if the user is currently logged in or not and I do not know how to keep the user logged in until either they sign out or something else so I need to learn that state management too. I will work on that next.

0
0
11
Open comments for this post

1h 25m 51s logged

DEVLOG #3

Today I worked on just the signup endpoint and the password hashing. I basically made an endpoint which would take all the collected data: full_name, username, email, hashed_password, role, team_name and use it to create team and user on the database. I have successfully implemented the basic idea that I had but it currently has no error handling like duplicate user checking or existing username.

So, what I thought was to keep a single endpoint and do the data validation at the end when the api call is made by querying the database first to check for unique email and username. But, That was not good user flow according to me, and I was looking for something like this:

PAGE-1:

  1. Enter full name
  2. Enter email
  3. set password
  4. Submit button
    Then we will internally check if the email exists or not. If it exists show “account already exists, login instead”. If the email does not exist then move into the next page.

PAGE-2:

  1. Set Username
    Check if username exists. If username already exists, show the error “username already taken” else move onto the next page.

PAGE-3:

  1. Choose if signing up as a business or as an individual.

PAGE-4:

  1. Set team name if applicable.

All the data required for the database entry for user creation is complete so after a few more random onboarding steps, commit all the collected data to the database to make the team and the user.


Basically this is the whole signup flow that I want with the most basic data collected from the user initially. Now what I want it some way to check the validity live on every page and I do not know how to do that. I will need to display the error messages and all through JS though I don’t know if I can also query the database live through JS to do some live validation. I will not learn this FastAPI concept and try to implement it in my API

0
0
17
Open comments for this post

2h 0m 15s logged

DEVLOG #2

Created all the database models along with database.py with the boilerplate code for making database and tables.

Database models that I made:

  1. Team -> id, team_name, created_at
  2. User -> id, full_name, username, email, hashed_password, role, team_id, solo_team_id, created_at
  3. Lead -> id, team_id, name, phone_number, website, rating, created_at

I also made some changes to scraper.py by adding more filtering such that:

  • If business does not have any phone number but has a website, lead is added.
  • If business has a phone number but no website, lead still added.
  • if business does not have any phone number or website, it is basically useless and excluded.

I have not faced any major challenges yet as it has mostly been boilerplate code straight from the docs or simple repetitive code. To be honest, this has been boring. But, now I will be starting with the FastAPI stuff and actually start making the API and I am very excited for that.

0
0
50
Open comments for this post

3h 55m 9s logged

DEVLOG #1

The scraper is something that I had completed a few months back. I made it for my friend’s business. Now, I am trying to expand the scope of this from just a scraper to a full Business platform where a whole team can collaborate on cold-calling with daily quotas and a manager who can view stats about his employees. I also want to make a live chat option to better increase coordination between the team. It is a pretty basic project but a pretty ambitious for me.

Right now, I have completed all the error handling and re-enforcing the scraper logic in the 4 hours that I have spent, to make it ready for a web-UI.

I will now start working on making the actual API and database for my project.

There are 3 basic tables that I have identified:

  1. Teams
  2. Users
  3. Leads

I believe that all other features can build on top of these 3 as these are the basic building blocks. Hence, I will start working on making these right now.

This is my first time working with FastAPI (earlier I had only used Flask) so there will be a learning gap but I have experience with Flask so I think that transitioning would be easier.

0
0
16

Delete project?

Are you sure you want to permanently delete this project? This action cannot be undone.

All devlogs, followers, and associated data will be removed.

Followers

Loading…