Minna Lunney

Modern-day eCommerce marketing strategies rarely go without content marketing in place. And to create and manage content that goes beyond product page requirements, you need to have a content management system (CMS) in place.

It's easy to feel overwhelmed by the sheer number of CMS platforms. If you're not using the right CMS, it could be holding your business back from realizing its full potential.

Let's examine these systems more closely and consider how to find the best one for your use case.

So you want to get started with headless eCommerce, and Crystallize in particular? It’s easier than you may think! We’ll talk you through getting your entire tech stack in order so you can hit the ground running.

Everyone’s seen topic maps everywhere, from teachers’ blackboards to their favorite apps. They seem intuitive and self-evident, like they must’ve been around forever, but the truth is, they haven’t.

Unlike spreadsheets, which have been around for thousands of years (maybe that’s why everyone loves Excel so much!), topic maps have only been around since the 1990s. We’ll go into what they are, what they can do, and how you can make the most of the topic map implementation offered within Crystallize.

Welcome back! In my last post, I showed how easy it was to install Crystallize’s open-source NextJS retail eCommerce boilerplate even though my programming days are some years behind me. The boilerplate is now deployed locally on my machine, pointing to my own custom tenant populated with demo data. Right off the bat, it’s got all these products, beautiful design elements, assets, and multiple payment integrations built in. Awesome!

To begin, it's essential to make sure we understand what GraphQL is. It's a technology developed by Facebook in 2012 to address their issues with mobile platforms. One of the technologies they were trying to use, REST, was not performing well in their particular setup, so they decided to replace it with a homegrown solution. GraphQL was the result. A few years later, the GraphQL specification was made open-source so that anyone could potentially benefit from it and contribute to it.

GraphQL is a query language for APIs (application programming interfaces) and a server for executing those queries. APIs are the means by which computer programs communicate with each other to exchange and manipulate data. 

REST is the most-used API architecture by far (as Postman's recent API report shows | graph is below); however, GraphQL adoption is on the rise, and many already are using it in place of REST to facilitate communication with all the different APIs that an application may have to talk to.

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?

More and more businesses are relying on cloud-native microservice apps to increase development speed and take advantage of the cloud's scalability and availability.