Astro and Laravel
Astro in front. Laravel behind it.
A content site that should be fast, and an application that should be solid. They do not have to be the same codebase.
Astro renders the public pages. Laravel keeps the accounts, the admin and the jobs. They meet at an HTTP API, or Astro reads from Laravel at build time when the content barely changes.
I do not split a product for the sake of a diagram. Ringske, Rolleke, Conference Ratings and this website are Laravel with Livewire or Alpine, because the interface is the application. The split is for a marketing site that should stay static and an app that should not.
For contrast
This website
Laravel and Livewire, on purpose. The pages are the application. I did not put Astro in front of it.
Home →Ringske and Rolleke
Both Laravel. Ringske uses Livewire. Rolleke uses Alpine. Guests and couples are in the same app as the data.
Ringske →Astro on its own
Content sites and migrations, including WordPress to Astro, when there is no application behind the pages.
Astro →How I set it up
- Name the public pages. Those go to Astro. If a page needs the session, it probably stays in Laravel.
- Name the API. A few endpoints, not a mirror of every Eloquent model.
- Deploy them separately. Astro can be static. Laravel stays a normal application. Redirects and the domain are decided before launch.
What each side owns
Astro
Laravel
The seam
When I refuse the split
- The product is the logged-in app. Livewire is enough.
- There is no content site, only screens. Astro would be a second deploy for nothing.
- The team is one person. Two codebases have to earn their keep. I am that person.
- You already have a Laravel app and a blog inside it that is fine.
Not sure which side a feature belongs on?
Describe the product. I will say what stays in Laravel and what, if anything, belongs in Astro.
Questions
Is this how eliancodes.com is built?
No. This site is Laravel and Livewire. I use the split when the public site and the app are different jobs.
Can Astro call Laravel during the build?
Yes, for content that can be baked. Anything that changes per visitor waits until the request, and then it is often just Laravel.
Who maintains both?
I do. That is the point of not handing the front end to someone else.