Home SOFTWAREPomoć i savetiArhitektura modernih web aplikacija – Deo 1: Uvod u arhitekturu web aplikacija – od monolita do mikroservisa

Arhitektura modernih web aplikacija – Deo 1: Uvod u arhitekturu web aplikacija – od monolita do mikroservisa

od Saša Ristić
Arhitektura modernih web aplikacija

Dobrodošli u prvi deo serijala „Arhitektura modernih web aplikacija“ na ITNetwork.rs! U ovom uvodnom tekstu ćemo postaviti čvrste temelje – razumećemo šta je arhitektura softvera, kako se razvijala kroz vreme, i uporediti tri ključna pristupa: monolit, SOA (Service-Oriented Architecture) i mikroservise. Na kraju ćemo videti praktičan primer monolitne aplikacije u Node.js + Express-u.

Šta je arhitektura softvera?

Arhitektura softvera je visokonivojski dizajn sistema – način na koji organizujemo komponente aplikacije, njihove međusobne veze i principe koji upravljaju njihovim ponašanjem.

„Arhitektura je ono što ostaje kada uklonite sav kod.“ – Grady Booch

Dobra arhitektura omogućava:

  • Skalabilnost – rast sistema sa opterećenjem
  • Održivost – lako dodavanje novih funkcionalnosti
  • Performanse – brzi odgovori korisnicima
  • Otpornost – oporavak od grešaka
  • Timsku produktivnost – više timova rade paralelno

Evolucija arhitekture web aplikacija (1995–2025)

Godina Pristup Ključne karakteristike
1995–2005 Monolit Cela aplikacija u jednom deploy-u (PHP, ASP, Java Servleti)
2005–2015 SOA / ESB Servisi komuniciraju preko centralnog bus-a
2010–danas Mikroservisi Nezavisni servisi, polyglot, cloud-native
2020–danas Serverless / Edge Funkcije po pozivu, izvršavanje na ivici mreže
1. Monolitna arhitektura

Definicija

Cela aplikacija je jedan izvršni fajl ili jedan deploy paket:

  • UI + logika + baza = jedan kodni repozitorijum
  • Primeri: WordPress, klasični Laravel/PHP projekti, Spring Boot aplikacije

Prednosti

+ Objašnjenje
Jednostavan razvoj Sve je na jednom mestu
Lako debugovanje Jedan proces, jedan log
Brzi lokalni razvoj npm start i gotovo
Jednostavan deployment Jedan fajl na server
Mane
– Objašnjenje
Teško skaliranje Ceo sistem se skalira zajedno
Dugotrajni buildovi Promena jedne linije → rebuild svega
Tehnološki lock-in Menjaš jezik → pišeš sve iz početka
Rizik od „spaghetti“ koda Sve je povezano
Kada koristiti?
  • Startup u ranoj fazi (MVP)
  • Mali tim (1–3 developera)
  • Projekat sa ograničenim opsegom

2. SOA (Service-Oriented Architecture)

Definicija

Aplikacija je podeljena na servise koji komuniciraju preko standardizovanih protokola (SOAP, XML-RPC, kasnije REST).

Centralni ESB (Enterprise Service Bus) upravlja rutiranjem, transformacijom i orkestracijom.

Prednosti

  • Ponovna upotreba servisa
  • Jasnije granice između domena
  • Lakše održavanje velikih sistema

Mane

  • Kompleksnost ESB-a („magija u kutiji“)
  • Performansni overhead
  • Teško praćenje grešaka kroz lance poziva

SOA je bila korak napred, ali je često postala „distribuirani monolit“.

3. Mikroservisna arhitektura

Definicija

Aplikacija je podeljena na male, nezavisne servise, gde svaki:

  • Ima svoju bazu podataka
  • Deploy-uje se samostalno
  • Komunicira preko laganih protokola (HTTP, gRPC, message queues)
  • Vlasništvo ima jedan tim („You build it, you run it“ – Amazon)

Prednosti

