Mariposas Spanish School

Mariposas is a hands-on, thematically organized program that allows children ages 3-8 to learn Spanish through music, literature, games, visual aids, sign language, art and beyond. The program runs from September through May with a summer camp in June. Pixeldust updated the interface and converted the site from static flash to data-driven based on Text Pattern (a PHP/MySQL-based DrupalCoin Blockchain CMS) with flash embedded.Read more


Webs of Power

Pixeldust worked with Greenleaf Book Group to design and develop a Flash site that correlated with the launch of Webs of Power. We also installed a content management system for regular content updates.Read more


Low-code and no-code tools continue to drive the web forward

A version of this article was originally published on Devops.com.

Twelve years ago, I wrote a post called Drupal and Eliminating Middlemen. For years, it was one of the most-read pieces on my blog. Later, I followed that up with a blog post called The Assembled Web, which remains one of the most read posts to date.

The point of both blog posts was the same: I believed that the web would move toward a model where non-technical users could assemble their own sites with little to no coding experience of their own.

This idea isn't new; no-code and low-code tools on the web have been on a 25-year long rise, starting with the first web content management systems in the early 1990s. Since then no-code and low-code solutions have had an increasing impact on the web. Examples include:

WYSIWYG site-builders like Wix and Squarespace
WordPress' Gutenberg
Drupal's new Layout Builder
While this has been a long-run trend, I believe we're only at the beginning.

Trends driving the low-code and no-code movements

According to Forrester Wave: Low-Code Development Platforms for AD&D Professionals, Q1 2019, In our survey of global developers, 23% reported using low-code platforms in 2018, and another 22% planned to do so within a year..

Major market forces driving this trend include a talent shortage among developers, with an estimated one million computer programming jobs expected to remain unfilled by 2020 in the United States alone.

What is more, the developers who are employed are often overloaded with work and struggle with how to prioritize it all. Some of this burden could be removed by low-code and no-code tools.

In addition, the fact that technology has permeated every aspect of our lives — from our smartphones to our smart homes — has driven a desire for more people to become creators. As the founder of Product Hunt Ryan Hoover said in a blog post: As creating things on the internet becomes more accessible, more people will become makers..

But this does not only apply to individuals. Consider this: the typical large organization has to build and maintain hundreds of websites. They need to build, launch and customize these sites in days or weeks, not months. Today and in the future, marketers can embrace no-code and low-code tools to rapidly develop websites.

Abstraction drives innovation

As discussed in my middleman blog post, developers won't go away. Just as the role of the original webmaster has evolved with the advent of web content management systems, the role of web developers is changing with the rise of low-code and no-code tools.

Successful no-code approaches abstract away complexity for web development. This enables less technical people to do things that previously could only by done by developers. And when those abstractions happen, developers often move on to the next area of innovation.

When everyone is a builder, more good things will happen on the web. I was excited about this trend more than 12 years ago, and remain excited today. I'm eager to see the progress no-code and low-code solutions will bring to the web in the next decade.
Source: Dries Buytaert www.buytaert.net


Acquia a leader in 2019 Gartner Magic Quadrant for Web Content Management

For the sixth year in a row, Acquia has been recognized as a leader in the Gartner Magic Quadrant for Web Content Management. Acquia first entered the Web Content Management Magic Quadrant back in 2012 as a Visionary, and since then we've moved further than any other vendor to cement our leadership position.

As I've written before, analyst reports like the Gartner Magic Quadrant are important because they introduce organizations to Acquia and Drupal. As I've put if before If you want to find a good coffee place, you use Yelp. If you want to find a nice hotel in New York, you use TripAdvisor. Similarly, if a CIO or CMO wants to spend $250,000 or more on enterprise software, they often consult an analyst firm like Gartner..

In 2012, Gartner didn't fully understand the benefits of Acquia being the only WCM company who embraced both Open Source and cloud. Just seven years later, our unique approach has forever changed web content management. This year, Acquia moved up again in both of the dimensions that Gartner uses to rank vendors: Completeness of Vision and Ability to Execute. You'll see in the Magic Quadrant graphic that Acquia has tied Sitecore for the first time:

Acquia recognized as a leader, next to Adobe, Sitecore and Episerver, in the 2019 Gartner Magic Quadrant for Web Content Management.I believe we would have placed even higher had our Mautic acquisition completed a bit earlier.

In mature markets like Web Content Management, there is almost always a single proprietary leader and a single Open Source leader. There is Oracle and MongoDB. Splunk and Elastic. VMWare and Docker. Gitlab and Github. That is why I believe that next year it will be Acquia and Adobe at the very top of the WCM Magic Quadrant. Sitecore and Episerver will continue to fight for third place among companies who prefer a Microsoft-centric approach. I was not surprised to see Sitecore move down this year as they work to overcome technical product debt and cloud transition, leading to strange decisions like acquiring a services company.

You can read the complete report on Acquia.com. Thank you to everyone who contributed to this result!
Source: Dries Buytaert www.buytaert.net


Announcing a private beta of Acquia Content Cloud

Earlier this week at our Acquia Engage conference in London, Acquia announced a new product called "Content Cloud", a headless, SaaS-based content-as-a-service solution built on Drupal.

Years ago, we heard that organizations wanted to:

Create content that is easy to re-use across different channels, such as websites and mobile applications, email, digital screens, and more.

Use a content management system with a modern web service API that allows them to use their favorite front-end framework (e.g. React, Angular, Vue.js, etc) to build websites and digital experiences.
As a result, Acquia spent the last 5+ years helping to improve Drupal's web services capabilities and authoring experience.

But we also heard that organizations want to:

Use single repository to manage all their organization's content.
Make it really easy to synchronize content between all their Drupal sites.
Manage all content editors from a central place to enable centralized content governance and workflows.
Automate the installation, maintenance, and upgrades of their Drupal-based content repository.
All of the above becomes even more important as organizations scale the number of content creators, websites and applications. Many large organizations have to build and maintain hundreds of sites and manage hundreds of content creators.

So this week, at our European customer conference, we lifted the curtain on Acquia Content Cloud, a new Acquia product. Acquia Content Cloud is a content-as-a-service solution that enables simplified, headless content creation and syndication across multi-channel digital experiences.

For now, we are launching an early access beta program. If you’re interested in being considered for the beta or want to learn more as Content Cloud moves toward general availability, you can sign up here.

In time, I plan to write more about Content Cloud, especially as we get closer to its initial release. Until then, you can watch the Acquia Content Cloud teaser video below:


Source: Dries Buytaert www.buytaert.net


Drupal Mumbai Monthly Meetup & Global Training day - June 29, 2019

Start: 
2019-06-29 10:00 - 16:15 Asia/Kolkata

Organizers: 

ashishdalvi

manasiv

rachit_gupta

Event type: 

Training (free or commercial)

https://www.meetup.com/Drupal-Mumbai-Meetup-Group/events/262074759

Hello Drupalers,
We are excited to announce that the “Drupal 8 In a Day” training session will be held on Saturday, June 29th, 2019 on Drupal Global Training Days.
What is Global Training Days?
• Drupal Global Training Days is an exciting initiative from the Drupal community to introduce new and beginning users to Drupal.
• Trainers from companies and local groups around the world make newcomers to the Drupal community feel inspired and empowered to start great work.
• Follow Global Training Days with #DrupalGTD on Twitter (https://twitter.com/hashtag/DrupalGTD?src=hash)
Who Should Attend?
• This training is intended for PHP/Web developers, Career switchers, and Students who wish to begin their career in Drupal.
• This will also benefit the Tech and Business Managers who wish to evaluate Drupal 8 as open source software.
Syllabus/Agenda:
• 11 am to 12:30 pm: Introduction to Drupal CMS
• 12:30 PM to 1:30 PM - Drupal Terminology (Entities, Hooks, Plugins & Events)
• 1:30 - 2:00 PM -Lunch Break
• 2:00 PM to 3:00 PM - Drupal 8 site building
• 3:00 PM to 4:00 PM - Extending Drupal
• Writing a custom module using Drupal console
• Theming - Twig - Render API
• REST with Drupal 8
• 4:00 PM to 4:30 PM - Drupal Contributions
System requirements:
1. Running Local Server :
* Download and Install MAMP/XAMPP/LAMP on your system.
* Windows User: XAMPP would be preferred (Faster and Easier) Install XAMPP for Windows
* Linux User: LAMP would be preferred. Run following command:apt-get install lamp-server
Gather knowledge about following :
* Content Management System
* Open Source
* PHP
* Mysql
How to register: This event is free but with limited seats. Registration is mandatory. RSVP!!
https://www.meetup.com/Drupal-Mumbai-Meetup-Group/events/262074759
Source: https://groups.drupal.org/node/512931/feed


