It’s no secret that all software products work significantly better when updated. Drupal is no exception. All websites built with the Drupal CMS benefit immensely from the regular updates of the Drupal core, modules, and themes. On the contrary, ignoring these procedures can bring trouble.
Discover more about the importance of and the options for updating Drupal websites from today’s blog post by the Golems team of Drupal experts.What are Drupal updates compared to upgrades?
While speaking about Drupal updates, we need to make the terminology clear. You will often hear both the terms “updates” and “upgrades.” While they are sometimes used interchangeably, the standard and the most common practice is to:
DrupalCon is enhanced through the time and talent contributed by volunteers, and we offer a number of opportunities to influence and support the design and implementation of the event. We’ve put together an overview of the volunteer opportunities for your review and consideration. If one or more of the roles aligns with your interests and availability, submit your interest form.
Our community is in need of additional drupal.org site moderators (formerly "webmasters") to assist day-to-day site moderation tasks.
Over the past few years, the number of active site moderators in the Drupal.org site moderators queue https://www.drupal.org/project/issues/site_moderators?categories=All has decreased significantly. Recognizing that this isn't a sustainable situation, the current active site moderators have embarked on an effort to recruit new volunteers.Responsibilities of a site moderator
Site moderators are primarily tasked with responding to issues in the Drupal.org site moderators issue queue and the ongoing on-boarding of new community members. These tasks include:
- Responding to issues in the Drupal.org site moderators issue queue.
- Reviewing posts flagged as spam, deleting spam, and blocking users who post spam on Drupal.org web sites.
- Confirming new Drupal.org users.
- Responding to reports of projects posted on Drupal.org that do not meet community norms.
- Other related tasks as described on the Moderation and maintenance documentation page https://www.drupal.org/drupalorg/docs/maintenance.
In order to become a site moderator, there are a few easy steps:
- Familiarize yourself with site moderator responsibilities via the project https://www.drupal.org/project/site_moderators and the Site Moderator role description. https://www.drupal.org/community/contributor-guide/role/drupalorg-site_moderators
- Announce your intent to start participating in the #drupalorg-site-moderators channel in the Drupal Slack workspace.
- Begin participating in site moderator issues https://www.drupal.org/project/issues/site_moderators?categories=All - it is recommended that at first you ask questions and propose solutions to issues in a way that current site moderators can provide useful feedback.
- Once you have participated in the site moderator issue queue enough that you feel that you have a good handle on its various processes, open a new issue in the queue asking for the Drupal.org "site administrator" role. It is highly recommended that you are active in the issue queue and Drupal Slack workspace channel, and have interacted with the other active site maintainers before applying for this elevated role.
If you've made it this far, then the obvious question is "why should I become a Drupal.org site moderator?" Develop and exercise your people-skills while helping the Drupal community become a more sustainable, welcoming, friendly, and productive place. Regardless if you’re a developer, becoming a site moderator is a pretty straightforward way to build those skills.
- You'll work with other site moderators around the globe, building up your Drupal community network.
- You'll have the opportunity to help nurture new community members in a meaningful way.
- You'll have the opportunity to earn contribution credits.
- Having the "site moderator" role is a position of leadership in our community. https://www.drupal.org/about/values-and-principles#choose-to-lead
- If you or your organization uses Drupal and is looking for a way to give back, this is a small thing that will have a big impact.
Interested? If you have any questions, pop into the Drupal Slack workspace #drupalorg channel and ask away. When you're ready, start with steps 1 and 2 above and start your journey!
Thanks to Donna Bungard (dbungard https://www.drupal.org/u/dbungard), Darren Oh (https://www.drupal.org/u/darren-oh), Jordana Fung ( jordana https://www.drupal.org/u/jordana), and Mike Anello (ultimike https://www.drupal.org/u/ultimike) for assisting with this blog post.
Mobile app development is not rocket science in today's day and age. Making a good mobile application, however, is a process that requires a very lengthy pre-planning process. It could be as simple as launching the IDE, putting a few items together, doing a quick round of screening, and uploading it to an App Store, all achieved in half a day's work, to create your mobile application. Or you can render it a deeply engaged process involving comprehensive up-front design, QA testing on a range of platforms, accessibility testing, a complete beta lifecycle, and then various forms of deploying it. Your vision is given form by the direction you chose.souvik Thu, 01/21/2021 - 23:26 Drupal Planet Drupal 7 Drupal 8 user friendly website Web Design website development services web developers
Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, January 21, at 1pm ET / 10am PT. (Convert to your local time zone.)
No set agenda this month, so we'll have plenty of time to discuss whatever Drupal-related thoughts are on your mind.
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes
This free call is sponsored by NTEN.org and open to everyone.
- Join the call: https://us02web.zoom.us/j/329736027
- Meeting ID: 329 736 027
- One tap mobile:
+13017158592,,329736027# US (Germantown)
+13126266799,,329736027# US (Chicago)
- Dial by your location:
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 929 205 6099 US (New York)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
- Find your local number: https://us02web.zoom.us/u/kegAvyuFSW
- Follow along on Google Docs: https://nten.org/drupal/notes
- Follow along on Twitter: #npdrupal
With great content modeling powers comes great responsibility for Drupal developers.
While building a website, you may face the challenge of creating multiple paragraphs without much reuse. This can contribute to a poor content architecture that will burden you for the lifetime of your application. This issue can come about when a developer is building out paragraphs and decides to generate multiple paragraphs with similar fields or new fields that perform the same functionality as other fields.
For example, let’s say a developer is tasked with building a normal Text Paragraph which is just one textarea field, which is simple enough. Now, let’s say a client comes to that developer and ask if the Text Paragraph could have a header field, and a subheader field. Usually, a developer might decide to just create a new paragraph, maybe call it a Card Paragraph, that has a new header field, subheader field, and a new body field. Well, what if you could just reuse the body field from the Text Paragraph? There is a way to do that by using Form Displays and the default Paragraphs reference field widget. Of course, the example above is simple, but there might be better cases which will be explained below.Solution: Reuse Paragraphs and Form Displays
Mediacurrent’s Rain CMS is an open source project that comes bundled with ready-to-use content types and paragraphs. One of those is the Card paragraph. The Card paragraph by itself might just have a title, media, body, and layout field. This is pretty useful as its own componentized item that can be reused on other components. Now let’s say you have another paragraph that is called a Breaker, which essentially is almost like a Card Paragraph but might have some variation. This Breaker paragraph might reuse the same title, body, but also has an extra field called right body for any text that might need to be put on the right column.
The way one can keep reusing the Card paragraphs, with other paragraphs that get created in the future is to add more fields onto the Card paragraph itself.
As displayed above we have a ton of fields added on to the Card Paragraph. One might say that why are you doing this, wouldn’t all these fields get displayed on the frontend. Technically yes at first, but there is a way to limit what fields get displayed on the Card paragraph itself and then a step on getting the Breaker paragraph to utilize the same fields coming from the Card paragraph.
This method is using what’s called view modes in the Form Display configuration. What you want to do is go into Managed Form Display in the CMS for the Card paragraph that you just created and take a look at what displays are available.
As you can see above we already have some displays created in the Rain distribution we are using. We have the Default, Breaker, Carousel, Column, Card Compound, and Overlay Breaker. These are all Form Display’s which are used for other Paragraph variations.
Creating a new display is easy; you want to go to the bottom under the Default view mode and hit Custom Display Settings, which should drop down the above selection. As displayed in the screenshot there are some that are enabled and disabled. You can create a new one by clicking Managed form modes.
Now that we sidetracked a bit and explained how view modes work and how they are created, let's dive back in and talk about how you can now create this Card variation paragraph which is called the Breaker. Since we have a display already enabled for the Breaker what you want to do is click on the Breaker and see what fields are enabled by default.
Shown above this has the title, body, and the new body right field which is technically still part of the Card Paragraph, but just using a different form display. If you compare this display with the default display you can see that different fields are enabled and disabled, which allows for flexibility for reusability. Now that we see that the fields needed for the Breaker have been created or enabled, let’s go create the Breaker paragraph.
We then add a description and say that this is a breaker that will have content with two columns. If you remember above we have a body field and a body right, this is used to create these two columns.
When creating your Breaker paragraph make sure to add all the fields that are unique to this breaker like Line Break, and Show Two Columns which have specific functionality for the Breaker, but you also want to create a Paragraph reference field called Card which will allow you to reference a Card.
So how do you get it so this Card field shows the fields that you want from the Card Paragraph? Well, that’s why we worked on using the view mode on the Form Display for the Card Paragraph. What you want to do is the following.
Under the Breaker paragraph go to the Managed Form Display. Then under the Card field, you can use any widget that has the Form Display mode available. This will allow you to use the Form Display mode option in the widget to target the right display mode you want to use from the Card. Select the Breaker display mode.
Once this is done, hit save. Now what you should expect is that whenever you go to create a breaker and you use the card field it should show the fields that are specified on the Card Breaker view mode.
Building Paragraphs the Smart Way
Now whenever you as a developer get tasked with building out a paragraph, make sure to ask yourself: What can I do to reuse fields and displays as much as possible? I hope this guide will help you to make smart decisions for a better content architecture going forward.
It's essential that companies have a presence online in the digitalised global economy. Enterprise web development is thus, naturally, an important opportunity for a company to achieve online exposure and enter a broader audience. Web creation for business is essentially the method of creating a company-level website.
Enterprises run the gamut from mid-sized to large-scale enterprises and institutions (governmental, for-profit or non-profit) to organizations and collectives (healthcare, education, philanthropy, or any other group with a common purpose or similar goals).
“Tell me and I forget, teach me and I may remember, involve me and I learn.” Wise words of a man whose head still appears on the 100 dollar bills in America. With Benjamin Franklin’s thoughts in the back of our minds, Dropsolid heads to DrupalCon every year. With one primary goal: learning. Learning from and teaching to a fantastic Drupal community. Because only by knowing what is really alive in this community we can make Dropsolid the most successful Martech company, with a focus on Open DXP solutions with Drupal at its core. So we put our money where our mouth is and we went out to investigate. For several years now we’ve been launching a survey in which we donate 15 minutes of open source contribution time for every completed form to develop Drupal even further. But we also exchanged ideas with like minded visitors and we conducted interesting follow-up conversations with listeners of all our sessions. What we’ve learned from this? We’ll tell you all about it below!
What keeps a Drupal developer up at night?
Jamstack & Drupal, match made in heaven?
Data is the new gold
Some developers are convinced that data is the new gold and this of course raises the concept of data ownership and the fear of being dependent on external vendors. There were a number of discussions at DrupalCon about how Drupal can deal with this and what standard privacy protection measures Drupal could take with new installations.
Rising star: DXP
What did come as a big surprise is that developers are not yet completely familiar with the concept of DXP. More than half of our surveyed developers said they had never heard of it. At Dropsolid, Drupal is a permanent pillar of content management in our DXP projects, and it has become our mission to put DXPs on the map!
Opportunities for Drupal developers in the future
From our research, the many conversations and responses to our sessions at DrupalCon, we noted that developers in general are less involved in the end-user experience and customer journeys of (potential) customers. They have a limited view on the different platforms a brand uses to connect with its customers and how exactly that happens. Not necessarily a problem? But also not that unimportant! Keeping the end goal in mind is important for every position in a company. The communication between the different departments runs smoother when this is clear to everyone, the noses are in the same direction and everyone speaks the same language. Just think of the gap between business and development: how do you get a concept really sharp without all departments having a clear view of the core objective?
It could be the perfect time, for you as a Drupal developer, to expand your horizon. If you, as a developer, have an overview of the end user's goal, show a healthy interest in the optimal customer experience for your client and understand the needs of this new market? Then you are already one giant step ahead. It’s precisely these profiles that fill the gaps in the current market and make big career opportunities possible.
3 things business owners can learn from this
- A good connection between the different departments, in particular business and IT, is priceless and an absolute must for every company.
- The balance between customer experience and operational excellence has to be in harmony.
- A lot of agency owners are worried about the previously listed roadblocks, and yet there is an obvious solution that is emerging: a Digital Experience Platform (DXP).
Introducing a DXP into your business offers solutions for many problems. But what exactly does it provide? We’ll dive in deeper below.Advantage 1: your team works closer together
A DXP brings teams closer to each other because everyone is working on one and the same framework. The end user is put in the center and the needs, wishes and goals of each individual are fulfilled this way. Doing so, companies can easily create a safe, maintenance-friendly and digital environment that offers an excellent experience to the visitor. The various employees, both developers and marketeers, ensure an excellent experience by co-creating as a cohesive team and achieving the end result together. The involvement of both parties increases, which of course benefits the quality.Advantage 2: increase of productivity
Increased productivity: among other things, the integration of Gitlab provides a boost in productivity. In this blog we dive deeper into this integration, we list the benefits and clarify with a short demo.Read the blog Advantage 3: a DXP is very accessible
Turning Drupal into a DXP… Really, it sounds more difficult than it actually is. Even for mid sized enterprises, it’s very accessible. We are by your side the entire way and will get you started with a solid foundation so your company can enjoy all the benefits a DXP has to offer. And we promise, there are many! In this technical webinar, our CTO, Nick Veenhof, explains exactly how to get started.Watch the replay DXP: an opportunity you can’t miss out on
In 2021, we're focusing even more on personalized, digital and progressive customer experiences. Mid-sized enterprises can also easily jump on that boat this year by turning their Drupal into a DXP. Not sure if your company is ready for this? Simply test it with our free trial. We’ll guide you, your company and your team from A to Z.Get your free trial
The dilemma of choosing the more suitable CMS from a range of possible CMS options can be overwhelming.' is a major question that comes to mind when thinking forward towards development.souvik Thu, 01/21/2021 - 18:30 Drupal Planet Drupal Development Drupal Drupal 7 Drupal 8 user friendly website Web Design website development services web developers
New year, new web design trends. This means that it is time to start updating your Drupal websites. Don't panic, there are not many things that need to be changed or upgraded. Check our article on web visual and technological trends that will be popular for websites and mobile applications in 2021.
You can find the link here.
The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal. For more information please see:
Exploits may be possible if Drupal is configured to allow .tar, .tar.gz, .bz2, or .tlz file uploads and processes them.Solution:
Install the latest version:
- If you are using Drupal 9.1, update to Drupal 9.1.3.
- If you are using Drupal 9.0, update to Drupal 9.0.11.
- If you are using Drupal 8.9, update to Drupal 8.9.13.
- If you are using Drupal 7, update to Drupal 7.78.
Versions of Drupal 8 prior to 8.9.x are end-of-life and do not receive security coverage.
Disable uploads of .tar, .tar.gz, .bz2, or .tlz files to mitigate the vulnerability.Reported By:
People today do not like to be confined, if I talk about development teams, they would hold up flags stating the same. Since development and innovation go hand in hand and constraint is the biggest enemy of innovation, you can’t tell me they are wrong to have that notion.
Talking specifically about web developments, there are a lot of areas to explore and a lot of technologies to help you do that. So, why limit yourself, when you don't have to? Drupal has brought such an impressive trend forward that has simply satiated the developer’s desire for innovation and that is the headless approach.
Unlike before, when your entire project had to be nestled inside one CMS, Drupal now gives you the opportunity to explore new technologies to your heart’s desire. This is possible because the presentation layer and the backend content become two separate entities. Drupal acts as the content repository and a frontend technology of your liking takes care of, of course, the frontend part of website architecture.
To provide a connection between the separated development aspects of the project, enters the API. An API layer is a necessity when going headless, because it transmits all the information from the front to the backend and vice-versa.
And the three available APIs in Drupal, REST, JSON and GraphQL, are the reason behind me writing this blog. Although the purpose of all three is the same, they are quite different from one another. Today, we would be highlighting their meanings, their pros and cons and all the visible distinctions they have. So, let’s begin.Decoding the APIs
REST, JSON and GraphQL bring in a similar outcome when they are used for decoupling Drupal. Yes, they are different too. And we would get into the difference between REST, JSON and GraphQL soon. Before that it is essential to understand their history, origin and what they were intended for because the differences actually start from there.
REST was developed by Roy Fielding in the year 2000, the purpose behind its development was to provide a software architectural design for APIs. In simple terms, it provided an easy path for one computer to interact with another by utilising an HTTP protocol. The communication between the two computers is not stored on the server, meaning it is stateless; rather the client sessions are stored on a client-side server.
There are six constraints necessary to implement REST in the complete sense.
- It needs a separated client and server;
- It needs to be able to make independent calls;
- It needs to able to store cacheable data;
- It needs to have a uniform interface;
- It is a layered system;
- Finally, it needs a code-on-demand.
REST offers a great deal of functionality without a lot of effort. For instance, if you are working on someone else’s RESTful API, you would not need a special library or special initialisation. Yes, your developers need to design their own data model using REST, but the HTTP conventions at play make programming a breeze.
To know how REST plays a key role in decoupling Drupal, read our blog REST APIs in Drupal.
With JSON: API, communication between the server and the client becomes extremely convenient. It not only formats the way a request should be written, but the responses also come in a formatted manner. The primary aim of JSON: API is to lessen the number of requests and shrink the size of the package, all using HTTP protocol.
- JSON reduces the number of requests and amount of data being transmitted;
- It requires zero configuration;
- It uses the same JSON access scheme for every piece of data, making caching very effective;
- It offers quite a few features and gives you, as the client, the opportunity to turn them on or off.
To know how JSON:API plays a key role in decoupling Drupal, read our blog, JSON API in Drupal.
The features of GraphQL are that;
- It allows users to request data from multiple resources in a single request.
- It can be used to make ad-hoc queries to one endpoint and access all the needed data.
- It gives the client the opportunity to specify the exact type of data needed from the server.
- All of these add to its predictable data structure, making it readable as well as efficient.
It was in 2015, after GraphQL was open-sourced that it became truly popular. Now its development is governed by The GraphQL Foundation, which is hosted by the Linux Foundation.
To know how GraphQL plays a key role in decoupling Drupal, read our blog, GraphQL in Drupal.
Now that we know the basics of all the three APIs, let us have a look at their popularity status, before beginning the comparison.A glimpse at the popularity of the three APIs. Source: State of API Report 2020REST vs JSON vs GraphQL
Now let’s get down to the details and understand why choosing one over the other two could be in your best interest. Let’s start with the differences between REST, JSON:API and GraphQL.How efficient is the data retrieval?
One of the most important aspects for an API is the way its fetches data. It could require one or more requests. Therefore, this aspect is also referred to as its request efficiency. Getting multiple data responses in a single request has to be an ideal, so let’s see how REST, JSON: API and GraphQL here.
The REST API is innately built to capitalise one resource per request. This works perfectly as long as you only need to retrieve a single piece of data like an article. However, if you need more than that, the number of requests you would have to type in separately would be equivalent to the amount of data you need.
One article = one request
Two articles = two requests
Two articles and the author information stored in a different field = Two requests for the articles + a long wait for the completion of those requests + two additional requests for the author information.
This sums up REST’s request efficiency to the T. You require to be equipped to handle a number of requests, which can ultimately stall your user experience, making it seem to go at a snail’s pace. No sugar-coating here, there are going to be a lot of round trips.
And the problem with a lot of round trips is a lot of extra information you do not even need. This is because there is a possibility that a REST API endpoint might not have the required data for an application. As a result, the said application will not get everything it needs in a single trip, making multiple trips the only option. It's safe to say that REST over-fetches and the verbose responses can be a problem.
JSON: API does not suffer from the multiple request conundrum. One single request can give you everything you want, be it one article, two or ten along with the author’s information, I kid you not.
This is possible because JSON: API implements a concept called ‘sparse fields.’ What this does is list the desired resource fields together for easy fetching. You can have as many fields as possible. If you feel the fields are too long and would not be cacheable, you can simply omit a few sparse fieldsets to cache the request.
Another thing to remember is that the servers can choose sensible defaults, so your developers would need to be a little diligent to avoid over-fetching.
Coming to GraphQL, it was also designed in a similar fashion to JSON: API and is competent enough to eliminate the problem of over-fetching and avoid sending multiple requests.
GraphQL has its own queries, schema and resolvers that aid the developers in creating API calls with particular data requirements in mind. Moreover, by mandating clear-cut additions to every resource field in every query and ensuring the developers cannot skip any of it, it is able to avoid multiple round trips. Thereby, making over-fetching information a thing of the past.
The only problem here can be that the queries may become too large, and consequently, cannot be cached.How is the code executed?
Using an API for calls involves the execution of a code on the server. This code helps in computing, calling another API or loading data from a database. All three of the APIs use a code, however, the code is implemented varies a little.
Route handlers are utilised for execution upon a REST call. These are basically functions for specific URLs.
- First the server receives the call and retrieves the URL path and GET;
- Then the functions are noted and the servers begins finding the same by matching GET and the path;
- After that the result is generated, since the server would have executed the function;
- In the final step, once the result is serialised by the API library, it is ready for the client to see.
GraphQL operates in a relatively similar manner. The only difference is that it uses functions for a field within a type, like a Query type, instead of using functions for specific URLs.
Route handlers are replaced by resolvers in GraphQL, they are still functions though.
- After the call is made and the server has received a request, the GraphQL query is retrieved.
- The query is then examined and the resolver is called upon for every field.
- Finally, the result is added to the response by the GraphQL library and it is ready for the client to see.
It should be noted that GraphQL offers much more flexibility as multiple fields can be requested in one request, and the same field can be called multiple times in one query. The fact they let you know where you performance needs fine-tuning makes resolvers excellent trackers as well.
This is simply not possible in REST and JSON. Do you see the difference in implementation?How do the API endpoints play a role?
Many a time, it is seen that once the API is designed and the endpoints are sealed, the applications require frontend iterations that cannot be avoided. You must know that the endpoints aid an application to receive the required data just by accessing it quickly in the view, so you could call them essential even.
However, the endpoints can pose a bit of a problem for the iterations, especially when they need to be quick. Since, in such an instance, changes in the API endpoints have to be made for every change in the frontend, the backend gets tedious for no reason at all. The data required for the same can be on the heavier side or the lighter side, which ultimately hampers the productivity.
So, which API offers the solution?
It is neither REST, nor JSON. GraphQL’s flexibility makes it easy for the developers to write queries mentioning the specific data needs along with iterations for the development of the frontend, without the backend having to bear the brunt.
Moreover, GraphQL’s queries help developers on retrieving specific data elements and provide insights to the user as to which elements are popular and which aren’t amongst the clients.
Why doesn’t REST?
The answer is simple, REST has the entire data in a single API endpoint. Being a user, you won’t be able to gain insights on the use of specific data as the whole of it always returned.How good is the API exploration?
Understanding your API and knowing about all of its resources and that too quickly and with ease is always going to benefit your developers. In this aspect, all three perform pretty contrastingly.
REST gives a lacklustre performance in API exploration to be honest. The interactivity is pretty substandard as the navigation links are seldom available.
In terms of the schema, it would only be programmable and validatable, if you are going to be using the OpenAPI standard. The auto-generation of the documentation also depends on the same.
JSON performs better than REST. The observation of the available field and links in JSON: API’s responses helps in its exploration and makes its interactivity quite good. You can explore it using a web browser, cURL or Postman.
Browsing from one resource to the next, debugging or even trying to develop on top of an HTTP-based API, like REST, can be done through a web browser alongside JSON.
GraphQL is indeed the front-runner here. It has an impressive feature, known as the GraphiQL, due to which its API exploration is unparalleled. It is an in-browser IDE, which allows the developers to create queries repeatedly.
What is even more impressive is the fact the queries get auto-completed based on the suggestions it provides and you get real-time results.Let’s focus on schema now
Schemas are important for the development team, the frontend and the backend equally. It is because once a schema has been defined, your team would know the data structure and can work in parallel. Creating dummy test data as well as testing the application would be easy for the frontend developers. All in all, the productivity and efficiency levels elevate.
REST does have an associated expected resource schema since it is a set of standard verbiage. Despite this, there is nothing that is specifically stated in them.
In terms of schema validation and programming, it does define a generic one, however, a reliable field-level schema is yet to be seen. Simply put, JSON is basic with regards to schema.
The fact that GraphQL functions completely on schemas makes it a pro in this regard. The schema used here is Schema Definition Language or SDL. What this means is that GraphQL uses a type system that sets out the types in an API because all the types are included in SDL. Thus, defining the way a client should access data on the server becomes easy.
To conclude this point, I would want to say that when there is immense complexity in the schema and resource relationships, it can pose a disadvantage for the API.How simple is to operate it?
Operating an API essentially involves everything, from installing and configuring it to scaling and making it secure. REST, JSON: API and GraphQL, all perform well enough to make themselves easy to operate. Let’s see how.
REST is quite simple to use, a walk in the park for a pro developer. It is because REST is dependent on the conventional HTTP verbiage and techniques. You would not need to transform the underlying resources by much, since it can be supported by almost anything. It also has a lot of tools available for the developers, however, these are dependent on their customisation before they can be implemented.
In terms of scaling, REST is extremely scalable, handling high traffic websites is no problem at all. To take advantage of the same, you can make use of a reverse proxy like Varnish or CDN. Another plus point of REST is that it has limited points of failure, being the server and the client.
JSON: API is more or less the same as REST in terms of its operational simplicity, so much so that you can move from REST to JSON: API without any extensive costs.
- It also relies on HTTP;
- It is also extremely scalable;
- It also has numerous developer tools, but unlike REST, JSON: API does not need customised implementations;
- Lastly, JSON also has fewer failure points.
GraphQL is the odd one out here. It isn’t as simple to use as the other two. It necessitates specific relational structure and specific mechanisms for interlocking. You would be thinkin that how is this complex? Let me ask you to focus on word specific, what this means is that you might need to restructure your entire API with regards to resource logic. And you must know that such restructuring would cost you time, money and a boatload of efforts.
Even in terms of scalability, GraphQL does not fare very well. The most basic requests also tend to use GET requests. For you to truly capitalise GraphQL, your servers would need their own tooling. If I talk about the points of failure here, even those are many, including client, server, client-side caching and client and build tooling.What about being secure?
The kind of security an API offers is also an important consideration in choosing it. A drastic difference is noted in REST and GraphQL. Let’s see what that is.
REST is the most secure amongst the three. The intrinsic security features in REST are the reason for the achievement.
- There are different APU authentication methods, inclusive of HTTP authentication;
- There are the JSON Web Tokens for sensitive data in HTTP headers;
- There are also the standard OAuth 2.0 mechanisms for sensitive data in JSON structure.
JSON:API is on a similar footing to REST in terms of security. The reason being the fact that like REST it exposes little resources.
It is not like GraphQL is not secure, it is; however, the security has to be manually attained. It is not secure by default and it is not as mature as REST in this regard.
When the user has to apply authentication and authorisation measures on top of data validation, the chances of unpredictable authorisation checks rise. Now, do I have to tell you that such an event is bound to jeopardise your security?How is the API design pinpointed?
If an API has to perform well for every use case, you have to make it do so. By creating such design choices that are a result of your understanding of the users’ needs. You cannot just go with the flow, evaluating how your users are going to be interacting with your API and getting an understanding of the same is key for your API’s design.
For REST, this exercise of deciphering the user requirements must happen before the API can be implemented.
As for GraphQL, this apprehension can be delayed a little. By profiling the queries, you would be able to tell their complexity level and pinpoint the sluggish queries to get to an understanding of user’s consumption of the API.What about their use in Drupal?
Drupal is an important player when it comes to building websites and managing their content. With decoupling Drupal becoming more and more popular, it has become crucial to understand how the APIs perform alongside Drupal.
With REST, the clients that cannot create queries with the needed filters on their own, since the REST module does not support client-generated collection queries. This is often referred to as decoupled filtering.
JSON:API module landed in Drupal core in Drupal 8.7. JSON:API’s configuration is as easy as ABC, there is simply nothing to configure. JSON is a clear winner in this aspect.
Moving to client-generated queries, JSON does offer its clients this luxury. They can generate their own content queries and they won't need a server-side configuration for the same. JSON’s ability to manage access control mechanisms offered by Drupal make changing an incoming query easy. This is a default feature in JSON:API.
The installation of GraphQL is also not as complicated as REST, but it isn’t as easy as JSON as well. This is because it does mandate some level of configuration from you.
Similar to JSON, GraphQL also offers decoupled filtering with client generated queries. A less common trend amongst GraphQL projects is seeking permissions for persisted queries over client-generated queries; entailing a return to the conventional Views-like pattern.
In addition to these three major Drupal web services, explore other alternatives in the decoupled Drupal ecosystem worthy of a trial. Read everything about decoupled Drupal, the architecture-level differences between headless and traditional setups, different ways to decouple Drupal, and the skills required to build a Decoupled Drupal web application to know more.Concluding with the basics
To sum up, let us look at the fundamental nature of the three APIs, which entails two aspects; simplicity and functionality.
In terms of simplicity, REST is a winner. A second would be rewarded to JSON, while GraphQL would not and could not be described as simple, complex and that too immensely with major implementations coming your way would be a more accurate description. In terms of functionality, GraphQL does offer the most. If you choose JSON over GraphQL, you would end up parting with some of its features unfound in JSON.
All three are powerful and efficient in what they can do for your application. The question is how much complexity are you willing to take up with that power?blog banner blog image JSON:API REST API GraphQL Drupal Web Services Blog Type Articles Is it a good read ? On