Uncategorized

When building apps that store files like images, PDFs, or videos using Amazon S3, the best practice is to keep your S3 bucket private. But what if you want to: Hide sensitive filesShow only allowed files to specific usersStill serve public assets like profile pictures or logos? Good news: you can do all this securely using pre-signed URLs and smart folder organization. Let’s walk through how.  Why You Shouldn’t Make Your S3 Bucket Public While you can make your bucket public, it’s strongly discouraged:  Anyone can access your files  Search engines might index them No access control Instead, keep the bucket private and generate secure, temporary URLs when users need to access private files. Basic Setup Here’s a typical setup using AWS S3 with a backend and a frontend app: S3 Bucket: private by default Backend (e.g., Strapi or Node.js): handles file uploads and generates access links Frontend (e.g., React Native app): fetches files only for authorized users Organize Your S3 Bucket for Access Control Use prefixes (folders) to separate file types and control access: <pre>s3://my-app-bucket/ ├── public/│ └── avatars/├── clients/│ ├── 001/│ │ └── journal.pdf│ │ └── mood-chart.png│ └── 002/│ └── mood-chart.png├── internal/│ └── admin-reports/</pre>    Explanation: /public/ → Used for public files like profile pictures. /clients/001/ → Private files for user ID 001. /internal/ → Admin-only files (e.g., internal reports). This structure makes it easy to control access based on folder paths. How to Show Private Files Securely: Pre-Signed URLs A pre-signed URL is a secure link to a private S3 file that: Expires after a short time Can’t be reused or bookmarked Is safe to send to the frontend Backend Code: Generate Pre-Signed URL (Node.js)  const AWS = require(‘aws-sdk’); // Load AWS SDK // Configure AWS S3 with your credentials const s3 = new AWS.S3({ accessKeyId: process.env.AWS_ACCESS_KEY_ID, secretAccessKey: process.env.AWS_ACCESS_SECRET, region: process.env.AWS_REGION, }); // Function to generate a pre-signed URL const getPresignedUrl = (key) => { const params = { Bucket: process.env.AWS_BUCKET_NAME, // Your S3 bucket name Key: key, // File path in the bucket Expires: 300, // Expiry time (300 seconds = 5 minutes) }; return s3.getSignedUrl(‘getObject’, params); };   Explanation: getSignedUrl() creates a temporary access link. The Expires value defines how long the link will work (e.g., 5 minutes). This URL can be used to fetch the file securely without making the bucket public. Add This to Your Strapi Controller  module.exports = { async getFile(ctx) { const { key } = ctx.query; // Extract file key from query (e.g., clients/001/journal.pdf) // Make sure the user has permission to access the file if (!ctx.state.user || !key.includes(`clients/${ctx.state.user.id}/`)) { return ctx.unauthorized(‘Access denied.’); } // Generate secure, time-limited link const url = getPresignedUrl(key); ctx.send({ url }); }, };  Explanation: ctx.state.user contains the authenticated user. The if check ensures users can only request their own files. If allowed, the signed URL is generated and returned. React Native Frontend Code  // Call your backend to get the signed URL const response = await fetch(`${API_URL}/api/get-file?key=clients/001/journal.pdf`); const { url } = await response.json(); // Use the URL to open or display the file Linking.openURL(url); // Opens in browser // OR <Image source={{ uri: url }} /> // Displays image in the app   Explanation: You request the file from your backend, not directly from S3. You then use the returned URL temporarily — it expires automatically. This keeps things secure while offering users access when needed. For Public Files: Set Bucket Policy You may have files (like logos or banners) that are okay to show publicly. In that case: Place them in a /public/ folder. Add this policy to your S3 bucket: { “Sid”: “PublicReadGetObject”, “Effect”: “Allow”, “Principal”: “*”, “Action”: “s3:GetObject”, “Resource”: “arn:aws:s3:::my-app-bucket/public/*” }   Explanation: This allows anyone to access files under /public/ The rest of the bucket stays private Great for assets like default avatars or app logos Best Practices at a Glance Strategy Why It’s Good Keep your bucket private Prevent accidental leaks Use folder prefixes (/public/, /clients/) Simplifies access control Use pre-signed URLs Secure, short-lived file access Validate user access before signing Prevents sharing someone else’s data Set URL expiry (3–5 mins) Minimizes the risk of misuse   Final Thoughts You don’t have to make your S3 bucket public or complex. Instead: Use folder structure to segment access Use pre-signed URLs for sensitive content Use bucket policies for safe public content This approach keeps your app secure, organized, and user-friendly — exactly what you want in a modern mobile or web app. Related reads: How to Set Up an S3 Bucket on AWS (Best Practices for Beginners) Understanding AWS IAM: The Key to Cloud Security for Beginners How to Set Up AWS CLI and IAM for S3 Bucket Access (Beginner-Friendly Guide) External resources: AWS Official Documentation

