Gatsby drupal hosting3/29/2023 performance - it’s blazing fast, and also scores high in SEO analytics due to speed.serverless - meaning that I can host it on Github Pages or Netlify - don’t have to pay for the hosting.Gatsby.JS has many advantages and features, I won’t list or cover all of them, but I’ll just list some that were important to me: I wanted to start learning React for a long time and Gatsby.JS was my introduction to it Gatsby.JS Why Gatsby.JS? Well, because it’s based on React and GraphQL, it’s super fast, it’s popular, it’s modern, it has a built bridge to Drupal 8, etc. I also worked on manual migration of Drupal 7 to Drupal 8, I didn’t use the automated ‘upgrade’ path as I didn’t want to have half of the modules or other junk (plus, maybe there were some back-doors in old DB that I didn’t spot). Also the 9th version is just polished off (minus the deprecated code) version of the Drupal 8. Why Drupal? Well, we know that Drupal is amazing, and the 8th version seems to be pretty solid. I eventually settled on Drupal 8 and Gatsby.JS. SEO - with some hiccups, the website usually performs pretty well on Google’s speed test ?.performance is amazing, static websites are crazy fast to load ?.no speed or pricing penalties for X concurrent visitors - if you have a popular article, it will result in same performance for everyone ?.no crucial updates needed, l ow maintenance ?.So to sum up, it comes with a lot of advantages, and even some extra bonuses: Static front won’t have any need for updates (at least no security related needs), can’t be hacked, and I don’t have to worry about operating system updates, packages updates, etc. Advantages of Headless Drupal + Static FrontĮventually I decided that I want to have a static front - running on a static engine, and the outputs of it can be hosted for free - either on some CDN, Github’s static pages, Netlify or even Amazon’s S3 Bucket. Also I don’t want to constantly run updates locally and then deploy those (that’s why I got hacked in first place).Īlso, other than CMS’s vulnerabilities, there are also PHP’s vulnerabilities, Apache/Nginx’s vulnerabilities, ssh vulnerabilities - so you’d have to update the operating system itself and all the packages, then restart nginx, php-fpm, mysql and hope for the best. However, to me, these options are way overkill - I don’t want to pay extra for Pantheon, nor I want to write a CircleCI (or Github Actions) script or a crontab + shell script. Normally you want to test things first on your local environment and then replicate things on production. something simpler but riskier would be - to have a cronjob that just runs updates directly on production - but you never know what will happen.have proper Core Updates and Contributed Module Updates, maybe even run tests and if all goes well to deploy to production. use a CI tool, like CircleCI or Github Actions - you can have regular tasks that run daily, i.e.use something like Pantheon - it comes with automatic core updates, however this still leaves room for contributed modules or plugins if you’re using Wordpress, which can also act as an attack vector.In modern days, there are ways one can automate this process, in example:
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |