LATEST FROM OUR BLOG

Take your daily dose of (only) relevant news, useful tips and tricks and valuable how to's on using the latest web technologies shaping the digital landscape. We're here to do all the necessary information sifting for you, so you don't have to, to provide you with content that will help you anticipate the emerging trends about to influence the web.

From Mobile Apps to... Multiexperience Apps: 4 Reasons to Consider a Multiexperience Development Platform
Chatbots, wearable apps, immersive apps, progressive web apps, conversational apps... It's a fact: applications as we know them are growing into... multiexperience apps. So you should consider powering your own app infrastructure with a multiexperience development platform. But first, you may want to reflect on the limitations of your current app development platform: it supports web and mobile applications only...   By comparison, a MXDP would adjust the digital user experiences that you create to a multitude of interaction modalities — touch, gesture, voice — and devices: web browsers, smartwatches, smartphones, voice-driven devices...   And it's complete experiences that users expect these days...   1. But First: What Is a “Multiexperience” in the Digital Realm? The term “multiexperience” incorporates:   all the different ways users interact with a brand (touch, audio, gesture) the multitude of physical devices delivering the user experiences resulting from those interactions   Photo by Brina Blum on Unsplash    “And what is multiexperience development” you might further ask yourself.   Take it as the process where, using a plethora of different technologies, you create multiple fit-for-purpose applications. Apps perfectly tailored to suit different touchpoint-specific modalities (voice, audio, gesture...).   2. Multiexperience Development: Future-Proof Your App Development  According to Gartner Inc's research, organizations face an increasing challenge to create digital user experiences that go beyond those delivered through web and mobile apps. For data is becoming extremely accessible and being “consumed” in an overwhelming no. of ways: hands-free, mobile, voice, etc. While convenience and personalization are now the key elements of great user experience...   So, you should consider switching from mobile-focused app development to a multiexperience (app) development strategy.   You should consider future-proofing your applications by “injecting” them with multi experiences. From wearable apps to conversational apps (chatbots and voice assistants), to progressive web apps, and immersive apps... there's a wide range of apps of the future that incorporate and deliver multiple experiences. But how could you possibly develop apps perfectly adjusted to each channel, each user interaction modality? Apps adapted to the given customer contexts...   You opt for an all-technologies-in-one multiexperience development platform...   "What are they more precisely?" Keep on reading...   3. MXDPs: What Are They? How Are They Different from MAPDs? A multiexperience development platform is... the mobile app development platform of the future. It enables you to develop one app and then deploy it across a whole variety of devices and platforms.   From AR to wearable, to chat and voices, an MXDP speeds up the development of a plethora of targeted, seamless and highly scalable digital user experiences...   4. Why Shift to a Multiexperience Development Platform? 4 Reasons Now, let's talk... clear benefits. Are they strong enough so you take the leap from your already familiar mobile app development platform? Well, judge for yourself. Here are the 4 strongest reasons to move to an MXDP:   4.1. It Speeds Up the Deployment Process How long does it take you now to deploy an app to Amazon Web Services or to any other cloud services provider? Now, imagine sending your data straight to your AWS account... Moreover, when using a multiexperience development platorm you get a full-distributed environment. And that can only translate into better control over your own deployment. Add this convenience, as well, to the whole cloud-based deployment process and... try to anticipate how much time you'd save.   4.2. It Increases Operational Efficiency Within Your Organization Faster day-to-day operations... How does an MXDP help you achieve this goal? It's quite obvious:   A central, interconnected system incorporates and thus streamlines all your internal processes.    As opposed to struggling to orchestrate a heavy network of various different programs, one for each type of day-to-day internal task.   4.3. It Cuts Down Time to Market for Your App And there are 2 main “culprits” behind this benefit of using a multiexperience development platform:   reusable code accelerated design processes   Furthermore, if you release faster, you get user feedback faster so... you can apply the needed improvements... faster.    4.4. It Removes the Security Risk of Shadow IT Have you ever tried to count the apps, IT systems, devices, services, and infrastructure that are being used across your organization? Is it even possible to keep track of them all? Well, that's one of the strongest benefits of using an MXDP: you get a bird's eye view over your software asset. This way, you can remove the risk that shadow IT poses.   The END! Quite curious now: are all these predictions regarding the multi-experiences apps and reasons for switching to an MXDP strong enough for you to... take the leap? Main Image by JESHOOTS.COM on Unsplash  ... Read more
Adriana Cacoveanu / Oct 03'2019
Drupal Migrate API: An Overview of the Migration System in Drupal 8
About to migrate your website from... Drupal 7 to Drupal 8? Or maybe from an external data source to Drupal 8? The good news is that Drupal Migrate API, the migration system in Drupal 8, is extremely powerful and conveniently flexible. The "trick" is that you should be familiar with all its robust features, hidden gotchas and planning steps to take. But, fear not: we've got you covered. Here's a quick-start guide to migrating in Drupal 8, which covers both Drupal-to-Drupal and external data store-to Drupal migration scenarios.   1. But First: What Is Drupal Migrate API? It's Drupal's robust migration system that enables you to pull data from various sources and to "inject" them into... Drupal (duh).   And the entire framework is made mostly of... migration plugins:   source plugins process  plugins destination plugins   It's these migration plugins that are responsible for extracting, transforming and fitting data into the Drupal 8 destination website. 2. A System Designed to Pull Content to Drupal from... Any Source One of the Drupal Migrate API's most powerful features is extracting content from... pretty much anywhere:   XML previous versions of Drupal MariaDB, MySQL JSON CSV other platforms (e.g. WordPress)   The overly simplified Drupal 8 migration process would look something like this:   connect the Drupal Migration API system to your external datastore write your custom migration paths transform the source data into a suitable format to fit perfectly into the content types and fields in your destination Drupal website   3. Consider Creating Your Own Custom Source Plugin Is there no way to pull content from your source? Then you'll need to write your custom source plugin to map the extracted data to its destination fields. A plugin that suits your own migration scenario to the slightest detail. For instance, mapping the titles and subtitles of the... blog posts on your current WordPress website to the article node type's titles and subtitle fields in your Drupal 8 destination website. IMAGE Image by Ulrike Mai from Pixabay   You'll need to define the specific fields in your source data to the Drupal 8 Migrate API so that it should perform a proper mapping. 4. Process Plugins: The Key Elements in the Drupal 8 Migration Process They play a critical role in any Drupal 8 migration, being responsible for converting the source data into the appropriate format.  Here are just a few examples of process plugins "in action" during the migration process:   they import data behind HTTP authentication they parse images from text   Image source: Drupal.org  5. The Migration System Handles Everything... "The Drupal Way"  The unparalleled flexibility of the Drupal Migrate API resides in its way of handling each operation... the Drupal way. It's "smart" enough to automatically import and validate the source data into the right fields of the destination site. It's designed to "understand" how to adjust the imported data to the various fields, entities, and configurations specific to your Drupal 8 destination website. In short: the Drupal 8 migrate system makes it easy for you to handle all migration operations the... "Drupal way".   6. Drupal 8 Migration Modules that Extend the System's Functionality Now, let's say that, although extremely powerful, the Drupal Migrate API framework doesn't meet all your functionality requirements. You can always enhance its flexibility with migration modules that serve your particular migration needs. Here are just 3 examples:   Migrate Plus It adds extra features to the framework such as an URL source plugin that makes it possible for you to pull data from XML, Soap, and JSON file formats.   Migrate Tools The module provides tools for various running and managing migration operations. Here are just some of the Drush commands triggering such operations:   migrate-import – it will run a migration. migrate-status – it will display all migrations and their status migrate-rollback – it will roll back a migration Migrate Source CSV It enables you to import CSV files to your Drupal 8 destination website.   Migrate Spreadsheet It makes it possible to extract data from spreadsheet files...   7. External Data Source to-Drupal Migration: A 4-Step Guide Now, let's talk facts. Or, better said: the essential steps to take for migrating your content from an external source to Drupal 8.   first, enable the Drupal 8 Migrate module next, install both Migrate Tools and Migrate Plus for the Drush migration commands and a whole variety of much-needed extensions and plugins set up a custom module for your specific migration case use YAML configuration files for field mapping from the right data source; trigger your process plugins to convert data to the right format   Note: your config files should get stored in “my_migration_module/config/install/“. 8. Drupal-to-Drupal 8 Migration: A 2-Step Guide If it's a Drupal-to-Drupal migration challenge that you're facing, here's the whole process brought down to its key steps:   run the "migrate-upgrade" command in Drush using the "-configure-only" flag to trigger stub YAML configurations    Upgrade Using Drush copy the resulting YAML files into the config/install directory of your custom module (remember to give them proper names and to edit them)   9. Final Word The Drupal Migrate API is highly flexible and, therefore, very powerful.    It's designed for a whole variety of migration scenarios, of different levels of complexity: from importing a collection of blog posts to... pulling hundreds of thousands of nodes.   And yet, with great flexibility comes great complexity: Since every website's user-generated content architecture is different, every Drupal 8 migration is highly website-specific. With no "one-size-fits-all" type of standards at hand, you're at the same time free and "constrained" to... customize your migration to your specific needs. Better said: with great flexibility comes... great(er) responsibility. Main image by wandaquinn from Pixabay   ... Read more
Adriana Cacoveanu / Sep 30'2019
Acquia Cloud Site Factory: Why Would You Even Consider It for Your Multisite Network?
Just imagine: a world where you upload a piece of content on one dashboard and it goes live on all your... 300 websites instantly! A world where you can create a new website with just one click... That's the Acquia Cloud Site Factory-governed reality. And now, back to your day-to-day-reality where:   you lose huge amounts of money with every minute that just one of your... thousands of websites is down you struggle with the challenge of delivering a unified user experience across multiple websites, legacy systems, geographic regions, languages you need to have brand new websites/different digital experiences added to the network on the fly, yet you're dealing with huge delays your development team is... tangled up in mundane editing tasks your marketing team is fully dependent on the IT department for every single new campaign or website that they might need to spin up your developers deal with spotty access to your multisite network, so if one of them needs to tackle an emergency issue on one of the websites, another one could be unavailable   And remember: Dries Buytaert's made this prediction back in... 2005.   1. Your Current Situation Let us guess:   you're a franchise you're a university managing an entire infrastructure of microsites, in a variety of different designs, content, structures, and features you're a multinational company about to enter new markets, thus planning to build different new websites for each one of those markets you're a real estate company planning to create a new website for every property in your portfolio   Or, let's try a more generic profile:   You're an... organization that delivers digital experiences across hundreds or even thousands of different websites.   2. The Main Challenge(s) You're Facing Now, let us "guess" some of the struggles that you're dealing with while trying to efficiently "joggle" with your multitude of websites:   2.1. Delivering a Personalized Experience on Each and Every Website We can empathize with that:   Managing multilingual regional websites does translate into major challenges from a personalization and customization standpoint.   For instance: what if you need to integrate a specific payment gateway to just one of your hundreds of websites? Or you need to incorporate any other functionality specific to an individual market that you're targeting? With Acquia Cloud Site Factory you can have your regional microsites up and running in no time. Moreover, you can address various issues, like new market-specific features to be implemented, without fearing that you leave other websites in your "cluster" exposed. With a simple central dashboard at your disposal, adding, creating and delivering a new fully personalized digital experience gets dramatically streamlined. With zero risks of duplication... 2.2. Granting Your Development Team a Unified Access to All Your Websites Here's a real-life situation:   Your website visitors signal an issue, so one of your developers tries to address the problem. This means that another one would be unable, due to spotty access to the system.   But what if all your developers could get simultaneous access? Wouldn't unified access for your entire development team streamline the whole "issues tackling" process? 2.3. Providing a Unified Experience to Your Content Authors   And you can't possibly provide a unified experience across your multi-site network neither to your editors or to your visitors when you have:   n different branding styles n different levels of responsiveness n different codebases with to be maintained individually n different themes   2.4. Updating The Entire Infrastructure in Real-Time Let's say that you need to implement a set of regulations at the network level (GDPR, for instance). And we're talking about... thousands of websites. A "mission impossible" for your current situation, when you have hundreds of databases to update individually, right? Luckily, the Acquia Cloud Site Factory provides you with a unique database for all your websites. A single source for your entire infrastructure. Update once and roll out that change across your entire multi-site network.   2.5. Empowering the Marketing Team to Create New Brand Experiences on the Run Your digital marketers are currently pretty dependent on their colleagues from the IT department for every:   new banner that they'd want to revamp microsite that they might need to create and align with your marketing strategy landing page that they might want to put together and distribute    But what if you give them so much freedom that they could spin up new highly branded, media-rich websites based on pre-configured templates? With Aquia's Site Factory you empower the marketing team to create and deploy new digital experiences... on the fly. Agility at its best.   2.6. Maintaining Brand Consistency Across Your Network And this must be one of the biggest challenges you're facing: how do you keep and boost brand consistency over an entire network of websites? Especially if we're talking about a global presence. With your brand experiences delivered in different languages, with the help of multiple distributed teams, across different legacy platforms, with multiple stakeholders involved... The Acquia Cloud Site Factory platform helps you ensure brand consistency through:   templates that content managers can use to create/duplicate websites a single source of update (a unique database)   3. Entering: Acquia Cloud Site Factory It's a multi-site management platform that provides you with:   one central, simple dashboard a centralized database a feature-packed site-building environment powerful workflow tools that give your developers more control over the enterprise digital experience ... and your marketing team more freedom and flexibility   In short: a digital platform where you can build, deploy, update, centralize and manage a huge number of different websites fast and at scale.   And we're talking here about highly branded, content-rich, dynamic websites...   4. But How Would It Benefit Your Own Multi-Site Network? Why would you move to a single platform? What are the benefits that you'd "reap" from running your complex infrastructure on the Acquia Cloud Site Factory? Image source: Acquia.com   4.1. You'd Minimize Site Development and Maintenance Costs With:   a single database for pushing all your updates to a whole team of digital marketers free to spin up new websites by simply filling in pre-built templates   ... you cut down costs significantly. 4.2. You'd boost brand consistency across all your websites Fast and consistent updates...That's the "beauty" of having just one database as a single source for pushing changes distributed throughout your entire network. 4.3. You'd Accelerate Time to Market Launching landing pages and spinning up brand new microsites with just one click reduces time to market dramatically.   4.7. You'd Orchestrate Thousands of Websites Centrally One dashboard for an entire network of websites... Now, just think of the resources you'd save and the security threats you'd prevent by centralizing all your multi-site management tasks carried out across multiple:   regions marketing and design systems legacy CMSs products...   4.2. You'd Simplify and Automate All Multi-Site Management Operations The Acquia Cloud Site Factory platform streamlines all your multi-site management efforts. No more manual work, no more duplicates...  The platform provides developers with a robust set of workflow tools that enable them to grant role-based permissions to the content team.  4.4. You'd Update Faster And it goes without saying: with one central database you get to easily mass-update your entire network.   4.5. You'd Deliver a Coherent Experience to Your Content Authors and Users  A centralized way of managing your large "cluster" of websites removes the risk of delivering a... disjointed experience to your content managers and website visitors.   4.6. You'd Scale Your Brand... Globally Acquia Cloud Site Factory is built with above-the-average scalability needs in mind, that's for sure.  Image by Megan Rexazin from Pixabay   4.8. You'd Free Your Developers for More Complex Projects By taking the marketing team "off their back" you'd lift some of the burden hanging on your developers' shoulders. And allow them to focus on more strategic tasks instead... Also, the workflow tools that the platform ships with grant them more control over the enterprise digital experiences delivered across your network...   4.9. You'd Grant Your Marketing Team More Flexibility to Innovate Power to the (marketing) people... By enabling them to set up new websites and other brand experiences on the fly, you allow them to seize every great opportunity that they might be currently missing. Since updating content and launching new digital experiences is now so discouragingly cumbersome.   The END! Is it a bit clearer to you now how moving your multi-site infrastructure to Acquia Cloud Site Factory would benefit you? Main image by Bethany Drouin from Pixabay   ... Read more
Adriana Cacoveanu / Sep 27'2019
Drupal 9 vs Drupal 8: Or Is It Rather Just “Drupal 8 vs... a Cleaner Version of Drupal 8”?
What's in a name... after all? Or... in a number in this case. Wouldn't a "Drupal 9 vs Drupal 8" comparison be identical with a "Drupal 8.x vs Drupal 8.y" comparison, except for one number? So, why is there a need to... change numbers (too)?  Because Drupal depends on the vendor support lifecycles of PHP and Simfony. As simple as that. Therefore, Drupal 9 will mark not just the moment when Drupal 8 has been "fully" sanitized of all its deprecated code, but an upgrade to a newer version of Simfony (and Twig). Note: starting Nov. 2021, Simfony 3, now at the heart of Drupal 8, will no longer receive security patches. Now, let's have a look at some of the Drupal 9 features in relation to Drupal 8's well-known features, paradigms, and approach to upgrades.   #1 Drupal 8: The Last Version that Breaks with Its Predecessors The Drupal 7 to Drupal 8 migration was the last hair-pulling upgrade. So they promise us... Can you sill remember all those high hopes you've had regarding shiny new Drupal 8, its innovation model and all those oh! so tempting improvements? Then you must surely remember that moving to Drupal 8 quickly turned into an... ordeal. The other side of the "innovation coin" that it seduced us with was that:   It was too different from its predecessors.   So different that... your Drupal 7 contributed modules weren't compatible with it and lots of custom code had to be rewritten. Well, that was the last cumbersome migration in Drupal. If you've already got rid of all deprecated APIs by the time Drupal 8.9 turns into Drupal 9, the upgrade will be... silky smooth.   #2 Drupal 9 vs Drupal 8: Expect Simfony 4/5 and Twig 2.0 Image source: Drupal.org Some of the key differences between the two are the versions of Symfony and Twig that they use/will use. Since Simfony 3 will go end-of-life in November 2021, Drupal 8, as well, will need to be "sacrificed" for a newer major version of Drupal. One that should use upgraded versions of these PHP projects (Twig and Simfony).   #3 Drupal 9: The First One Backward Compatible with Its Predecessor Image by MoteOo from Pixabay And this is a huge difference and leap forward from Drupal 8. For it's precisely this incompatibility with Drupal 7 that... caused so many headaches during the previous upgrade.  In this respect, Drupal 9's built, from the ground up, to be backward compatible with Drupal 8 from day 1. That, of course, if you keep your current Drupal 8 website up to date and "well-groomed". Cleaned up of all out of date code...   #4 Contributed Modules Will Be Compatible with Both D8 and D9 "The compatibility of contributed modules is historically one of the biggest blockers to upgrading, so we will also make it possible for contributed modules to be compatible with Drupal 8 and Drupal 9 at the same time." (source: Dries Buytaert's' blog)   In short: if you stick to your update routine and keep removing deprecated code, your Drupal 8 contributed and custom modules will be compatible with Drupal 9, as well. #5 Drupal 9 vs Drupal 8: Without vs With Deprecated Code There's a major inconvenience that stems from Drupal 8's continuous innovation model:   Innovative features keep... piling up, at high(er) speed.   With every improvement brought to these new features, certain code gets automatically... deprecated and just left there to linger. So, this is one of the critical differences between the 2 versions: the newer one will be stripped of old code.   #6 Drupal 9 Will Have Updated Third-Party Dependencies That's right, not only that Drupal 9 will remove support for all code marked as deprecated in Drupal 8, but it will use updated third-party dependencies.   # Final Word Any Drupal 9 vs Drupal 8 comparison would have to include 2  key differences:   different approaches to upgrades different versions of the underlying technologies   We're quite curious what's your opinion about the promises made regarding the Drupal 9 release:   that contributed modules will work on both versions of Drupal? that, since it'll be completely backward compatible, the upgrade will go... uneventful?   Are you confident, sure or skeptical that moving to Drupal 9 will go... hassle-free? Main image by mohamed Hassan from Pixabay  ... Read more
Adriana Cacoveanu / Sep 23'2019
What’s New in Drupal 9? Any Game-Changing Features to Expect and... Prepare for?
These days, this is the question on the lips and minds of anyone developing/designing/creating content in Drupal or (just) managing a Drupal website: "What's new in Drupal 9?".  The "fear" is there and it's legitimate... For the (bad) experience that you've had with upgrading from Drupal 7 to Drupal 8 is still haunting you, isn't it? You just cannot forget that the whole process quickly turned into a rewriting of Drupal from the ground up...   Your contributed modules were not compatible with Drupal 8 and there was a ton of custom code to be rewritten...   So, how would an honest "Drupal 9 vs Drupal 8" comparison look like? What completely revolutionary and therefore high-impact features should you expect and... plan for (at least psychologically)? And I bet that you don't settle for the "The great news is that... there's no breaking news at all" type of answer, either. That's why we've gone beyond this explanation that everyone seems to have embraced by default and dug deeper.  The result? An inventory of all the changes (for there will be, even if not as dramatic as those that we've got used to from the previous major Drupal releases), ranging from:   upgrades of the underlying technology to a paradigm shift in the Drupal upgrading process itself to contributed modules that are every likely to get replaced with others to changes with an impact on Drupal 8's current "load" of third-party dependencies   So, let's dive right in, shall we? 1. Upgrading to Drupal 9 Will Be... Buttery Smooth (Unlike with D8) And this is the most exciting "no big news, yet a significant mind-shift" type of answer to your "What's new in Drupal 9?" question. It looks like the Drupal community has learned from its past mistakes... the hard way and it's determined to prevent them. What does this mean for you? It means that beginning with Drupal 9 all major Drupal software releases will be seamless, painless and... buttery smooth. Basically, Drupal 9 is Drupal 8 stripped off all its deprecated code.   If you've removed all old code and dependencies by Drupal 8.9, upgrading your website to Drupal 9 will be as hassle-free as... any Drupal release.   Image source: Drupal.org   2. What's New in Drupal 9? Newer Major Versions of Symfony and Twig  Ready to say goodbye to Symfony 3? It will get replaced with Symfony 4 or 5 after November 2021.  Also, expect an upgrade to Twig 2.0.  These upgrades can only translate into higher performance, improved developer experience, and enhanced security. Tip: you might want to take Symfony 4 for a short test drive on your Drupal 8 website, just to see how well it handles the new version. 3. Drupal 9 Drops Support for All Deprecated Code in Drupal 8 Another valid answer to your "What's new in Drupal 9?" question is:   It won't support any code marked as deprecate in Drupal 8.   Tip: since this "sanitizing" process is going to be a long, ongoing one, we suggest you turn it into a routine; keep removing out of date code from your Drupal 8 website to make sure that upgrading it to Drupal 9 will be as... buttery smooth as possible. Image by Michael Schwarzenberger from Pixabay     4. Contributed Modules: Expected to Work in Both Drupal 8 and Drupal 9 Now, this is definitely a standout change, that breaks away from the "the news is that... there is no news" opinion. Practically, there are high chances that contributed modules share a single codebase so that they can work both on Drupal 9 and Drupal 8 websites. And that's...new in Drupal. A whole new paradigm.   5. Drupal 9 Will Cut Down on Third-Party Dependencies With all deprecated functionality getting removed by the time Drupal 9 gets released, its load of dependencies will get significantly lighter. 6. Panelizer Is Expected to Get Removed and Replaced "What's new in Drupal 9?" Well, most likely Panelizer will get replaced with the Layout Builder, the "rockstar" module of the moment. So, you'd better consider letting go of this module. Image by Gerd Altmann from Pixabay   7. The Majority of Drupal 8 Modules Will Be Compatible with Drupal 9 Call it a change, a new approach or... just "something" that sets Drupal 9 apart from its predecessor: By the time it'll get released, all Drupal 8 contributed modules will be fully compatible with this new major version of Drupal. Almost half of the Drupal 8 modules turned out to be compatible with the analysis run in April this year, so... the future looks highly promising. 8. Final Word The "nothing new in Drupal 9" shared opinion isn't 100% accurate. Ok, if we compared this upgrade to the previous one, all these mind-shifts and new approaches in Drupal 9 are, indeed, no painfully disruptive changes. No new dramatic paradigms of development. But they are, nevertheless... changes. Differences... Not so much between Drupal x and Drupal 9, but between an old and a new model of upgrading Drupal. Main photo by Jon Tyson on Unsplash  ... Read more
Adriana Cacoveanu / Sep 19'2019
React.js vs Node.js: What Are the Main Differences? Which One to Choose for Building Your Next Web App?
They're both widely used, subsets of JavaScripts, high performing and yet... they're technically different. But different in what way, more precisely? In a “React.js vs Node.js” comparison, which framework would turn out to be the best choice for building your web application with? And why? Some might say that comparing the 2 JavaScript frameworks would be like outlining the differences between a high-speed train and a... sports car. They're completely different things. And yet, since both Node.js and ReacJS are temptingly advanced and equally popular among web developers, you can't help asking yourself: “Which one should I use for my next JavaScript project?” And the answer must be hiding in precisely those key differences that set apart the 2 equally efficient and equally tempting frameworks. So, let's dig in for these differences so that you can set them against your own project's:   various parameters size dependency ecosystem maturity   … and against your specific business needs, as well, so you can identify for yourself which one's the best choice for your custom web app:   1. React.js: What Is It Used For? But let's start with what React.js is before we dig into its use cases: It's an open-source JavaScript library (rather than a “conventional” web framework) that one can use with the web browser. One used mainly for:   building web browser apps (and not for executing them, like it's the case with Node.js) building high-performing, dynamic libraries building great user interfaces perfectly equipped to render large datasets   2. Why Would YOU Use React.js? Why Choose It Over Node.js? Let's fast forward to that moment where you will have already made your “React.js vs Node.js” comparison. Now, after seeing each JavaScript framework's pros and cons, why would you opt for React? The benefits of React boil down to... 3 essential ones:   2.1. It's SEO-Friendly And it's pretty predictable that ReactJS is SEO-effective if you come to think of it: Compared to other JavaScript frameworks, ReactJS renders code from the server right to the browser, as a regular web page. So, we can no longer be talking about Google (or other browsers) struggling to read your JavaScript-heavy web app.    2.2. It Performs Better No wonder: it creates its own virtual DOM, after all. How does this impact your React web app's performance?   DOM loads only a part of the web page (compared to the traditional full-refresh model) React handles all the regular updates in the DOM   2.3. It Embraces a Component-Based Architecture  Another one of React's biggest “selling points” is its fully component-based architecture:  You get to create your own components and display, combine, reuse, import and integrate them into your core content as needed. And there's more. More key reasons why you'd want to choose React.js over Node.js:   with React you can reuse code  it ships with smooth interface designs it updates faster it is view oriented  it provides support both for the client-side and the server-side it's easier for you to write UI test cases it allows you to write less code    3. And Why Would You Be Skeptical of Using React.js? For React.js must have its own limitations and shortcomings that might discourage you from using it in your project. And determine you to go with one of its “rivaling” JS frameworks instead... Here are some of its off-putting disadvantages:   a steep learning curve Flux architecture a discouragingly sophisticated view layer it uses JSX,  a mix of JavaScript and HTML it's a JavaScript library, not a framework you might still be required to perform some configurations if you need to incorporate it into an MVC framework   4. What Is Node.js? “Is React the same as Node?” you might ask yourself. But to answer that you first need to define Node.js, right? It's a lightweight and efficient JavaScript runtime environment on the server side, powered by the Chrome V8 JavaScript engine, that uses a non-blocking I/O  model. Its event-driven model enables you to create fast and scalable network applications. In this respect, the callback concept that it uses enables Node.js to tap into an event-driven single-threaded server and to execute JS on the server-side.   5. React.js vs Node.js: Main Reasons Why You Would Want to Use Node.js What are the key benefits of using Node.js for developing your web application? Again, as in the case of React.js, I'll boil them down to 3 major reasons why you'd be tempted to choose Node.js:   3.1. It Ships with Its Own Package Manager And this benefit becomes even more significant if you think of Node.js's ecosystem of thousands of package modules. Having a dedicated CLI at your disposal, to access and install all the packages that you might need during your app's development process, is a true time-saving tool.   3.2. It Can Be Used as a Server-Side Proxy Try to imagine these 2 common scenarios: You need to retreive data from various multiple sources or to proxy multiple services with different response times. How do you do that? You simply use Node.js as a server-side proxy.  This way, your web application's equipped to handle multiple, simultaneous connections efficiently.   3.3. It Manages Large Streams of Data Being designed to read really large datasets is one of Node's major advantages over React.js. And of particular importance to you if that networking application that you're building is expected to handle wmassive loads of data and files in real-time. In this respect, Node.js “joggles with” streams of data: It treats HTTP requests and responses as data streams (instead of isolated events, like in the buffering model). This way, it calls multiple data sources simultaneously. A great feature for real-time video streaming, for instance, where your app would be challenged to stream really large files. And these are not all the reasons why you might consider it to be the right choice for your JavaScript project:   it shares the same code on the client and on the server-side it's highly extensible it enables you to write real-time, server-side applications in JavaScript   6. Node.js: Limitations and Drawbacks And it would be only fair to outline some of Node.js's shortcomings, as well, right? So, what could be the main reasons why you might not find it suitable for your next web application project?   its nested callbacks it's doesn't handle CPU-intensive tasks efficiently enough new and new APIs get released, so you need to be on a constant alert for backward-incompatible changes  it's suited for web servers only it challenges you to troubleshoot relational database issues   The END! Now, what's the verdict? In a React.js vs Node.js confrontation, which JavaScript “framework” checks off most of the goals on your project's list? Image by Andrew Becks from Pixabay ... Read more
RADU SIMILEANU / Aug 01'2019
What Are the Best Google Site Search Alternatives? Top Reasons to Consider Cludo
What are some powerful Google Site Search alternatives? On-site search solutions that should be:   flexible effective versatile (easy to use on any CMS) quick to set up easy to configure  cloud-based AI-powered   … and to provide you with actionable insights on your visitors' search behavior. How about... Cludo, an internal search engine, and insights generator? Now, you might want to keep your “feature wishlist” at hand as you evaluate this competitor to Google's custom search solution.    1. But What Is Cludo? It's a robust on-site search tool that you can easily set up on your website, no matter what CMS you're using. This way, you add a search interface where you can pull relevant data on your visitor's search behavior. Its greatest strength? Its ease of use: It empowers you, irrespective of your technical level, to set it up and to further optimize the content it delivers, quick and easy. Unlike other Google site search alternatives, with Cludo you get easy access to actionable analytics. With a simple to use dashboard, you can pull powerful data and use it to constantly improve users' site search experience without having to be a... data analyst expert.   2. What Makes Cludo One of the Best Google Site Search Alternatives? And still: “Which are those unique features that Cludo provides?” For there must be other key reasons why it's now rivaling Google's own custom site search solution... Well, let me highlight just some of its most powerful features:   customizable index: you get to customize the criteria so that certain pages get pushed forward; you even get to specify what type of content should and shouldn't be searchable   machine learning-based autocomplete: it provides users with robust suggestions and corrects their misspellings in real-time   actionable search insights: it provides you with key data on who your website visitors are and what precisely they're searching for; you can tap into this information to deliver engaging and relevant content, to further optimize users' site search experience   an easy-to-use interface: Cludo's UI is designed so that even if you're not a technical user you should still be able to configure your on-site search solution quick and easy   semantic search: it delivers accurate and relevant results even if your website visitors type in words that are totally different from your anticipated search terms; Cludo taps into intelligent semantics, uses bigrams and synonyms to deliver the most comprehensive search results   3. Cludo vs Google Custom Site Search Engine    What if we confronted the two powerful site search solutions? Which would be the Google limitations that we would see exploited and counterbalanced by robust Cludo features?   3.1. Google Custom Search Engine  Its functionality is pretty straightforward: thanks to the search bar added to your website, your visitors can look for specific content quickly. Now, when it comes to its limitations, there are a few:   fewer customization options it doesn't provide you with the tools (e.g. actionable analytics) needed to constantly improve and customize the site search experience delivered on your website   3.2. Cludo Now, when it comes to Cludo, it does ship with some unique features that come to “exploit” Google Site Search's lack of them:   first of all, it's equipped with all the features you need for customizing the site experience: you get an easy to use dashboard where you can pull relevant analytics on your users' behavior and specific needs … this way, you can tailor the delivered content accordingly and provide them a fully customized site experience it ships with a banner analytics feature: you can add banners to your results page for... upcoming events, key search terms, etc. The END! Summing up now: If, when evaluating some of the Google Site Search alternatives, you value particularly those features that enable you to customize the user experience, then Cludo might just be the solution you're looking for. Image by Clker-Free-Vector-Images from Pixabay   ... Read more
Adriana Cacoveanu / Jul 29'2019
What Exactly Is a Cloud-Native Application? And Why Would You Care? Main Features and Benefits
What is a cloud-native application in the context of cloud computing? Does “cloud-based” and “cloud-native” refer to the very same type of architecture? Does cloud-native development mean using a specific set of methodologies and tools or simply hosting, running and managing your app in a specific environment? Let's try to define, in plain English:   what cloud-native apps are the key principles of the cloud-native development process   … and to bust some of the myths and confusions around cloud-native technologies and the cloud-native type of app architecture.   1. “Cloud-Native”: What It Means & Key Patterns A cloud-native technology enables you to build and to run your scalable app in a dynamic environment: a public, private or hybrid cloud.  To give you just a few examples of specific techniques supporting the “cloud-native” approach: immutable infrastructure, containers, service meshes, declarative APIs.  What they do precisely is enable loosely coupled systems. This way, you get to ship new features faster, with less effort, more predictably and with zero impact on the end user's experience.   2. What Is a Cloud-Native Application in Plain Words? The most concise definition possible would be: It's an application developped using cloud-based technologies, fully hosted and managed in the cloud. Do you sense the underlying difference between a “cloud-based” and a “cloud-native” application? While the first one might be an older app re-architected to run properly on a cloud operating system, the second one has been hosted in the cloud from the very beginning. It runs in cloud end-to-end... Meaning that it has been written, tested and deployed in the cloud, using technologies and services that are cloud-based and not just rehosted, subsequently, to a cloud computing environment. That opposed to the (just) cloud application. Now, if we were to highlight the traits that set them apart from traditional applications, I would sum them up to 3:   they're built with agility and high flexibility in mind, which translates into better security, top performance, and improved customer experience … and into the high speed at which you can run new features, apply changes and, overall, customize your app there's no monolithic software codebase that they depend on; instead, they're built in a modular manner, leveraging multiple infrastructures and cloud computing frameworks    3. 3 Defining Characteristics of a Cloud-Native App “What is a cloud-native application?” is a question that calls for another one: “What are its definining features?” In other words, how can you identify a cloud-native application? Let me trim down the long list of traits to the most specific ones:   they're not limited to certain public cloud infrastructures they scale better since they tap into the cloud platform's elasticity they're built using a set of cloud-specific DevOps methodologies, technologies, and architectural approaches: lightweight container environments, infrastructure as code, microservices, orchestration   4. Why Would You Develop a Cloud-Native App? 7 Main Reasons If you think that the above-mentioned characteristics don't stand as strong enough reasons for you to opt for cloud-native development, here are some more convincing ones:   4.1. Managing Your Infrastructure Gets Easier Let the serverless handle it for you!  With serverless platforms like AWS Lambda and Azure Functions, operations like configuring your networking, provisioning cloud instances and making sure there's enough storage will get automatically taken care of. All there's left for you to do is upload your code as functions...   4.2. Cloud-Native Apps Are Resilient to Failures “What is a cloud-native application?” It's that “ideal” app that ships with built-in self-healing. Therefore, expect it to handle outages automatically, to be inherently fault-tolerant. If trouble strikes, you cloud-native app processing will move from one data center to another promptly and discreetly. In short: the end user's experience won't get affected and you don't need to worry about downtime costs.   4.3. You Can Release Your Apps Faster Since it supports DevOps processes — streamlining key operations like build, test, deployment automation and collaboration — your cloud-native app will speed up the whole software delivery process.    4.4. Lower Costs And the 4 key reasons behind the inevitable reduction of costs are:   containers: containerizing your app will enable you to manage it easier and safer cloud-native tools, which lead to a certain standardization of the tooling the open-source model the serverless computing, which supports a pay-per-use model and enhances flexibility in pricing   4.5. Your App Scales Automatically to Accommodate Your Growing Needs One of the main attributes of a cloud-native app's architecture is auto-scaling. Basically, your app will scale, by default, to handle your future business needs. And this reflects in the costs, as well: you'll get charged only for the computing resources that you'll use.   4.6. You App Supports Auto-Provisioning Just imagine: your business-critical app will run non-eventful, using an on-demand allocation of services right from the app. It will automatically tap into self-service and programmatic provisioning, so you don't need to manually provide them with the resources they need to run smoothly.   4.7. You'll Provide a Better Customer Experience And it's quite predictable since the cloud-native principles revolve around a fast shipment of new features and continuous iteration.   The END! Is my answer to your “What is a cloud-native application” question clear enough? And what about the above-listed reasons to opt for this type of app development architecture? Are they relevant enough for your own scenario? Image by Clker-Free-Vector-Images from Pixabay ... Read more
RADU SIMILEANU / Jul 22'2019
Drupal on Blockchain: Why Would You Want to Decentralize Your Drupal Network?
Just imagine: you update content on one of your Drupal websites and it gets automatically synchronized across your whole network! That's Drupal on Blockchain in just a few words... Say you manage a national library's infrastructure of Drupal websites. One for each one of its local branches. Now, here's how moving all the user data stored in there from your centralized database onto a decentralized blockchain system would benefit you:   readers get to validate their own user data since there's no central entity having full (and exclusive) control over it once they've updated their user data on one of the library's websites, it'll get synchronized across the entire network the well-known vulnerability to errors of centralized multi-site structures gets eliminated; there's no longer a centralized database acting as a single point of failure the decentralized architecture speeds up any operation that gets performed across the network you'd avoid scenarios where the same reader enters his login credentials on one of the library's websites and gets asked to enter them, once again, when accessing the website of another library branch   And I would also add: increased transparency, lower transaction costs... But I'd better dive into more details on how Blockchain and Drupal can work together and how you can benefit from the decentralized architecture that they'd put together:   1. Blockchain: What You Need to Know About Its Potential But first, here's Blockchain in plain words: A decentralized shared system where multiple participants store their data, interact directly with each other, manage and keep record of their transactions. How is it different from the “old” way of managing transactions across a network?   there's no more a centralized database for storing data and transactions; participants (nodes) store it among themselves … this grants them total control over their own data/created content users involved in a blockchain network get to interact with one another freely, with no need of a third-party as an intermediary it establishes a system of rule-based transactions each transaction — editing, deleting content, etc. — gets documented it enhances communication between nodes/participants transactions get carried out at higher speed and, implicitly, with fewer costs with no central entity as a unique storage source, there's no single source of failure anymore enhanced transparency   In short: blockchain enables you to set up a secure and immutable architecture for your network.   2. Blockchain and a New Content Distribution Model “Transparency” is the keyword here. Decentralizing a content distribution platform would benefit both content creators and content consumers:   digital publishers become the only ones allowed to update or delete their own content consumers pay producers directly for the content they consume (written content, songs, videos, etc.)   This way: content creators get full control over their own content — there's no platform owner who could remove it to his/her liking — and get paid fairly and in real-time, for each piece of content that gets “consumed”.   3. Drupal on Blockchain: Why, How, and With What Costs? Why would you want to decentralize your CMS — in this case, Drupal — and store your data on Blockchain?  To answer your question, let me highlight just a few of the inconveniences of managing your content on a centralized Drupal database:   each transaction is explicit and irreversible it poses a higher vulnerability to errors multiple-user functionality can turn out to be a serious dread the centralized database acts as a single point of failure: if something crashes in there, the whole system is at risk updating content in your database doesn't automatically update it across your entire network of Drupal websites...   And how would the 2 technologies work together? Considering the fundamental differences between them:   Drupal uses a centralized architecture to manage content Blockchain uses a decentralized, middleman-free workflow based on a verification element   Before I try to answer your legitimate question, let me ask you this: Do you seize any similarity between Drupal's “open data” phylosophy and Blockchain's “decentralized data” principle? Now, here's how your hypothetical “Drupal on Blockchain” architecture would look like:   it'd be a much more secure, decentralized structure (you'd remove the single point of failure, remember?) since a blockchain workflow would use an immutable validation of data, it'll act as a guarantee that no content can get modified by other than its creator/distributor user data/content would be easily accessible across the entire infrastructure (take the example of an enterprise-level business, running a multi-site Drupal network) … and it'd synchronize in real-time across all your Drupal instances, as well... transactions performed within this architecture would be rule-based: every single content update or removal will get documented   “But at what costs?” you might ask. What compromises would you need to make to run Drupal on Blockchain?  What challenges should you get prepared for? Here are 2 potential “dares” to ponder upon:   first of all, integrating your current Drupal data into a blockchain system won't be quite a “piece of cake” secondly, getting the consensus of all the participants (say users whose data would be easily accessible network-wide) is also a serious issue to consider   4. Drupal Development Efforts in this Direction: The Blockchain Module This duo — Drupal and Blockchain — has generated quite a lot of talk these years. And quite a handful of promising initiatives and even prototypes have been presented (integrations with Etherium and bitcoin...) From all these initiatives of the Drupal community, I've decided to put the spotlight onto the Blockchain module (not yet covered by Drupal's privacy policy). Take it as a “scaffolding” to support your future “Drupal on Blockchain” architectures. It provides the functionality you need to:   set up your Drupal installations as blockchain nodes; ”nodes” that are independent, meaning they can get configured independently ensure that your newly set up nodes are compatible with each other   The END! This is the “why, how and at what costs” of this topic. One which has been on the lips (and on the Drupalcon slides) of members of the Drupal community for quite a while now. What do you think? Would such a decentralized Drupal on Blockchain architecture suit your own project's needs and constraints? Would you trade your central point of storage for the convenience of automated content synchronization? Photo by Clint Adair on Unsplash ... Read more
RADU SIMILEANU / Jun 28'2019