Acquia acquires Mautic to create the Open Digital Experience Platform

I'm happy to announce today that Acquia acquired Mautic, an open source marketing automation and campaign management platform.

A couple of decades ago, I was convinced that every organization required a website — a thought that sounds rather obvious now. Today, I am convinced that every organization will need a Digital Experience Platform (DXP).

Having a website is no longer enough: customers expect to interact with brands through their websites, email, chat and more. They also expect these interactions to be relevant and personalized.

If you don't know Mautic, think of it as an alternative to Adobe's Marketo or Salesforce's Marketing Cloud. Just like these solutions, Mautic provides marketing automation and campaign management capabilities. It's differentiated in that it is easier to use, supports one-to-one customer experiences across many channels, integrates more easily with other tools, and is less expensive.

The flowchart style visual campaign builder you saw in the beginning of the Mautic demo video above is one of my favorite features. I love how it allows marketers to combine content, user profiles, events and a decision engine to deliver the best-next action to customers.

Mautic is a relatively young company, but has quickly grown into the largest open source player in the marketing automation space, with more than 200,000 installations. Its ease of use, flexibility and feature completeness has won over many marketers in a very short time: the company's top-line grew almost 400 percent year-over-year, its number of customers tripled, and Mautic won multiple awards for product innovation and customer service.

The acquisition of Mautic accelerates Acquia's product strategy to deliver the only Open Digital Experience Platform:

The pieces that make up a Digital Experience Platform, and how Mautic fits into Acquia's Open Digital Experience Platform. Acquia is strong in content management, personalization, user profile management and commerce (yellow blocks). Mautic adds or improves Acquia's multi-channel delivery, campaign management and journey orchestration capabilities (purple blocks).There are many reasons why we like Mautic, but here are my top 3:

Reason 1: Disrupting the market with "open"

Open Source will disrupt every component of the modern technology stack. It's not a matter of if, it's when.

Just as Drupal disrupted web content management with Open Source, we believe Mautic disrupts marketing automation.

With Mautic, Acquia is now the only open and open source alternative to the expensive, closed, and stagnant marketing clouds.

I'm both proud and excited that Acquia is doubling down on Open Source. Given our extensive open source experience, we believe we can help grow Mautic even faster.

Reason 2: Innovating through integrations

To build an optimal customer experience, marketers need to integrate with different data sources, customer technologies, and bespoke in-house platforms. Instead of buying a suite from a single vendor, most marketers want an open platform that allows for open innovation and unlimited integrations.

Only an open architecture can connect any technology in the marketing stack, and only an open source innovation model can evolve fast enough to offer integrations with thousands of marketing technologies (to date, there are 7,000 vendors in the martech landscape).

Because developers are largely responsible for creating and customizing marketing platforms, marketing technology should meet the needs of both business users and technology architects. Unlike other companies in the space, Mautic is loved by both marketers and developers. With Mautic, Acquia continues to focus on both personas.

Reason 3: The same technology stack and business model

Like Drupal, Mautic is built in PHP and Symfony, and like Drupal, Mautic uses the GNU GPL license. Having the same technology stack has many benefits.

Digital agencies or in-house teams need to deliver integrated marketing solutions. Because both Drupal and Mautic use the same technology stack, a single team of developers can work on both.

The similarities also make it possible for both open source communities to collaborate — while it is not something you can force to happen, it will be interesting to see how that dynamic naturally plays out over time.

Last but not least, our business models are also very aligned. Both Acquia and Mautic were "born in the cloud" and make money by offering subscription- and cloud-based delivery options. This means you pay for only what you need and that you can focus on using the products rather than running and maintaining them.

Mautic offers several commercial solutions:

Mautic Cloud, a fully managed SaaS version of Mautic with premium features not available in Open Source.
For larger organizations, Mautic has a proprietary product called Maestro. Large organizations operate in many regions or territories, and have teams dedicated to each territory. With Maestro, each territory can get its own Mautic instance, but they can still share campaign best-practices, and repeat successful campaigns across territories. It's a unique capability, which is very aligned with the Acquia Cloud Site Factory.
Try Mautic

If you want to try Mautic, you can either install the community version yourself or check out the demo or sandbox environment of Mautic Open Marketing Cloud.

Conclusion

We're very excited to join forces with Mautic. It is such a strategic step for Acquia. Together we'll provide our customers with more freedom, faster innovation, and more flexibility. Open digital experiences are the way of the future.

I've got a lot more to share about the Mautic acquisition, how we plan to integrate Mautic in Acquia's solutions, how we could build bridges between the Drupal and Mautic community, how it impacts the marketplace, and more.

In time, I'll write more about these topics on this blog. In the meantime, please feel free to join DB Hurley, Mautic's founder and CTO, and me in a live Q&A session on Thursday, May 9 at 10am ET. We'll try to answer your questions about Acquia and Mautic.
Source: Dries Buytaert www.buytaert.net


Should Product Marketing report to Product or Marketing?

Product marketing teams are responsible for bringing products to market and championing their success and adoption. To make this happen, they work closely with three sets of key stakeholders: the product team (development/engineering), the marketing team and the sales team.
In some organizations, product marketing reports to marketing. In other organizations, it reports to product. The most common pattern is for product marketing teams to live in marketing, but in my opinion, a product marketing organization should sit where the highest frequency of communication and collaboration is needed. That can depend on the type of product, but also the maturity of the product.
For new products, companies with an evolving product strategy, or very technical products, it make most sense for product marketing to report directly to the product team. For mature and steady products, it makes sense for product marketing to report into marketing.
This reporting structure matters in that it facilitates communication and alignment.
For example, Acquia has recently decided to restructure product marketing to report to the product team, rather than marketing. We made this decision because there has been a lot of change and growth on the product front. With product marketing embedded into the product team at Acquia, we will ensure that we can bring the right messaging to the market quickly.
We've also added to our product leadership team, hiring an SVP of Product Marketing, Tom Wentworth to work closely with Matt Kaplan, our SVP of Product, and me. Those of you who have followed Acquia's story may know Tom as our former CMO and head of product marketing. You can read more about it in Tom's blog post — he explains why he rejoined Acquia, but also provides some great content management history.
Source: Dries Buytaert www.buytaert.net


What is Drupal? An Introduction to Drupal 8 in Ottawa

Start: 
2019-04-18 09:00 - 12:30 UTC

Organizers: 

pixelite

Event type: 

Training (free or commercial)

https://evolvingweb.ca/training/what-drupal-introduction-drupal-8

What is Drupal? Drupal is a popular, open source content management system. It powers websites for governments, NGOs, communities, and businesses around the world. Drupal 8, the newest version, has recently been released and there are many exciting new features for end users, site builders, and developers.
If you're considering a platform for your next web development project, this half-day training session is a great opportunity to learn more about what Drupal has to offer.
This session is designed for project managers, decision makers, site builders and developers who are new to Drupal and want to learn the basics. Evolving Web also offers more advanced trainings on a variety of Drupal topics.
Agenda:
9:00am - Coffee + Refreshments Served
9:15am - Welcome + Introductions
9:30am - Overview of Drupal 8 Features
9:45am - What You Can Build with Drupal
10:00am - Hands-on Demos: Drupal Content Management + Site Building
11:30am - Overview of Backend Functionality + Custom Development
11:45am - Meet the Drupal Community! Open Source + Community Involvement
12:00am - QA + Open Discussion
The event is free but an Eventbrite ticket is required as places are limited
For more trainings please visit out website : https://evolvingweb.ca/training
Source: https://groups.drupal.org/node/512931/feed


Headless CMS: REST vs JSON:API vs GraphQL

The web used to be server-centric in that web content management systems managed data and turned it into HTML responses. With the rise of headless architectures a portion of the web is becoming server-centric for data but client-centric for its presentation; increasingly, data is rendered into HTML in the browser.

This shift of responsibility has given rise to JavaScript frameworks, while on the server side, it has resulted in the development of JSON:API and GraphQL to better serve these JavaScript applications with content and data.

In this blog post, we will compare REST, JSON:API and GraphQL. First, we'll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.

