DEV Community: Suryansh Chaudhary

We're deleting our vector database and our graph database. Both of them.

Suryansh Chaudhary — Tue, 18 Aug 2026 09:41:01 +0000

Not because they were bad. Because we counted, and we were running three retrieval
substrates for one product: a managed vector RAG service, a hosted graph database, and
the application's own Postgres. Three vendors. Three sets of credentials. Three failure
modes to reason about at 2am. Two of them billing us to embed the same text twice.

This is the write-up of why both are going, why one data warehouse is replacing both, and
the four things that cost us the most time to discover. If you're standing up RAG on
BigQuery, sections 4–7 are the ones that will save you a week.

The honest status: the graph migration is built. The RAG half is a decision we've
committed to measuring, with criteria written down in advance. I'll show you those
criteria at the end, including the outcome where we delete the whole thing instead.

1. Why we're leaving a managed RAG service

The seductive thing about managed RAG is that chunking, embedding, indexing and retrieval
arrive as one API call. The expensive thing is that when retrieval goes wrong, you own the
symptom and not the machinery.

Ours went wrong like this. A workspace with ~500 ingested documents was surfacing one to
three of them, over and over, no matter what was asked. Not low-quality answers —
starved answers, grounded in a handful of sources while 497 sat there unread.

The root cause is a shape you should go check for in your own stack right now:

One shared corpus for every tenant. Retrieve the global top-50 across all tenants.
Then filter down to the current tenant, client-side.

That's post-filtering. The top-50 is a lottery drawn from everyone's data, and your
tenant wins however many tickets it wins — which, on a shared corpus, is a handful.
Ingesting more documents does not help. It makes it worse, because it adds tickets to a
draw you're already losing.

The obvious fix — server-side metadata filtering — was a closed door at our configuration:
metadata search was only available in a beta API surface and explicitly unsupported in
serverless mode. Not an oversight on our part; a documented limitation.

The next fix — pass explicit document IDs to scope the search — collided with something
even more mundane. The serverless vector backend caps the request payload at ~10 KB, and
the query embedding alone was ~9.6 KB of it. That left room for roughly fifteen IDs.
Fifteen, out of five hundred. Which is how you end up maintaining ~150 lines of ID
batching, adaptive request-splitting, and an all-or-nothing fallback that only fires at
exactly zero results — so "three documents out of five hundred" was being counted as
success by our own code.

Add a regional quota of about 25 requests per minute, shared across import, list and
delete, and the picture resolves: we weren't tuning a retrieval system. We were building
scaffolding around one.

What we lose by leaving, stated plainly: native reranking, corpus lifecycle
management, and grounded generation as a single call. The first one is real and we have to
rebuild it. More on that in section 8.

2. Why we're leaving the graph database

This one is less dramatic and more useful, because the graph database was working
fine.

There was no incident. No performance cliff. It was a paid third-party service living
outside the cloud project everything else runs in, with its own credentials, its own
uptime, its own invoice. Consolidation was the whole motivation, and I'd rather say that
plainly than invent a technical grievance after the fact.

But auditing it did surface something worth generalising. Here was our graph model:

(:Resource)-[:HAS_CHUNK]->(:Chunk {text, embedding})
(:Resource)-[:MENTIONS]->(:Entity {name, type})
(:Entity)-[:RELATED {type}]->(:Entity)

And here is what the read path actually did: vector-search the chunks, join to the
resource, collect one level of entity relationships. That's it.

No variable-length patterns. No *1..5. No path finding, no centrality, no traversal of
unknown depth. A vector search and two joins.

So the question stopped being "how do we migrate our graph database" and became:

If none of your Cypher contains a variable-length pattern, what are you paying a graph
database for?

A graph database earns its price on traversals whose depth you don't know in advance —
that's the query class where the index-free adjacency actually beats a join. One hop is
not that query class. One hop is a join, and every database does joins.

If you have a knowledge graph in production, go grep your queries for * between two
node patterns. The answer is genuinely informative either way. If you find them, keep your
graph database — this post doesn't apply to you. We didn't find any.

3. Why one substrate, and why a warehouse

Once both moves are on the table, the third fact becomes impossible to ignore: we were
running two complete chunk → embed → search stacks over identical text.

