- Notifications
You must be signed in to change notification settings - Fork0
Modern mainstream web application example
License
mikaelhg/modern-mainstream-web-example
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Dev tools:
- mise-en-placefor installing node, pnpm, the JDK, various command line tools.
Build tools:
- Gradle with a NPM plugin for the backend build and formanaging the frontend build, and mushing the frontend and backend together.
Virtual machines / programming language runtimes:
JDK 25 with ZGCfor running the backend, as well as executing the build.
Programming languages:
Kotlinfor developing the backend. Compiles into JVM class files and a runnable JAR.
TypeScript for the frontend.
Frameworks and libraries:
Spring Bootand Spring Security
React.js,Redux,Redux ToolkitwithVite for developing the frontend.
Bootstrap orTailwindCSSfor presenting the combination of web content and visual user interface,and structuring the collaboration between frontend developers and UI/visual designers.
Other resources:
CoreUIfor a NPM-packaged Bootstrap web interface for administrative user interfaces.
Wrap Bootstrap andThemeforestfor high-level user interface design products, which allow you to spend yourUI budget on features, rather than duplicating standard components and views.
Unsplash for great photographic visual elements.
Operational tools:
Docker andDocker Composefor building production/staging-deployable application containers.
Dexas the OpenID / OAuth2 authentication server, suitable for bothlocal containers and production deployments.
Traefik orCaddy as a reverse HTTP/S proxy andLet's Encrypt free SSL certificate automation manager.
Grafana Loki,Grafana Alloy andVectorfor collecting log events and errors into a searchable and trackable database.
Prometheus for collecting quantitative data related bothto the business logic and the application infrastructure.
OpenTelemetry andJaegerfor distributed enterprise application tracing, where you need transparency intobusiness processes which have been distributed across many separate applications.
Frontend and backend developers should first collaborate in building a functional paperprototype of the minimum viable product, or something equivalent, which allows them tospecify the most elementary aspects of the interface between the backend and the frontend.
After that, the backend developers should create a mock interface with static data pulledfrom JSON / YAML files provided by the frontend developers, while the frontend developerscreate simple browser-based integration tests for accessing the mock backend.
After that, the development will begin in earnest, and iteration can start.
The developers should useIntelliJ IDEA, which has goodsupport for all of the elements used in this example, and can be licensed on a monthly basis.
Developers use Docker on their laptops, which should be relatively beefy, to run the variousinfrastructure components locally.
If you genuinely can't afford the commercial version of IDEA, get the free communityversion of IDEA for backend development, and useVS Codefor frontend development. It's not quite as good as IDEA, but it will do in a pinch.
docker compose up
After you've started the application, you can browse these links:
The ideal way to handle deployment into the shared development environment, or staging,is with an automatic deployment from the CI/CD system, which packages the application intoa Docker container, and executes a Docker Compose command which creates / recreates thewhole set of containers required for the operation of the service.
Assuming that the application is run in the cloud, the CI/CD system should push any releasecontainers (usually as a response of being tagged as releases in Git) into the cloud service'scontainer registry. From there, the operators should use the cloud service's own deploymenttools, if they don't want to use continuous deployment into production.
Your operational infrastructure should enable teams to systematicallyobserve,diagnose, andadapt to issuesbefore they escalate into outagesor user-facing failures.
Instrument comprehensively:
- Capture structured logs, key metrics, and transaction traces in a formatthat contextualizes events (e.g., user IDs, session identifiers, request timelines).
- Aggregate this data into searchable, centralized systems that retain history longenough to investigate recurring patterns.
Automate anomaly detection:
- Define thresholds and heuristics for critical workflows (e.g., API latency spikes,error rate surges, resource exhaustion).
- Trigger alerts only when deviations correlate with user impact, to avoid alert fatigue.
Treat observability as iterative:
- As your application’s logic grows, audit your instrumentation gaps.For example: Do complex multi-service workflows leave breadcrumbs?Can you reconstruct a user’s journey from login to error?
- Prioritize adding context to logs/metrics that repeatedly lack actionable detailsduring post-mortems.
Successful operations depend less on specific tools and more on cultivating aproduction-first mindset – assume failureswill occur, and ensure your team canefficiently gather evidence to explain why.
About
Modern mainstream web application example
Resources
License
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Releases
Uh oh!
There was an error while loading.Please reload this page.
Contributors2
Uh oh!
There was an error while loading.Please reload this page.