ARCHITECTURE
How the website is built.
Many client landing pages are static, but a website can also include interactive features, a backend-for-frontend (BFF) layer, backend services, and a database. We choose the architecture around the work the website needs to do. Different parts of the same site can use different approaches.
Read the thinking behind these choicesArchitecture
Choose the architecture around the features.
For landing pages, service pages, and articles whose content can be prepared ahead of time, we usually use Astro static site generation (SSG). Pages are built before a visit and delivered by the hosting network. That describes how those pages are delivered, not the whole website's architecture.
Public pages that need current data may use server-side rendering (SSR). Forms, inquiries, bookings, and customer portals may use browser-side interaction, a service API, or a BFF connected to backend services and a database. These can coexist with static pages; a dynamic feature does not have to be a private application.
One website can combine SSG or SSR pages with interactive interfaces. Where an action needs server-side processing, it calls a service API or BFF connected to backend services, a database, or an external platform.
A static page delivers HTML prepared before the visit. A server-rendered page generates HTML for the request and may read backend data. Both can deliver readable HTML to visitors and crawlers; interactive actions have their own service requests.
Choose the model for the job
We assess page delivery and business features separately: should the content appear in search, how fresh must it be, what actions can visitors take, and which actions need backend processing or saved data? A single website can combine several of the approaches below.
| Website surface | Delivery model | Why it fits |
|---|---|---|
| Marketing pages, articles, and service pages | Astro SSG | Content is prepared in HTML before release. Reading these pages does not require a page-rendering server; other features on the same website can still use backend services. |
| Content pages with forms, search, or bookings | SSG or SSR + service API / BFF as needed | Page delivery and business processing are separate choices. The interface calls an external service or a custom backend; requests are validated and data is stored where needed. |
| Public pages with content that must be fresh on each request | Astro SSR | Consider server rendering when search engines need the changing content in the HTML. This adds a runtime to operate and monitor. |
| Private portals and interactive dashboards | SPA or SSR + backend / BFF + database as needed | Frequent navigation, permissions, and saved business data shape the design. SPA is one option; backend services and data storage are scoped around the actual workflow. |
Choose page delivery, interface behavior, and data processing around their respective needs. They do not have to use the same model across the website.
- Page delivery
- SSG prepares HTML before release; SSR generates it when a request arrives. The choice depends on how fresh the content needs to be and whether it varies by visitor. Both can support browser-side interaction.
- Interactive features
- A menu or calculator can run in the browser. Submitting an inquiry, signing in, or changing saved data usually needs a service API. Frequent interaction may suit a single-page application (SPA), without making SPA a requirement for every interactive site.
- Backend services and data
- A BFF adapts backend operations to the interface and can coordinate service calls. Backend services validate requests, apply business rules, and read or write the database. A BFF is used when needed; not every site needs a separate layer.
Each part needs an operating plan.
Changing statically generated content requires a new build. Server rendering, BFF layers, and backend services need deployment, monitoring, and updates; databases need backups and a tested recovery process. We agree the delivery scope, maintenance responsibilities, and costs for the parts the website actually uses.
Static page delivery and dynamic business features can be part of the same website.
Connected services
Connect the task to the right service.
Forms, inquiries, bookings, newsletters, and commerce can use an external platform or custom backend services. We first assess whether an existing tool fits the workflow, then scope any custom development that is needed.
Each connection needs an owner, a fee, an access model, and an expected failure behavior. Integration scripts and embeds are reviewed for their effect on the page.
A visitor action calls an external service or a server-side API or BFF. Backend services validate the request, process the operation, and store data where needed. The interface shows the result or an appropriate recovery path.
- Specialist systems
- Commerce and payment platforms manage their transaction workflows. We connect the visitor journey and clarify who owns configuration, accounts, and ongoing fees.
- Custom business features
- Inquiry catalogs, customer portals, and custom booking systems may need APIs, backend services, and databases. We agree their development and maintenance scope separately from a standard website build, whether the interface is public or requires sign-in.
- Failure handling
- Check success and failure states. A booking outage should not prevent a visitor from reading already published information; provide an appropriate fallback contact path.
Keep dynamic features behind a clear boundary
Payments and other specialist functions can use dedicated platforms. Custom features may call a backend API directly or use a Backend for Frontend (BFF) that adapts data and coordinates services. Database credentials and service secrets stay on the server.
A BFF is not limited to private dashboards: public inquiry or booking flows may also use it. Backend services validate requests and enforce permissions. Sign-in and password-reset flows belong with the application that owns the accounts.
Where page content is independent of a connected service, a service outage can leave that content available. Backend services and databases have their own recovery needs; rolling back a page release does not undo business records or transactions.
A useful integration includes ownership and failure handling.
Access & security
Keep public content outside private systems.
Public pages may be static or server-rendered. Either way, visitors receive only the content they are allowed to see. An SSR service can read a database without exposing its credentials to the browser.
Credentials stay on the server. Public forms still need input validation and abuse controls; operations involving accounts or protected data also need authentication and authorization. Search controls are never a substitute for access control.
Visitors read public pages delivered through SSG or SSR. Interactive requests pass through server-side validation and, where required, authentication and authorization before reaching backend services or a database. Credentials never enter the public HTML or browser code.
- Public release
- Review generated HTML and client bundles for unintended private content or credentials. Keep administration separate from the public reading experience.
- Protected access
- Validate requests on the server, authorize protected operations, and expose only the required API actions. The browser is not trusted to enforce permissions.
- Operational ownership
- Maintain access to repositories, deployment systems, domains, backend hosting, databases, CMS accounts, and connected services. Review dependencies, test data recovery, and define who responds to an incident.
Access controls and maintenance must cover the actual pages, services, and data the website uses.