The ingestion service scraped a page, wrote it to object storage, and imported it into the
managed corpus, which chunked and embedded it internally. Then the application read the
same text back out of object storage, chunked it again with its own splitter, and
embedded it again. Same source. Two chunkings. Two embedding passes. Two bills. Two things
that can drift apart silently and give different answers to the same question.

Neither vendor was wrong. The seam between them was.

Collapsing both into one BigQuery dataset gives one text corpus, one chunking, one
embedding model, one query surface — and, structurally, it can't starve:

-- pre-filter, then top-k
SELECT ... FROM VECTOR_SEARCH(
  (SELECT chunk_id, text, embedding
     FROM v_chunk JOIN v_chunk_embedding USING (chunk_id)
    WHERE workspace_id = @ws),        -- <<< this runs FIRST
  'embedding',
  (SELECT @qvec AS embedding),
  top_k => @probe,
  distance_type => 'COSINE')

The tenant predicate is inside the search subquery. The k nearest are computed within
the tenant, not filtered down to it afterwards. The starvation failure mode from
section 1 is not mitigated here; it is unrepresentable.

The cost model that makes this viable: in a warehouse, query cost is bytes scanned.
A 5,000-chunk workspace at 768 dimensions scans roughly 30 MB — about $0.0002 per
query — and brute-force vector search is competitive below a few thousand rows anyway.

And the alternative we turned down, because a decision post that only lists the
winner's virtues isn't a decision post: Postgres + pgvector was the better fit on the
merits. The database was already deployed, already credentialed everywhere, MERGE maps
1:1 onto ON CONFLICT, HNSW works at any row count, and latency stays in milliseconds
instead of BigQuery's 0.5–2s floor. We went the other way for warehouse-side batch
embedding and analytics colocation. It's a real trade, not a slam dunk, and if latency is
your binding constraint you should probably pick differently.

4. Trap one: the embedding parameter that is accepted and ignored

This is the most dangerous thing in the post, so it goes first.

Newer embedding models have deprecated the task_type parameter — and the backend
silently ignores it. You pass RETRIEVAL_DOCUMENT. You get no error. You get no
warning. You get raw-text embeddings with no task optimisation, and retrieval that is
quietly worse than it should be with nothing to debug.

Degraded quality with a clean log is the worst failure shape there is. A crash you can fix
in an afternoon.

The task now goes in the text, as a prefix, and it stays deliberately asymmetric:

# one shared constant — two call sites that must never drift
DOC_PREFIX   = "task: retrieval_document | "
QUERY_PREFIX = "task: retrieval_query | "

-- ingest
SELECT * FROM AI.GENERATE_EMBEDDING(
  MODEL `ds.embed_model`,
  (SELECT chunk_id, 'task: retrieval_document | ' || text AS content FROM v_chunk ...),
  STRUCT(768 AS output_dimensionality));

Two rules we now enforce with unit tests, because production won't tell you:

Ingest and query must use the same model at the same dimensionality. Break it and you don't get an exception, you get meaningless neighbours.
Ingest and query must use different task prefixes. That asymmetry is the entire point of task types; symmetry silently costs you quality.

Test that no code path passes TASK_TYPE at all. It's three lines and it protects you
from a bug that has no other detector.

5. Trap two: the warehouse's model endpoint name is a different surface than the model

The embedding model went GA on the ML platform in April. As of docs updated at the end of
July, the warehouse's remote-model endpoint list still named it with a -preview
suffix.

These are two independent surfaces and the warehouse's lags. A wrong endpoint string
doesn't degrade — it fails outright at CREATE MODEL, which is at least honest, but it
will burn an afternoon if you're confident the model is GA and therefore assume the
endpoint string matches.

Do this before you build anything on top of it:

CREATE OR REPLACE MODEL `ds.embed_model`
  REMOTE WITH CONNECTION `proj.region.conn`
  OPTIONS (ENDPOINT = 'model-name');          -- rejected? try 'model-name-preview'

Then put whichever one worked in config and never infer it again. Related gotcha from the
same family: a globally-available model can expand to a multi-region path that conflicts
with your dataset's region. That reads like an IAM error and isn't one.

6. Trap three: mutating DML doesn't queue past its limit — it fails

This is the most portable idea in the post, and it applies to anyone doing
fire-and-forget background writes into a warehouse.

