标签：#webdev

Hey guys, would love to get some feedback on whether my approach here makes sense. I’m building a real-time chat application where users can upload and receive images/files. Files can be fairly large (up to ~100MB). Current stack is: fastapi, websockets, tanstack, postgres and redis. I use GCP as my cloud provider. My current flow is: Backend generates a signed URL Frontend uploads directly to a GCS bucket A Cloud Function handles post-upload processing For downloads, the frontend fetches directly from GCS using redirects/signed URLs so the backend doesn’t become a bottleneck This architecture works great for smaller files (<30MB), but once I started testing larger uploads (100MB images/videos), I noticed very high memory consumption during processing (btw pagination & virtualization is used throughout the project). I’m trying to figure out what’s considered best practice here for large media uploads in chat systems: Should compression/downscaling happen client-side or server-side (currently there is not compression at all)? Also, Is it common to generate thumbnails/previews (for images) separately while keeping the original untouched? Should I stream uploads instead of buffering them? Are Cloud Functions even the right choice for heavy file processing? For images specifically, I’m considering: client-side compression before upload, automatic thumbnail generation, storing multiple resolutions, converting to formats like WebP/AVIF. Would love to hear how you guys handle this in production systems. Thanks! submitted by /u/omry8880 [link] [留言]

Looking for assistance. Copy/Pasting my post from another sub. Hey all, young web dev/designer here. If helpful, I run SiteGround hosting, WordPress, Divi 5 builder. I'm having a really confusing issue that I can't resolve in a satisfying way. For some reason, a hidden menu for an Italian water company (revital.it) is getting placed onto my website. It's honestly baffling. The site I'm currently troubleshooting is holbrook-electrician.com. I've seen this happen now on two websites that I've built. I've used Divi Cloud sections that I built on one and used on the other, so unsure if that's how it's getting placed onto the site. There will be rare instances where if I view my live site, the menu will be overlayed overtop the page (pictured). Both page source and inspect show the revital.it links. From what I've gathered with the help of AI, the menu is tied to a Divi canvas called "menu slide". The thought is that it came in with a template import, but I don't remember using a template when I first started (1-2 months ago). I think I started from scratch. I obviously want to remove all links and prevent them from reappearing. I can't find them anywhere in the page builder. I can't trace it to any plugin I'm using or code I've added. The only success I've had to remove it is going to phpMyAdmin, and running a query to eliminate instances of "revital.it". I did this once for this site, but it looks to have come back for unknown reasons. Just to confirm, I have nothing to do with this Italian website. I did not put this menu or the links on my site. I really have no clue how it originally got here, how to prevent it from appearing on other sites I look to build, and how to permanently remove it. Any help or suggestions would be greatly appreciated! Rouge menu overlayed on my home page submitted by /u/exodeath29 [link] [留言]

And before you ask, yes, it's free. always will be. I built it in 48 hours. planning to release it tonight or tomorrow. submitted by /u/West_Subject_8780 [link] [留言]

I saw someone mentioned a guest book and I had to look it up. Apparently people would leave public messages on a dedicated page and you can reply to them. Guess spam ruined that. Any thing else, didn't really get to experience it being young and all. Maybe some could make a comeback and one of us could implement it. submitted by /u/Successful-Title5403 [link] [留言]

I’m building a web app called EccoMuse, it’s a music discovery platform that lets listeners blend their music tastes with the tastes of artists, with features to monetize these unique playlist blends. Right now, I'm tackling the classic marketplace problem: distinguishing regular users/listeners from the actual artists. I need to make sure that if someone claims to be JPEGMAFIA or a small indie artist, they are actually that person (or their manager), and not an impersonator trying to hijack the profile. I want to avoid scraping Spotify bios (against ToS/fragile) and I can't rely on OAuth for X/Twitter because their new API pricing is too expensive for a bootstrapped summer project. Here is the manual verification system I currently have planned: Standard Login: User logs in as a listener (SSO/Email). Claim Profile: They paste their Spotify/Apple Music URL and their primary social handle (IG/X), then declare if they are the Artist, a Faceless Artist, or a Manager. The Challenge: The app generates a unique 6-digit code. The Proof: Public Artists take a webcam selfie holding the code, AND DM the code to our official Instagram from their verified/established artist account. Managers / Faceless Artists skip the selfie but must DM the code from the official artist account OR email us from the public booking email listed on their Spotify/socials. Manual Review: I look at the DM/Email, verify the account authority, cross-reference the selfie (if applicable), and manually approve the claim. Why it doesn’t feel fully fortified: While this works and costs $0 in API fees, it feels like it has some friction and potential holes. What if the manager doesn't have access to the artist's Instagram to send a DM? Is a webcam selfie too much friction for onboarding? How can I make sure an impersonator doesn't get through, I dont want someone to pretend to be an artist. I initially thought about asking them to put the code in their public IG or SoundCloud bio, but artists hate defacing

