Member Avatar for gicio

Build an enterprise application for a customer with aprox. 100 Clients ???

HI!!!

If you would happen to get the chance to build an enterprise application
for a customer with aprox. 100 Clients (and increasing) which technology
and architecture would you choose. The security policy is pretty strong
so we would have actually only port 80 available. Besides that no deployment
effort on client side is desirable. There is a 100Mbit LAN and this new
application would be deployed on the intranet (internal network).
The GUI of this application should be very rich and fast like win32 applications.
What would you propose in order to fulfil those requirements.

It is an enterprise app so inputing data, printing invoices,
packing lists, reporting, etc
Clients are win xp machines It processes data on the server mainly,
the presentation is on the clients Data is stored in a database
100Mbit has to do with the access speed to the backbone resources
from clients.(only port 80)

Any hints, links and ideas will be highly appreciated

Regards,

gicio

  • 3 Contributors
  • 2 Replies
  • 103 Views
  • 4 Months Discussion Span
  • Latest Post Latest Post by Tekmaven

Dani AI

Generated

Brief, practical add-on to the replies from and — a compact architecture checklist and validation plan to turn the idea into a production-quality intranet app.

Start with a browser-first UI that renders most work client-side to get "native feel": deliver compact JSON, render locally, and apply optimistic updates and client-side caches so interactions feel instant. Use a push channel for real-time state (WebSocket with fallback to polling); see the WebSocket API for implementation details (MDN WebSocket). Keep each API call small and predictable to avoid chatty network behavior.

On the server pick a stateless API layer, strong server-side authorization, and background workers for heavy or slow jobs (report generation, batch processing). Emit printable documents from the server as PDFs rather than forcing complex client drivers; server-side PDF generators (for example, wkhtmltopdf) give consistent print output across clients (wkhtmltopdf). Follow server session and token best practices from OWASP to avoid common pitfalls (OWASP Session Management Cheat Sheet).

Operational checklist to validate early:

  • Prototype a single workflow end-to-end and measure 95th-percentile latency.
  • Profile DB queries, add indexes and use pooling; offload long tasks to a queue.
  • Confirm printing from browser-produced PDFs matches layout and fonts on representative machines.
  • Add monitoring, logging, and automated backups before rolling out beyond a pilot group.

Tradeoffs and quick cautions: if some client machines lack modern browser features, either polyfill selectively or accept a tiny signed helper for printing/OS integration. Prioritize server-side enforcement of business rules and security; keep the client disposable.

Recommended Answers

All 2 Replies

Member Avatar for freesoft_2000

Hi Everyone,
Try using rapid-q as your main thread and insert java codes for the functionality of printing with fonts and save individual encrypted files on the disk.
Should be quite cool

Yours Sincerely

Richard West

Member Avatar for Tekmaven

Based on your requirement of only Port 80, Web Services are the prime way to get data back and forth from client and server.

If you make the entire app in a .NET enabled language, such as C#, you'll have killer performance, easy deployment, and the ability to do client/server stuff via port 80 ;).

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.