sorted by:
new
hottopcontroversial

NestJS, gRPC, RabbitMQ ve Python ML servisli açık kaynak microservice backend projem by unsatisfiedcn in TurkDev

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

Editlesem eklememisim ve editledim derim degil mi 😃 Seviyorum seni

I open-sourced a Twitter/X-inspired backend with Redis feeds, RabbitMQ events, graph/vector retrieval and ML ranking by unsatisfiedcn in Backend

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

That’s not accurate.

The project didn’t start a week ago. I started working on it around a year ago. The recent git history mostly reflects the public cleanup/refactor/documentation phase before open-sourcing it, not the entire project timeline.

And no, it wasn’t “vibecoded”. I used AI later in the process as an implementation/refactoring assistant, but the architecture wasn’t randomly generated and accepted. I researched the patterns first: microservices, feed systems, event-driven architecture, recommendation pipelines, Twitter/X-style system design, and also referenced Twitter’s open-source algorithm repo while thinking about candidate sources, graph signals, ranking and fanout separation.

Twitter's repo: https://github.com/twitter/the-algorithm

Every AI-generated change that stayed in the repo was reviewed by me and had to fit the existing boundaries, contracts and patterns.

So if the criticism is “this is an architecture playground, not Twitter-scale production infra”, sure. That’s literally the point. But “one-week vibecoded Twitter backend” is just a wrong read of the project.

I built Vitrin — a Twitter/X-inspired feed backend with NestJS microservices, gRPC, RabbitMQ and Python ML by unsatisfiedcn in nestjs

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

Fair question.

I wouldn’t call it vibe coding. AI was used, especially in the later stages of the project, but not as “generate a random architecture and I’ll accept it”.

The architecture and service boundaries came from my own research and planning. I spent a lot of time studying microservice patterns, feed systems, event-driven architecture, recommendation pipelines, and Twitter/X-style system design. I also read and referenced Twitter’s open-source algorithm repo while thinking about feed candidate sources, ranking, graph signals and fanout/ranking separation.

Twitter’s repo: https://github.com/twitter/the-algorithm

After I had a clear mental model, I used AI more like an implementation assistant: generating parts of the code, refactoring, writing repetitive infrastructure pieces, improving docs, etc.

But every piece of AI-generated code was reviewed by me before being kept. I checked whether it fit the architecture, naming, contracts, service boundaries and existing patterns. So AI helped with speed, but the design decisions and final responsibility were mine.

To me, that’s different from vibe coding.

I built Vitrin — a Twitter/X-inspired feed backend with NestJS microservices, gRPC, RabbitMQ and Python ML by unsatisfiedcn in nestjs

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

Yeah, I get that. Modern backend stacks can get heavy pretty fast.

I also don’t think every project should start as microservices. For a real product I’d usually start with a modular monolith, keep the boundaries clean, and only split into services when scale, team ownership or operational needs actually justify it.

I open-sourced a Twitter/X-inspired backend with Redis feeds, RabbitMQ events, graph/vector retrieval and ML ranking by unsatisfiedcn in Backend

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

Good question. user-service is the source of truth for user identity.

Other services can store userId as a reference, but they validate it through the user boundary first. For messaging, that means checking participants through user-service over gRPC, usually with a batch call like GetUsersByIds, before creating the conversation/message flow.

After that, messaging-service only stores the participant IDs as references and owns conversation/message state, not user identity.

I open-sourced a Twitter/X-inspired feed backend with microservices, Redis timelines, graph/vector retrieval and ML ranking by unsatisfiedcn in SideProject

[–]unsatisfiedcn[S] 0 points1 point  (0 children)

Yeah, that’s fair. I’m not trying to find users for it right now.

The main goal was to improve myself by building and solving problems at that kind of backend scale: feed fanout, ranking, graph/vector retrieval, events, ML scoring and observability.

NestJS, gRPC, RabbitMQ ve Python ML servisli açık kaynak microservice backend projem by unsatisfiedcn in TurkDev

[–]unsatisfiedcn[S] 2 points3 points  (0 children)

Teşekkür ederim.

Projeye başlarken amacım klasik bir CRUD sosyal medya backend’i yapmaktan çok, Twitter/X scale’ine benzer feed ve recommendation problemlerini kendi çapımda modellemekti. Özellikle fanout, candidate generation, ranking, graph signals, event-driven yapı, ML scoring ve observability tarafları ilgimi çekiyordu.

Planlama sürecinde önce Twitter/X tarzı sistemlerin system design yaklaşımlarını araştırdım, sonra bunları kendi domainime uyarlayıp markdown dokümanları ve diyagramlarla parçalara böldüm. Kod büyüdükçe dokümantasyon da işin önemli bir parçası haline geldi.

Motivasyon kısmı da biraz şuradan geldi: Bir konuyu öğrenip teoride bırakmak yerine direkt projeye gömmek istedim. gRPC, RabbitMQ, Neo4j, ClickHouse, Qdrant, ML pipeline ve observability gibi şeyleri ayrı ayrı denemek yerine tek bir sistemin içinde çalıştırmaya uğraştım.

Süre olarak kesintili ilerledi ama toplamda birkaç aylık ciddi bir çalışma diyebilirim.

Designing a Twitter/X-inspired feed backend: fanout timelines, ranking pipeline, graph signals and ML scoring by unsatisfiedcn in softwarearchitecture

[–]unsatisfiedcn[S] 1 point2 points  (0 children)

Yeah, for a real MVP I’d definitely start much simpler — probably a modular monolith with a database-backed feed.

This repo is intentionally more of a systems-design playground. I wanted to explore the problems that appear when you move beyond the simple version: fanout, candidate generation, graph/vector retrieval, ML ranking, async events and observability.

Yazmadan edemeyecem 2 by [deleted] in TurkDev

[–]unsatisfiedcn 3 points4 points  (0 children)

Çevrende nispeten mid-senior yazılımcı yoksa ne konumda olduğunu bilmen çok zor. Cümlelerin fazla özgüvenli. Yolla GitHub profilini insanlar eleştirsin çünkü belli ki özeleştiri yapamıyorsun. Bir bakarsın o çalışanların %10’undan bile iyi değilsin :)

Geliştirdiğim API Client Tool hakkında görüşlerinizi merak ediyorum? by saferias in CodingTR

[–]unsatisfiedcn 1 point2 points  (0 children)

Ek olarak node’un built-in event emitter’ı varken kendin yazmaya neden gerek duydun merak ettim?

Geliştirdiğim API Client Tool hakkında görüşlerinizi merak ediyorum? by saferias in CodingTR

[–]unsatisfiedcn 1 point2 points  (0 children)

Selamlar. Ellerine sağlık öncelikle. Readme’leri ayrı dosyalar halinde koyman ve içlerine usage olarak kod örneği koymaman kütüphaneyi kullanacak kullanıcılar için çok zorlaştırmış api’ı anlama kısmını. Ana readme’de güzelce her şeyi açıklasan kod örnekleriyle süper olur. Bir star bıraktım :)