I'm 22, working as a fullstack developer at a startup. 9 hour days, decent enough at my job, but completely switched off after work hours. I don't want to leetcode after work. I don't want to learn new frameworks at night. I want to write, play guitar, and just exist peacefully. I'm not trying to become a senior dev or a tech lead. I just need the salary to sustain while I build something on the side that actually excites me. My question is — how long can someone realistically coast on existing skills without getting fired or becoming unemployable? And what's the bare minimum to stay relevant without burning out? Not looking for "passion for tech" lectures. Just honest experiences from people who've been there. submitted by /u/Available_Guess_7344 [link] [留言]

There is a fascinating psychological phenomenon in modern software engineering: the relentless pursuit of the upgrade. As frontend developers, we are conditioned to believe that speed and efficiency come from adopting the newest technologies. We migrate from Webpack to Vite to shave seconds off our build times. We transition between UI libraries in search of better reconciliation algorithms. We constantly audit our CI/CD pipelines. We treat performance as a destination we must reach by continuously adding or swapping out the moving parts of our toolchain. Yet, amidst this endless cycle of optimization, we consistently overlook the most sophisticated, highly optimized piece of software in our entire stack. It is the software you are using to read this article right now: the web browser. The Underappreciated Engine The modern browser is an absolute marvel of engineering. Over the past decade, teams of the world's most talented systems engineers have engaged in a fierce arms race to optimize browser engines like V8, SpiderMonkey, and JavaScriptCore. Today’s browsers feature Just-In-Time (JIT) compilation, sophisticated garbage collection, and massively parallelized rendering pipelines. They are capable of executing highly complex, interactive applications with a level of fluidity that was unimaginable a few years ago. However, when we evaluate developer tools—specifically the online IDE or the browser-based code editor—there is a stark contrast. The environments we use to write and test our code rarely reflect the speed of the engine they run inside. Why the Standard Web IDE Misses the Mark If you want to quickly prototype a component or isolate a bug, you will likely reach for a frontend playground or a popular Replit alternative. What happens next is often a masterclass in friction. The environment feels heavy. The interface is cluttered with features you didn't ask for. As you type, the live code editor experiences micro-stutters. The instant live preview isn't actu

The plan was simple Take the specs we'd written, turn them into Jira epics, stories and subtasks, and start sprinting. It took longer than expected. Here's what actually happened — and what I learned. Why automate Jira setup at all? HandyFEM has 8 epics, 37 stories and ~160 subtasks. Creating that manually would take a full day and be error-prone. More importantly: the specs were already written in a structured format. Translating structured data into Jira issues is exactly the kind of repetitive task that should be automated. So I wrote a Node.js script to do it via the Jira REST API. Problem 1 — Jira Spaces ≠ Jira Classic My account uses Jira Spaces — Atlassian's newer interface. The classic Jira has CSV import built in. Jira Spaces doesn't. This isn't documented anywhere obviously. You discover it by looking for the import option and not finding it. Lesson: always check which version of Jira you have before planning your workflow. The API still works, but some endpoints behave differently. Problem 2 — The API token wasn't the issue (until it was) First attempt: connection error. I assumed it was the token. It wasn't — it was an expired token from a previous session. Regenerating it fixed the connection. The real lesson: curl -u email:token https://your-domain.atlassian.net/rest/api/3/myself is the fastest way to verify auth before running any script. Problem 3 — customfield_10014 doesn't exist in team-managed projects In classic Jira, linking a story to an epic uses a field called customfield_10014 (Epic Link). In team-managed projects (Jira Spaces), this field doesn't exist. You use parent instead. The error was clear once I saw it: "customfield_10014" : "Field cannot be set. It is not on the appropriate screen, or unknown." Fix: remove customfield_10014 , keep only parent: { id: epicId } . Problem 4 — Board search doesn't work for team-managed projects The Agile API endpoint /rest/agile/1.0/board?projectKeyOrId=HFM returns empty for team-managed projects, even

