We added a feedback API to our application
HTML-код
- Опубликовано: 2 июн 2024
- My Products
📖 ProjectPlannerAI: projectplannerai.com
🤖 IconGeneratorAI: icongeneratorai.com
📝 ThumbnailCritique: thumbnailcritique.com
Useful Links
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
![Darren Waller - Who Knew (Her Perspective) [Official Video]](http://i.ytimg.com/vi/GytDjB8u6bM/mqdefault.jpg)
I love how you're constantly building side projects
Now I just need to focus on really finishing one out until real profitability
I would say the same, @WebDevCody 👍. Quick question, how much time per week do you employ on these side projects?
@@ElvisMorales maybe 30 min a night give or take
@@WebDevCodygreat job! I wanted to ask how you come up with ideas though, I’m not exactly sure what to build :( AI is the new craze but dunno what to build with it. Endless possibilities messing with my decision making, lol.
@@ElvisMorales Build something that you want to use yourself. This way, you know that there is a market, you're more motivated, and you constantly test your own app.
I really love the UI on this project. Would you ever consider making a video on how you design the UI for these projects?
i vouch for this
+1
You are the GOAT of you tube developers who are actually developers. Also, I have no idea how you get all the things you do done.. You must to have a secret clone we don't know about.
😂 just 30 minute a night is enough time to add one new feature or fix one bug. Hosna is also adding a lot of features
Looks good, two pieces of feedback I have are:
1: Definitely use an API key, you want to tie requests to users and not have to rely on rate limiting or hosting providers to handle banning abusive behaviour
2: You should consider versioning your API so you can introduce breaking changes if need be, also consider having an API docs page dedicated to it so people can test in their browser and regenerate APIs, revoke them etc. if I’m getting attacked I don’t want to have to remember where to go to quickly ban someone
Hey I have a question/suggestion: Wouldnt it be better to create something like an API Key to pass instead of the projectId? When someone finds out the project id and spams nonsense feedback you dont have a way to revoke access to the endpoint. Couldnt a key of some sort that is revokeable protect you as a provider from spams and the user of your service from getting spammed if it leaks?
I'll try to think about this more, but here is my logic.
If I required an api key, then it's the responsibility for the developer to make their own protected endpoint and add rate limiting and then also monitor and rotate their keys often to keep it secure. That's a lot of extra work to put on the developer just to collect feedback. This is the same idea as an analytics application such as google analytics, posthog, or sentry, they give you a public key which you add to your UI and their code uses that to send events to their service. That key isn't private, anyone can open the console log and spam analytic events to that endpoint if they want. As of right now, I have a rate limit on how much feedback a project can accept, and I also might had a toggle for disabling feedback if needed.
@WebDevCody "Thats alot of work" Welome to being a real developer and to do things right and secure. Otherwise Whats the point. Specially after what you just went through. I would think secure is fresh on your mind.
@@Chris...S lol, shit take. Why do you think lots of people use managed systems like Convex, Firebase, Vercel and so on? I guess in your opinion everyone should build everything themselves on top of AWS or nvm, use a VPS and set up everything yourself, right?
The idea is simplicity here. You slap something on your project and it works. Wouldn’t wanna bother with a Feedback app that took me a whole week to set up just because that’s what “real engineers” do…
@Chris...S "real developer"s rely on tooling and libraries for the majority of things in practice when possible. Creating abstractions for things is a good portion of software, and engineering in general.
It just removes a lot of unnecessary busy work, among other things.
man you are just cool as fuck. after my working hours i generally have no energy whatsoever for my side hustles (though i do 10-11 hours of job-related coding everyday ahha), so you are genuinely such an inspiration for me. keep up the good work man!
For the feedback API one thing you can do to improve it is make sure that the user can add metadata. Make a metadata field and the user can add whatever they want in that field. Sometimes you might want certain details about the user you know?
That’s a really good idea!
Looks like a useful project :)
Doing great work babe!!!❤
You may generate OpenAPI spec for the endpoint with examples and use Scalar for this.
very interested in learning how are you doing rate limiting with convex
What library are you using to do rate limiting?
Is there a way I can check out the code for this project? Would love to learn how you have ordered and coded some stuff.
Hey Cody, when you said about token, i thought you could maybe use something like this for more security : limiting the feedback from a particular user to certain amount (maybe 5 - 10 feedbacks per day using maybe rate limiting or db count), this could potentially reduce spamming too many feedbacks by a single user. Token for a specific api would work when charging for a certain amount of requests to the client. Do let me know if i got the token usage wrong.
Tutorial on doing rate limiting to a nextjs endpoint/api without upstash/redis would be great
would love to see you building and shipping components
and one more think what is best practices for api route protections ? does rate limiting prevents bot attacks ?
rate limiting won't prevent someone from using a variety of IP addresses. It'll only help prevent a single user from trying to abuse your system. I do have the endpoint behind cloudflare which would help prevent abuse.
Also why adding API key would be needed IMO. Any API that is more then a GET call should be key protected. Also because its just another point of defense even for GET only API.
I think it's better to use something like jwt's tokens to hide the plan id, this way if someone uses the api in a vite app where there is no backend and he then decides to add a backend because someone abused the api( if 10s rate limiting isn't enough), he can go to the api part and generate a new api endpoint that will override the old token, ofc this requires a table to store the tokens but I think it's fine
Hey @Web Dev Cody
Are you implementing this project full-time or after work?
He has a real software job
after work I add features when I can, I work full time at my real job
Also it's a Colab project. Not Just Cody.
Can you give me the link of this project tutorial ?
this isn't a tutorial
how much active users use your app ?
Not much
we want more projects which are not clones
Hey, I would like to contribute towards this project.
sorry, we are not taking contributors
@@WebDevCody Ok