Hands-On Experience: Remix.run eCommerce Starter
Remix is getting quite some attention lately, and being in the eCommerce space, it has caught our eye.
4 minutes
The performance, server-side data loading, simplicity, and the way Remix.run does not manage cache in the framework is excellent for fast-changing dynamic eCommerce pages - especially at scale. These are some reasons why we have built an open-source Remix boilerplate tailor-made for product storytelling and performance. Learn why here.
The last few years have been packed with front-end frameworks using the Jamstack methodology. Frameworks that are statically pre-generating the web pages so that they are fast. This is great for regular web pages and perhaps when the number of pages is not that big. But when you have more dynamic content, the concept of pre-generation is not the greatest.
Don’t get us wrong, we like Jamstack, and it is an excellent fit with Crystallize. But sometimes, depending on the use case, there's just something that is a better fit, in this case: Remix.run.
With Remix, all the pages are being generated dynamically. Good old server-side rendering (SSR), but with a modern React-based front-end framework. All the page fragments are being rendered in parallel, meaning less waiting.
The way it works is really fancy.
First, you have the initial page load where the page is Server Side Rendered, there is nothing done in parallel in the browser here, but there is a key point: only the page is loaded. Remix does not load all your application “shell” on the first load, only what it needs to render the page. It works without Javascript!
Then when you browse the website, Remix will fetch fragments in parallel and load the data. That’s fast! Also, fragments are not HTML, they are Javascript scripts. Once they have been loaded, they are not requested anymore, and they stay in the browser cache for future visits. They are actually “immutable.” This makes sense because, for a specific build, the application shell (splitted in fragments) is immutable per nature!
The data on the other side might change, and Remix will fetch the data all the time, but HTTP Cache comes in handy here. It’s really easy to implement Browser Caching, Reverse Proxy Caching, and/or CDN.
And to conclude on the magic touch, the code you write is the same Server Side and Client Side, of course, it’s all (Re)mix. Remix knows when to load the needed data Server Side (onFirstLoad) or via a fetch when browsing subsequent pages or fragments.
Regarding the HTTP Cache, it’s important to mention that the cache control is not part of the Remix framework. It is based on the HTTP standards where you use the cache headers. Having complete control over the HTTP cache headers with a great CDN in front, you have the foundation for event-driven HTTP caching.
You can decide to have a cache strategy for SSR page loads and for data loading.
Protip: don’t forget to consider that only the SSR cache is in play on the first load as the data are (re)mixed in the page rendered server-side.
In short, speed, standards-based, simplicity, and ultimately more control. And that is not all. With Remix, among other things, you have nested routes natively (on top of React Router v6), Optimistic UI mechanisms, a fancy way to handle the errors (server or client-side), and “Actions” managed like a charm to handle your forms! (with or without JS)!
By default, Remix is dynamic. It is optimized for delivering dynamic content in real-time. There is less overhead in the framework, which is also great for site speed.
We have already talked about cache-control with fine-grained headers. This means that we can cache content in a more controlled fashion. E.g., we could cache prices for a specific type of customer. We can purge cache based on tags.
To make it easier to get started with Remix and eCommerce, we have built an open-source Remix eCommerce Boilerplate. This boilerplate allows you to quickly get up and running with a fully functional webshop built on the following tech stack:
- Remix.run as the frontend framework
- Tailwind for styling
- A CDN of choice for event-driven HTTP caching
- Crystallize as GraphQL ecommerce backend
With Remix being built on web fundamentals we can more easily design our composable commerce stack to fit our needs. The first composable commerce stack we launched with Remix is based on the following:
- Remix.run - frontend framework
- Fly.io - hosting service
- Fastly - CDN caching
- Crystallize - super fast GraphQL ecommerce API
We did a Livestream on this boilerplate and commerce stack. You can view the recording below.
Without a doubt Remix is an exciting new framework that offers amazing possibilities out of the box. And yes, only time will tell if it will catch on.
Schedule a 1-on-1 demo so we can help you understand the ins and outs of our Remix Run boilerplate. Or, why not START building for FREE with Crystallize
It’s as easy as that!
👇More Framework Templates.
Retail eCommerce Remix Boilerplate Has Been Released!
Remix and eCommerce go well hand in hand, and we have a free open-source boilerplate for retail storefronts to prove it.
Hands On Experience: How to Build an eCommerce Store with Next.js?
But first, a background story to give you context. I didn't take the path most Computer Science students take once they graduate. At some point during my college career, while coding my brains out in Java, C++, and assembly, I decided that being a full-time developer was not for me.
To be fair, I hadn't known what to do with myself even before college. I’d always liked writing, but you couldn’t get paid for that. (Right?)
As the Internet became more popular, I’ve enjoyed building homemade websites in HTML+CSS, learned a great deal about how to use search engines, connected with people worldwide, and even bought books and Star Trek memorabilia off eBay.
Therefore, the elders in my life had nudged me toward Computer Science, saying I’d be sure to make a lot of money once I graduated. I’d started with programming classes in high school, then continued with that path into college. And while I kept up with my coursework, I was never all that into coding for coding’s sake. It wasn’t something I itched to do in or out of the classroom.
As a result, my career path has been colorful: tech support, technical training, business analysis, and project management. I once had a job helping developers who used my company’s SaaS and APIs to get up and running and troubleshoot their programming issues. But by far, my favorite thing to do has always been technical writing and documentation. I enjoyed writing articles for the company website, for the knowledge base, you name it.
It turned out I could get paid for writing. Who would’ve thunk it?
I like writing so much that I’ve done a fair bit of it outside work as well. It’s been mostly for myself and my own fun, but I was able to get some work self-published under a pen name.
Now I’m doing technical writing full-time. Although I enjoy every second of it and wouldn’t want things any other way, there’s no denying that my technical side has atrophied a bit. It's super-hard for a full-time developer to keep up with all the latest technological trends, never mind someone who isn’t constantly immersed in it.
So, every once in a while, I like to dip my toes back into that water to learn what’s going on. It helps me to write better documentation when I know firsthand what’s important from the developer’s perspective.
On one occasion, I wanted to see if I could deploy one of the Crystallize boilerplates myself. And if I wanted to later on, I could eventually customize the boilerplate to sell my short stories and novels without having to rely on the big A or the big G.
What follows is a nice bit of hands-on experience. How easy or hard was it for a beginner like me to pull off?
Hands-On Experience: eCommerce Store with Astro?
Astro🚀 has been a hot topic since its release in June 2022, especially because it is extremely fast. So it was a no-brainer to choose which framework we should go with next for our series of minimal eCommerce boilerplates titled ‘dounut’.