It's worth noting that there are of course lots of intricacies and "it depends" when comparing these three approaches. When we discuss REST, we mean the "typical REST API" as opposed to one that is extremely well-designed or following a specification (not REST as a concept). When we discuss JSON:API, we're referring to implementations of the JSON:API specification. Finally, when we discuss GraphQL, we're referring to GraphQL as it used in practice. Formally, it is only a query language, not a standard for building APIs.

The architectural comparison should be useful for anyone building decoupled applications regardless of the foundation they use because the qualities we will evaluate apply to most web projects.

To frame our comparisons, let's establish that most developers working with web services care about the following qualities:

Request efficiency: retrieving all necessary data in a single network round trip is essential for performance. The size of both requests and responses should make efficient use of the network.
API exploration and schema documentation: the API should be quickly understandable and easily discoverable.
Operational simplicity: the approach should be easy to install, configure, run, scale and secure.
Writing data: not every application needs to store data in the content repository, but when it does, it should not be significantly more complex than reading.
We summarized our conclusions in the table below, but we discuss each of these four categories (or rows in the table) in more depth below. If you aggregate the colors in the table, you see that we rank JSON:API above GraphQL and GraphQL above REST.

REST
JSON:API
GraphQL
Request efficiency
Poor; multiple requests are needed to satisfy common needs. Responses are bloated.
Excellent; a single request is usually sufficient for most needs. Responses can be tailored to return only what is required.
Excellent; a single request is usually sufficient for most needs. Responses only include exactly what was requested.
Documentation, API explorability and schema
Poor; no schema, not explorable.
Acceptable; generic schema only; links and error messages are self-documenting.
Excellent; precise schema; excellent tooling for exploration and documentation.
Operational simplicity
Acceptable; works out of the box with CDNs and reverse proxies; few to no client-side libraries required.
Excellent; works out of the box with CDNs and reverse proxies, no client-side libraries needed, but many are available and useful.
Poor; extra infrastructure is often necessary client side libraries are a practical necessity, specific patterns required to benefit from CDNs and browser caches.
Writing data
Acceptable; HTTP semantics give some guidance but how specifics left to each implementation, one write per request.
Excellent; how writes are handled is clearly defined by the spec, one write per request, but multiple writes is being added to the specification.
Poor; how writes are handled is left to each implementation and there are competing best practices, it's possible to execute multiple writes in a single request.

If you're not familiar with JSON:API or GraphQL, I recommend you watch the following two short videos. They will provide valuable context for the remainder of this blog post:

A 3-minute demo of Drupal's GraphQL implementation.
A 5-minute demo of Drupal's JSON:API implementation.
Request efficiency

Most REST APIs tend toward the simplest implementation possible: a resource can only be retrieved from one URI. If you want to retrieve article 42, you have to retrieve it from https://example.com/article/42. If you want to retrieve article 42 and article 72, you have to perform two requests; one to https://example.com/article/42 and one to https://example.com/article/72. If the article's author information is stored in a different content type, you have to do two additional requests, say to https://example.com/author/3 and https://example.com/author/7. Furthermore, you can't send these requests until you've requested, retrieved and parsed the article requests (you wouldn't know the author IDs otherwise).

Consequently, client-side applications built on top of basic REST APIs tend to need many successive requests to fetch their data. Often, these requests can't be sent until earlier requests have been fulfilled, resulting in a sluggish experience for the website visitor.

GraphQL and JSON:API were developed to address the typical inefficiency of REST APIs. Using JSON:API or GraphQL, you can use a single request to retrieve both article 42 and article 72, along with the author information for each. It simplifies the developer experience, but more importantly, it speeds up the application.

Finally, both JSON:API and GraphQL have a solution to limit response sizes. A common complaint against typical REST APIs is that their responses can be incredibly verbose; they often respond with far more data than the client needs. This is both annoying and inefficient.

GraphQL eliminates this by requiring the developer to explicitly add each desired resource field to every query. This makes it difficult to over-fetch data but easily leads to very large GraphQL queries, making (cacheable) GET requests impossible.

JSON:API solves this with the concept of sparse fieldsets or lists of desired resource fields. These behave in much the same fashion as GraphQL does, however, when they're omitted JSON:API will typically return all fields. An advantage, though, is that when a JSON:API query gets too large, sparse fieldsets can be omitted so that the request remains cacheable.

REST
JSON:API
GraphQL
Multiple data objects in a single response
Usually; but every implementation is different (for Drupal: custom "REST Export" view or custom REST plugin needed).
Yes
Yes
Embed related data (e.g. the author of each article)
No
Yes
Yes
Only needed fields of a data object
No
Yes; servers may choose sensible defaults, developers must be diligent to prevent over-fetching.
Yes; strict, but eliminates over-fetching, at the extreme, it can lead to poor cacheability.
Documentation, API explorability and schema

As a developer working with web services, you want to be able to discover and understand the API quickly and easily: what kinds of resources are available, what fields does each of them have, how are they related, etc. But also, if this field is a date or time, what machine-readable format is the date or time specified in? Good documentation and API exploration can make all the difference.

REST
JSON:API
GraphQL
Auto-generated documentation
Depends; if using the OpenAPI standard.
Depends; if using the OpenAPI standard (formerly, Swagger).
Yes; various tools available.
Interactivity
Poor; navigable links rarely available.
Acceptable; observing available fields and links in its responses enable exploration of the API.
Excellent; autocomplete feature, instant results or compilation errors, complete and contextual documentation.
Validatable and programmable schema.
Depends; if using the OpenAPI standard.
Depends; the JSON:API specification defines a generic schema, but a reliable field-level schema is not yet available.
Yes; a complete and reliable schema is provided (with very few exceptions).
GraphQL has superior API exploration thanks to GraphiQL (demonstrated in the video above), an in-browser IDE of sorts, which lets developers iteratively construct a query. As the developer types the query out, likely suggestions are offered and can be auto-completed. At any time, the query can be run and GraphiQL will display real results alongside the query. This provides immediate, actionable feedback to the query builder. Did they make a typo? Does the response look like what was desired? Additionally, documentation can be summoned into a flyout, when additional context is needed.

On the other hand, JSON:API is more self-explanatory: APIs can be explored with nothing more than a web browser. From within the browser, you can browse from one resource to another, discover its fields, and more. So, if you just want to debug or try something out, JSON:API is usable with nothing more than cURL or your browser. Or, you can use Postman (demonstrated in the video above) — a standalone environment for developing on top of an any HTTP-based API. Constructing complex queries requires some knowledge, however, and that is where GraphQL's GraphiQL shines compared to JSON:API.

Operational simplicity

We use the term operational simplicity to encompass how easy it is to install, configure, run, scale and secure each of the solutions.

The table should be self-explanatory, though it's important to make a remark about scalability. To scale a REST-based or JSON:API-based web service so that it can handle a large volume of traffic, you can use the same approach websites (and Drupal) already use, including reverse proxies like Varnish or a CDN. To scale GraphQL, you can't rely on HTTP caching as with REST or JSON:API without persisted queries. Persisted queries are not part of the official GraphQL specification but they are a widely-adopted convention amongst GraphQL users. They essentially store a query on the server, assign it an ID and permit the client to get the result of the query using a GET request with only the ID. Persisted queries add more operational complexity, and it also means the architecture is no longer fully decoupled — if a client wants to retrieve different data, server-side changes are required.

REST
JSON:API
GraphQL
Scalability: additional infrastructure requirements
Excellent; same as a regular website (Varnish, CDN, etc).
Excellent; same as a regular website (Varnish, CDN, etc).
Usually poor; only the simplest queries can use GET requests; to reap the full benefit of GraphQL, servers needs their own tooling.
Tooling ecosystem
Acceptable; lots of developer tools available, but for the best experience they need to be customized for the implementation.
Excellent; lots of developer tools available; tools don't need to be implementation-specific.
Excellent; lots of developer tools available; tools don't need to be implementation-specific.
Typical points of failure
Fewer; server, client.
Fewer; server, client.
Many; server, client, client-side caching, client and build tooling.
Writing data

For most REST APIs and JSON:API, writing data is as easy as fetching it: if you can read information, you also know how to write it. Instead of using the GET HTTP request type you use POST and PATCH requests. JSON:API improves on typical REST APIs by eliminating differences between implementations. There is just one way to do things and that enabled better, generic tooling and less time spent on server-side details.