If you've ever worked with auth, you've seen a JWT — a long string like eyJhbGci... split into three parts by dots. It looks cryptic, but it's surprisingly simple once you see inside. A JWT has three parts header.payload.signature Header – tells you the signing algorithm, e.g. {"alg":"HS256","typ":"JWT"} Payload – the claims (the actual data), e.g. {"sub":"123","name":"John","iat":1516239022} Signature – verifies the token wasn't tampered with (needs the secret/key) The header and payload are just Base64url-encoded JSON — not encrypted. That means anyone can read them. So: ⚠️ Never put secrets in a JWT payload. It's signed, not hidden. Decoding one yourself You can decode the payload in the browser console: const [, payload ] = token . split ( " . " ); console . log ( JSON . parse ( atob ( payload ))); Or, if you just want to paste a token and instantly see the header + payload (without sending it to a server), I built a free decoder that runs entirely in your browser: https://forgly.dev/tools/jwt-decoder Decoding ≠ verifying Reading a JWT is trivial. Trusting it is not — you must verify the signature on your server with the secret/public key before relying on any claim. Decoding just lets you inspect what's there. That's the whole mental model: a JWT is a readable, signed envelope — not a locked box.

https://youtu.be/kL1PDqzqhM4 This video has corrected information on the history of Lorem Ipsum! submitted by /u/GreatRedditorThracc [link] [留言]

I added a few more asteroids to my build asteroids project and suddenly my FPS just tanked. Like completely unusable. Now I’m looking at my code and realizing my build asteroids loop is basically just redrawing everything every frame with no real optimization. I assumed request animation frame would kinda handle it automatically but yeah… that was me being naive. Is there a normal pattern people use when building asteroids so it doesn’t just fall apart as soon as you add more objects? submitted by /u/Tricky-Highway-7099 [link] [留言]

Maybe it’s just me, but I’ve been running into more and more half-working products lately. Buttons that do nothing. Checkouts that fail silently. Forms that throw errors with no explanation. And not from random small sites either, from companies that should absolutely know better. I think it’s the result of AI + fast shipping + less quality control. Teams are pushing out features at a speed that wasn’t possible 2 years ago, but the QA, testing, and ownership of quality hasn’t scaled with it. AI didn’t break the web. It just made it easier to ship things that were never properly checked. The other thing I’ve noticed: when something breaks now, you can’t even get to a real person. Support bots loop you in circles, and the actual humans who could fix it are buried somewhere behind 5 layers of auto-responses. Curious if others are seeing the same thing, or if I’m just unlucky lately. submitted by /u/Good-Locksmith-4978 [link] [留言]

You build a tournament bracket with a popular React library. In Chrome it's perfect — neat columns, clean connector lines. Then you open it on an iPhone, or in Safari, or inside your Capacitor app… and every match is crammed into the top-left corner, stacked on top of the round headers. If you've ever shipped a bracket to iOS, you've probably seen this exact bug. Here's why it happens — and a tiny library that fixes it for good. The symptom It looks fine everywhere Chromium runs (Chrome, Edge, Android WebView) and completely broken everywhere WebKit runs: Safari (macOS and iOS) iOS WKWebView Capacitor / Cordova apps Electron-on-WebKit The matches don't just shift a little — they all render at coordinate (0,0) of the bracket, piling on top of each other and the headers. The cause: SVG <foreignObject> in WebKit Most React bracket libraries — @g-loot/react-tournament-brackets , react-tournament-bracket , and friends — render the bracket as an SVG and place each match's HTML inside a <foreignObject> positioned with x / y attributes. WebKit has a long-standing bug: it ignores x , y , and transform on <foreignObject> and positions the content relative to the top-level <svg> instead of the foreignObject's own coordinates. Every match therefore collapses to the origin. And there's no CSS escape hatch — x , y , and transform are all ignored on foreignObject in Safari, so you can't nudge the content back into place. I even tried patching a library to wrap each match in a <g transform="translate(x,y)"> instead of a nested <svg x y> ; WebKit ignores ancestor transforms for foreignObject positioning too. The SVG approach is simply a dead end on WebKit. The fix: don't use SVG at all A bracket is really just columns of cards joined by connector lines — and both are expressible in plain CSS. Here's the key insight. Put each round in a flex column where every match sits in an equal flex: 1 slot. Because each round has half the matches of the previous one, a match's slot spans exactl

