Welcome To Corrison
I am a full-stack web developer building a multi-functional platform that can be deployed across multiple domains while maintaining code consistency.
When building eCommerce sites or websites I encountered the same challenge: I wanted similar functionlity but with unique branding. I run content and affiliate sites, all of which earn anything from $5 a month to a few hundred. Collectively it adds up!
The traditional approach of creating separate codebases for each project was time consuming. The main issues were:
- I need hosting for each site
- I need a domain name for each site
- I had to start from scratch when building each site - coding each one.
Yes, sometimes I could reuse a component, like a blog, but for the most part I had to keep creating and building sites. So I went in search of a faster, more sustainable way.
A Different Approach
I considered setting up a multi-site with Django but it looked too difficult. In the past I had set up a backend / frontend site and a conversation in Slack reminded me of that - it got me thinking.
The question I asked was "how can I get similar functionality without starting from scratch and include unique branding using separate front and back ends?"
So I put that question into Claude AI. I used it to help me get started and figure out the best way to go forward. I also got it to provide the base code I needed. That sometimes became a curse as much as it was a blessing!
That led to the development of Corrison API. A platform that provides enterprise-level functionality while remaining flexible enough to adapt to different business needs.
Corrison API Was "Born"
Corrison is designed to be fully headless and modular. It was claude.ai that recommended using FAST API but as I know Django I opted to use Django REST Framework for the API.
For design I opted for Tailwind CSS because I love it and don't want to learn React, right now.
Finally, I needed a frontend Framework. After considering next.js I opted for Astro. Having never used it before I relied on Claude.ai to help me. However, I soon discovered it was a little like next.js and it was fairly simple to use/learn.
Corrison has been created using a headless, API approach. One site. Many uses. It uses a Django-based API that serves content (blog posts, products, pages, calendar and ecommerce) to any front‐end. It includes a CMS backend built with Django and Django REST Framework, powering multiple websites with a shared API infrastructure.
Here's what I can do:
- Use only the blog endpoints for a standalone CMS blog.
- Use the store endpoints (e.g. ecommerce, cart and checkout) to power a headless shop.
- Use the pages endpoints for dynamic landing pages.
- Use the calendar to create a custom-build appointment setter.
- Use LinkHub to create link-in-bio style pages.
- Mix and match; your existing Django site can fetch from Corrison's API without rewriting all your templates.
Architecture - Key Design Principles
At its core, Corrison separates business logic from presentation through a comprehensive service layer.
This means:
Cleaner Code: Views remain thin and focused on presentation.
Reusability: Business logic can be shared across different views and contexts
Testability: Services can be tested independently of the web framework
Maintainability: Changes to business rules don't require modifications to views
Modular Architecture
Corrison has been arranged into focused Django apps, each responsible for specific functionality:
corrison/
├── accounts/ User management
├── cart/ Shopping cart functionality
├── checkout/ Order processing and payments
├── products/ Product catalog
├── blog/ Content management
├── pages/ Build websites and landing pages
├── linkHub/ Display links to your content around the web
├── calendar/ Let your clients book appointments
├── profile/ Each user/client gets a profile and dashboard area
Multi-Domain Deployment
Corrison uses a sophisticated settings structure that makes deployment across different environments seamless:
Base Settings: Shared configuration across all environments
Environment: Specific: Development, staging, and production settings
Site Settings: Domain-specific configuration for multi-site deployment.
A Business Website Example
Let's use a made-up example to demonstrate. Your website is at potteryplace.com.
Need a different UK and USA site? Create your site once, set it up on different domains.
Need a promo/landing page - promo.potteryplace.com - gives you one.
Need a documentation site docs.potterplace.com
Need a place to sell your pottery. Set up the ecommerce store pottery.potteryplace.com
Why do this? Geo-targeting & SEO
A “.co.uk” TLD can rank better in UK search results, while “.com” is more global.
You serve the same copy, but search engines see you as local.
International Markets: Easily adapt the platform for different regions
Currency and language support
Region-specific product availability
Localised payment methods
Compliance with local regulations
Using the same code on different domains.
Use SEO to “unify” the sites
You might think that having all these different sites will affect your SEO but there is a way to make sure that does not happen.
A central hub (potteryplace.com) links prominently to each sub-domain.
Cross-linking: In the Footer or Navigation bar of each sub-domain I point back to the central hub domain.
Shared branding: Use the same logo, meta tags, CSS so Google (and users) see them as part of one brand.
Sitemap & Search Console:
Create a root sitemap at potteryplace.com/sitemap.xml that references all sub-site sitemaps.
In Google Search Console, add the “Domain Property” (potteryplace.com) to cover all sub-domains automatically.
Use of canonical headers (if any content overlaps) so Google knows which URL I prefer indexed.
Headless API Structure
Corrison has been created using a headless, API approach. One site. Many uses. It uses a Django-based API that serves content (blog posts, products, pages) to any front‐end. Right now, I am using the Astro framework as the frontend.
It includes a CMS backend built with Django and Django REST Framework, powering multiple websites with a shared API infrastructure.
Single API Endpoint
Corrison uses a Single API endpoint. I deploy the Django app once (e.g. at corrison.yourdomain.com), and it exposes REST or GraphQL endpoints like:
GET /posts/
GET /products/
GET /pages/
The front-end then fetches the data.
Any front‐end, whether it’s Astro, React, Vue, Gatsby, Next.js, a mobile app, or even another Django instance. Your front-end framework simply calls those endpoints, receives JSON information then shows it on the browser.
Astro Front-End
Astro is a modern web framework designed for building fast, content-focused websites. I decided to use it because it's particularly well-suited for static sites, blogs, documentation sites, marketing pages, and e-commerce sites.
I create an Astro project and use Astro’s getStaticPaths/ getStaticProps to fetch data from the Django API. All the content and information is stored in the Django backend. The front-end displays it all. I deploy that Astro site to my hosting. Right now I am using Hetzner. Railway is another option.
While Astro is primarily known for static sites, it also supports server-side rendering (ssr) and API routes. You can create API endpoints that run on the server, making it suitable for:
- Building full-stack applications
- Creating serverless functions
- Handling form submissions
- Integrating with databases and external services
I chose Astro because I wanted the performance benefits of static sites but I also needed dynamic functionality. Plus it is great for content-rich sites whether you are just starting out or have loads of documents. Another important consideration, apart from being able to use API, was the fact that speed and SEO are priorities and Astro handles both really well.
CORS & Authentication
With a plug-and-play system like this one does that mean anyone can set up a site using my domain name?
NO! And I'll tell you for why...
The site has the ability to enable CORS on the API so that requests from domain-a.com, domain-b.com, etc. are allowed.
API keys or OAuth tokens are issued so that each front‐end or client registers and authenticates when it asks for data.
So if a domain is not registered with my site it can't get access to your information.
Demo Sites
As of July 2025 I am currently putting together demo sites to demonstrate how this all works. You will find links to them in the header and/or footer.
https://corrisonapi.com - the main site
https://corrison.corrisonapi.com - the engine that makes this work - nothing to actually see because it is all backend.