When it comes to hosting web applications, two web servers dominate the conversation: Nginx and Apache. Both are powerful, open-source, and widely used  but they approach performance and architecture very differently. So which one is better? The answer depends on your use case, traffic, and tech stack. In this guide, we’ll break down the key differences, use cases, and when to choose one over the other. Quick Introduction Apache (HTTPD) Developed by the Apache Software Foundation Released in 1995 Known for its .htaccess support and flexible modular architecture Handles each connection with a separate thread or process Nginx (pronounced “Engine-X”) Created by Igor Sysoev in 2004 Built to solve the C10K problem (handling 10,000+ concurrent connections) Uses an event-driven, non-blocking architecture Famous for speed and low resource usage  Architecture: Process vs Event-Driven Feature Apache Nginx Request Handling Multi-threaded / process-based Event-driven / asynchronous Performance Slower under heavy traffic Excellent at handling high concurrency Resource Usage High memory with many connections Low memory footprint Scalability Limited by threads Built for scale   Verdict: Nginx wins for high-performance, high-traffic websites Configuration & Flexibility Feature Apache Nginx Configuration Files httpd.conf, .htaccess nginx.conf only .htaccess Support Yes — supports per-directory overrides ❌ Not supported Ease of Use Flexible but complex for beginners Clean and simple, but strict   Verdict: Apache wins for per-directory flexibility (like shared hosting) Static vs Dynamic Content Handling Task Apache Nginx Serving Static Files Good Excellent (super fast!) Handling Dynamic Content Embedded (PHP via mod_php) Reverse proxy to app server (e.g., PHP-FPM)   Verdict: Use Nginx for fast static sites and modern web stacks Use Apache for simple LAMP stack sites (PHP, MySQL) Reverse Proxy & Load Balancing Nginx is widely used as a reverse proxy, API gateway, or load balancer. Feature Apache Nginx (preferred) Reverse Proxy Supported (via mod_proxy) Built-in, faster, and more efficient Load Balancing Basic Advanced with health checks & retries   Verdict: Nginx dominates here — it’s the go-to choice for modern architectures like microservices or containerized apps (e.g., Docker, Kubernetes) Security & Community Support Aspect Apache Nginx Security Mature with strong updates Also secure and maintained actively Community Huge — decades of plugins Fast-growing, strong ecosystem Enterprise Apache HTTPD + Apache2 tools Nginx Open Source / Nginx Plus   Verdict: Both are secure and well-supported. Nginx is newer but backed by F5 and widely used by companies like Netflix, Airbnb, Dropbox Use Cases Use Case Recommended Web Server High-traffic APIs, React/Vue apps Nginx CMS like WordPress on shared hosting Apache Serving static files (JS, CSS, media) Nginx Custom PHP scripts via mod_php Apache Reverse proxy in front of Node/Flask Nginx   Can You Use Both? Yes! Many architectures use Nginx as a reverse proxy in front of Apache. Internet → Nginx (proxy) → Apache (app server) → PHP/MySQL This gives you: Speed and caching from Nginx Flexibility of Apache for complex backends Final Verdict You Should Choose If You Need… Nginx Fast static content, scalable performance, low resource usage, API proxying Apache Deep .htaccess support, shared hosting, legacy LAMP stack simplicity Related reads: Is PHP Dead Working with Docker External resources: Apache HTTP Server Official Documentation Nginx Official Documentation