Everyone knows the old per-day DML quota is gone. Here's what replaced it:

Operation	Concurrency	Queue	Past the queue
`UPDATE` / `DELETE` / `MERGE`	2 per table	up to 20	jobs FAIL
`INSERT`	10 (after the first 1,500/table/24h run immediately)	up to 100	queued

Our ingestion is background tasks fanned out across many tenants. A large batch plus a
concurrent reconcile sweep can plausibly stack more than 20 MERGEs on one table — and
those don't wait their turn, they error. Recently-written rows aren't reliably mutable
either.

So we removed mutating DML entirely. Append-only writes, plus a dedup view:

CREATE OR REPLACE VIEW v_chunk AS
SELECT * FROM chunk
QUALIFY ROW_NUMBER() OVER (PARTITION BY chunk_id ORDER BY ingested_at DESC) = 1;

Re-ingesting appends a newer generation. The view returns only the newest. Every reader
gets MERGE semantics with zero mutating DML — the upsert logic didn't move into the
application, it moved into the read path, where the warehouse is happy to do it.

Two things this pattern quietly buys you:

Load jobs instead of DML. They're free, they have no streaming-buffer semantics, and their few-second latency is irrelevant on an async path.
A free work queue. Embeddings fill via INSERT … SELECT over chunks that have no embedding row yet. Rows whose embedding call failed are simply absent, so the next sweep retries them. The NOT EXISTS join is the retry bookkeeping. There is no other retry bookkeeping.

One ordering rule, learned the hard way: load jobs are not transactional across tables, so
write your commit-marker table last. If the "this document is ingested" row lands
first and a later load fails, that document is permanently marked done with zero chunks —
never retried, never retrievable, and invisible to your gap metrics. Write it last and a
partial failure leaves no marker, so the sweep retries and the system converges. Orphan
rows from the failed attempt are harmless; the retry's newer generation supersedes them
through the same view.

7. Trap four: your embedding dimension is a cost decision, not a quality decision

The default output is 3072 dimensions. We use 768. That's not a quality compromise we
grudgingly accepted — it's the single biggest cost lever in the design.

In a warehouse, the vector dominates the row:

3072 dims → ~24 KB per chunk → a 5,000-chunk tenant scans ~120 MB per query
768 dims → ~6 KB per chunk → the same tenant scans ~30 MB per query

4× on every single query, forever. And modern embedding models are trained with
Matryoshka Representation Learning, so truncated outputs are automatically normalised —
768 is a recommended size, not a hack. You trade a little quality for four times the
throughput per dollar on the hot path.

Two companions to it:

Cluster on your tenant key. Every read is tenant-scoped; without clustering, each
query scans every vector in the table. This is the difference between scanning one
tenant's data and scanning everyone's, and it's one line of DDL.

Skip the vector index on purpose. It sounds like the obvious optimisation and it's a
trap here: a vector index requires a materialised table and forces you back into
post-filtering by tenant — which is exactly the starvation pattern from section 1,
faithfully reimplemented in a new database. Brute force below a few thousand rows per
tenant is fast, cheap and, more importantly, correct by construction.

Note also: two independent embedding stacks don't need to agree with each other. Vectors
from different stores are never compared as geometry — results are combined as text. The
only invariant that matters is internal consistency within one stack.

8. What we haven't decided — and the bar we set in advance

Here's where I stop claiming a win.

Ending the duplicate stack has exactly two coherent end-states, and they're mutually
exclusive:

Path A — keep the managed RAG service, share its embeddings. Point the corpus at a
feature-store backend that writes chunks and embeddings into a table you own. The service
chunks and embeds once; the graph reads those rows and adds only the entity layer. Our own
embedding fill disappears. Reranking, grounded generation and corpus lifecycle all survive
untouched.

Path B — remove the managed service, warehouse only. One stack, so no duplication by
construction. The ingestion service drops its import step and gets strictly simpler.
Corpus lifecycle code is deleted, not replaced. Grounded generation becomes
retrieve-then-generate at three call sites. And reranking has to be rebuilt — an LLM
reranker over the top-N candidates, temperature 0, falling back to score order on any
failure.

They can't be combined, because the feature-store option is the managed service.

We wrote the decision criteria down before collecting data, which is the only way this
isn't rationalisation:

Metric	Why it decides the fork
Graph-hit rate	If retrieval rarely hits, Path B isn't viable at all
Results per hit	The old path starves to 1–3. This is the axis pre-filtering should win on
Answer quality, new vs fallback	The only thing that actually matters
Retrieval latency	The warehouse has a 0.5–2s floor; the managed call is faster
Bytes scanned per query	Validates the clustering claim, which is currently asserted and unmeasured

Path B is viable if hit rate is high, results-per-hit meaningfully beats the old path, and answer quality is at least equal.
Path A wins if hits are inconsistent or quality drops — because then reranking and managed retrieval are carrying weight we didn't replace.
Neither if the hit rate is low enough that the graph isn't earning its keep. In which case the honest move is deleting the graph outright, which is strictly cheaper than either migration.

That third option is the one I'd encourage you to keep on your own table. Every call site
in our system already degrades gracefully to the fallback — which means "turn the flag off
and delete 800 lines" was always available, and measuring first would have been cheaper
than either migration. We're doing the measurement after the build. Do it before.

The five-line version

Post-filtering starves multi-tenant retrieval. Filter before top-k, not after.
One hop is a join. Grep for variable-length patterns before you pay for a graph database.
Deprecated parameters that are silently ignored are worse than ones that error.
Append-only + a dedup view gives you MERGE semantics with zero mutating DML.
Write the decision criteria down before the data arrives. Otherwise you'll find the data agrees with whatever you already built.

If you've run RAG on a warehouse in production — especially the latency floor on
interactive paths — I'd genuinely like to hear how it went.

I deleted the smartest feature in my download manager

Suryansh Chaudhary — Thu, 30 Jul 2026 09:23:41 +0000

In 1.3, I deleted half of it. The half I was proudest of.

The feature

Downloads opened at 4 connections. Every 3 seconds the engine added one more,
measured aggregate throughput, and kept the new connection only if throughput
improved by at least 15%. Otherwise it dropped back and stopped climbing.

Read that back. It sounds like the responsible thing to do. It measures instead
of assuming. It has a control loop. It even has a tunable threshold.

The bug

"Throughput didn't improve by 15%" has two completely different causes, and the
probe couldn't tell them apart:

The host is refusing to serve more connections. → Stop climbing. Correct.
Your link is already saturated. → Also stop climbing. Catastrophically wrong.

On a 100 Mbit connection pulling from a fast CDN, four connections will happily
saturate the pipe. Connection five adds nothing measurable — not because the
server refused it, but because there's no headroom left to measure it with.
The probe reads a flat line and concludes the ceiling is 4.

Then the link frees up. Another download finishes, the VPN reconnects, whatever.
Now there is headroom — and the probe already stopped climbing. It settled low
precisely in the case where extra connections were free.

The heuristic's failure mode was invisible because it never errored. It just
quietly returned a smaller number than it should have, forever, and every
download looked "fine."

The fix: back off on evidence, not on absence of evidence

A download now opens at its full effective thread count immediately, staggered
100 ms apart so a burst of SYNs doesn't trip anti-abuse middleboxes. No ramp, no
probe.

Backing off is still there, but it now requires a positive signal instead of a
missing one. DemotionPolicy halves the worker count when:

4 chunk attempts fail without progress
inside a 10-second window
and bytes are still flowing on the other connections

That last condition is the whole fix. It's what separates a hostile host —
refusing some connections while happily serving the rest — from a dead local
link, where everything fails at once because your Wi-Fi dropped.

Without it, a 3-second network blip wrote a permanent per-host cap against a
server that had done nothing wrong. Learned caps now also expire after 7 days and
are clearable from Settings, so a cap mislearned during an outage heals itself.

The lesson I keep re-learning: a control loop that treats "I measured nothing"
as "there is nothing" will always fail toward doing less. If your only feedback
signal is absence, you don't have feedback.

Endgame chunk splitting

Related tail problem. MacGet slices range-capable downloads into more pieces than
workers (8 MB target, up to 256 pieces), so a finished worker steals the next
outstanding piece instead of idling.

That works right up until every piece is assigned. Then the freed workers have
nothing to steal, and the download waits on whichever single piece landed on the
slowest path.

