|
|
@@ -42,11 +42,11 @@ Another advantage is the ability to leverage various SaaS third party components
|
|
|
|
|
|
#### Disadvantages
|
|
|
|
|
|
-Service oriented architectures can be a drag and I recently wrote up a post about the monolithic architecture at Stack Overflow<sub>7</sub>. I've often quipped about the reliance on third party microservices<sub>8</sub> and sigh everytime I have a request to debug one because it inevitably means reading their documentation. We used to have tightly coupled frameworks like those in Rails or Django and we've now losing them to API-powered SPAs. Some of the APIs are still powered by frameworks. The fact of the matter is that a lot of the Saas companies are still using a monolithic infrastructure to power these same APIs. Shopify uses Rails. A lot of folks are creating a new buzzword around Local-First<sub>9</sub>, which is re-coupling the application stack creating faster read/write times and simplified state management. Up until now, developers have been building a bunch of custom sync tools to try and deal with the APIs.
|
|
|
+Service oriented architectures can be a drag and I recently wrote up a post about the monolithic architecture at Stack Overflow<sub>7</sub>. I've often quipped about the reliance on third party microservices<sub>8</sub> and sigh everytime I have a request to debug one because it inevitably means reading their documentation. We used to have tightly coupled frameworks like those in Rails or Django and we've now losing them to API-powered SPAs. Some of the APIs are still powered by frameworks. The fact of the matter is that a lot of the Saas companies are still using a monolithic infrastructure to power these same APIs. Shopify uses Rails. A lot of folks are creating a new buzzword around Local-First<sub>9,10</sub>, which is re-coupling the application stack creating faster read/write times and simplified state management. Up until now, developers have been building a bunch of custom sync tools to try and deal with the APIs.
|
|
|
|
|
|
Headless as an acronym for microservices or APIs, just means that your content ( media, data, etc ) is elsewhere on the network. Most of the newfangled CMS systems won't tell you that place is actually just Amazon Web Services. Some of the newer offline capable software like Figma or Dropbox offer desktop software that is just essentially repackaged web browsers to seem local. Having more components to system just introduces additional points of failure.
|
|
|
|
|
|
-The cost of service as software is why _Why Software is Eating the World_<sub>10</sub> became a thing. By the time you wrangle up four or five various digital services, you're now the middleman. Decoupling services means you have to maintain multiple systems and it will cost manhours to do so. And unless you've got the team and manhours to dedicate to building out some rather complex systems, you're going to be missing out on a lot of features. Another hidden cost of the lack of ownership is access to your data. Although there has been a good bit written about privacy, I mostly referring to the fact that if your product sells well on Amazon, there will be a competing product in exact t minus 0 hours. It's also the reason that every innovative company is spending time on the other side of a regulatory body at some point defending their overarching reach.
|
|
|
+The cost of service as software is why _Why Software is Eating the World_<sub>11</sub> became a thing. By the time you wrangle up four or five various digital services, you're now the middleman. Decoupling services means you have to maintain multiple systems and it will cost manhours to do so. And unless you've got the team and manhours to dedicate to building out some rather complex systems, you're going to be missing out on a lot of features. Another hidden cost of the lack of ownership is access to your data. Although there has been a good bit written about privacy, I mostly referring to the fact that if your product sells well on Amazon, there will be a competing product in exact t minus 0 hours. It's also the reason that every innovative company is spending time on the other side of a regulatory body at some point defending their overarching reach.
|
|
|
|
|
|
|
|
|
|
|
|
@@ -57,7 +57,7 @@ Size is at the core of speed. Going headless won't necessarily solve this for yo
|
|
|
|
|
|
My real world experience has also taught me that no matter how simple you try make the features, users will find a way around it. Even if your headless site is completely decoupled, there may be instances where an end user wants to edit part of the design. I sometimes try to configure templates in such a way so that you don't lose the design to the editors. Likewise with data, I'll build and configure a feature to edit whatever data field and the users will decide to put something else there. I've also learned that no matter whatever sophisticated real-time collaboration tool a company is using for productivity or to communicate, folks will send email attachments with screenshots. The best way to weave a digital system into a company is by using their existing workflow and trying to make it better.
|
|
|
|
|
|
-What used to be called a website is now called a digital customer experience platform and an advertising agency is now called a digital solutions transformation consultancy. Personally, I prefer simple but I also like to tinker with all the bells and whistles. I know that simple is more sustainable and I'll always lean toward it while recommending on a case by case basis. For now, I'm just happy I know some of the fundamentals to sift through the shite. There's some part of me that really admires the aesthetics of high value really simple software. If I started a new web project this afternoon, headless or not would likely be whatever is in my wheel house and instead of spending the time here ranting, I could be expanding my strike zone.<sub>11,12,13,14,15</sub>
|
|
|
+What used to be called a website is now called a digital customer experience platform and an advertising agency is now called a digital solutions transformation consultancy. Personally, I prefer simple but I also like to tinker with all the bells and whistles. I know that simple is more sustainable and I'll always lean toward it while recommending on a case by case basis. For now, I'm just happy I know some of the fundamentals to sift through the shite. There's some part of me that really admires the aesthetics of high value really simple software. If I started a new web project this afternoon, headless or not would likely be whatever is in my wheel house and instead of spending the time here ranting, I could be expanding my strike zone.<sub>12,13,14,15,16</sub>
|
|
|
|
|
|
|
|
|
<div style={{marginTop: '2rem'}}><br/></div>
|
|
|
@@ -73,9 +73,10 @@ What used to be called a website is now called a digital customer experience pla
|
|
|
7. _Monolithic Infrastructure_ - https://davidawindham.com/til/posts/monolithic-infrastructure
|
|
|
8. Microservices - https://en.wikipedia.org/wiki/Microservices
|
|
|
9. _Local-first software_ - https://www.inkandswitch.com/local-first/
|
|
|
-10. _Why Software is Eating the World_ - https://a16z.com/why-software-is-eating-the-world/
|
|
|
-11. End-to-end typesafe APIs - Typescript - https://github.com/trpc/trpc
|
|
|
-12. Build reactive, realtime, local-first apps directly on Postgres - Postgres/Elixir - https://github.com/electric-sql/electric
|
|
|
-13. Automerge - Typescript - https://github.com/automerge/automerge-repo
|
|
|
-14. Payload CMS - Typescript - https://github.com/payloadcms/payload
|
|
|
-15. Directus - Typescript - https://github.com/directus/directus
|
|
|
+10. _Some notes on Local-First Development_ - https://bricolage.io/some-notes-on-local-first-development/
|
|
|
+11. _Why Software is Eating the World_ - https://a16z.com/why-software-is-eating-the-world/
|
|
|
+12. End-to-end typesafe APIs - Typescript - https://github.com/trpc/trpc
|
|
|
+13. Build reactive, realtime, local-first apps directly on Postgres - Postgres/Elixir - https://github.com/electric-sql/electric
|
|
|
+14. Automerge - Typescript - https://github.com/automerge/automerge-repo
|
|
|
+15. Payload CMS - Typescript - https://github.com/payloadcms/payload
|
|
|
+16. Directus - Typescript - https://github.com/directus/directus
|