+ Objašnjenje
Nezavisno skaliranje Samo servis pod opterećenjem se skalira
Tehnološka sloboda JS, Python, Go, Rust – po servisu
Brži release ciklus Deploy 10 puta dnevno
Otpornost Pad jednog servisa ne ruši sve
Mane
– Objašnjenje
Distribuirana kompleksnost Mrežni pozivi, latency, failover
Upravljanje podacima Nema globalnih transakcija
Operativni overhead Više servera, logova, monitoringa
Potreban DevOps Bez automatizacije – haos
Kada koristiti?
  • Veliki timovi (>6 developera)
  • Kompleksni domeni (e-commerce, fintech)
  • Potreba za brzim eksperimentisanjem

Poređenje: Monolit vs. SOA vs. Mikroservisi

Kriterijum Monolit SOA Mikroservisi
Veličina tima Mali Srednji Veliki
Brzina razvoja (početak) ★★★★★ ★★★ ★★
Skalabilnost ★★ ★★★ ★★★★★
Kompleksnost ★ ★★★★ ★★★★★
Deployment Jedan klik Više klikova Automatizacija obavezna
Primer kompanije Startup.rs Banka 2008 Netflix, Uber, Shopify
Praktičan primer: Monolitna aplikacija u Node.js + Express

Napravimo jednostavnu TODO aplikaciju kao monolit.

Struktura projekta

todo-monolith/
├── server.js
├── package.json
├── db.js
└── routes/
    └── todos.js

1. package.json

{
  "name": "todo-monolith",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "body-parser": "^1.20.2"
  }
}

2. db.js – In-memory baza

// db.js
let todos = [
  { id: 1, title: "Kupi mleko", completed: false },
  { id: 2, title: "Nauči mikroservise", completed: true }
];

let nextId = 3;

module.exports = { todos, nextId };

3. routes/todos.js

// routes/todos.js
const express = require('express');
const router = express.Router();
const db = require('../db');

router.get('/', (req, res) => {
  res.json(db.todos);
});

router.post('/', (req, res) => {
  const { title } = req.body;
  if (!title) return res.status(400).json({ error: 'Title required' });

  const todo = {
    id: db.nextId++,
    title,
    completed: false
  };
  db.todos.push(todo);
  res.status(201).json(todo);
});

module.exports = router;

4. server.js

// server.js
const express = require('express');
const bodyParser = require('body-parser');
const todoRoutes = require('./routes/todos');

const app = express();
const PORT = 3000;

app.use(bodyParser.json());
app.use('/api/todos', todoRoutes);

app.get('/', (req, res) => {
  res.send('<h1>TODO Monolit API</h1><p>POST /api/todos → kreiraj</p>');
});

app.listen(PORT, () => {
  console.log(`Monolit radi na http://localhost:${PORT}`);
});

Pokretanje

npm install
npm start

Testiranje (cURL)

# Dohvati sve
curl http://localhost:3000/api/todos

# Kreiraj novi
curl -X POST http://localhost:3000/api/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Pročitaj ITNetwork serijal"}'

Sve je u jednom procesu. Jedna greška = pad celog sistema.

Dijagram: Monolitna arhitektura

monolitna arhitekturaCelokupna logika je u jednom procesu. Lako za početak – teško za skaliranje.

Kada krenuti od monolita?

Situacija Preporuka
MVP, 1–2 developera Monolit
10+ funkcionalnosti, 5+ timova Mikroservisi
Enterprise sa legacy sistemima SOA ili postepena migracija

Zlatno pravilo: Počni sa monolitom. Refaktoriši u mikroservise kada osetiš bol.

Šta dalje?

U drugom delu ćemo ući u frontend arhitekturu:

  • SPA vs. SSR vs. SSG
  • React Server Components
  • Next.js App Router

Tvoj izazov

  1. Pokreni gornji primer lokalno
  2. Dodaj PUT /api/todos/:id za ažuriranje
  3. Komentariši ispod: „Da li bi tvoj trenutni projekat bio monolit ili mikroservisi?“

Serijal nastavlja uskoro na ITNetwork.rs Prati nas!

Autor: Dušan Antonijević – saradnik ITNetwork.rs
Hvala na čitanju! Ako ti se svideo tekst – podeli ga sa timom.

Banner

Banner

Možda će vam se svideti i