标签：#web

On the side after work I've been experimenting a bit with aws cloud launching my own apps and website (its mostly for hobby/for fun not really expecting income but maybe one day) anyways, one of my website a couple months ago was hit by a bot attack which made my netlify monthly bill go from $20 to $140 in one day Which spooked me im not going to lie. And my knowledge of devops thing is so limited that I had to resort to asking ai to help debug this. We found that there was 8 million botted requests sent to my frontend website and on my .netify.app link netlify does not give you ddos protection unless you pay extra. My actual domain was protected by cloudfare rate limit I didnt even know I had this secondary domain for that website. Anyways that was useful discovery now I feel safer about netlify at least. I don't really want to give up this hobby. Is there anyway to get predictable billing I don't even mind if they shutdown my app if it exceeds usage. I read that fly.io is based on credit usage. Is that good for backend? submitted by /u/Ok_Indication_3656 [link] [留言]

A post titled "Learn SQL Once, Use It for 30 Years" hit the front page of r/programming this week (307 points, 48 comments). The claim sounds like the kind of thing a database vendor would put on a billboard, so I went looking for the part that holds up. It turns out the longevity is not marketing. It is a property of how the language was designed, and it is the reason SQL is one of the few skills on a developer's resume that does not quietly expire. I run a site that compares developer tools, which means I spend a lot of time watching technologies rise, peak, and get replaced. Most of what you learn in this field has a half-life measured in single-digit years. The framework you mastered in 2019 is legacy by 2024. SQL is the strange exception, and the reasons are worth understanding before you decide where to spend your next month of learning. Where the staying power comes from SQL did not start as a language. It started as a math paper. In 1970, Edgar Codd published "A Relational Model of Data for Large Shared Data Banks," which proposed organizing data into tables of rows and columns with formal rules for combining them. IBM built a query language on top of that model in the mid-1970s, called it SEQUEL, and later renamed it SQL after a trademark conflict. The important detail is the order: the model came first, the language second. SQL is a surface over a mathematical foundation that has not needed to change. That foundation is why the skill compounds instead of decaying. When you learn SQL, you are not memorizing one vendor's API. You are learning the relational model, and the model is the same whether the data sits in Postgres, MySQL, SQLite, Oracle, or SQL Server. A join is a join everywhere. Move from one database to another and the syntax shifts at the edges, but the way you think about the problem carries over intact. Compare that to a frontend framework, where moving stacks means relearning how to think, not just how to type. Declarative is the whole trick

Hi everyone, I've been working on building my own website for my upcoming small business in the pest control. My set up is cloudflare for domain, Hostinger for hosting, and WordPress for CMS. I have a fair amount of coding and tech knowledge (Code simple things in a different languages and understand enough abouting coding to understand most non robust code; have also built a couple simple websites in wordpress) and really want to do things right. My question is what tools, choices, or practices are there that someone trying to research the space wouldn't be able to easily find that provide high value? Things deeper in scope than just building pages with custom blocks, using plug ins, and tweaking settings. Essentially, of the millions of tools and implementations existing in this space, where should a person looking to move from amateur to advanced but not career web dev look? And what is the value in those tools or choices? Additionally. outside of page speed insights, what audits are actually worth running to ensure everything is secure and running as smooth as possible without costing an arm and leg cumulatively? If you were a single person looking to build as professional of a website as possible, in a reasonable timeline (a month or two), what things would you really be focused on? My overall goal is to build everything as close to professional as a single person realistically could, so if you guys could help, I'd really appreciate it! Thanks in advance submitted by /u/ChestnetR [link] [留言]

Hello everyone, PHP comes up here from time to time, and I've noticed the discussion is usually based on what the language looked like 5+ years ago. Since I work with it every day and have genuinely come to enjoy it, I wrote a short article recapping where it actually stands today. It covers modern deployment (FrankenPHP, Docker), software architecture (modular monoliths, the Symfony kernel, agents), the type system and its tooling (PHPStan, PHP CS Fixer), and the state of concurrency (ReactPHP, Swoole, the True Async RFC). Full article: https://morice.live/posts/your-next-project-will-run-on-php/ Let me know if I missed anything, or if you'd like me to go deeper on a specific topic! submitted by /u/andre_ange_marcel [link] [留言]

