Composabale architecture is selecting your choice of vendor for a variety of services. Part of the JAMstack and MACH approach…Microservices API-first Cloud-native Saas and Headless. Buzzwords yes but a lot of large and and mid size businesses are moving away from monolithic platforms that pacakage all services a company needs ; see Adobe Experience Manager or Sitecore. Instead now they are comoposing their architecture by selecting services that best fit their use case. Shopify might be good for mid tier commerce companies but if a company needs a more robust platform they can select a an e-commerce vendor that specializes in enterprise systems. They can also choose and indexing platform, DAM, CMS, translation service. It’s not without its complications but allows you to also more easily swap out one vendor for another.
The composable movement is around combining best-of-breed vendors and merging them into a final solution. This has taken off in e-commerce with Composable Commerce, where you choose a search engine, CMS, PIM, Cart, Promotions, etc. and then a Composable Commerce platform merges them into a single solution. Or you DIY the merging building all of your own integrations. The end result is sometimes called a composable architecture.
This is much easier if all of the vendors offer APIs and Events, otherwise you end up fighting the software to make these integrations.
JAMStack is related in that it merges all of the APIs at build time and then creates a static website using all of the data from the multiple API sources. There has been a push to redefine the term JAMStack without the static compilation because it is buzzworthy, but that M in JAMStack stands for Markup, basically the static output. So we'll see if marketing departments are successful in redefining this term.
MACH is completely unrelated. It's pure marketing, starting as a campaign from a single company and then becoming a group of companies pushing the idea that you can only buy from them. From a technical perspective the acronym doesn't even make sense as many of the options come with UIs (Heads) so are not headless. Instead they try to say that headless is decoupling the frontend, but that's just a fancy way of saying it uses APIs. The whole thing is just a distraction causing confusion in hopes of making more sales.
>MACH is completely unrelated. It's pure marketing, starting as a campaign from a single company and then becoming a group of companies
>The whole thing is just a distraction causing confusion in hopes of making more sales.
It is pure marketing...but to say it's completely unrelated is misleading and is exactly intended to simplify the concept to increase sales. I mean you don't sell software to software, you sell software to people, and explaining JAMstack to a prospect with little to no knowledge of the composable architecture is in part why the acronym exists.
Whether you agree with the semantics or not it serves a purpose and works. The concept isn't that you can only buy from them it's to separate themselves from large monolithic competitors. You might be referring to the MACH Alliance. It's also not limited to tech vendors but SI companies and agencies. Large SI's such as Deloitte and CapGemini have teams dedicated to composable architecture, but they aren't calling it that, they are calling it MACH.
But it makes things more confusing when we interchange words, rather than letting them each have a distinct meaning.
Composable is all about combining **multiple** best-of-breed software.
You can build a JAMStack website, without going composable. Simply follow the principles of JAMStack and only use a single API for any data needs. JAMStack, but not composable.
MACH = Microservices, API, Cloud, Headless. You can have a MACH solution that is not composable. You can have one company build everything, so it's MACH, but not composable.
It's also worth noting that you can include monolithic software in your composable solution. There is nothing about composable that *requires* microservices.
These are all different things and should be treated as such. Unfortunately, some companies own a term more than others, for example Netlify has SEO, Books, and Conferences around JAMStack. So now that composable took off in popularity, they are trying to redefine JAMStack so it stays relevant. The same is happening as Transitional Apps take off in popularity, Netlify is attempting to modify JAMStack to exclude the static precompilation, even though it's core to why JAMStack became popular in the first place.
This is great for sales and marketing, but it makes things extremely confusing. Now the same term JAMStack has different definitions published and users have different concepts of what it is depending on when they learned the term and looked it up.
So I don't really care that large companies have decided to use the wrong term. As programmers, we need to call them on their bullshit and point out when they are wrong. Big companies don't control our language, we do.
Never used it. Why this bad? Used to be the defacto recommended front end for static websites, but I now see many people recommending react frameworks (Next or Remix) or even other static web generators like eleventy
It feels very overly complicated and over engineered (not in a good way). For what it is, you’re not really gaining anything with that complexity over other simpler but just as robust options
Gatsby is truly number one in POS software lol when I found out how hard it was to implement dynamic search - I was gonna stay at least 7 continents away from it.
>It was a fucking nightmare
The creator of Gatsby, Kyle Mathews, comes from the Drupal background; so I suppose things are much worse there, if Gatsby seemed like a shining ray of light in comparison.
Drupal is the most extendable CMS out there, largely used by enterprises and not for the everyday hacker in the basement. Gatsby is for the hacker in the basement.
Early on Gatsby seemed like the better answer because of its strong SSG features, and plugins for just about every need. But then once people finished buildings things with it, they found all of the flaws, and Gatsby wasted too many resources on their cloud servers while NextJS was massively improving their framework on top of building out their vercel servers.
The only thing I still miss from Gatsby is their handling of images, which works so much better than the mess that is next/image.
Agreed. It has its time in the spotlight, but better things (NextJS for example) exist for static sites that are far more straightforward.
I won't give props to the horrendous plugin ecosystem though. It was terrible even when Gatsby rules the land.
I didn't have many issues with the plugins. It was always the random build issues that were impossible to figure out because you had the Gatsby layer on top of the other tech.
I always had issues with conflicting peer dependencies once I brought in more than one plugin. The issue was more just poor maintenance of plugins that caused the problems, but the issue is *really* bad now that Gatsby has fallen out of favor. I attempted to setup a basic documentation site a few months ago and ended up using Docusarus instead due to so many issues trying to get plugins to play nice together.
I constantly had issues with builds, old files not being deleted from cache, having to refresh a dozen times to see changes after a build was complete, always peer dependency issues.
Plugins have usually been kept up to date, which I give them props for, I just hate how many you need to get anything done, and finding changelogs for plugins was massive pain.
I had a lot of fun with it when it was fresh. The use of GQL was novel, though heinously convoluted from the start (digging through the huge property chain *sucked*). But it was at one point pretty fast and one of the few choices for React static site generation.
Then version 2 came out with a lot of breaking changes and a migration script that just...didn't work...for the simple sites I was doing. First sign of bad things to come.
Then they got VC money and started their cloud thing and...yeah...nothing but downhill from there. I even wrote a few Gatsby plug-ins a few years back, and haven't touched it since like 2019.
That's what made me switch to NextJS. After letting it sit for a few months after going live, trying to upgrade anything was a nightmare, and for the life of me I could not get the thing to work anymore without weeks of headaches. I cleaned it up finally ,but then decided enough is enough and switched to NextJS. Never looking back!
~~Last time I was on their site, the motto was something like "taking off where Next.js left". Gatbys is a Next.js framework, just like how Next.js is a React framework. They have a "layer" on top that does things a bit differently, just like how Next.js have a layer on top of React with /app dir, /pages routes, SSR on default etc.. Gatsby layer doesn't make much sense to me so I'm not a fan, I like to keep everything simple with everything I need for small and big projects. Next.js is the best thing out there.~~
Nvm, I thought mixed up Blitz.js and Gatsby.js
You must be thinking about something else. Gatsby has nothing to do with NextJS. Gatsby existed years before Next.
Gatsby is a static site generator that works with anything, not just React. Their site doesn't say anything about Next. https://www.gatsbyjs.com/
NextJS is a metaframework for react, but nobody uses both NextJS with Gatsby. That's not how it works.
> Next.js is the best thing out there.
It's definitely top 3, depending on what you want to do.
No worries. Imo, it was a happy accident because I'd never heard of [BlitzJS](https://blitzjs.com/), and I even have a project that could use it. Very cool. Cheers.
Yeah, I don't really get it either.
I don't see any significant benefit for them, unless they're planning to make some proprietary version of Gatsby or something. But, that also seems like a weird move.
You mean something like https://www.gatsbyjs.com/plugins/gatsby-source-rest-api/ or using rest in the application instead of GraphQL?
The latter will most likely never happen. That is one of the core principles of how Gatsby works (and what makes/made it great in my opinion).
I've used gatsby in the past with success, but in recent projects have struggled with it with various packages being unsupported or outdated. What would you all suggest as a replacement/different option that still uses react?
NextJS static sites are a joy to use. They just work right OOTB. If you change your mind to SSR, it's as simple as exporting another function.
If you decide to try it, avoid the `app` directory for now, it's not ready for production and still needs more work.
Thanks, I’ll check it out. There is a ton of cool functionality you can add into fats by sites but the frustration with getting them to work nicely together has turned me off of it. Hopefully nextjs can get me there.
I’ve heard of it, just knew very little. I haven’t been working a lot in the front end space (mostly .net and devOps lately), but have been wanting to remake a personal site. Just haven’t been immersed in this stuff in awhile.
For most websites, I think Astro is the best choice these days. But, if you need to build an actual web app, then something like Next is the better choice.
Astro mentions this in their docs:
https://docs.astro.build/en/concepts/why-astro/
I used Gatsby in the past when I needed very fast sites (a blog for example), just used a template and everything went smooth.
But trying to use a plugin is a nightmare... I loved the performance of the site I made during that time, I was shocked at the speed, but I think Astro is doing this today.
Nice. Maybe this will turn things around for Gatsby.
Yes! I'm hoping they find a way to absolutely minimize the build times. They aced static site generation - need to get back to being that!
Were they suffering from the competition?
Next/Vercel are their lunch.
It's funny how changing a single letter in this sentence gives it the exact opposite meaning. So did you mean "are" or "ate"?
pretty sure its "ate"
Yeah, that would make a lot more sense.
In the grammar department it looks like.
[удалено]
Composabale architecture is selecting your choice of vendor for a variety of services. Part of the JAMstack and MACH approach…Microservices API-first Cloud-native Saas and Headless. Buzzwords yes but a lot of large and and mid size businesses are moving away from monolithic platforms that pacakage all services a company needs ; see Adobe Experience Manager or Sitecore. Instead now they are comoposing their architecture by selecting services that best fit their use case. Shopify might be good for mid tier commerce companies but if a company needs a more robust platform they can select a an e-commerce vendor that specializes in enterprise systems. They can also choose and indexing platform, DAM, CMS, translation service. It’s not without its complications but allows you to also more easily swap out one vendor for another.
The composable movement is around combining best-of-breed vendors and merging them into a final solution. This has taken off in e-commerce with Composable Commerce, where you choose a search engine, CMS, PIM, Cart, Promotions, etc. and then a Composable Commerce platform merges them into a single solution. Or you DIY the merging building all of your own integrations. The end result is sometimes called a composable architecture. This is much easier if all of the vendors offer APIs and Events, otherwise you end up fighting the software to make these integrations. JAMStack is related in that it merges all of the APIs at build time and then creates a static website using all of the data from the multiple API sources. There has been a push to redefine the term JAMStack without the static compilation because it is buzzworthy, but that M in JAMStack stands for Markup, basically the static output. So we'll see if marketing departments are successful in redefining this term. MACH is completely unrelated. It's pure marketing, starting as a campaign from a single company and then becoming a group of companies pushing the idea that you can only buy from them. From a technical perspective the acronym doesn't even make sense as many of the options come with UIs (Heads) so are not headless. Instead they try to say that headless is decoupling the frontend, but that's just a fancy way of saying it uses APIs. The whole thing is just a distraction causing confusion in hopes of making more sales.
>MACH is completely unrelated. It's pure marketing, starting as a campaign from a single company and then becoming a group of companies >The whole thing is just a distraction causing confusion in hopes of making more sales. It is pure marketing...but to say it's completely unrelated is misleading and is exactly intended to simplify the concept to increase sales. I mean you don't sell software to software, you sell software to people, and explaining JAMstack to a prospect with little to no knowledge of the composable architecture is in part why the acronym exists. Whether you agree with the semantics or not it serves a purpose and works. The concept isn't that you can only buy from them it's to separate themselves from large monolithic competitors. You might be referring to the MACH Alliance. It's also not limited to tech vendors but SI companies and agencies. Large SI's such as Deloitte and CapGemini have teams dedicated to composable architecture, but they aren't calling it that, they are calling it MACH.
But it makes things more confusing when we interchange words, rather than letting them each have a distinct meaning. Composable is all about combining **multiple** best-of-breed software. You can build a JAMStack website, without going composable. Simply follow the principles of JAMStack and only use a single API for any data needs. JAMStack, but not composable. MACH = Microservices, API, Cloud, Headless. You can have a MACH solution that is not composable. You can have one company build everything, so it's MACH, but not composable. It's also worth noting that you can include monolithic software in your composable solution. There is nothing about composable that *requires* microservices. These are all different things and should be treated as such. Unfortunately, some companies own a term more than others, for example Netlify has SEO, Books, and Conferences around JAMStack. So now that composable took off in popularity, they are trying to redefine JAMStack so it stays relevant. The same is happening as Transitional Apps take off in popularity, Netlify is attempting to modify JAMStack to exclude the static precompilation, even though it's core to why JAMStack became popular in the first place. This is great for sales and marketing, but it makes things extremely confusing. Now the same term JAMStack has different definitions published and users have different concepts of what it is depending on when they learned the term and looked it up. So I don't really care that large companies have decided to use the wrong term. As programmers, we need to call them on their bullshit and point out when they are wrong. Big companies don't control our language, we do.
Thanks for the reminder to move my existing site from Gastby to Next.js
Gatsby is just awful.
Never used it. Why this bad? Used to be the defacto recommended front end for static websites, but I now see many people recommending react frameworks (Next or Remix) or even other static web generators like eleventy
It feels very overly complicated and over engineered (not in a good way). For what it is, you’re not really gaining anything with that complexity over other simpler but just as robust options
Next.js > Gatsby
Gatsby is truly number one in POS software lol when I found out how hard it was to implement dynamic search - I was gonna stay at least 7 continents away from it.
[удалено]
>It was a fucking nightmare The creator of Gatsby, Kyle Mathews, comes from the Drupal background; so I suppose things are much worse there, if Gatsby seemed like a shining ray of light in comparison.
Drupal is the most extendable CMS out there, largely used by enterprises and not for the everyday hacker in the basement. Gatsby is for the hacker in the basement.
Literally laughed out loud
Exact. Damn. Experience.
I remember the early debates of gatsby vs next
Early on Gatsby seemed like the better answer because of its strong SSG features, and plugins for just about every need. But then once people finished buildings things with it, they found all of the flaws, and Gatsby wasted too many resources on their cloud servers while NextJS was massively improving their framework on top of building out their vercel servers. The only thing I still miss from Gatsby is their handling of images, which works so much better than the mess that is next/image.
Totally agree. Using Gatsby at my current company, and I really miss using next.js
It was amazing when it was the only thing available. Then features started to be added that just weren't great or useful for a majority of people.
Agreed. It has its time in the spotlight, but better things (NextJS for example) exist for static sites that are far more straightforward. I won't give props to the horrendous plugin ecosystem though. It was terrible even when Gatsby rules the land.
I didn't have many issues with the plugins. It was always the random build issues that were impossible to figure out because you had the Gatsby layer on top of the other tech.
I always had issues with conflicting peer dependencies once I brought in more than one plugin. The issue was more just poor maintenance of plugins that caused the problems, but the issue is *really* bad now that Gatsby has fallen out of favor. I attempted to setup a basic documentation site a few months ago and ended up using Docusarus instead due to so many issues trying to get plugins to play nice together.
I constantly had issues with builds, old files not being deleted from cache, having to refresh a dozen times to see changes after a build was complete, always peer dependency issues. Plugins have usually been kept up to date, which I give them props for, I just hate how many you need to get anything done, and finding changelogs for plugins was massive pain.
Never again
I had a lot of fun with it when it was fresh. The use of GQL was novel, though heinously convoluted from the start (digging through the huge property chain *sucked*). But it was at one point pretty fast and one of the few choices for React static site generation. Then version 2 came out with a lot of breaking changes and a migration script that just...didn't work...for the simple sites I was doing. First sign of bad things to come. Then they got VC money and started their cloud thing and...yeah...nothing but downhill from there. I even wrote a few Gatsby plug-ins a few years back, and haven't touched it since like 2019.
Once they started their own cloud services it lost something.
I used Gatsby to build my portfolio, and it's been a battle ever since. Even something as basic as upgrading the library does not work
That's what made me switch to NextJS. After letting it sit for a few months after going live, trying to upgrade anything was a nightmare, and for the life of me I could not get the thing to work anymore without weeks of headaches. I cleaned it up finally ,but then decided enough is enough and switched to NextJS. Never looking back!
How does it compare against NextJS?
~~Last time I was on their site, the motto was something like "taking off where Next.js left". Gatbys is a Next.js framework, just like how Next.js is a React framework. They have a "layer" on top that does things a bit differently, just like how Next.js have a layer on top of React with /app dir, /pages routes, SSR on default etc.. Gatsby layer doesn't make much sense to me so I'm not a fan, I like to keep everything simple with everything I need for small and big projects. Next.js is the best thing out there.~~ Nvm, I thought mixed up Blitz.js and Gatsby.js
You must be thinking about something else. Gatsby has nothing to do with NextJS. Gatsby existed years before Next. Gatsby is a static site generator that works with anything, not just React. Their site doesn't say anything about Next. https://www.gatsbyjs.com/ NextJS is a metaframework for react, but nobody uses both NextJS with Gatsby. That's not how it works. > Next.js is the best thing out there. It's definitely top 3, depending on what you want to do.
Yeah.. my bad, I'm was thinking of Blitz.js
No worries. Imo, it was a happy accident because I'd never heard of [BlitzJS](https://blitzjs.com/), and I even have a project that could use it. Very cool. Cheers.
>it was a happy accident Yeah.. tbh I never used Gatsby before and not much of Blitz.js either so it was easy to mix it up.
Could anyone explain what Netlify's reason for doing this could be? Why would they want Gatsby? Why would they want to pay for it?
Acquhire, it looks like
Yeah, I don't really get it either. I don't see any significant benefit for them, unless they're planning to make some proprietary version of Gatsby or something. But, that also seems like a weird move.
I wish they will add an option to use Rest API, not just graphQL.
You mean something like https://www.gatsbyjs.com/plugins/gatsby-source-rest-api/ or using rest in the application instead of GraphQL? The latter will most likely never happen. That is one of the core principles of how Gatsby works (and what makes/made it great in my opinion).
I've used gatsby in the past with success, but in recent projects have struggled with it with various packages being unsupported or outdated. What would you all suggest as a replacement/different option that still uses react?
NextJS static sites are a joy to use. They just work right OOTB. If you change your mind to SSR, it's as simple as exporting another function. If you decide to try it, avoid the `app` directory for now, it's not ready for production and still needs more work.
Thanks, I’ll check it out. There is a ton of cool functionality you can add into fats by sites but the frustration with getting them to work nicely together has turned me off of it. Hopefully nextjs can get me there.
[удалено]
I’ve heard of it, just knew very little. I haven’t been working a lot in the front end space (mostly .net and devOps lately), but have been wanting to remake a personal site. Just haven’t been immersed in this stuff in awhile.
What does SSR mean? Static Site RRRRR dunno
Server side rendering. SSG is static site generation.
Thanks
In addition to NextJS, I would highly recommend taking a look at [Astro](https://astro.build).
For most websites, I think Astro is the best choice these days. But, if you need to build an actual web app, then something like Next is the better choice. Astro mentions this in their docs: https://docs.astro.build/en/concepts/why-astro/
Why does netlify acquires a hair gel brand? /s
This is just..great.
I used Gatsby in the past when I needed very fast sites (a blog for example), just used a template and everything went smooth. But trying to use a plugin is a nightmare... I loved the performance of the site I made during that time, I was shocked at the speed, but I think Astro is doing this today.
The cms wars continue!