By Suryansh Sinha (sinxcos07) Introduction Recently, I built AstroFit , a fitness-focused web application as a personal project to learn more about modern web development, deployment, databases, and building complete applications from idea to production. This project helped me understand how different parts of a web application work together, from the user interface to backend functionality and deployment. Why I Built AstroFit I wanted to work on a project that felt practical and useful while also helping me improve my development skills. Instead of creating a simple clone project, I decided to build a fitness application where I could experiment with real-world features and deployment workflows. Development Journey Building AstroFit involved much more than just creating pages and connecting them together. Some of the areas I explored while working on this project included: Frontend development Backend integration Database management Authentication systems Deployment and hosting Debugging production issues One of the biggest learning experiences was understanding how different technologies communicate with each other in a complete application. Future Plans I plan to continue improving AstroFit by adding more features, refining the user experience, and expanding its capabilities over time. This project is still evolving, and I'm excited to keep working on it. Project Links Live Demo: astrofit-fitness.vercel.app GitHub: sinxcos07 / astrofit-frontend Fitness platform combining workout tracking and astrology-inspired personalization. AstroFit AstroFit is a modern fitness web application that combines workout tracking with astrology-inspired personalization to create a unique and engaging fitness experience. Features Modern responsive UI Astrology-inspired fitness experience Workout tracking interface User authentication system Backend integration Smooth and interactive design Mobile-friendly layout Tech Stack Frontend HTML5 CSS3 JavaScript Backend Node.js Express.js SQL

I’ve been working on Hooklistener for a long time now, several months, probably closer to years. It’s a free tool for receiving and inspecting webhook requests. The CLI is open source and lets you forward captured requests to localhost whenever you want, as many times as you need. It can also create ngrok-like tunnels, but the feature I personally find most useful is listen : it forwards incoming webhook requests from Hooklistener directly to your local service. I recorded a short video showing how it works. CLI repo: http://github.com/hooklistener/hooklistener-cli/ The rest of the app is built with Elixir and Phoenix. If you would like to try it: https://hooklistener.com , thanks! submitted by /u/absoluterror [link] [留言]

submitted by /u/Wise_Stick9613 [link] [留言]

Most apps don't just call one API endpoint. They call a whole chain of them. For example, you might log in, get a token, and then pass that token to another service. Tracking these multi-step chains can get messy quickly. To help fix this, the OpenAPI Initiative created the Arazzo Specification . It gives us a standard way to link different endpoints into clear workflows. But writing these workflow files by hand in a regular text editor is tough. It is very easy to lose track of how data moves from one step to the next. That is why I built Arazzo Visualizer for VS Code. It is a free, open-source extension that makes the Arazzo spec visual and easy to use. Live Interactive Graphs The extension reads your workflow files and turns them into interactive maps on the fly. See Data Flow: Look at exactly how data moves between steps. Catch Errors Early: Spot broken paths before you even run your code. Clean Layouts: Navigate large workflows without getting lost in thousands of lines of text. Built-In Workflow Runner Seeing the map is great, but testing it is even better. The tool has a step-by-step runner built right into your editor. Run a single step or execute the whole chain. See real-time data payloads and HTTP headers. Watch requests happen live to pinpoint bugs fast. Give it a Try The project is fully open source, and you can grab it or check out the code using the links below: Download: Install it directly from the VS Code Marketplace . Source Code: Check out the repository, report bugs, or contribute on GitHub . Deep Dive: Read my full technical breakdown and design on Medium . If you are working with API chains, I would love for you to try it out. Drop your feedback in the comments below! Note: Arazzo v1.1.0 is out with official AsyncAPI support. I am currently updating the VS Code extension to support these new features. Stay tuned for future updates!