https://youtu.be/gd3QLL63bT0 submitted by /u/Prize_Concept_41 [link] [留言]

A bit of context: I'm having fun building my app. I'm trying to built something truly great for monitoring. I run a pool of workers on a couple of VPSes and probes about 10k endpoints on a tight loop down to every 15 seconds. The part that was quietly bleeding money, was that every probe result got written to our document db and all dashboards subscribed to those documents with real-time listeners (onSnapshot). In Firestore that's the obvious way to build a live dashboard and it actually works great until you draw out the actual data flow: workers write on every cycle every write fans out to a read to every browser that is running the dashboard so cost just scales with amount of cycles and open dashboards The database quietly became a message bus with billing on every message. I guess this is how you learn about proper architecture the hard way. 😄 A good Friday evening, with a glass of whisky, I decided to make something cool. I wanted a true live experience for the users, directly on the website. Basically something that looked directly into the VPS. So I flipped it. The WebSocket is the source of truth for live fields The DB gets demoted to config + state transition "Still up" heartbeats get batched, instead of writing "200 OK" everything cycle, we switch to a transition model and flush the no-change on a interval Results: ~95% fewer DB writes Live status reads went to zero Time from probe to pixel went from 1-3 seconds to <300ms (p90) It feels a bit like cheating. Making the product insanely more cool and useful, while also cutting costs, and not only cutting immediate costs. This thing scales like crazy. Basically the only real thing needed is a good amount of memory. Memory is not cheap nowadays, but it's definitely cheaper than continuous real-time DB reads and writes. Some tradeoffs worth mentioning. I kept the DB listeners as fallback if socket drops. The UI degrades instead of breaking. Websockets are real ops work. Is has become a bit harder to maintain an

I work as a Developer Advocate helping people ship web apps as native mobile apps, and I kept answering the same questions over and over. So I wrote a guide that summarizes everything I recommend, based on 13+ years working in mobile development. From what I've seen, every time someone in a web dev community asks "how do I publish my React/Vue/Angular app to the App Store?", the answers are either "just make a PWA" (which doesn't actually get you on the stores) or links to tutorials that assume you already know what a provisioning profile is and have Xcode configured on a Mac. This one starts from zero. It's structured as an index, not a wall of text. Each step links to specific posts, videos, tools, and automation resources so you can go as deep as you need, at your own pace. Some things I cover that I rarely see explained well: - Why PWAs won't get you into the App Store or Google Play (and what to use instead) - How to generate iOS certificates directly from your browser, without a Mac or Keychain Access - The Google Play closed testing requirement that blindsides most first-time publishers: personal accounts created after November 2023 need 12 testers actively opted in for at least 14 consecutive days before you can go public. - Why you should install the Live Update plugin in your very first release, even if you have nothing to update yet. Adding it later means another full native build and another review cycle, which is the last thing you want when you're trying to push a critical fix. - How to build for iOS without owning a Mac Honest feedback welcome: is there a step that's unclear, or something you think is missing? https://capawesome.io/blog/11-steps-to-get-your-web-app-on-the-app-store/ submitted by /u/DayanaJabif [link] [留言]

I feel like this might start becoming a lot more common, due to all the hype and marketing surrounding AI. Seems a lot of ppl believe anyone can build an app in one-shot and we don’t need experienced engineers anymore. When they ask a question like “why can’t we just one-shot the app”, it puts you on the hot seat to explain the entire development process to them, and all the steps it takes to get to a production quality app. AI can be used to assist and augment that process but you need a human in the loop to know and understand what they are doing. Rather than just telling them “go ahead and try it yourself”, how would you respond to this? How would you explain why AI can’t just make the entire app? How would you breakdown the step by step process of building an entire application? Thanks submitted by /u/throwaway0134hdj [link] [留言]