So now, when there's nothing left to steal, a freed worker splits the largest
in-flight piece in half and takes the back half — BitTorrent's endgame mode,
basically, applied to HTTP ranges. Floored at 1 MB so you don't spend a fresh TCP
handshake and an HTTP round trip on a 40 KB scrap.

SlotFiller.next(...) →
  .steal(piece)   // an outstanding piece exists
  .split(piece)   // nothing outstanding: halve the largest in-flight one
  .none           // everything is too small to bother splitting

The last slow chunk no longer sets the finish time.

Book catalogs, and three APIs that didn't work

1.3 also adds a catalog browser (⇧⌘B): search a book catalog, pick a format, it
goes to the download queue like any other URL. The interesting part was that the
obvious integration path was wrong for all three sources — and I only found out
by hitting the live services.

Project Gutenberg. It publishes OPDS, so: use OPDS, right? Its search feed
returns navigation entries — one sub-feed per result — so rendering a 50-book
grid with download links would cost 50 extra requests. Those per-book feeds were
also returning 504s, and the OPDS 2.0 endpoint is a 404. Gutendex returns every
format's direct URL inline, so that's what the grid uses.

Internet Archive. IA's OPDS BookServer doesn't just return errors —
bookserver.archive.org no longer resolves at all. Replaced with
advancedsearch.php?output=json for browse plus metadata/<id>/files for the
per-item file list, fetched lazily on selection.

Standard Ebooks. Every OPDS feed returns 401 to anonymous clients; access is a
donor benefit. It ships as a built-in source that's disabled by default, which
forced a small design point: CatalogStore has to track both explicitly-enabled
and explicitly-disabled built-ins, so a shipped default can apply until the user
actually expresses a preference.

Everything still normalizes into one CatalogFeed model, so the UI never branches
on source. And AcquisitionLink.isDownloadable is a single gate — direct-download
rel, no price, http(s), known format. DRM fulfilment documents get parsed and
displayed but never fetched, because that href is a license token, not a book.
Archive.org lists LCP Encrypted EPUB right next to the free files.

One more: catalog requests use a different URLSession than downloads do. The
download session sets waitsForConnectivity = true and
timeoutIntervalForResource = .infinity, which is exactly right for a 6 GB file
and exactly wrong for a metadata fetch behind a spinner.

BitTorrent

Magnets and .torrent files now run through the same queue as everything else —
same concurrency limit, same pause/resume, same quiet hours. It's off by default
and asks once before enabling, because unlike every other download type it
uploads on your connection and puts your IP in front of a swarm.

Two things worth stealing if you ever wrap aria2:

MacGet owns the queue, aria2 doesn't. --save-session and --input-file are
deliberately absent. queue.json is the source of truth and MacGet re-adds
torrents itself on launch; if aria2 also restored its own session, every info hash
would be registered twice and aria2 fails the duplicate outright. Resume comes
from --continue=true plus the .aria2 control file.

Magnets have a metadata phase that looks exactly like success. The first GID
downloads only the metainfo — a few hundred KB — and then reports complete with
completedLength == totalLength. Indistinguishable from a finished download
unless you're looking for it. An isAwaitingMetadata flag suppresses completion
and byte reporting until followedBy hands off to the real GID. Get it wrong and
your 6 GB torrent shows "Completed" at 500 KB.

Also: bind ports as a range (6881-6890), not a single value. aria2 hard-fails
with "Errors occurred while binding port" the moment another client holds it.

Install

brew install --cask suryansh-codes2209/macget/macget

Or grab the DMG: https://macget.suryansh.work

MIT licensed, and the engine is genuinely fun to poke at — clone it, open
Macget.xcodeproj, ⌘R. No package manager step, no codegen:
https://github.com/Suryansh-Codes2209/Macget

Issues and PRs welcome. I'm especially interested in ideas for what belongs in a
download manager in 2026 — if you've got a feature you've always wanted and never
found, open an issue.

And if you've ever shipped a heuristic that looked smart and was quietly costing
you something, I'd like to hear about it. I clearly can't be trusted to spot my
own.

Why more download threads make your downloads slower (and how I fixed it)

Suryansh Chaudhary — Mon, 29 Jun 2026 07:07:16 +0000

There's a myth baked into almost every "download accelerator": open more connections, download faster. It's intuitive, and it's wrong for most of the modern web.