Is PHP Dead? A Thoughtful Look at the Evolution of a Veteran Language When developers say a language is “dead,” they rarely mean that no one is using it. Instead, they often refer to its perceived relevance in modern development, community growth, innovation, or overall momentum in the tech landscape. So when the question arises, “Is PHP dead?” — it deserves a thoughtful, nuanced exploration rather than a simple yes or no. What Does “Dead” Mean in Tech? In technology, a language or tool is often considered “dead” when: It is no longer actively developed or maintained. It lacks a vibrant community or ecosystem. It’s not being adopted in new projects. It feels outdated or is losing mindshare to newer alternatives. However, this definition has its flaws. For example, COBOL is decades old and rarely used for new projects — yet it’s still running mission-critical systems in banks and governments. That doesn’t make it dead; it makes it legacy. The same nuance applies to PHP. Is PHP Still Being Used? Absolutely. PHP powers more than 75% of websites on the internet, including major platforms like WordPress, Drupal, and Magento. Facebook originally ran on PHP and still relies on it internally (albeit a heavily modified version called Hack). Platforms like: WordPress (which powers 40%+ of the web) Laravel (a modern PHP framework that is extremely popular) Symfony, CodeIgniter, and other frameworks show that PHP is not only used, but also thriving in certain areas. Why Developers Say PHP is “Dead” Despite its continued use, many developers refer to PHP as “dead” for several reasons: 1. Bad Reputation from the Past PHP, especially in its early versions, had major issues: Inconsistent syntax Poor security practices Spaghetti code common in beginner-written apps This led to a reputation that’s been hard to shake off, despite improvements. 2. Rise of JavaScript and Node.js The explosion of JavaScript (with Node.js, React, etc.) gave rise to full-stack JavaScript apps. Developers found it easier to use one language for both front and back end. 3. Modern Alternatives Languages like Python (with Django/Flask), Ruby (with Rails), and even Go and Rust have gained popularity for their performance, cleaner syntax, and modern design patterns. 4. Lack of Innovation Perception Compared to fast-moving ecosystems like JavaScript or Python, PHP feels slower to evolve — even though PHP 8 introduced great features like JIT compilation and type safety. Why PHP Is Still Very Much Alive Despite the criticism, PHP continues to improve and grow. 1. Massive User Base Because of WordPress, PHP is likely the first backend language many developers still encounter. It dominates small business websites, blogs, and even e-commerce. 2. Modern Frameworks (Laravel) Laravel, one of the most elegant and modern PHP frameworks, brought structure, simplicity, and beauty back to PHP development. Its ecosystem rivals that of any modern backend framework. 3. Performance Improvements PHP 8 and 8.1 brought major performance and syntax improvements. Features like union types, attributes, and the JIT compiler make PHP more capable than ever. 4. Easy to Learn, Fast to Deploy PHP is still one of the easiest languages to get started with. You can spin up a PHP server with minimal configuration, which is attractive for beginners and small projects. 5. Robust Hosting Support PHP is supported out-of-the-box by nearly every web hosting provider, making it the go-to for quick deployments and shared hosting environments. Conclusion: PHP Isn’t Dead — It’s Just Mature Calling PHP “dead” is both inaccurate and unfair. It may not be the trendiest language on the block, but it has matured into a solid, reliable, and modern language that powers a huge part of the web. Developers might move to shinier tools, but PHP remains an essential part of the internet’s infrastructure. Like a veteran craftsman, it may not flash the latest trends, but it gets the job done — reliably, securely, and at scale. So is PHP dead? No. It’s alive, stable, and quietly powering the backbone of the internet while the world debates its relevance.  