I'm working on a personal one-man project. It's very simple : it's a static website generated from some data stored in a JSON file. I have a prototype written in TypeScript/TSX, consisting of fewer than ten files (views), each containing an average of less than fifty lines of code. Only two of the pages retrieve data from JSON; the rest are simple TSX files that describe the project (pages like "About" or the "Privacy" page). Given how simple it is, I thought I'd go the extra mile and focus heavily on ensuring the entire code, from the build process to the distribution, is 1000% correct, stuff like: crazy type safety 0% chance of logical and consistency errors validation of JSON against a schema HTML (and attributes) that conforms to the specifications (no mains inside spans, no booleans inside hrefs...) I started exploring the various programming languages that allowed me to do all these things at once, and I found OCaml . It: is statically typed has yojson to parse JSON and into a nested OCaml tree data structures has tyxml to build valid HTML. If I understood correctly, it has the distinctive feature of performing strict checks on (HTML) element's attributes while libraries in other languages simply accept any string To be honest, I also looked into Elm , which seems to be even more lenient when it comes to error handling; however, its HTML generation library doesn't seem to have strict controls over attributes, not nearly as strict as tyxml. Is there something even more powerful that allows me to achieve what I want (code safety and error free) or is OCaml already the best? If so, what has been your experience with it? Any advice? I'll say it again: the project is so simple that you could rewrite it in any programming language in an hour, it's no problem for me. It's a chance to learn something new. Thanks in advance. submitted by /u/Wise_Stick9613 [link] [留言]

Some time ago, I embarked on the journey to radically simplify building realtime apps. I wanted: No backend/socket.io setup, and no logins A simpler client to handle race conditions Ultimately I came up with: A public/free relay server that anyone can use A thin WebSocket client that talks directly to that service (or any other WS server) The Dilemma: I always assumed it should be angled at the rapid prototyping crowd, since it's literally a service you can use in a single line from your browser DevTools, but the client itself is pretty f*cking amazing... for ~466 bytes, you can do things like this: connect('wss://socket.massive.com/crypto') .on('*', e => console.log(e['0'])) // listen .send({ action: 'auth', params: 'MY-API-KEY' }) // login .send({ action: "subscribe", params: "XQ.*" }) // subscribe If you notice, that's usually a race-condition nightmare that involves callbacks/promises, etc. The tiny client sorts all that out under the hood (and much more). While of course I use the underlying service to power apps, I find myself using the client itself just to check any existing WS service, because it's 100x easier to use than native WS code. The Question In the NPM library specifically, which should I focus on? The hosted integration, or strictly as a more user-friendly WebSocket client (with an aside mention of the integrated service)? It's all 100% free, so it's not like this is a product question - it's more of a "am I sleeping on something that could help more of the community?" question. submitted by /u/kevin_whitley [link] [留言]

The more I code, the worse my relationship with builder projects gets. It's just reality. I migrate a lot of sites to VPS these days. Cuts hosting costs significantly for clients, and honestly I've gotten pretty good at it. If anyone does the same, curious if you've run into this too. The thing is, most of these projects come with builders already in place. Elementor mostly, some Bricks, some older stuff that's a complete disaster. And the core problem is always the same: these tools design in the database. Not in code. So on a live ecommerce site you've got payments, emails, transactional stuff, chat integrations. All of that gets disabled on dev. Fine. But then when you need to push something back to main, especially if the builder is involved, it becomes a mess. The database on staging and the database on production have diverged, and there's no clean way to merge them. My current approach: stop fighting the chaos, join it with a method. Every DB action I take on staging gets documented as a WP-CLI command. Those commands live in a migration script. When it's time to push, I run the script on production after a backup. It's not magic, but it works, it's readable, and it lives in git. Not sure if this is the right way though. Meanwhile, when design lives in code (custom theme, Gutenberg blocks, PHP templates) the whole problem disappears. Git handles it. Deploy is clean. How do you all handle this in practice? Do you steer clients away from builders? Have you found a builder that plays nicely with proper deploys? Or do you just accept that builder sites need a different, more careful workflow? submitted by /u/Substantial_Word4652 [link] [留言]

Imagine you're responsible for a company's website. Everything seems healthy. Pages load quickly. Users can log in. Content editors publish articles every day. Customers aren't reporting problems. From the outside, everything looks perfect. But then one day you discover something surprising: Attackers don't care whether your website looks healthy. They care whether the software behind it is vulnerable. That's exactly what happened with Drupalgeddon2. One of the most significant CMS vulnerabilities in recent years. And one that still teaches valuable lessons for developers, DevOps engineers, and security professionals today. The Building Manager Analogy Imagine a large office building. The company hires a building manager. The manager handles: Visitors Deliveries Maintenance Schedules Room Access The employees don't worry about these details. They trust the manager. A Content Management System (CMS) works similarly. Instead of manually managing every page and article, organizations rely on a CMS. Website ↓ CMS ↓ Content The CMS becomes the central control system. And that's why it becomes such an attractive target. What Is Drupal? Drupal is an open-source Content Management System. Organizations use it to manage: Corporate websites Government portals Universities Media platforms Enterprise applications A simplified architecture looks like: Visitor ↓ Drupal ↓ Database ↓ Content Every request passes through Drupal. Which means Drupal becomes part of the application's attack surface. Why Attackers Love CMS Platforms Suppose an attacker discovers a vulnerability in: Custom Internal Tool Maybe a few organizations are affected. Now suppose they discover a vulnerability in: Popular CMS Thousands of organizations may be affected. Potentially millions of users. One vulnerability. Many targets. That's why CMS platforms receive so much attention. Understanding Drupalgeddon2 Drupalgeddon2 refers to: CVE-2018-7600 A Remote Code Execution vulnerability affecting Drupal. The import

This week, the first offline-first PWA went live on WebsitePublisher.ai . A travel blog that works without internet. Write posts on a plane, attach photos, and everything syncs the moment you reconnect. Service Worker, IndexedDB, sync queue — the full stack. The twist: it was built entirely through conversation with an AI assistant. No IDE, no terminal, no deploy pipeline. How that works WebsitePublisher.ai exposes 92 integrations as building blocks via MCP (Model Context Protocol). Any AI assistant — ChatGPT, Claude, Cursor, Windsurf, Copilot, Gemini, Grok, Mistral — connects to the same runtime and assembles these blocks into working applications. The offline-first PWA is one of those blocks. The AI doesn't generate a Service Worker from scratch. It activates a proven, tested building block and configures it for the use case. We call this wave coding — one deliberate wave of proven pieces, instead of 15 fragile vibe-coding attempts. What shipped recently Offline-first PWA building block — push/pull sync, conflict handling, IndexedDB storage, works on iOS 92 integrations (up from 78) — 45 built-in, 47 bring-your-own-key Integration stacks — pre-composed combinations: e-commerce (13 integrations), lead generation, B2B prospecting, booking, content/blog 9 AI platforms supported — all via MCP, no vendor lock-in 416 API endpoints across the platform ## The architecture in short AI assistant (any) → MCP → WebsitePublisher runtime ├── PAPI (pages + assets) ├── MAPI (structured data) ├── SAPI (forms + auth + sessions) ├── IAPI (integration proxy) ├── VAPI (encrypted vault) └── AAPI (scheduled AI agents) Credentials never touch the AI. They're stored AES-256-GCM encrypted in the vault and injected server-side during execution. The positioning We're not competing with Lovable or Bolt on the chat interface. We're the Supabase + Vercel + n8n underneath — reachable via whichever AI you already use. The platform your AI builds on. websitepublisher.ai

