Morocco developer turns project work into backend training

Anass, a graphic designer from Morocco, introduced himself to the DEV Community as a software developer building real projects across web and backend stacks.

He centers his learning on JavaScript, TypeScript, Next.js, Go, Spring Boot and Rust. That mix gives him two useful angles: product speed on the frontend and stricter thinking on services, APIs and data flow.

A project-first path gives a developer feedback that tutorials cannot provide. You learn where a Next.js route should stop, where a Go service should own business rules, and where a database transaction should protect state. You also learn the cost of choices that look small at the start.

A real backend project forces three questions early. The first: who owns each piece of data? The second: which reads need fresh data, and which reads can tolerate delay? The third: how should clients call the system without knowing too much about internal code?

Those questions lead straight into consistency models. A small app can start with one database and strong consistency for account data, orders or permissions. A larger app may use caches, queues or replicas, which means users may see stale reads for activity feeds, analytics or notifications. A developer should choose that trade-off on purpose.

API design brings another set of constraints. REST works well for resource-based workflows, such as users, posts and comments. RPC fits command-heavy services, such as payment capture or image processing. GraphQL can help clients fetch shaped data, though the server team must control query cost and authorization checks.

Go gives Anass a strong base for network services because it keeps concurrency and deployment concerns close to the code. Spring Boot gives him exposure to mature enterprise patterns, dependency injection and broad Java ecosystems. Rust teaches ownership and memory safety, which sharpens how a developer thinks about resources, failure and boundaries.

The trade-off comes from spread. A developer who studies five stacks at once can lose depth. Anass can manage that risk by assigning each stack a job: Next.js for full-stack product work, Go for APIs, Spring Boot for enterprise architecture and Rust for systems concepts.

The next step should involve one complete app with production-shaped constraints. A useful version would include authentication, role-based access, a PostgreSQL schema, background jobs, structured logs, tests and deployment. Add one cache only after slow queries appear. Add a queue only after a request path needs work outside the response cycle.

That sequence builds judgment. You see latency in traces, discover bad indexes through query plans and learn why idempotency matters after a retry creates duplicate work. You also learn that system design starts with user actions, data ownership and failure cases before diagrams.

Sloan, a DEV moderator, welcomed Anass and pointed new writers to DEV’s posting guidance. Community feedback can help here if Anass shares concrete project notes: a schema decision, an API draft, a failed deployment or a benchmark result. Experienced developers can respond to code and constraints with useful advice.

For developers following a similar path, the strongest portfolio piece will show decisions. Describe the API contract. Explain the database indexes. Name the consistency choice. Show how the service handles retries, timeouts and bad input.

A learning post can become more than an introduction when the author brings readers into the build. Anass has the right raw material: design experience, product curiosity and a backend stack that exposes real trade-offs.