What is Docker? Why Developers Love It (And You Should Too) In modern software development, agility, consistency, and scalability are crucial. That’s where Docker comes in — a powerful tool that’s essential for developers, DevOps engineers, and testers. If you’ve ever heard someone say, “It works on my machine!” only to watch it fail in production, Docker solves that exact problem. Related read:Is PHP Dead? |Which do you prefer php or NodeJs Learn more at: Docker Documentation. What is Docker? Docker is an open-source platform that lets developers package applications and all their dependencies into a container — a lightweight, standalone executable that runs consistently across any environment. Think of a container as a mini-computer inside your computer, built to run one app and everything it needs. How Docker Works Docker uses a client-server architecture: Dockerfile: Script defining your container’s base image, code, dependencies, and commands. Docker Image: Snapshot of the app + environment, built from the Dockerfile. Docker Container: Running instance of a Docker image. Docker Engine: The runtime that builds and manages containers. Example workflow   # Step 1: Write a DockerfileFROM node:18WORKDIR /appCOPY package*.json ./RUN npm installCOPY . .CMD [“npm”, “start”] # Step 2: Build an imagedocker build -t my-node-app . # Step 3: Run the containerdocker run -p 3000:3000 my-node-app Boom — your app is running in an isolated container, ready to deploy anywhere. What Problems Does Docker Solve? Here’s where Docker shines: ✅ “It works on my machine” syndrome — Consistency across dev, test, prod.✅ Dependency hell — Each container holds its own versions.✅ Slow onboarding — Share the Docker image; no extra setup.✅ Complex deployments — Simplifies CI/CD pipelines.✅ Heavy virtual machines — Containers are faster, lighter, and use fewer resources. Why Developers Recommend Docker Docker helps developers: Repeat builds identically on any machine Run services modularly (frontend, backend, DB in separate containers) Spin up test environments quickly Deploy faster with fewer bugs Work cloud-ready (compatible with Kubernetes, serverless, etc.) Final Thoughts Docker isn’t just a developer trend — it’s a foundational tool for modern software development. Whether you’re building microservices, a monolith, or experimenting with AI models, Docker helps you move faster, with fewer bugs and greater confidence. 👉 If you haven’t tried Docker, now’s the time. Your future self will thank you. Related read:Is PHP Dead? |Which do you prefer php or NodeJs Learn more at: Docker Official Documentation.  

PHP vs Node.js – Which Should You Use (and Why I Choose Node.js) When building modern web applications, two powerful backend technologies often come into the conversation: PHP and Node.js. In this post, we’ll compare PHP vs Node.js, explore their strengths, and help you decide which is best for your project. If you’re also wondering “Is PHP Dead” in today’s tech landscape, we covered that too! A Quick Comparison of PHP vs Node.js Feature PHP Node.js Language PHP JavaScript Runtime Interpreted server-side Event-driven, non-blocking JS Speed Slower for concurrent tasks Fast, especially under load Hosting Shared hosting ready Requires VPS or Node-ready host Learning Curve Easier for beginners Steeper, especially with async Community Support Huge legacy community Large, modern ecosystem Frameworks Laravel, Symfony Express.js, NestJS   If you’re setting up a server, check out our post on Nginx vs Apache: Which Web Server Should You Use? to choose the right web server for your stack. Why I Prefer Node.js Single Language Across the Stack With Node.js, developers write JavaScript for both frontend and backend, creating cleaner code sharing and better team collaboration. Modern Development Flow Node.js excels with tools like NPM, ES Modules, TypeScript, and Socket.io for real-time apps — perfect for startups and chat-based platforms. Performance Node.js shines for apps needing real-time updates or concurrent processing. Unlike PHP, it handles multiple I/O operations efficiently. When PHP Might Be Better PHP still shines in cases like: WordPress or Drupal sites Shared hosting environments Quick CRUD apps If you want to learn PHP from the source, visit the official docs at PHP.net. Conclusion: Choose What Solves Your Problem Best Both PHP and Node.js are production-ready. For speed, scalability, and modern workflows, I prefer Node.js — but PHP is still great for certain use cases. If you’re curious about containers, also explore Working with Docker. Ready to choose? Weigh the strengths of PHP vs Node.js based on your project’s needs, and check out more practical guides on our Blidot Blog.