The nature of GraphQL's write operations (called mutations) means that you must write custom code for each write operation; unlike JSON:API the specification, GraphQL doesn't prescribe a single way of handling write operations to resources, so there are many competing best practices. In essence, the GraphQL specification is optimized for reads, not writes.

On the other hand, the GraphQL specification supports bulk/batch operations automatically for the mutations you've already implemented, whereas the JSON:API specification does not. The ability to perform batch write operations can be important. For example, in our running example, adding a new tag to an article would require two requests; one to create the tag and one to update the article. That said, support for bulk/batch writes in JSON:API is on the specification's roadmap.

REST
JSON:API
GraphQL
Writing data
Acceptable; every implementation is different. No bulk support.
Excellent; JSON:API prescribes a complete solution for handling writes. Bulk operations are coming soon.
Poor; GraphQL supports bulk/batch operations, but writes can be tricky to design and implement. There are competing conventions.
Drupal-specific considerations

Up to this point we have provided an architectural and CMS-agnostic comparison; now we also want to highlight a few Drupal-specific implementation details. For this, we can look at the ease of installation, automatically generated documentation, integration with Drupal's entity and field-level access control systems and decoupled filtering.

Drupal 8's REST module is practically impossible to set up without the contributed REST UI module, and its configuration can be daunting. Drupal's JSON:API module is far superior to Drupal's REST module at this point. It is trivial to set up: install it and you're done; there's nothing to configure. The GraphQL module is also easy to install but does require some configuration.

Client-generated collection queries allow a consumer to filter an application's data down to just what they're interested in. This is a bit like a Drupal View except that the consumer can add, remove and control all the filters. This is almost always a requirement for public web services, but it can also make development more efficient because creating or changing a listing doesn't require server-side configuration changes.

Drupal's REST module does not support client-generated collection queries. It requires a "REST Views display" to be setup by a site administrator and since these need to be manually configured in Drupal; this means a client can't craft its own queries with the filters it needs.

JSON:API and GraphQL, clients are able to perform their own content queries without the need for server-side configuration. This means that they can be truly decoupled: changes to the front end don't always require a back-end configuration change.

These client-generated queries are a bit simpler to use with the JSON:API module than they are with the GraphQL module because of how each module handles Drupal's extensive access control mechanisms. By default JSON:API ensures that these are respected by altering the incoming query. GraphQL instead requires the consumer to have permission to simply bypass access restrictions.

Most projects using GraphQL that cannot grant this permission use persisted queries instead of client-generated queries. This means a return to a more traditional Views-like pattern because the consumer no longer has complete control of the query's filters. To regain some of the efficiencies of client-generated queries, the creation of these persisted queries can be automated using front-end build tooling.

REST
JSON:API
GraphQL
Ease of installation and configuration
Poor; requires contributed module REST UI, easy to break clients by changing configuration.
Excellent; zero configuration!
Poor; more complex to use, may require additional permissions, configuration or custom code.
Automatically generated documentation
Acceptable; requires contributed module OpenAPI.
Acceptable; requires contributed module OpenAPI.
Excellent; GraphQL Voyager included.
Security: content-level access control (entity and field access)
Excellent; content-level access control respected.
Excellent; content-level access control respected, even in queries.
Acceptable; some use cases require the consumer to have permission to bypass all entity and/or field access.
Decoupled filtering (client can craft queries without server-side intervention)
No
Yes
Depends; only in some setups and with additional tooling/infrastructure.
What does this mean for Drupal's roadmap?

Drupal grew up as a traditional web content management system but has since evolved for this API-first world and industry analysts are praising us for it. As Drupal's project lead, I've been talking about adding out-of-the-box support for both JSON:API and GraphQL for a while now. In fact, I've been very bullish about GraphQL since 2015. My optimism was warranted; GraphQL is undergoing a meteoric rise in interest across the web development industry.

Based on this analysis, we rank JSON:API above GraphQL and GraphQL above REST. As such, I want to change my recommendation for Drupal 8 core. Instead of adding both JSON:API and GraphQL to Drupal 8 core, I believe only JSON:API should be added. While Drupal's GraphQL implementation is fantastic, I no longer recommend that we add GraphQL to Drupal 8 core.

On the four qualities by which we evaluated the REST, JSON:API and GraphQL modules, JSON:API has outperformed its contemporaries. Its web standards-based approach, its ability to handle reads and writes out of the box, its security model and its ease of operation make it the best choice for Drupal core. Additionally, where JSON:API underperformed, I believe that we have a real opportunity to contribute back to the specification. In fact, one of the JSON:API module's maintainers and co-authors of this blog post, Gabe Sullice (Acquia), recently became a JSON:API specification editor himself.

This decision does not mean that you can't or shouldn't use GraphQL with Drupal. While I believe JSON:API covers the majority of use cases, there are valid use cases where GraphQL is a great fit. I'm happy that Drupal is endowed with such a vibrant contributed module ecosystem that provides so many options to Drupal's users.

I'm excited to see where both the JSON:API specification and Drupal's implementation of it goes in the coming months and years. As a first next step, we're preparing the JSON:API to be added to Drupal 8.7.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Preston So (Acquia) and Alex Bronstein (Acquia) for their feedback during the writing process.
Source: Dries Buytaert www.buytaert.net


What is Drupal? An Introduction to Drupal 8 in Chicago

Start: 
2019-06-27 09:00 - 12:30 America/Chicago

Organizers: 

pixelite

erika.d

Event type: 

Training (free or commercial)

https://evolvingweb.ca/training/what-drupal-introduction-drupal-8

What is Drupal? Drupal is a popular, open source content management system. It powers websites for governments, NGOs, communities, and businesses around the world. Drupal 8, the newest version, has recently been released and there are many exciting new features for end users, site builders, and developers.
If you're considering a platform for your next web development project, this half-day training session is a great opportunity to learn more about what Drupal has to offer.
This session is designed for project managers, decision makers, site builders and developers who are new to Drupal and want to learn the basics. Evolving Web also offers more advanced trainings on a variety of Drupal topics.
Agenda:
9:00am - Coffee + Refreshments Served
9:15am - Welcome + Introductions
9:30am - Overview of Drupal 8 Features
9:45am - What You Can Build with Drupal
10:00am - Hands-on Demos: Drupal Content Management + Site Building
11:30am - Overview of Backend Functionality + Custom Development
11:45am - Meet the Drupal Community! Open Source + Community Involvement
12:00am - QA + Open Discussion
Source: https://groups.drupal.org/node/512931/feed


Acquia retrospective 2018

Every year, I sit down to write my annual Acquia retrospective. It's a rewarding exercise, because it allows me to reflect on how much progress Acquia has made in the past 12 months.

Overall, Acquia had an excellent 2018. I believe we are a much stronger company than we were a year ago; not only because of our financial results, but because of our commitment to strengthen our product and engineering teams.

If you'd like to read my previous retrospectives, they can be found here: 2017,2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009. This year marks the publishing of my tenth retrospective. When read together, these posts provide a comprehensive overview of Acquia's growth and trajectory.

Updating our brand

Exiting 2017, Acquia doubled down on our transition from website management to digital experience management. In 2018, we updated our product positioning and brand narrative to reflect this change. This included a new Acquia Experience Platform diagram:

The Acquia Platform is divided into two key parts: the Experience Factory and the Marketing Hub. Drupal and Acquia Lightning power every side of the experience. The Acquia Platform supports our customers throughout the entire life cycle of a digital experience — from building to operating and optimizing digital experiences.

In 2018, the Acquia marketing team also worked hard to update Acquia's brand. The result is a refreshed look and updated brand positioning that better reflects our vision, culture, and the value we offer our customers. This included updating our tagline to read: Experience Digital Freedom.

I think Acquia's updated brand looks great, and it's been exciting to see it come to life. From highway billboards to Acquia Engage in Austin, our updated brand has been very well received.

When Acquia Engage attendees arrived at the Austin-Bergstrom International Airport for Acquia Engage 2018, they were greeted by an Acquia display.Business momentum

This year, Acquia surpassed $200 million in annualized revenue. Overall new subscription bookings grew 33 percent year over year, and we ended the year with nearly 900 employees.

Mike Sullivan completed his first year as Acquia's CEO, and demonstrated a strong focus on improving Acquia's business fundamentals across operational efficiency, gross margins, and cost optimization. The results have been tangible, as Acquia has realized unprecedented financial growth in 2018:

