The Earth is round, a buttered toast will always fall butter-side down and doing clear cache is every Drupal developer's best practice, these are all globally-accepted truths! And speaking of the latter, when you discover that the familiar Drush clear cache technique is no longer universally unique you wonder: why the change? Why go from clear-cache, to... actually rebuilding cache, starting with Drupal 8? What's the catch? This new way to clear Drupal cache must be stemming from a certain limitation that earlier versions of Drupal presented: Partially completed cache-clearing operations threatening to grow into fatal errors. And now, let's dig into more details on: clear Drupal cache: why & when the 4 methods for clearing your cache in Drupal Drush clear cache vs rebuilding cache: differences, the initiative behind this change, main benefits to expect So, shall we proceed? Clearing Your Drupal Cache: Why Bother? And When? First of all, here's the “motivation” that drives Drupal to create a cache in the first place: Each time a Drupal site has to render a certain web page, it is “forced” to perform specific database queries; and since all these queries have a negative impact on the overall page loading time, Drupal “decides” to store these web pages, once it will have rendered them, in a cache for later (streamlined) reference. OK, now that we've settled this whole “cause and effect” process, let's see why and when you should clear cache on your Drupal site: when you're troubleshooting problems on your website; clear Drupal cache before you undertake any debugging, since this might just confirm to you that the “alerting issue” was nothing but a bad cache entry whenever you want Drupal to quickly record all the updates that you will have performed via the UI, all the changes you will have applied to your code when you're moving your website to a new host when you're installing a new theme or module on your Drupal site; just another scenario when Drush clear cache should be the very first step to take while you're troubleshooting In a few words: clearing your cache might just be one of the most frequent actions you'll take while working (or simply maintaining) on a Drupal site. And in many cases, the one that will “save the day”, without the need to apply other more complex techniques from your “arsenal”. 4 Different Methods to Clear Drupal's Cache For there are several ways for you to clear your Drupal site's cache. Just go with the one that best suits your work style: 1. The Easy Way: Clear the Drupal Cache From the User Interface By far the handiest (and some might say “the less-efficient”, too) method to clear Drupal cache is via the UI: just go to Administration>Configuration>Development>Performance and hit the “Clear all caches” button It won't be long till Drupal displays the “Caches cleared” message for you! And that's it! 2. Drush Clear Cache (Drupal 7) or Drush Cache-Rebuild (Drupal 8) And now, the second method in your “arsenal”: the clear Drupal cache command line one! A two-way method, better said, which depends greatly on the version of Drupal on your website: 7 or 8? In this respect, here's the “magic command” to use for clearing your Drupal 7's cache: drush cache-clear all or drush cc all Whereas in Drupal 8, this is the Drush command for tackling your cache: drush cache-rebuild or, alternatively, these 2 aliased commands: drush rebuild or drush cr And here I'm sure you can already tell which are the specific steps to take for handling your cache in Drupal 8 using Drush (still the most convenient way to do it): first of all, you open a Terminal window and CD in your Drupal 8 website's root (a step that you can overlook if it's Drush aliases that you're using): next, your run your “magic formula”, your Drush command (“drush cache-rebuild” or “drush cr”) and wait for it to complete its task before going back to your website and finally, you just reload the page you were on, in your web browser 3. Run the /core/rebuild.php file for Clearing Your Drupal 8 Site's Cache Among all the improvements that Drupal 8 “lures” us in with (built-in WYSIWYG, a Twig templating system and so on), there's the /core/rebuild.php file standing out! And “promising” us to streamline our frequent (and time-consuming) cache tackling tasks that we need to carry out during development: The Drupal 8 site in question doesn't even have to be working and the whole process doesn't require Drupal Console or Drush either! How about that? The one and only requirement (for there still is one) is that your site's configuration supports it. And how can you check whether your site's config accepts this functionality? Well, there 2 methods at your disposal: in case you're working locally, just ensure that $settings['rebuild_access'] = TRUE; in your settings.php (settings.local.php) or run this script in your command line: /core/scripts/rebuild_token_calculator.sh; then just use the results there as query parameters for /core/rebuild.php (https://goo.gl/qTrJ9d) And voila! This “trick” will rebuild all cache without even requiring for the Drupal 8 site itself to be working during the whole process! Which makes it the perfect “plan B”, whenever you don't have Drupal Console or Drush installed where you're working! The only condition is that your websites' configuration supports this functionality! 4. In the Database: Truncate all Tables Starting With “cache_” Spoiler alert: by “truncate” I do mean emptying, not removing! The fourth method to clear Drupal cache involves clearing all the data from the cache-related tables in your database. Meaning all the tables starting with “cache_”. For this, you just go over to your phpMyAdmin, select all the cache_* table and then click “Truncate” in the “with selected” drop-down menu placed at the bottom of the page: TRUNCATE cache_config; TRUNCATE cache_container; TRUNCATE cache_data; TRUNCATE cache_default; TRUNCATE cache_discovery; TRUNCATE cache_dynamic_page_cache; TRUNCATE cache_entity; TRUNCATE cache_menu; TRUNCATE cache_render; TRUNCATE cache_toolbar; As for the command line, feel free to scan through and then to tap into the valuable info that you'll find here: https://goo.gl/1b4otB here's another practical example: Let's say it's Sequel Pro — an SQL GUI app — that you're using. For truncating those specific tables, connect to the server, track down your site's database, have those specific “cache_” tables highlighted and just choose “Truncate tables”, from the drop-down menu! Also, in the above-mentioned “scenario” you could alternatively go to your PhPMyAdmin's SQL command field or MySQL CLI and run the above-mentioned command: From Drush Clear Cache to Cache Rebuilding in Drupal 8: Why the Change? Here's the challenge that the conventional Drush clear cache (or “drush cc all”) used to make us deal with: Drupal's using caching intensively and therefore, it implicitely creates lots of inter-dependencies. Only partially flushing this heavy load of caches used to pose some major risks for any website. This is where the “cache-rebuild” method stepped in, starting with Drupal 8! It practically rebuilds (re-bootstraps) the whole Drupal site, after making sure that all cache is perfectly cleared. A “check and double check” technique, you may call it, which makes sure that: your site is up and running all cache gets flawlessly flushed! Drupal 7's so very popular Drush cache command itself gets cleared and replaced with “cache-rebuild” in Drupal 8. Which (the Drush cache-rebuild command specific to Drupal 8) carries out the following tasks: clearing the APC cache bootstrapping Drupal calling drupal_rebuild() removing the Drush cache 4. Wrap-Up Summing it up now, the essential info to remember is that: “clear cache” should be on top of your “best practices” list as a Drupal developer you have not just 1, but 4 methods to choose from, depending on your work style and context: via the UI, clear cache using Drush, by truncating your “cache_” database tables, by running the /core/rebuild.php file Drupal 8's cache-rebuild is a step forward from the conventional cache-clear practice; it adds a new “re-bootstrapping” operation to the “cache clearing” process!
RADU SIMILEANU / Mar 02'2018
When to use REST? What are some practical use cases of REST web services? How does it work? What's the “catch”, why has this new architecture for web services had such an impact on the industry? How is it any different/better than SOAP? Why use RESTful web services after all? “Tormented” by all these questions related to the REST approach/alternative to building web services? Relax now, you'll have your answers in a minute (or a few seconds)! For here are the REST-related “enigmas” that I commit myself to solving in today's post: What is REST and how does it work? Which are the specific use cases for building web services using the REST architecture? What's driving it? Why is this technology increasingly popular? What sets REST apart from the traditional SOAP approach to web services? When NOT to use RESTful web services? And now... the answers that I promised you: What Is REST and How Does It Work? Here are some valid answers to all your “What?” questions: “What is REST?”, “What are web services”, “What are RESTful web services?” REST is the native API of web browsers REST is how one creates web services web services are... the future of everything: creating and publishing APIs that would do CRUD (create, read, update and delete) … thus making machine-to-machine communication possible, making apps' functionality accessible to multiple users and external systems RESTful web services are those resources on the web that can be tapped into for retrieving certain information “And how does it work?” First of all, we should get one thing straight: REST is not an official standard! It's more of an architectural style, the one organizing a network of systems, where the “systems” are basically servers and clients. Here's how it works: Clients make a request to the web servers; the latter process it and, in response, return the appropriate web pages. And in this request-and-response equation, RESTful web services are the very resources on the web that servers tap into for retrieving the requested data. Does this definition shed any light on your RESTful web services-related questions? Why Use RESTful Web Services? Here's the actual context where the RESTful web services technology emerged and “grew like a beanstalk”, with a huge impact on the industry: The web “exploded” and, starting with web 2.0, the interaction between websites and client apps, between multiple sites, multiple devices, sites and databases, became increasingly intense. And more and more “demanding”, calling for a new technology that could handle and streamline this communication taking place on the web. And here's where web services and REST, a new way of building them, emerged! The REST architecture is designed to build: maintainable lightweight scalable … web services, which make retrieving the data requested and “exposing” all that information far less cumbersome. As compared to the conventional SOAP/XMLRPC web page-scrapping method. Data's being passed on the web, from one website/app/device/database to another, faster than ever these days. Just think about all those websites incorporating Twitter and Facebook content! Or of websites “capturing” data coming from multiple sources: financial information, sales data, online communities... RESTful web services is the technology that streamlines all these intense data “harvesting” processes! This is the answer to your “Why use RESTful web services?” question. When Should You Use RESTful Web Services? 5 Practical Use Cases There are specific use cases when you should go “the RESTful way”. Adopt this approach to building web services if: 1. In your distributed app it's crucial to keep the coupling between client and server components to a minimum: you'll need to be able to update your server frequently, without having to update the client software, as well your server's going to be used by multiple clients, yet you don't want them to have control over it Just make sure you follow all the REST constraints for achieving this kind of basic level of coupling. Maintaining a purely stateless connection will be challenging, but not impossible if you “follow the rules”. 2. It's a custom, on-demand digital product that you're developing Such as an Ubercart or Drupal online store that you're putting together on a remote cloud server: you set it up create a suitable architecture that would scale the environment if/when this your custom product goes viral 3. You want your game's high scores and user community forums to be displayed both in-game and on the web Let's say that you're a mobile/console game developer facing the above-mentioned “challenge”. In your practical use case you can: have your Drupal site publish an API, using Services (thus doing “CRUD” with the data that needs to be “harvested”) leverage a RESTful type of communication with the Drupal site in order to retrieve that data and have it displayed in-game, on mobile/console, too 4. You want to create a user alert system on your e-commerce website One that would alert your customers, via your e-commerce mobile app, whenever a product that they visualized becomes available (or its price drops). Also, you want those alerts to pop up in an iPhone app and on Facebook, too. And the solution is: Your Drupal site (for yes, it's a Drupal site that you own in this scenario) will use Services & a custom module to have the example.com/alerts/uid API published. And it's this specific API that the iPhone app and Facebook will use for manipulating that particular content to be shown in the user “alerting” message. 5. You want to provide (paid) access to commercially-controlled data Such as movies, music, stock or trading data. Imagine that you own an event venue and you publish a ticketing API. People (such as ticket brokers) will be charged for gaining access to it. In short: RESTful web services for can be used for all kinds of commercial activities, as well. Just use them to create and to publish the API that will do CRUD with precisely that commercially-controlled data that people are willing to pay for gaining access to! What Sets REST Apart from the Traditional SOAP Approach to Web Services? Of simply put: Why use RESTful web services instead of the traditional SOAP-based web services? Here's a list of strong arguments: with REST, all that intense data interaction is more lightweight; it doesn't weight so heavy on your web server like a SOAP page-scrapping method would with REST, only the specifically requested information gets retrieved, instead of having whole web pages scrapped off the “target” content (like with the SOAP approach) the architecture is way simpler than the SOAP one and it leverages the standards (and protocols) of modern web And what does this last argument even mean? It means that heavy SOA (Service Oriented Architecture) is shifting to lightweight WOA (Web Oriented Architecture), since these days apps need to tap into a web that's “packed” with REST resources. And so, instead of leveraging a few point SOA services, data gets collected and displayed via millions of granular REST resources. Developing arbitrary apps, that interact over the network, has become conveniently easier. Complex things (systems) get simplified! When not to Use REST Web Services? There are — as I've just pointed out — use cases when the REST approach is the perfectly suitable one: business-to-consumer apps. But there also are specific cases when RESTful web services don't work so well: B2B apps! Take this practical example here: A bookstore might find it a bit more challenging to make a volume purchase from an online vendor as compared to a regular customer. It would need to “juggle with” several apps to track shipment, sales, determine re-orders etc. And where do you add that one app might need to be re-entered into other apps, turning the entire process into an overly complex, hard-to-manage one. The END! Have I managed to answer your “Why Use RESTful web services?” question or not quite? Or just partially? Do be honest and, if it's the case, share your other REST inquiries and dilemmas with me! Or point out those use case examples or explanations presented here that you'd like me to shed some more light on.
RADU SIMILEANU / Feb 23'2018
RADU SIMILEANU / Feb 15'2018
To go or not to go serverless... This is one of 2018's most asked questions in the IT industry. And it's true that serverless computing has grown from a niche solution, with a somewhat misleading name, into a tech trend guaranteed by all the industry experts. Yet, you're still a bit hesitant when it comes to replacing your heavy, yet familiar infrastructure with a serverless framework, right? You feel like “dipping a toe into the water” first. And who could blame you? It's a more than legitimately prudent approach considering the implications of such a switch. You shouldn't make a move, not until you have some unbeatable arguments at hand. Until you gain a deep understanding of all the benefits that derive from adopting a cloud-native approach. Well, this is precisely what this blog post is all about: pointing out all the strongest benefits that you will reap from taking the infrastructure management weight off your shoulders and going... serverless. But First: What Is Serverless Architecture More Exactly? First of all, let's get one thing straight: “serverless computing” doesn't mean, by all means, that there isn't a server, out there somewhere, doing its data workload processing work! It's just that the user (yes, you!): is no longer burdened with all the server (or fleet of servers) management and monitoring ongoing tasks doesn't know (or care) where in the world his server is located You'd be practically running your code right in the cloud, taking out of the picture the need of provisioning servers on your enterprise's end. "But how does the data processing work on cloud?" A valid question indeed. Basically, you're enabled to set up your individual API endpoints which will fire code and perform certain actions once triggered. As simple as that. And if I am to exemplify, probably the best-known example would be the serverless computing AWS: Amazon's AWS Lambda. It has already managed to “seduce” plenty of IT managers in the industry and its popularity is sure to... explode in 2018. Why? Because it's a serverless computing architecture which: scales automatically, granting enterprises the flexibility they need and helping them cut down costs it executes code only when/if certain events occur, when specific endpoints get triggered And it's not a serverless framework without “rivals”. Competition is about to get fierce when other frameworks such as Webtask, Microsoft Azure Functions, Google Cloud Functions, IBM OpenWhisk and Iron.io will start to... take off. It's Horizontally Scalable: Relax and Let It Handle Massive Waves of Traffic for You In other words: you get to worry less about balancing the heavy load, about the waves of traffic that your site/app might face once certain of your endpoints get exposed. And about rushing in to put together the properly robust infrastructure. The underlying system will handle it for you! You're Free to Set Up Each Endpoint in the Language of Your Choice Or simply put: your API endpoints will be language-agnostic! You (or your lucky team of developers) get to write each endpoint in a different language runtime. So, you're free to use the one that you're most familiar with or the one that best fits our work scenario. And this is already a major pro for adopting a serverless computing approach in 2018! You Only Pay for What You Use: A Strong Benefit of Serverless Computing Here's another “irresistible” benefit that you can reap from going serverless: you only pay for what you use! So, there's no need (not anymore) to pile up on T2 small instances and auto-scaling groups... just in case. The “case” here being: “if I ever hit a surge of traffic”. When you're using a serverless architecture all this comes without a price tag on! Worry Less About Managing The Underlying Infrastructure: It's Being Taken Cared Of! Your serverless cloud provider will be managing the entire fleet of servers for you. And this “management” includes applying security patches as soon as they get released, as well! So, take all these monitoring and security-related concerns off your back and... focus more on turning great ideas into great digital products! And this is — all these resources of time and effort that you'll get to invest elsewhere — the main advantage that you'll leverage from switching to serverless computing! Turn That Great Idea of Yours Into The Next Big Thing Quicker Than Ever! Just think about it: going from having a great idea to actually turning it into the next big... app (let's say) will take you a whole less time (and effort). Serverless computing will smooth the path for you and shorten the process, meaning that: you'll be having your idea production ready a lot quicker you'll gain more confidence to try on newer technologies, as well Summing Up... Plus a Forecast for 2018 “Serverless IT will move from the niche corners of the cloud estate into the spotlight as it addresses the three key areas that keep IT admins up at night: speed, cost and risk.” (Jason McDonald, President U.S., Contino) Yet (for there is a “yet”), serverless computing isn't a “one size fits all” type of solution. It won't scale to all app architectures and needs (like the need to closely monitor and to control how things get configured). Nevertheless, if we: go beyond its somehow misleading name see its strong benefits consider it only for those use cases that it's best fitted for ... serverless architecture is here to stay and change the way we build software from the ground up!
RADU SIMILEANU / Jan 04'2018
It's overwhelmingly lengthy, it's discouragingly “crowded”... it's your checklist to follow when choosing the right CMS for your content-heavy website! And there's no way around it: you need to check them ALL off, all the must-have features and functionalities included there. For you can't afford to make compromises on security for a boosted performance, for instance. And you sure can't get away with trading high speed for easy authoring, right? Or with accepting anything less than “the very best” editorial experience for the sake of easy-to-customize design, for example. It should be an all-in-one CMS solution! Well, it looks like Drupal is the only platform to fit the profile: it lives up to your legitimately high standards and is capable to meet your content-packed site's specific needs. Here's why: 1. It's Ideally Flexible & Conveniently Extensible Dare to dream big, for your Drupal site's content infrastructure is built to grow, seamlessly and almost organically, at the same rate as your future plans! For any performance, security, content management-related, or any other heavy-content site/industry-specific functionality that you might need to add... there is a Drupal contributed module! … or there is a team of Drupal developers ready to write custom code for you and build your custom-fit Drupal module from scratch! And here are 2 possible scenarios where you could capitalize on Drupal's impressive flexibility and extensibility: you need to integrate SalesForce with your website: there isn't just one, but several Drupal modules that you can use for injecting this type of functionality into your website you need to add an Apache Solr to your search bar for indexing results (a critical integration for any large-scale, content-heavy website): Drupal turns this type of integration into a... breeze Whether it's a blog or a content-packed, high-trafficked website that you own or plan to build: Drupal's conveniently extensible to fit any size, any business needs. 2. It Provides a Both Flexible and Rich Content Authoring Experience Here's another strong reason why Drupal's the right CMS for your content-heavy website: it makes content authoring unexpectedly easy! “Armed” with the WYSIWYG editor — which makes such an easy to use content management and editing interface — with URLs, taxonomy, custom lists and tags, your editorial team gets to: craft edit publish perfectly structure … content on your site. Podcasts, articles, infographics, guides, e-books, case studies... your heavy infrastructure gets ideally easy to manage with Drupal as your site's backbone-CMS. 3. It Ships With Impressive Database Accommodation Capabilities Not only that your Drupal CMS's built to seamlessly accommodate your large and enlarging database, but it ships with organizing and sorting features, as well. Features/functionalities delivered to you in the form of dedicated modules. In other words: setting up your customized, ideally structured, perfectly usable library calls for zero custom code writing when using Drupal as your website's CMS! 4. It's Open Source, Making It a Perfectly Suited CMS for Your Content-Heavy Website Drupal's open source nature opens the door to a whole world of possibilities (free of charge) to you! Just imagine this scenario here: Your heavy-content website has a huge influx of regular visitors and then...all of a sudden... a big nasty bug attacks! And it's just inevitable when we're talking about a content-rich website, with content being added and updated almost on a daily basis! What do you do then? You reach out for a patch digging deep into all the free resources put at your disposal by the Drupal community! Just think of all the costs that you'll be cutting off when building your large-scale project with so many modules, site elements specific to your use case and features out there for you to just... “grab” and implement. 5. It Meets The Highest Government Online Security Standards High waves of traffic and a robust content infrastructure do come at a cost: the cost of the highest levels of security. And it's by far the most important point on your checklist to finding the most suitable CMS for your content-heavy website. Drupal's already built a solid reputation around it as the CMS that powers government and high education websites. Need we add more? If it's powering and safeguarding the White House's website from cyber threats, then it must be built with high-security standards mind, don't you agree? Where do you add that, in addition to its robust built-in security features, there's always the worldwide large Drupal community out there to “alert” if something goes bad. A community constantly monitoring Drupal's status at a security level. 6. It's Highly Customizable in Terms of Design How to design content for heavy websites? The best example in this respect is the Panels module that Drupal puts at your disposal. Harness its power to create layouts perfectly tailored to each specific use case. How? With drag and drop! Put together the custom layout and then just fill it in with its corresponding content. Hence, you get to personalize each page on your website all while keeping a visual continuity throughout it! The END! Do you find these 6 reasons strong enough for you to start seeing Drupal as the most suitable CMS for your content-heavy website? What other must-have features (if any) would you add to your checklist?
RADU SIMILEANU / Nov 23'2017