I have almost 8 YOE experience working in B2B SaaS doing full stack. I broke into the industry in early 2018 without a degree and being completely self taught. Note, I have no degree at all. I did go to college and almost completed my AA, but found work that paid pretty well at the time (not tech related) and off I went. I have been on the market for ~2 months now, and I have noticed I am getting zero traction, unlike before 2022. My last role lasted 4 years and moved to a Senior position. I had been removed from the market this whole time, woefully unaware of what has been going on. Have sent ~150 targeted applications and always an auto reject. Granted it's only been 2 months, but to have a 0/150 interview rate from cold apps is unlike anything I have experienced in the past. I am not spraying and praying, I apply to positions that match my experience. I have also had a technical resume writer rewrite my resume entirely. Right now, I am solely relying on LinkedIn recruiters at this point. I have exhausted my personal network; the few people I can hit up have all said their companies unfortunately are not hiring. Targeting remote, AND in person / hybrid. I am seeing more and more listings asking for CS or equivalent degree. They do mention, "or relevant experience," but the thing is, when a job has 300 applicants, the first filter likely is the degree. I have spoken to many recruiters via LinkedIn and they have all gone nowhere. I get past the initial phone screen no problem, and the recruiter will submit me to the hiring manager of the job, and I hear nothing back after. I was wondering what was happening, and finally a recruiter called me to tell me that a job she submitted me for told her that they are prioritizing candidates with a degree. I have also interviewed about 5 times, passed first rounds and also second round technicals, to only be ghosted. I am currently getting my B.S. as we speak, and should be done in ~7 months. Luckily I was already working on it

For me AI has been a saviour when it comes to coding as it help me learn at the start. However, AI is still relatively young and stilll in development especially a pain when you working big projects. Now the question is: What is the number 1 most constant thing that you dealt with AI in coding (aside from a colleague using it and make a mess of your code)? submitted by /u/Haunting-Bother7723 [link] [留言]

Just wanted to share my journey after 3.5 years of building a live web analytics tool from scratch, and without AI: WireBoard.io As a web publisher for the last 15 years, I used UA (before GA4) and then Chartbeat. I always loved real-time. At the beginning of the internet I spent my time on IRC, which was great and a huge change from newsgroups and forums. A few years later, Chartbeat was changing its customer base and focusing on big news publishers, and my workflow was about to change with it. I loved being able to watch my traffic live and spot anything unusual, day by day, compared to the same day the previous week. So I decided to replace it with my own product, but with the things their tool was missing. I spent about 8 months thinking it through and sketching different architectures to handle the load and the logic of the data processing pipeline. Then I learned to code in Go (which was surprisingly easy) and built an MVP. After some iterations, I worked on the frontend (Laravel + React) and kept improving the product based on user feedback. The features I couldn't find anywhere else: Truly real-time data via streaming instead of polling. Merging data from different websites into one chart, so I can see at a glance whether traffic is unusual "today" compared to last week. A flexible dashboard, arranged like widgets on a phone. I mostly worked on this quietly and didn't talk about it much on social media or anywhere else, since I'm a dev and not a marketer. This is my biggest project, and I've enjoyed the long journey. All of this happened before the AI era, which turned out to be good timing: I can work on the codebase knowing exactly what does what and where. Over the last 6 months I've experimented with using Claude on some parts of the project (only the frontend), but in limited areas: Performance improvements (useMemo, etc.) Security reviews (not strictly needed, but reassuring when it confirms what I expected) CMS (blog section) The tech stack: Data proc