Channel-partner bookings grew 52 percent
EMEA-based bookings grew 103 percent
Gross profit grew 39 percent
Adjusted EBITDA grew 78 percent
Free cash flow grew 84 percent
2018 was a record year for Acquia. Year-over-year highlights include new subscription bookings, EMEA-based bookings, free cash flow, and more.International growth and expansion

In 2018, Acquia also witnessed unprecedented success in Europe and Asia, as new bookings in EMEA were up more than 100 percent. This included expanding our European headquarters to a new and larger space with a ribbon-cutting ceremony with the mayor of Reading in the U.K.

Acquia also expanded its presence in Asia Pacific, and opened Tokyo-based operations in 2018. Over the past few years I visited Japan twice, and I'm excited for the opportunities that doing business in Japan offers.

We selected Pune as the location for our new India office, and we are in the process of hiring our first Pune-based engineers.

Acquia now has four offices in the Asia Pacific region serving customers like Astellas Pharmaceuticals, Muji, Mediacorp, and Brisbane City Council.

Acquia product information, translated into Japanese.Acquia Engage

In 2018, we welcomed more than 650 attendees to Austin, Texas, for our annual customer conference, Acquia Engage. In June, we also held our first Acquia Engage Europe and welcomed 300 attendees.

Our Engage conferences included presentations from customers like Paychex, NBC Sports, Wendy's, West Corporation, General Electric, Charles Schwab, Pac-12 Networks, Blue Cross Blue Shield, Bayer, Virgin Sport, and more. We also featured keynote presentations from our partner network, including VMLY&R, Accenture Interactive, IBM iX and MRM//McCann.

Both customers and partners continue to be the most important driver of Acquia's product strategy, and it's always rewarding to hear about this success first hand. In fact, 2018 customer satisfaction levels remain extremely high at 94 percent.

Partner program

Finally, Acquia's partner network continues to become more sophisticated. In the second half of 2018, we right sized our partner community from 2,270 firms to 226. This was a bold move, but our goal was to place a renewed focus on the partners who were both committed to Acquia and highly capable. As a result, we saw almost 52 percent year-over-year growth in partner-sourced ACV bookings. This is meaningful because for every $1 Acquia books in collaboration with a partner, our partner makes about $5 in services revenue.

Analyst recognition

In 2018, the top industry analysts published very positive reviews about Acquia. I'm proud that Acquia was recognized by Forrester Research as the leader for strategy and vision in The Forrester Wave: Web Content Management Systems, Q4 2018. Acquia was also named a leader in the 2018 Gartner Magic Quadrant for Web Content Management, marking our placement as a leader for the fifth year in a row.

Product milestones

Acquia's product evolution between 2008 and 2018. When Acquia was founded, our mission was to provide commercial support for Drupal and to be the "Red Hat for Drupal"; 12 years later, the Acquia Platform helps organizations build, operate and optimize Drupal-based experiences.

2018 was one of the busiest years I have experienced; it was full of non-stop action every day. My biggest focus was working with Acquia's product and engineering team.
We focused on growing and improving our R&D organization, modernizing Acquia Cloud, becoming user-experience first, redesigning the Acquia Lift user experience, working on headless Drupal, making Drupal easier to use, and expanding our commerce strategy.

Hiring, hiring, hiring

In partnership with Mike, we decided to increase the capacity of our research and development team by 60 percent. At the close of 2018, we were able to increase the capacity of our research and development team by 45 percent percent. We will continue to invest in growing our our R&D team in 2019.

I spent a lot of our time restructuring, improving and scaling the product organization to make sure we could handle the increased capacity and build out a world-class R&D organization.

As the year progressed, R&D capacity increasingly came online and our ability to innovate not only improved but accelerated significantly. We entered 2019 in a much better position, as we now have a lot more capacity to innovate.

Acquia Cloud

Acquia Cloud and Acquia Cloud Site Factory support some of the largest and most mission-critical websites in the world. The scope and complexity that Acquia Cloud and Acquia Cloud Site Factory manages is enormous. We easily deliver more than 30 billion page views a month (excluding CDN).

Over the course of 10 years, the Acquia Cloud codebase had grown very large. Updating, testing and launching new releases took a long time because we had one large, monolithic codebase. This was something we needed to change in order to add new features faster.

Over the course of 2018, the engineering team broke the monolithic codebase down into discrete components that can be tested and released independently. We launched our component-based architecture in June. Since then, the engineering team has released changes to production 650 times, compared to our historic pace of doing one release per quarter.

This graph shows how we moved Acquia Cloud from a monolithic code base to a component-based code base. Each color on the graph represents a component. The graph shows how releases of Acquia Cloud (and the individual components in particular) have accelerated in the second half of the year.Planning and designing for all of these services took a lot of time and focus, and was a large priority for the entire engineering team (including me). The fruits of these efforts will start to become more publicly visible in 2019. I'm excited to share more with you in future blog posts.

Acquia Cloud also remains the most secure and compliant cloud for Drupal. As we were componentizing the Acquia Cloud platform, the requirements to maintain our FedRAMP compliance became much more stringent. In April, the GDPR deadline was also nearing. Executing on hundreds of FedRAMP- and GDPR-related tasks emerged as another critical priority for many of our product and engineering teams. I'm proud that the team succeeded in accomplishing this amid all the other changes we were making.
Customer experience first

Over the years, I've felt Acquia lacked a focus on user experience (UX) for both developers and marketers. As a result, increasing the capacity of our R&D team included doubling the size of the UX team.

We've stepped up our UX research to better understand the needs and challenges of those who use Acquia products. We've begun to employ design-first methodologies, such as design sprints and a lean-UX approach. We've also created roles for customer experience designers, so that we're looking at the full customer journey rather than just our product interfaces.

With the extra capacity and data-driven changes in place, we've been working hard on updating the user experience for the entire Acquia Experience Platform. For example, you can see a preview of our new Acquia Lift product in this video, which has an increased focus on UX:

Drupal

In 2018, Drupal 8 adoption kept growing and Drupal also saw an increase in the number of community contributions and contributors, both from individuals and from organizations.

Acquia remains very committed to Drupal, and was the largest contributor to the project in 2018. We now have more than 15 employees who contribute to Drupal full time, in addition to many others that contribute periodically. In 2018, the Drupal team's main areas of focus have been Layout Builder and the API-first initiative:

Layout Builder: Layout Builder offers content authors an easy-to-use page building experience. It's shaping up to be one of the most useful and pervasive features ever added to Drupal because it redefines the how editors control the appearance of their content without having to rely on a developer.
API First: This initiative has given Drupal a true best-in-class web services API for using Drupal as a headless content management system. Headless Drupal is one of the fastest growing segments of Drupal implementations.
Our R&D team gathered in Boston for our annual Build Week in June 2018.Content and Commerce

Adobe's acquisition of Magento has been very positive for us; we're now the largest commerce-agnostic content management company to partner with. As a result, we decided to extend our investments in headless commerce and set up partnerships with Elastic Path and BigCommerce. The momentum we've seen from these partnerships in a short amount of time is promising for 2019.

The market continues to move in Acquia's direction

In 2019, I believe Acquia will continue to be positioned for long-term growth. Here are a few reasons why:

The current markets for content and digital experience management continues to grow rapidly, at approximately 20 percent per year.
Digital transformation is top-of-mind for all organizations, and impacts all elements of their business and value chain.
Open source adoption continues to grow at a furious pace and has seen tremendous business success in 2018.
Cloud adoption continues to grow. Unlike most of our CMS competitors, Acquia was born in the cloud.
Drupal and Acquia are leaders in headless and decoupled content management, which is a fast growing segment of our market.
Conversational interfaces and augmented reality continues to grow, and we embraced these channels a few years ago. Acquia Labs, our research and innovation lab, explored how organizations can use conversational UIs to develop beyond-the-browser experiences, like cooking with Alexa, and voice-enabled search for customers like Purina.
Although we hold a leadership position in our market, our relative market share is small. These trends mean that we should have plenty of opportunity to grow in 2019 and beyond.

Thank you

While 2018 was an incredibly busy year, it was also very rewarding. I have a strong sense of gratitude, and admire every Acquian's relentless determination and commitment to improve. As always, none of these results and milestones would be possible without the hard work of the Acquia team, our customers, partners, the Drupal community, and our many friends.

I've always been pretty transparent about our trajectory (e.g. Acquia 2009 roadmap and Acquia 2017 strategy) and will continue to do so in 2019. We have some big plans for 2019, and I'm excited to share them with you. If you want to get notified about what we have in store, you can subscribe to my blog at https://dri.es/subscribe.

Thank you for your support in 2018!


Source: Dries Buytaert www.buytaert.net


What is Drupal? An Introduction to Drupal 8 in Madison, WI

Start: 
2019-06-28 09:00 - 12:30 America/Chicago

Organizers: 

pixelite

Event type: 

Training (free or commercial)

https://www.eventbrite.ca/e/what-is-drupal-an-introduction-to-drupal-8-i...

What is Drupal? Drupal is a popular, open source content management system. It powers websites for governments, NGOs, communities, and businesses around the world. Drupal 8, the newest version, has recently been released and there are many exciting new features for end users, site builders, and developers.
If you're considering a platform for your next web development project, this half-day training session is a great opportunity to learn more about what Drupal has to offer.
This session is designed for project managers, decision makers, site builders and developers who are new to Drupal and want to learn the basics. Evolving Web also offers more advanced trainings on a variety of Drupal topics.
Agenda:
9:00am - Coffee + Refreshments Served
9:15am - Welcome + Introductions
9:30am - Overview of Drupal 8 Features
9:45am - What You Can Build with Drupal
10:00am - Hands-on Demos: Drupal Content Management + Site Building
11:30am - Overview of Backend Functionality + Custom Development
11:45am - Meet the Drupal Community! Open Source + Community Involvement
12:00am - QA + Open Discussion
Source: https://groups.drupal.org/node/512931/feed


What is Drupal? An Introduction to Drupal 8 Chicago

Start: 
2019-06-27 09:00 - 12:30 America/Chicago

Organizers: 

pixelite

Event type: 

Training (free or commercial)

https://www.eventbrite.ca/e/what-is-drupal-an-introduction-to-drupal-8-t...

What is Drupal? Drupal is a popular, open source content management system. It powers websites for governments, NGOs, communities, and businesses around the world. Drupal 8, the newest version, has recently been released and there are many exciting new features for end users, site builders, and developers.
If you're considering a platform for your next web development project, this half-day training session is a great opportunity to learn more about what Drupal has to offer.
This session is designed for project managers, decision makers, site builders and developers who are new to Drupal and want to learn the basics. Evolving Web also offers more advanced trainings on a variety of Drupal topics.
Agenda:
9:00am - Coffee + Refreshments Served
9:15am - Welcome + Introductions
9:30am - Overview of Drupal 8 Features
9:45am - What You Can Build with Drupal
10:00am - Hands-on Demos: Drupal Content Management + Site Building
11:30am - Overview of Backend Functionality + Custom Development
11:45am - Meet the Drupal Community! Open Source + Community Involvement
12:00am - QA + Open Discussion
Source: https://groups.drupal.org/node/512931/feed


How to decouple Drupal in 2019

The pace of innovation in content management has been accelerating — driven by both the number of channels that content management systems need to support (web, mobile, social, chat) as well as the need to support JavaScript frameworks in the traditional web channel. As a result, we've seen headless or decoupled architectures emerge.

Decoupled Drupal has seen adoption from all corners of the Drupal community. In response to the trend towards decoupled architectures, I wrote blog posts in 2016 and 2018 for architects and developers about how and when to decouple Drupal. In the time since my last post, the surrounding landscape has evolved, Drupal's web services have only gotten better, and new paradigms such as static site generators and the JAMstack are emerging.

Time to update my recommendations for 2019! As we did a year ago, let's start with the 2019 version of the flowchart in full. (At the end of this post, there is also an accessible version of this flowchart described in words.)

Different ways to decouple Drupal

I want to revisit some of the established ways to decouple Drupal as well as discuss new paradigms that are seeing growing adoption. As I've written previously, the three most common approaches to Drupal architecture from a decoupled standpoint are traditional (or coupled), progressively decoupled, and fully decoupled. The different flavors of decoupling Drupal exist due to varying preferences and requirements.

In traditional Drupal, all of Drupal's usual responsibilities stay intact, as Drupal is a monolithic system and therefore maintains complete control over the presentation and data layers. Traditional Drupal remains an excellent choice for editors who need full control over the visual elements on the page, with access to features such as in-place editing and layout management. This is Drupal as we have known it all along. Because the benefits are real, this is still how most new content management projects are built.

Sometimes, JavaScript is required to deliver a highly interactive end-user experience. In this case, a decoupled approach becomes required. In progressively decoupled Drupal, a JavaScript framework is layered on top of the existing Drupal front end. This JavaScript might be responsible for nothing more than rendering a single block or component on a page, or it may render everything within the page body. The progressive decoupling paradigm lies on a spectrum; the less of the page dedicated to JavaScript, the more editors can control the page through Drupal's administrative capabilities.

Up until this year, fully decoupled Drupal was a single category of decoupled Drupal architecture that reflects a full separation of concerns between the presentation layer and all other aspects of the CMS. In this scenario, the CMS becomes a data provider, and a JavaScript application with server-side rendering becomes responsible for all rendering and markup, communicating with Drupal via web service APIs. Though key functionality like in-place editing and layout management are unavailable, fully decoupled Drupal is appealing for developers who want greater control over the front end and who are already experienced with building applications in frameworks like Angular, React, Vue.js, etc.

Over the last year, fully decoupled Drupal has branched into two separate paradigms due to the increasing complexity of JavaScript development. The so-called JAMstack (JavaScript, APIs, Markup) introduces a new approach: fully decoupled static sites. The primary reason for static sites is improved performance, security, and reduced complexity for developers. A static site generator like Gatsby will retrieve content from Drupal, generate a static website, and deploy that static site to a CDN, usually through a specialized cloud provider such as Netlify.

What do you intend to build?

The essential question, as always, is what you're trying to build. Here is updated advice for architects exploring decoupled Drupal in 2019:

If your intention is to build a single standalone website or web application, choosing decoupled Drupal may or may not be the right choice, depending on the features your developers and editors see as must-haves.
If your intention is to build multiple web experiences (websites or web applications), you can use a decoupled Drupal instance either as a) a content repository without its own public-facing front end or b) a traditional website that acts simultaneously as a content repository. Depending on how dynamic your application needs to be, you can choose a JavaScript framework for highly interactive applications or a static site generator for mostly static websites.
If your intention is to build multiple non-web experiences (native mobile or IoT applications), you can leverage decoupled Drupal to expose web service APIs and consume that Drupal site as a content repository without its own public-facing front end.
What makes Drupal so powerful is that it supports all of these use cases. Drupal makes it simple to build decoupled Drupal thanks to widely recognized standards such as JSON:API, GraphQL, OpenAPI, and CouchDB. In the end, it is your technical requirements that will decide whether decoupled Drupal should be your next architecture.

In addition to technical requirements, organizational factors often come into play as well. For instance, if it is proving difficult to find talented front-end Drupal developers with Twig knowledge, it may make more sense to hire more affordable JavaScript developers instead and build a fully decoupled implementation.

Are there things you can't live without?

As I wrote last year, the most important aspect of any decision when it comes to decoupling Drupal is the list of features your project requires; the needs of editors and developers have to be carefully considered. It is a critical step in your evaluation process to weigh the different advantages and disadvantages. Every project should embark on a clear-eyed assessment of its organization-wide needs.

Many editorial and marketing teams select a particular CMS because of its layout capabilities and rich editing functionality. Drupal, for example, gives editors the ability to build layouts in the browser and drop-and-drag components into it, all without needing a developer to do it for them. Although it is possible to rebuild many of the features available in a CMS on a consumer application, this can be a time-consuming and expensive process.

In recent years, the developer experience has also become an important consideration, but not in the ways that we might expect. While the many changes in the JavaScript landscape are one of the motivations for developers to prefer decoupled Drupal, the fact that there are now multiple ways to write front ends for Drupal makes it easier to find people to work on decoupled Drupal projects. As an example, many organizations are finding it difficult to find affordable front-end Drupal developers experienced in Twig. Moving to a JavaScript-driven front end can resolve some of these resourcing challenges.

This balancing act between the requirements that developers prioritize and those that editors prioritize will guide you to the correct approach for your needs. If you are part of an organization that is mostly editorial, decoupled Drupal could be problematic, because it reduces the amount of control editors have over the presentation of their content. By the same token, if you are part of an organization with more developer resources, fully decoupled Drupal could potentially accelerate progress, with the warning that many mission-critical editorial features disappear.

Current and future trends to consider

Over the past year, JavaScript frameworks have become more complex, while static site generators have become less complex.

One of the common complaints I have heard about the JavaScript landscape is that it shows fragmentation and a lack of cohesion due to increasing complexity. This has been a driving force for static site generators. Whereas two years ago, most JavaScript developers would have chosen a fully functional framework like Angular or Ember to create even simple websites, today they might choose a static site generator instead. A static site generator still allows them to use JavaScript, but it is simpler because performance considerations and build processes are offloaded to hosted services rather than the responsibility of developers.

I predict that static site generators will gain momentum in the coming year due to the positive developer experience they provide. Static site generators are also attracting a middle ground of both more experienced and less experienced developers.

Conclusion

Drupal continues to be an ideal choice for decoupled CMS architectures, and it is only getting better. The API-first initiative is making good progress on preparing the JSON:API module for inclusion in Drupal core, and the Admin UI and JavaScript Modernization initiative is working to dogfood Drupal's web services with a reinvented administrative interface. Drupal's support for GraphQL continues to improve, and now there is even a book on the subject of decoupled Drupal. It's clear that developers today have a wide range of ways to work with the rich features Drupal has to offer for decoupled architectures.

With the introduction of fully decoupled static sites as an another architectural paradigm that developers can select, there is an even wider variety of architectural possibilities than before. It means that the spectrum of decoupled Drupal approaches I defined last year has become even more extensive. This flexibility continues to define Drupal as an excellent CMS for both traditional and decoupled approaches, with features that go well beyond Drupal's competitors, including WordPress, Sitecore and Adobe. Regardless of the makeup of your team or the needs of your organization, Drupal has a solution for you.

Special thanks to Preston So for co-authoring this blog post and to Angie Byron, Chris Hamper, Gabe Sullice, Lauri Eskola, Ted Bowman, and Wim Leers for their feedback during the writing process.

Accessible version of flowchart

This is an accessible and described version of the flowchart images earlier in this blog post. First, let us list the available architectural choices:

Coupled. Use Drupal as is without additional JavaScript (and as a content repository for other consumers).
Progressively decoupled. Use Drupal for initial rendering with JavaScript on top (and as a content repository for other consumers).
Fully decoupled static site. Use Drupal as a data source for a static site generator and, if needed, deploy to a JAMstack hosting platform.
Fully decoupled app. Use Drupal as a content repository accessed by other consumers (if JavaScript, use Node.js for server-side rendering).
Second, ask the question "What do you intend to build?" and choose among the answers "One experience" or "Multiple experiences".

If you are building one experience, ask the question "Is it a website or web application?" and choose among the answers "Yes, a single website or web application" or "No, Drupal as a repository for non-web applications only".

If you are building multiple experiences instead, ask the question "Is it a website or web application?" with the answers "Yes, Drupal as website and repository" or "No, Drupal as a repository for non-web applications only".

If your answer to the previous question was "No", then you should build a fully decoupled application, and your decision is complete. If your answer to the previous question was "Yes", then ask the question "Are there things the project cannot live without?"

Both editorial and developer needs are things that projects cannot live without, and here are the questions you need to ask about your project:

Editorial needs

Do editors need to manipulate page content and layout without a developer?
Do editors need in-context tools like in-place editing, contextual links, and toolbar?
Do editors need to preview unpublished content without custom development?
Do editors need content to be accessible by default like in Drupal's HTML?
Developer needs

Do developers need to have control over visual presentation instead of editors?
Do developers need server-side rendering or Node.js build features?
Do developers need JSON from APIs and to write JavaScript for the front end?
Do developers need data security driven by a publicly inaccessible CMS?
If, after asking all of these questions about things your project cannot live without, your answers show that your requirements reflect a mix of both editorial and developer needs, you should consider a progressively decoupled implementation, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely developer needs, then ask the question "Is it a static website or a dynamic web application?" and choose among the answers "Static" or "Dynamic." If your answer to the previous question was "Static", you should build a fully decoupled static site, and your decision is complete. If your answer to the previous question was "Dynamic", you should build a fully decoupled app, and your decision is complete.

If your answers to the questions about things your project cannot live without show that your requirements reflect purely editorial needs, then ask two questions. Ask the first question, "Are there parts of the page that need JavaScript-driven interactions?" and choose among the answers "Yes" or "No." If your answer to the first question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the first question was "No", then you should build a coupled Drupal site, and your decision is complete.

Then, ask the second question, "Do you need to access multiple data sources via API?" and choose among the answers "Yes" or "No." If your answer to the second question was "Yes", then you should consider a progressively decoupled implementation, and your decision is complete. If your answer to the second question was "No", then you should build a coupled Drupal site, and your decision is complete.
Source: Dries Buytaert www.buytaert.net


Webinar : Is Drupal a Good Fit for My Organization?

Start: 
2019-02-07 12:00 - 14:00 America/New_York

Organizers: 

pixelite

erika.d

Event type: 

Training (free or commercial)

https://evolvingweb.ca/training/drupal-good-fit-my-organization

Selecting your content management system is key to the success of your digital strategy. You need to balance taking advantage of features out-of-the-box with the flexibility and customization that you need. You want to be able to customize and personalize your content, branding, and functionality.
Drupal is an open platform that can evolve with your organization. It can turn your static website into a dynamic, marketing platform. It all depends on how you adopt it at your organization. In this session, we’ll talk about your criteria for selecting a platform like Drupal, what’s easy and difficult with Drupal, and how to validate whether it’s the best option for your organization.
Source: https://groups.drupal.org/node/512931/feed


5-Day Drupal 8 Training Washington DC

Start: 
2019-02-25 09:00 - 2019-03-01 16:30 America/New_York

Organizers: 

pixelite

erika.d

Event type: 

Training (free or commercial)

https://evolvingweb.ca/training/5-day-drupal-8-training

Learn how to build a website with Drupal from top to bottom. This is a week-long Drupal class divided into three parts: site building, theming, and module development. You can register for all five days, or for each part individually, depending on your learning needs.
Day 1: Drupal 8 Site Building
The Drupal content management system is known for its flexibility. Drupal can be used for many types of websites, from media portals to e-commerce sites, to community forums. Site builders have the task of customizing Drupal depending on the content and feature-set they want to provide. This section of the course will give participants a thorough understanding of the Drupal site building process. You'll get hands-on experience implementing advanced features with Drupal core and contributed modules. Understanding of basic Drupal concepts (or having taken an introduction to Drupal course) is required.
Days 2-3: Drupal 8 Theming
Learn techniques for customizing the look of a Drupal site by creating a custom theme. This section of the course will cover Twig templating, creating layouts, and best practices for organizing your theme. We'll also cover responsive techniques and sub-theming. Familiarity with HTML and CSS is required.
Days 4-5: Drupal 8 Module Development
While Drupal 8 core and contributed modules provide a lot of powerful features, you might have some situations where you need to develop custom functionality for your website. In this section of the course, you'll learn how to create Drupal 8 modules from scratch. Some programming background required.
For a full course outline, see the training description on our website.
Location: Downtown Washington (Exact Location TBD)
Registration: https://evolvingweb.ca/training/5-day-drupal-8-training or https://www.eventbrite.ca/e/5-day-drupal-8-training-in-washington-dc-tic...
FAQ
What's provided? Lunch, snacks, and a training manual. Lots of one-on-one help as you go through the course.
Should I bring a laptop? Yes, please bring a laptop for the course.
Can I pay with a cheque? Yes, contact us and we can issue you an invoice for the training.
What are the pre-requisites? Understanding of basic Drupal concepts for Day 1, Familiarity with HTML and CSS required for Days 2-3, Programming experience required for Days 4-5
Do you offer discounts? Yes, we provide discounts for students, freelancers, and non-profit organizations. Please contact us for details.
Source: https://groups.drupal.org/node/512931/feed


Acquia a leader in the 2018 Forrester Wave for Web Content Management Systems

For the second year in a row, Acquia was named a leader in the Forrester Wave: Web Content Management Systems.

The report highlights Acquia and Drupal's leadership on decoupled and headless architectures, in addition to Acquia Cloud's support for Node.js.

I'm especially proud of the fact that Acquia received the highest strategy score among all vendors, ahead of Adobe, Sitecore and everyone else.