I learned this the hard way building MacGet, a free, open-source, native macOS download manager — and the fix turned into the most interesting part of the project.

The problem: parallelism looks like an attack

When you split a file into N chunks and open N HTTP-Range connections at once, a naive downloader assumes the server will happily serve all of them. Modern CDNs don't. To them, one IP suddenly opening 16 connections and pulling ranges looks exactly like leech/abuse behavior. So they fight back:

TCP-RST your connections after a few bytes
throttle your IP for a while
403 new requests outright

The result is counterintuitive: crank the thread count up and your download gets slower, or fails entirely. More threads ≠ more speed.

The fix: discover each host's real capacity at runtime

Instead of trusting a fixed thread count, MacGet's engine treats parallelism as something to discover per host:

Adaptive up-scaling. Downloads start at 4 connections and probe upward one at a time, keeping each added connection only when aggregate throughput improves by ≥15%. So it climbs toward the host's real ceiling instead of guessing.
Demotion on rejection. When ≥4 chunk attempts fail without making progress inside a 10-second window the signal that the host is rejecting parallelism the engine halves its worker count, cancels the lowest-progress chunks, and carries on. It repeats until it stabilizes at a level the host actually allows.
Per-host memory. That learned cap is persisted (host_caps.json). The next download from the same host starts at the right level — no rediscovery tax. Caps only ratchet downward.
Staggered spawns. Workers start ~100ms apart, so anti-abuse middleboxes see a steady ramp instead of a SYN burst from one IP.
Smart retry classification. Permanent failures (401/403/404/410/451, range refusals, malformed responses) fail fast. Transient ones (mid-stream RSTs, server-side stream kills, 5xx) retry with full-jitter exponential backoff under a hard cap — and 429/503 honor the server's Retry-After.

There's also a macOS-specific gotcha: App Nap. If you switch apps, macOS will happily throttle your "background" download into the ground. MacGet holds a ProcessInfo activity assertion while any download runs, so the OS leaves it alone.

Killing the slow-chunk tail

Even when a host allows N connections, fixed N-way chunking has a long tail: split a file into N equal pieces and the whole download waits on whichever piece landed on the slowest path. MacGet slices range-capable downloads into more pieces than workers (8 MB target), and a finished worker immediately steals the next
outstanding piece. No worker sits idle while another grinds through the tail.

How it's built

The engine is modeled with Swift's actor concurrency, which made the
correctness story dramatically easier than locks-and-queues would have:

DownloadEngine (actor)
  └─ DownloadCoordinator (actor)   // one per download: probe → plan → stream → finalize
       ├─ ChunkWorker              // one HTTP-Range request, streamed via AsyncThrowingStream
       └─ FileWriter (actor)       // serializes positional writes so chunks don't race

A few more design notes:

Probe first. A HEAD request (falling back to GET Range: bytes=0-0, since some servers 405 on HEAD) establishes size, Accept-Ranges, ETag, and Last-Modified.
HTTP/3 when offered. Requests opt into QUIC via assumesHTTP3Capable, with graceful fallback to HTTP/2 → HTTP/1.1.
Integrity at finalize. SHA-256 / MD5 is verified before the partial is promoted to the final filename; a mismatch fails the download and keeps the partial instead of handing you a corrupt file.
Sparse partials. The partial file is truncated to full size up front; APFS keeps it sparse until bytes actually land.
Resumable across restarts. Per-chunk byte offsets are persisted, and workers send the recorded ETag/Last-Modified as If-Range so a file that changed server-side fails fast instead of silently corrupting your partial.
Survives a dropped connection. An NWPathMonitor pauses active downloads on network loss ("Waiting for network…") and auto-resumes when it's back, instead of burning retries through an outage.
Live speed/ETA. A 3-second rolling window over (time, bytes) samples; ETA goes nil below 1 KB/s instead of lying to you.

The whole thing is SwiftUI on top, with @Observable view models draining an AsyncStream of engine events — the UI never mutates download state directly, only through the engine actor.

Beyond the engine

The latest release (1.2) builds a real download manager around that core:

Video & audio downloads. A conservative host classifier routes known video/audio sites to a bundled yt-dlp + ffmpeg extractor (with a quality/format picker); ordinary links still download as plain HTTP through the engine above.
Authenticated downloads. A Keychain-backed credential store answers Basic/Digest/NTLM challenges and remembers them per host across launches.
A browser extension (Chrome/Edge/Brave/Firefox) that hands off downloads you start in the browser — carrying the cookies, referrer, and user-agent — so logged-in downloads actually work.
Auto-sort finished files into category folders, High/Normal/Low priorities, bandwidth throttling, and signed auto-updates via Sparkle (EdDSA-verified — a tampered update is rejected).

Try it

Just want to use it? Download the DMG: https://suryansh.work/macget (free, un-notarized — right-click → Open on first launch for the one-time Gatekeeper step).
Want to read or hack the code? It's MIT licensed and the engine is genuinely fun to poke at: https://github.com/Suryansh-Codes2209/Macget — clone, open Macget.xcodeproj, ⌘R. No setup.

Unleashing the Power of Django on AWS: Best Practices for Seamless Deployment!

Suryansh Chaudhary — Tue, 30 Jan 2024 04:48:26 +0000

Hey Dev Community! 💻 Excited to share some golden nuggets on deploying Django web apps on AWS. Let's make your deployment journey smoother with these best practices:
**
**AWS App Runner Magic: Dive into the simplicity of deploying and scaling Django apps on AWS App Runner. Check out this AWS blog for a quick guide.

Elastic Beanstalk Brilliance: Discover the art of deploying Django apps on Elastic Beanstalk with AWS's official guide here. It's like a magic wand for streamlined deployment.

Kubernetes Mastery: Elevate your Django deployment game by containerizing with Kubernetes. Explore the scalability and security in this DigitalOcean tutorial.

PostgreSQL Power: Level up your Django app by integrating PostgreSQL on AWS Elastic Beanstalk. Learn the ropes in this insightful Real Python tutorial.

Remember, the key to a successful deployment is a mix of AWS services tailored to your app's needs. Keep it efficient, keep it scalable! 🔗✨

Django #AWS #DevOps #DeploymentMastery

AWS Elastic Beanstalk: ⚡Simplifying Web Application Deployment and Scaling

Suryansh Chaudhary — Mon, 15 Jan 2024 11:34:02 +0000

AWS Elastic Beanstalk is a fully managed service that streamlines the deployment and scaling of web applications.

Easy Deployment: Simply upload your code, and Elastic Beanstalk takes care of the deployment process. It eliminates the need for manual intervention in tasks like capacity provisioning and configuration.

Automatic Scaling: Elastic Beanstalk dynamically scales your application based on demand. It leverages Auto Scaling, ensuring that your application can handle varying traffic loads efficiently.

Load Balancing: The service includes Elastic Load Balancing, distributing incoming traffic across multiple instances to enhance application availability and fault tolerance.

Health Monitoring: Elastic Beanstalk continuously monitors the health of your application. It automatically replaces unhealthy instances, ensuring high availability and reliability.

Traffic-Splitting Deployments: With features like traffic-splitting deployments, Elastic Beanstalk minimizes downtime by creating a new set of instances for updates while preserving the existing environment.

In summary, AWS Elastic Beanstalk abstracts the complexities of infrastructure management, allowing developers to focus on building robust applications without worrying about the intricacies of deployment, scaling, and monitoring.

Launching 🚀Your AWS Application Journey with EC2: A Student's Guide⚡

Suryansh Chaudhary — Mon, 15 Jan 2024 11:13:24 +0000

Are you a student eager to embark on your AWS application journey? Start by mastering Amazon EC2, a fundamental service that provides virtual machines in the cloud. Here's a step-by-step guide to kickstart your production-making adventure:

Set Up Your AWS Account:
Begin by creating an AWS account. Follow the official guide to ensure a seamless setup.

Launch Your First EC2 Instance:
Learn the basics of launching an EC2 instance with this tutorial. Choose an Amazon Machine Image (AMI), select an instance type, and configure your settings.

Understand Virtual Machines:
Delve into the world of virtualization. Understand how EC2 instances function as virtual machines, providing scalable computing power for your applications.

Explore CodeDeploy for Deployments:
Familiarize yourself with CodeDeploy, a service that automates application deployments. Follow this guide for deployments on EC2.

Enhance Security with Security Groups:
Master the art of managing security groups to secure your EC2 instances. Follow best practices outlined in the official documentation.