The dangerous part of web extraction is not the error. The dangerous part is a clean JSON response that looks correct and is not. If an AI agent uses that output, the mistake does not stay inside a scraper. It moves into a report, a lead list, a price alert, a CRM update, or an automated decision. So before you trust any web extraction API in an agent workflow, test whether it fails honestly. Here is the checklist I use. 1. Test a real page, not a demo page Demo pages are usually polite little museum exhibits. Use pages that behave like the actual internet: a JavaScript-heavy product page a search results page a page with missing fields a login-gated page a blocked or rate-limited page a thin page that has layout but little useful content If the tool only looks good on clean static pages, you have not learned much. 2. Check whether the API separates fetch success from extraction success A page can return HTTP 200 and still be useless. Common examples: the final page is a login screen the visible content is a bot challenge the useful data loads after hydration and never appeared in the fetch the page contains a generic country selector instead of the product the source has navigation text but no actual item data The extractor should not treat these as success just because the request completed. A better response says something like: { "status" : "failed" , "failure_type" : "login_required" , "extracted" : null , "next_step" : "Use a public URL, authorised access, or sample content." } That is boring. Boring is good here. Boring means the agent can stop safely. 3. Ask for fields that are not on the page This is the easiest lie detector. Ask the extractor for something impossible: Extract the product name, price, stock status, warranty length, CEO name, office address, and refund policy. If the page only contains product name and price, the API should say the other fields are missing or low confidence. It should not politely invent them because the schema asked nicely.

With ideas and project specs scattered across platforms like Notion while actual tasks live in GitHub, keeping them in sync is constant manual overhead—how do you bridge this gap without your PM tools and repos becoming a mess? submitted by /u/asifdotpy [link] [留言]

You can't imagine how bad my experience with Next.js has been recently. I have two projects running on the same Ubuntu laptop: One Next.js app One TanStack app The Next.js dev server was literally the biggest process on my entire machine, sitting at almost 4GB of RAM and absolutely murdering my old Lenovo. Even Brave and VScode consume less memory. Meanwhile, the TanStack app was using around 800MB. Still not amazing, but nowhere near as insane. Out of frustration, I asked an AI to help optimize the Next.js setup. It ended up changing some config to force Webpack instead of the default Turbopack setup and also added limits to how large the cache could grow. Believe it or not, memory usage dropped from nearly 4GB down to around 1–2GB. That's still a ridiculous amount of RAM for a dev server, but at least it no longer tries to consume every available resource on my laptop. Maybe Vercel is thinking that everybody has a fancy Macbook M4 with 64GB ram?! P.S. both codebases are small, max 50k lines in each. submitted by /u/hanzo2349 [link] [留言]

I added real-time activity logging and security scoring to my Claude Code dashboard The problem with just seeing costs Knowing how much you spent is useful. But it's not enough. The real question is: what is your AI actually doing? Which files did it read? Which commands did it run? Is your environment even safe to run it in? I couldn't answer any of those. So I built the answers in. What's new in v0.1.17 Activity Log — see every action in real-time Claude Code logs everything via hooks. Every file read. Every command executed. Every API call. Risk-labeled. Timestamped. Live. Set it up once in ~/.claude/settings.json : { "hooks" : { "PostToolUse" : [{ "matcher" : ".*" , "hooks" : [{ "type" : "command" , "command" : "curl -sf -X POST http://localhost:3000/api/actions -H 'Content-Type: application/json' --data-binary @- 2>/dev/null || true" }] }] } } Then open http://localhost:3000/activity . Watch your AI's actions stream in real-time. This is the audit layer AI agents have been missing. Security Score — how safe is your Claude Code environment? Scored out of 100. Checks 7 things: Is Bash(sudo *) in your allow list? (-20) Is ~/.ssh/** in your deny list? (-20) Is Bash(curl *) unrestricted? (-15) Are .env files protected? (-15) Is strictMode enabled? (-10) Is Bash(rm *) restricted? (-10) Are hooks configured? (-5) I scored 90/100. What's yours? The point isn't to shame anyone. It's to make the invisible visible — so you can make informed decisions about what your AI is allowed to do. Try it npm install -g @notenkidev/claude-token-dashboard claude-token-dashboard Open http://localhost:3000 GitHub: https://github.com/notenkitoclient-cpu/claude-token-dashboard This started as a simple token counter. It's becoming something bigger — an observability layer for AI agents. More coming.