By Takeshi Yokoyama — Onecarat Labs Hi. I'm Yokoyama, and I build a local-first AI text editor as a side project, along with a few other experimental tools. Working on them, I keep running into the same question about where the web is going. This post is one observation, plus a small experiment I built to test it — including a Chrome extension you can actually try. The short version: I think websites will increasingly be read through AI agents, reshaped per reader, on the fly. And once that happens, there's a clear gap between sites that are easy for an AI to read and sites that aren't. What's starting to happen Until now, people read websites as websites. You open the top page, follow the menu, read the body, click a button — tracing the path the maker designed. As local AI and AI agents become normal, that breaks. People stop opening the page directly. They tell an AI what they want — "Can I try this quickly?" , "I just want to check it's safe" , "Just the gist" — and the AI reads the web and reshapes it into the form that reader wants. What the reader receives is no longer the layout the maker built. This isn't speculation. The idea that AI generates the interface for the reader already has a name — Generative UI — and it's one of the hottest areas in frontend right now, with Google, Vercel and others building toward it. But notice who's holding the pen in almost every version of that story: the site , or an AI embedded in an app — something under the maker's control. What I'm looking at is one step past that: a local AI, in the reader's own hands, reshaping any site into that person's preferred form — with no involvement from the maker at all. The initiative moves from the maker to the reader. The part that nags at me as a builder I build software too. So this shift nags at me. A site carries its maker's intent and rights. The order things appear in, what gets emphasized, the tone. Design, copy, flow — all of it is deliberate. Having an AI quietly reorder, rewri

A walkthrough of the architecture decisions behind Flacron Gamezone a production full-stack app built with Next.js, Express, PostgreSQL, and Redis. When a client approached me to build a live football match discovery platform, the requirements sounded straightforward on the surface: show live scores, let users subscribe, handle authentication. But the moment you start thinking about how those pieces connect in production, straightforward gets complicated fast. This is the story of how I designed the backend for Flacron Gamezone — what decisions I made, why I made them, and what broke along the way. Table of Contents The Problem With "Just Building It" The Architecture: Four Distinct Layers Why This Matters to a Client The Bug That Taught Me Something Real The Full Stack at a Glance What I'd Do Differently The Problem With "Just Building It" The easiest version of this app is a single Express file: one route handler that queries the database, formats the data, and sends a response. I've seen this pattern in tutorials everywhere. It works for demos. It falls apart in production. The problems are predictable: you can't test business logic without hitting the database, a change in one feature quietly breaks another, and the moment a second developer joins the codebase, nobody knows where anything lives. I wanted to build something I could actually be proud to show an employer or a client. That meant committing to a proper layered architecture from day one, even on a project this size. The Architecture: Four Distinct Layers The entire Express backend is organized into four layers. Each layer has one job and talks only to the layer directly below it. Route → Controller → Service → Repository Here's what each one actually does. Routes are just maps. They declare that POST /api/v1/subscriptions exists, attach the auth middleware, and hand off to the controller. No logic lives here. Controllers handle the HTTP boundary. They extract data from req.body or req.params , call th

I've recently been getting reacquainted with frontend dev after having spent the last few years focusing mostly on design. I plan to do a combination of both again from now on. The last full-time job I was at we used drag-and-drop website builders that seem to be all the rage these days. I gotta say it was a truly painful experience. The websites we would handover would be a complete mess, clients would have to edit columns, widgets, layouts themselves which just felt like a recipe for disaster. We would often have to duplicate various widgets such as image sliders, one of mobile and one for desktop. I'd then have to explain to clients that they needed to update them twice, with the same content. Also, a lot of times I'd have to set up HTML widgets because of how limited the software was, so I'd also have to explain to clients that they'd sometimes need to edit actual code when simply updating content on their site. But the concerning thing is, I've had a number of other job interviews at marketing agencies lately and it seems like EVERYONE is doing the same thing. I also sometimes hear on podcasts people describing default WordPress as being 'old fashioned', as though the future of web dev is just doing everything with these hideous website builders WTF 🤮 Are these people mainly just taking the basic / shitty web dev projects while leaving the proper ones to those who know how to do it properly? or have a lot of developers lost out on work because of these? submitted by /u/Weekly_Frosting_5868 [link] [留言]