Thank you to everyone who contributed to this result! It's another great milestone for Acquia and Drupal.
Source: Dries Buytaert www.buytaert.net


Free Drupal 8 in a Day Training by Drupal Pune community in association with QED42 on 1st December 2018

Start: 
2018-12-01 10:30 - 17:00 Asia/Kolkata

Organizers: 

piyuesh23

ashishdalvi

Event type: 

Training (free or commercial)

http://bit.ly/drupalpunegtd

Hello Drupaler's,
We are excited to announce that the “Drupal 8 In a Day” training session for beginners will be held on Saturday, December 1, 2018 on Drupal Global Training Days.
This training session is an initiative by Drupal Pune Community in Collaboration with QED42 and Drupal Association.
Venue: QED42, Pune. Address : QED42, Sapphire Plaza, 401, 4th, New Airport Rd, Sakore Nagar, Viman Nagar, Pune, Maharashtra 411014
What is Global Training Days?
• Drupal Global Training Days is an exciting initiative from the Drupal community to introduce new and beginning users to Drupal. Trainers from companies and local groups around the world make newcomers to the Drupal community feel inspired and empowered to start great work.
• Follow Global Training Days with #DrupalGTD on Twitter
Who Should Attend?
• This training is only for beginners, a newbie who wants to learn Drupal.
• Drupal 7 and starting with Drupal 8
• This training is intended for PHP/Web developers, Career switchers, and Students who wish to begin their career in Drupal.
• This will also benefit the Tech and Business Managers who wish to evaluate Drupal 8 as an open source software.
Syllabus/Agenda:
• 10:30 am to 11 am: Introduction of the community
• 11 am to 12:30 pm: Introduction to Drupal CMS and Drupal 8
• 12:30 - 1:30 PM - Drupal Terminology
• 1:30 PM to 2:30 PM - Lunch Break
• 2:30 PM to 3:30 PM - Drupal 8 site building
• 3:30 PM to 4:30 PM - Extending Drupal
• Writing a custom module using Drupal console
• Theming - Twig - Render API
• 4:30 PM to 5:00 PM - Drupal Contributions
Bring along your laptop to make the best use of this workshop.
System requirements:
1. Running Local Server :
* Download and Install MAMP/XAMPP/LAMP on your system.
* Windows User: XAMPP would be preferred (Faster and Easier) Install XAMPP for Windows
* Linux User: LAMP would be preferred. Run following command:apt-get install lamp-server
Gather knowledge about following :
* Content Management System
* Open Source
* PHP
* Mysql
How to register: This event is free but with limited seats. Registration is mandatory. RSVP!! http://bit.ly/drupalpunegtd
Source: https://groups.drupal.org/node/512931/feed


Why Drupal's Layout Builder is so powerful and unique

Content authors want an easy-to-use page building experience; they want to create and design pages using drag-and-drop and WYSIWYG tools. For over a year the Drupal community has been working on a new Layout Builder, which is designed to bring this page building capability into Drupal core.

Drupal's upcoming Layout Builder is unique in offering a single, powerful visual design tool for the following three use cases:
Layouts for templated content. The creation of "layout templates" that will be used to layout all instances of a specific content type (e.g. blog posts, product pages).
Customizations to templated layouts. The ability to override these layout templates on a case-by-case basis (e.g. the ability to override the layout of a standardized product page)
Custom pages. The creation of custom, one-off landing pages not tied to a content type or structured content (e.g. a single "About us" page).
Let's look at all three use cases in more detail to explain why we think this is extremely useful!

Use case 1: Layouts for templated content

For large sites with significant amounts of content it is important that the same types of content have a similar appearance.

A commerce site selling hundreds of different gift baskets with flower arrangements should have a similar layout for all gift baskets. For customers, this provides a consistent experience when browsing the gift baskets, making them easier to compare. For content authors, the templated approach means they don't have to worry about the appearance and layout of each new gift basket they enter on the site. They can be sure that once they have entered the price, description, and uploaded an image of the item, it will look good to the end user and similar to all other gift baskets on the site.

Drupal 8's new Layout Builder allows a site creator to visually create a layout template that will be used for each item of the same content type (e.g. a "gift basket layout" for the "gift basket" content type). This is possible because the Layout Builder benefits from Drupal's powerful "structured content" capabilities.

Many of Drupal's competitors don't allow such a templated approach to be designed in the browser. Their browser-based page builders only allow you to create a design for an individual page. When you want to create a layout that applies to all pages of a specific content type, it is usually not possible without a developer.

Use case 2: Customizations to templated layouts

While having a uniform look for all products of a particular type has many advantages, sometimes you may want to display one or more products in a slightly (or dramatically) different way.

Perhaps a customer recorded a video of giving their loved one one of the gift baskets, and that video has recently gone viral (because somehow it involved a puppy). If you only want to update one of the gift baskets with a video, it may not make sense to add an optional "highlighted video" field to all gift baskets.

Drupal 8's Layout Builder offers the ability to customize templated layouts on a case per case basis. In the "viral, puppy, gift basket" video example, this would allow a content creator to rearrange the layout for just that one gift basket, and put the viral video directly below the product image. In addition, the Layout Builder would allow the site to revert the layout to match all other gift baskets once the world has moved on to the next puppy video.

Since most content management systems don't allow you to visually design a layout pattern for certain types of structured content, they of course can't allow for this type of customization.

Use case 3: Custom pages (with unstructured content)

Of course, not everything is templated, and content authors often need to create one-off pages like an "About us" page or the website's homepage.

In addition to visually designing layout templates for different types of content, Drupal 8's Layout Builder can also be used to create these dynamic one-off custom pages. A content author can start with a blank page, design a layout, and start adding blocks. These blocks can contain videos, maps, text, a hero image, or custom-built widgets (e.g. a Drupal View showing a list of the ten most popular gift baskets). Blocks can expose configuration options to the content author. For instance, a hero block with an image and text may offer a setting to align the text left, right, or center. These settings can be configured directly from a sidebar.

In many other systems content authors are able to use drag-and-drop WYSIWYG tools to design these one-off pages. This type of tool is used in many projects and services such as Squarespace and the new Gutenberg Editor for WordPress (now available for Drupal, too!).

On large sites, the free-form page creation is almost certainly going to be a scalability, maintenance and governance challenge.

For smaller sites where there may not be many pages or content authors, these dynamic free-form page builders may work well, and the unrestricted creative freedom they provide might be very compelling. However, on larger sites, when you have hundreds of pages or dozens of content creators, a templated approach is going to be preferred.

When will Drupal's new Layout Builder be ready?

Drupal 8's Layout Builder is still a beta level experimental module, with 25 known open issues to be addressed prior to becoming stable. We're on track to complete this in time for Drupal 8.7's release in May 2018. If you are interested in increasing the likelihood of that, you can find out how to help on the Layout Initiative homepage.

An important note on accessibility

Accessibility is one of Drupal's core tenets, and building software that everyone can use is part of our core values and principles. A key part of bringing Layout Builder functionality to a "stable" state for production use will be ensuring that it passes our accessibility gate (Level AA conformance with WCAG and ATAG). This holds for both the authoring tool itself, as well as the markup that it generates. We take our commitment to accessibility seriously.
Impact on contributed modules and existing sites

Currently there a few methods in the Drupal module ecosystem for creating templated layouts and landing pages, including the Panels and Panelizer combination. We are currently working on a migration path for Panels/Panelizer to the Layout Builder.

The Paragraphs module currently can be used to solve several kinds of content authoring use-cases, including the creation of custom landing pages. It is still being determined how Paragraphs will work with the Layout Builder and/or if the Layout Builder will be used to control the layout of Paragraphs.

Conclusion

Drupal's upcoming Layout Builder will be unique in the market in that it supports multiple different use cases; from templated layouts that can be applied to dozens or hundreds of pieces of structured content, to designing custom one-off pages with unstructured content. The Layout Builder is even more powerful when used in conjunction with Drupal's other out-of-the-box features such as revisioning, content moderation, and translations, but that is a topic for a future blog post.

Special thanks to Ted Bowman (Acquia) for co-authoring this post. Also thanks to Wim Leers (Acquia), Angie Byron (Acquia), Alex Bronstein (Acquia), Jeff Beeman (Acquia) and Tim Plunkett (Acquia) for their feedback during the writing process.
Source: Dries Buytaert www.buytaert.net