Forem: Wrike Tech Club

Callisto: An Easy Way To Run Selenium Tests in the Cloud

Wrike Tech Club — Tue, 09 Feb 2021 11:35:52 +0000

Wrike recently open sourced a tool for Selenium testing called Callisto, so we wanted to share our experience with its development and usage.

Say no to Selenium Grid

Callisto is an open-source Kubernetes-native implementation of Selenium Grid.

We had previously been using Selenium Grid, but the experience wasn’t always great.

Selenium Grid has critical downsides:

It demands a lot of computational resources, but there’s always a chance of stability and reliability issues.
Selenium Hub (the part of Grid) can be an infrastructure bottleneck; it stores sessions/nodes mapping and forwards requests from a test to an appropriate node. It’s not possible to horizontally scale Hub by adding new instances, so if Hub is down, all sessions in Grid are inaccessible.
After a while we had a broad range of Selenium configurations (nodes, browsers, etc.), and it was difficult to maintain.
There were constant pain points of observability and error handling. Timeouts and unpredictable delays of test execution happened often, and unfortunately we had no tools to debug these issues properly.

It didn’t look good so we started to think about how we could fix these issues. We wanted the platform to run tests and not require constant support from QA and operation engineers.

As a result of our initial research we learned what we wanted our infrastructure to be: it should be managed by the Infrastructure as Code approach, eliminate toil and manual work, and bring the benefits of immutability and autoscaling.

Key application requirements and Kubernetes (unsurprisingly)

Based on previous conclusions we defined some key application requirements:

We don’t want to manage data and think about storage. That’s why our solution for Selenium testing should be stateless.
It should be lightweight so we can optimise our resource usage.
Containers and orchestration are cool for short release cycles and fast iterative development, so we started to think about the Kubernetes-native approach.
Since we wanted to increase visibility, we decided to use a fresh and clean environment for each and every test.

In regards to the second point above, it’s easy to understand why we chose Kubernetes, as there are obvious perks:

Kubernetes is an open-source solution, and has a great community and ecosystem.
It allows you to build an on-demand and scalable infrastructure.
The powerful API is helpful for any integration purposes.
Finally, we can declare all objects as code and pass it through our CI/CD pipelines without any trouble.

Our failed attempt to not reinvent the wheel

After we described what we wanted to achieve, we researched existing solutions.

It’s no surprise that we started with considering to fork Selenium Grid.

But we soon realized the Selenium codebase is big and complex. If we wanted to develop and maintain it, we needed to hire people with specific and specialized skill sets. And still it’d be difficult to integrate our changes to upstream.

At that time there was the public beta of Moon from Aerokube. Moon is the solution that brings you one universal autotest endpoint for all your applications and teams. Look’s good, but you have to pay to use it.

Also we understood that if we simplify this approach we’ll get a scalable, stateless solution that could be built quickly and on your own.

There’s no need for one central endpoint for all tests if you’re able to create several test endpoints with various configurations for every application on the fly. It’s simple enough to set up all the parameters for a test run and an infrastructure from the continuous integration pipeline.

So let’s conclude our intentions. We don’t want to develop a multi-purpose and complex toolchain. Instead, we decided to create a Kubernetes-native and simple solution that should do one thing and do it well. And as long as we keep it simple, we can observe and debug it with less effort.

Keep it simple

Before we dive into a detailed review of Callisto, we should outline what problem it solves.

Generally, there are UI tests that require browsers to execute some actions. To create a pod with a browser, we have to use the Kubernetes API. In principle, the tests could do it themselves, but this way has drawbacks that include observability and security issues. Another option is to move the Kubernetes interaction logic to a specific service.

That’s why we’ve created Callisto.

The test asks Callisto to create a browser. Using Kubernetes API, Callisto creates a pod with Webdriver and a browser, gives it to a test, and then deletes a pod at the end of a test.

How Callisto works

To deploy Callisto you can use the production-ready Helm chart; to automate the deployment, just use your usual CI/CD toolchain. We prefer to deploy the Callisto instance for every CI pipeline and shut it down at the end of test runs.

Let’s take a closer look at the usual browser creation workflow. This workflow is simplified and doesn’t include Kubernetes-related parts (ingress, service, etc).

Some external clients (e.g., Java-based autotests) send POST requests to Callisto endpoint for browser creation purposes. Callisto uses standard Webdriver protocol. Client creates a session by sending a POST to /session endpoint.

The request is first handled by Nginx, which then forwards /session requests to the Callisto application. Callisto processes these requests and interacts with the Kubernetes API to create a Webdriver pod.

When the pod is ready, Callisto passes /session request to the Webdriver instance inside the pod, and Webdriver creates a browser.

After the browser is created, Callisto returns SessionId to a client.

SessionId contains information about a pod name and internal IP. Nginx takes it into account and forwards requests from clients (tests) to appropriate pods with Webdriver and browser. There’s no need to store session data in the database, and that’s why Callisto is a stateless and fault tolerant solution.

Here you can see the complete workflow that we use to create a Webdriver session. After this stage Webdriver and the browser inside the cluster are ready to work.

The client can interact with Webdriver using SessionID from the previous step and sends commands to the browser. Nginx gets this type of request and forwards it to Webdriver, then a browser performs some test actions and returns the result to the client.

When the job is finally done, a client needs to clean up the mess. Our client sends another request to Callisto endpoint, in this case it should be DELETE http request.

Usually after a DELETE request, Webdriver uses the WebDriver.quit() method to close all browser windows and terminate the session. But with Callisto you don’t have to waste time on a browser termination, because Callisto creates a brand new pod for every test. So we can skip termination and delete a pod right away, allowing us to complete a test as fast as possible and decrease the cost of infrastructure on a large scale.

That’s why Callisto just deletes the Webdriver pod using Kubernetes API and returns a WebDriver.quit() sample response to a client.

Here’s a complete workflow of Webdriver sessions termination.

Why you should give Callisto a try

It’s easy to deploy and use Callisto on top of your Kubernetes cluster.
Callisto is stateless and therefore reliable.
The stateless and lightweight nature of Callisto makes it fault-tolerant and gives you the ability to run your tests on cheap hardware without trade-offs between reliability and costs. You can run Callisto on top of preemptible or spot instances. For example, we prefer to deploy Google Kubernetes Engine worker nodes based on preemptible instances, and our spendings decrease significantly compared to Selenium Grid usage.
Callisto uses open-source Webdriver images (all thanks to folks from Aerokube), allowing you to focus on your tests instead of browser packaging and updates.
Callisto provides a useful set of metrics (either for monitoring or debugging) in Prometheus format. You can build fancy dashboards in Grafana based on these metrics.

Thanks for reading! I hope everything was clear and informative enough for you to start using Callisto. You can get it all on Github: source code, docs, and Helm chart. Feel free to contribute and share your experience. Good luck!

Zones in Dart: Open Heart Surgery for Environment

Wrike Tech Club — Fri, 23 Oct 2020 12:28:50 +0000

Hello! My name is Dima, I’m a frontend developer at Wrike. We write the client part of the project in Dart, and we often deal with asynchronous operations. Zone is one of the most useful and powerful tools that Dart provides for this purpose. I decided to dig into it myself and share my knowledge with you.

Disclaimer: All the code used in this article only pretends to be a copy paste. In fact, I’ve greatly simplified it and got rid of the irrelevant details. For this article, I used Dart version 2.7.2 and AngularDart version 5.0.0.

I hadn’t heard much about zones before Dart. They aren’t typically used directly and have quite specific features. As the dart:async import hints to us, they make sense particularly for asynchronous operations.

In Wrike (as well as any other project on AngularDart), you can usually find zones in pieces of code like this:

Advanced Dart developers call it ancestral knowledge — just do what others did before you and it’ll work.

However, if you look under the hood of some libraries, you’ll find that zones are often used to:

Simplify the API in utilities that use asynchronous operations.
Fix some drops in app performance.
Catch unhandled exceptions and fix bugs (which are sometimes caused by zones but are irrelevant now).

There are a few resources about zones in the Dart community, except for the issues on GitHub. This is the API documentation, an article from the official site of the language, which explains the case of catching asynchronous errors, and a few talks such as the DartUP conference. Therefore, as the most complete guide I suggest the code itself.

In this article I’ll show you code examples from the libraries that we use in the project:

package:intl;
package:quiver;
package:angular.

Let’s start with the basics.

Intl and temporary locale switch

The Intl package is part of our localization engine. The principle of operation is quite simple: When the application starts, we look for a locale selected by default, load it, and each time we call the message or plural methods, we return the required text for the passed key.

Keys are named this way:

Sometimes we need to change the locale temporarily, i.e., a user enters a time period and we need to parse it from the current language. If we can’t do it from the current one, then we’ll try a fallback language. We use the withLocale method provided for this purpose:

Here we’re trying to parse user input first in the default locale, and then in the fallback locale.

It looks like withLocale changes the current language to the specified one, executes the passed callback, and then returns everything as it was.

But the parseText method returns with Future, because the necessary locale may not be loaded yet, which means we need to wait for the result. While we’re waiting, the user touches something in the interface and it starts to re-render. Since the current locale at this moment is Russian, the interface also changed the language to Russian. And when the operation is over, it’s back to English. No good.

What we want here is Future itself to report that the asynchronous operation has ended, then to pass on control and the result. In that case, the algorithm could switch the locale at the right time.

1. What’s under the hood of Future?

The good news is it’s possible! We’ll call ab asynchronous function and get a Future instance at the output:

When creating an instance, Future remembers the current zone. Now we’ll need to plan the processing of the result by using the then method:

Interesting! First, we’ll tell the current zone which callback will be executed in the future. Then we’ll create a new Future, schedule it to process the result of the asynchronous operation, and return it. The new Future remembers the zone where it was created — Zone.current. After getting the result thanks to the runUnary method, it executes a callback in the saved zone. Zone knows when the callback was added and when it should be executed, which means the execution process can be managed!

2. What’s a zone, where does the current zone come from, and what does “run inside the zone” mean?

“It’s an execution context.” — Brian Ford, zone.js author

Zone is an object that can be described by the word “context.” It can carry contextual data and behavior. All entities that know about zones use the data or behavior of the current zone in one way or another. When working with Future, we’ve already seen that if it needs to execute a callback, it delegates this work to the zone using the run* family of methods. And it already imposes final features and side effects on the execution of the callback.

The current zone is the zone currently referenced in the _current field. Zone.current is a static getter for accessing _current. In the code it looks like this:

This field differs from a global variable because it can’t be easily changed. To do this, you need a set of run* methods the zone instance has: run, runUnary, and runBinary. In the simplest case, these methods temporarily write their zone in the _current field:

Before executing the callback, a new zone is written in the _current field, and the old zone is returned after execution. To execute inside the zone means replacing the zone in the Zone.current field with the one selected for the duration of the function.

That’s it! You can even say that if the current field had a setter, these two code pieces would act similarly:

An important difference is that run* methods guarantee the current zone will not only switch to the necessary one, but will also return to the previous one when the callback is finished. The switch will be only temporary. Instead, the developer may forget about switching or simply consider it unnecessary.

Now you see that the Intl service should be fine if it uses zones under the hood. They’ll help control the switching of the locale.

3. How does Intl service use zones?

Let’s go back to the service and look at the withLocale method:

That’s something new! Let’s start at the beginning.

The runZoned function executes a callback inside the zone. But we don’t provide an instance of the existing zone, because runZoned creates a new zone and immediately executes a callback in it. And the run* methods execute a callback in an already created zone.

The second interesting detail here is the zoneValues map — powerful tool that allows you to save data in the zone. You can put any type of data in zoneValues with a unique key (our piece of code uses Symbol).

Now let’s see where the data is read:

Voila! First, we’ll check if the locale ID is in the zone. Next, we’ll return either the locale ID or the default locale. If a locale is recorded in the zone, it’ll be used.

Data in the zone is read using the [] operator, which searches for the value in the zone and its parents (we’ll discuss them later). But the []= operator is undefined, which means that the data assigned to the zone during creation can’t be changed. This is why the withLocale method uses runZoned:

A pre-created zone wouldn’t work here, so we’re constantly creating a new zone with the current data.

Finally, let’s go back to the beginning:

Now we know the callback of the withLocale method will be executed in the zone, and the locale we need will be written in it. Moreover, each Future created in this zone will save a link to the zone and execute its own callbacks in it. This means that the locale will switch to the specified one each time before executing _parseText and return immediately after executing _parseText. Just what the doctor ordered!

Now we also know how Future can interact with zones. Future, Stream, and Timer are “soaked” with such interactions with zones inside and out. Zones are aware of almost every step they take; that’s why they have such capabilities and power. We can learn more about them from the following example.

FakeAsync and fast asynchronous code testing

In our team, all frontend developers write unit tests. Sometimes we need to test code that works asynchronously. Dart out of the box has great testing tools, i.e., the test package that can work with asynchronous tests. When we need to wait, it’s enough to return Future from the callback of the test function, and the tests will wait for the call of the expect function until Future is completed:

In this fairytale, I’m not satisfied with one thing: waiting. What if we’re testing a stream with debounce per second or an operation has a one-hour timer? In such cases it’s worth using the mock from the outside, but this isn’t always possible.

We’re back to the problem of asynchronous tasks. But now we know we can ask zones for help. Authors of package:quiver have already done this and have written a FakeAsync utility.

This is how it works:

We’ll create a FakeAsync object, an asynchronous operation will start with it, and all timers and microtasks will be reset. And then all the scheduled work is executed.

Let’s imagine ourselves as Penn and Teller again and see how this magic works.

1. How FakeAsync actually works

Let’s take a look at the run method:

Create your own zone, run a callback in it, and return the result. There’s nothing to it.
But from the first line we’ll meet two new details: fork and specification.

When starting the Dart app, we always have one zone already: the root. It’s so special that you can always access it via the static getter Zone.root. Each correct zone must be a root fork, since all the basic features are implemented in the root zone. Remember this run piece that should switch the current zone?

That was a cheat similar to the old school rule that you can’t divide by zero. In fact, the code should look more like this:

So under the guise of a normal zone, the real game changer was hidden!

All other zones are forks of the root zone. You need them to add side effects to your main work.

2. How ZoneSpecification affects the behavior of the zone

ZoneSpecification is the second important public interface for zones, along with zoneValues:

These are all possible ways to influence the behavior of the zone and, consequently, the environment. Each of the specification getters is a handler function. For each handler the first three arguments are the same, so we can use the example of a single function to explore several.

Let’s analyze a small theoretical example by calculating how many times the code will ask you to do something in the zone:

Here we create a zone with its own specification. All callbacks called using the run method will pass through the run handler. The handler side effect is an increment of the global counter, so we’ll calculate it.

There are some points of interest here.

When we call any method from a zone, it calls the corresponding handler from its specification under the hood. This method helps minimize the number of arguments that we pass to the handler function. It substitutes the first three.

The forked zone is a node of the tree. When we call the zone method with some arguments, they must be “passed” from the node to the root through each parent. If the chain is broken, the work we’re counting on may not be completed, because nothing will reach the root zone. This makes sense for cutting off extra work, but not in our example.

The first argument is the zone that owns the handler.

The second argument is the parent zone delegate, which is used for “passing” further. If we don’t call it, the root zone in the example won’t be able to switch the current zone to the one we need, and there’s no other way to write in the _current field.

The third argument is the zone where the call initially happened. Sometimes we need to know it because the zone that owns the handler may not be the last in the hierarchy. When this argument reaches the root, the value of the current zone in the example will change to it.

This sounds complicated, but it usually comes with practice. Another small example is illustrated by a diagram:

Here we have a hypothetical hierarchy: You can see step by step what happens if you execute your work in zone B while the current zone is D.

The first arguments for all other handlers work the same way, which means the same patterns apply to them.

3. What side effects needs FakeAsync

Now back to FakeAsync. As we recall, in the run method the current zone is forked, and a new one is created using the specification. Let’s take a look:

First we see the scheduleMicrotask handler. It’ll be called when something asks to schedule work in a microtask so it runs immediately after the current execution thread. For example, Future is required to process the result in a microtask, so every single Future will ask the zone to do this at least once. And not only Future — asynchronous Stream also actively uses it.

It’s an easy way FakeAsync schedules microtasks — they’re stored synchronously under the hood for later, without any questions.

Next is the createTimer handler. You can call the createTimer method for a zone to get a Timer object, oddly enough. You might be asking, “What about its own constructor?” Let’s take a look:

The Dart timer is just a kind of wrapper over the environment timer, but the zone wants to be able to influence the process of creating it, i.e., if you need to create a dummy timer that doesn’t count anything. This is exactly what FakeAsync does: It creates a _FakeTimer, and the only task is to save the callback passed to it.

Unlike our example with the run handler, the parent delegate isn’t used here because we don’t really need to schedule anything. The chain is broken, so there will be no timers or microtasks in the test environment. In fact, the point of the FakeAsync zone is to collect all callbacks for timers and microtasks that are scheduled by any asynchronous structures or actions during code execution.

All of this is done in order to then execute them synchronously in the right order! This can happen by calling the flushTimers method:

The method iterates through the scheduled timers, synchronously calls their callbacks, and then synchronously iterates through all their scheduled microtasks. It does this until there are no tasks left. As a result, all asynchronous tasks are executed synchronously!

We learned how zones are created and talked about ZoneSpecification, but there are still many handlers not mentioned.

This is what they can also do:

Catch and handle errors (handleUncaughtError, errorCallback)
Modify the callback at the creation stage (registerCallback*)
Create a repeating timer (createPeriodicTimer)
Affect standard logging (print)
Influence the zone fork process (fork)

That’s it for today. In this article we looked at examples of using zones in two small libraries and hopefully understood their basic features. In the next article, we’ll analyze details that aren’t self-evident on AngularDart — a framework that has slotted into our frontend life more than others.

Feel free to leave a comment below with your thoughts. I’d be more than happy to answer your questions!

API Portal: What to Consider When Designing

Wrike Tech Club — Fri, 14 Aug 2020 16:09:06 +0000

Wrike's experience

Using public APIs helps companies to increase the value of their own resources, create unique content, and meet the requirements of various business tasks. Wrike is no exception. More than 30,000 applications have been created based on the Wrike API. The number of product users is growing, which means that the requirements for the portal are getting higher every day.

In this article, I share my experiences with redesigning the Wrike developer portal interface and show you some changes worth noting.

During the redesign we managed to:

Create intuitive navigation.
Create a grid for optimal content display on both desktop and mobile devices.
Upgrade the portal design according to the current design system and create the missing components.
Reach the AA level of accessibility standards and implement them.

1. Intuitive navigation

We conducted a series of interviews with the main users of the portal — backend developers and the user support team, who gave us feedback from external users.

We learned that, in addition to technical problems with notifying and updating information, the portal had navigation problems: It was difficult for users to find important information such as references and documentation. It was also difficult to get to the sections located after the methods. For example, to find the BI Export section, you had to view all the methods first, and there was no option to collapse the section.

Navigation on the previous version of the portal

To optimize the portal structure, we highlighted the main sections and subsections, as well as separated the technical content from informational. In the new portal, we set five main sections: Introduction, API Documentation, API Reference, BI Export, and Support. The Community API section is a separate link at the bottom of the sidebar so that the user can quickly get help.

Placing the navigation in the sidebar helps users see not only the main sections but also the subsections. And the ability to hide methods makes it easier to work with the panel. If needed, the user can collapse unnecessary sections or go deeper into the ones they need. The logo, toggle, and search field are still in the top menu (under development).

Portal navigation redesign (before and after)

To simplify the interaction for the user, it’s better to show the structure of the portal with a level of nesting no deeper than two. Additional features (such as search) can be added to the top menu. If the user needs to log in to use the portal, you can also separate the login button from the main navigation. This way you can provide a quick search for the necessary information and easy navigation between pages.
Navigation on the new portal

2. Grid for optimal content display

The Wrike developer portal consists mainly of static pages with varied information content. Tables and text blocks take up the full width of the grid, so the number of columns doesn’t matter.

We paid special attention to the methods page. There are two ways to build this page:

Divide the content part into two blocks: the description and tables on the left, and examples on the right.
Make a single block with content: examples are inside each method.

The previous version of the portal used the first method.

Method page on the previous version of the portal: description and query on the left, the slider with the response and examples on the right

We analyzed the Wrike API methods and decided to use the second option. It allows us to keep tables with their nesting in an easy-to-read form, as well as view the response and example without switching the slider.

Method page on the new portal

It’s important to predict the grid behavior at different resolutions, so that the portal is correctly displayed from the screen of a computer, laptop, or tablet. There’s no need to stretch the content to full screen width, because reading text with a width of 2560 px can be uncomfortable. At the same time, you don't want to break the tables.

Create a fluid grid by setting the maximum and minimum width of the content area. Set the minimum margins from the content part and make a central alignment. The content display will change in proportion to the screen width, but the user will still be able to read text and tables.

You should also consider the option of hiding the sidebar, so that the user could expand the content area if necessary. This is especially important when working on devices with a screen width of 1024 px.

Principle of grid operation on the new portal

Most developers use devices with wide screens. Still, it’s better to provide the option of working with the portal on tablets. You can open the sidebar on mobile devices over the content area. It allows users to keep the information in a readable form.

3. Portal redesign in accordance with the current design system and creating missing components

Portal API entities differ from standard website entities. I highlighted several components that required special attention from the design team.

HTTP methods

HTTP methods (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH) are one of the most important API entities. Depending on the type of action, the entity has a specific HTTP method. When designing HTTP methods, try to follow these recommendations:

Assign a color ID to each of the nine existing HTTP methods so that you can visually distinguish them without confusing the user.
Add a URL to the component of the HTTP method to make life easier for developers. They won’t need to perform additional actions to view this information.
Make it possible to see both the query and the example at the same time. In the new version of the Wrike API portal, examples are placed inside the method instead of hidden in the slider.
Don’t place methods that relate to the same entity on separate pages. In the old version, Query Tasks, Create Task, and Modify Task were separate pages. Instead, divide the pages by entities: Contacts, Users, Tasks, and so on. This will also simplify working with the portal. HTTP methods on the new portal

Tables

All requests sent to the server are presented as tables with a large amount of data.

Table on the old version of the portal

Try to avoid piling up information. In the previous version, the mandatory parameter was indicated by a badge with an inscription. This not only created visual noise but also contradicted the site's accessibility requirements. In the new version, a separate Required column is allocated for this parameter.

Table on the new portal

Try to make nesting as obvious as possible and specify which parameter it refers to. In the previous version of the portal, only the description column was highlighted in color, even though the nesting was related to the entire parameter.

Nesting on the previous version of the portal

In the new portal, a chevron refers to the parameter itself and helps the user understand that there’s content hidden inside.

Please note that the columns of a nested table are better to place under the columns of the parent table. It facilitates perception of information.

Let’s keep the focus on the selected information. The user might have problems focusing when working with a large amount of data. For more visual convenience, hovering the mouse over a line can be highlighted with color. Highlighting a nested table and keeping the ability to select a row inside it is also a good idea.

Nesting on the new portal

Examples

An example shows how to work with a specific method and what will be returned if the request is correct. The request is generated using CURL by specifying the necessary data.

Examples must be visually separated from the rest of the information and set with a fixed height so that the scroll is inside the components, not inside the page. It will save users from endless scrolling.

For comfortable work with the example, you can add an option of copying to the buffer.

Examples on the new portal

4. Compliance with accessibility and theming

Sites should not only be logical, convenient, and good-looking but also accessible for users with disabilities. As mentioned above, most of the portal components comply with the AA accessibility level and the principles of inclusive design.

The contrast of plain text, titles, and graphic elements meet the WCAG standards.

We provide the ability of tabulation, i.e., the site is manageable and accessible for the keyboard.

Each graphic object has a description. For example, for buttons that copy information to the buffer, the text “Copy” is located next to the icon. When you click the button, the text changes to “Copied CURL example.”

If you make an error in the application registration form, in addition to a text message and highlighting the input in red, a graphic symbol appears in the input field so that the user understands which field contains the error and can easily correct the entered value.

Giving the user a choice of interface themes deserves special mention. It has become a great advantage of the new portal for several reasons:

It's a friendly solution that conforms to one of the main principles of inclusive design: the principle of choice.
Dark mode is the most popular among developers.
Dark mode adjusts the screen brightness according to lighting conditions and reduces eye strain.
Providing themes with improved contrast makes the site accessible to people with impaired vision or color blindness.

Theming on the Wrike developer portal

To summarize

To create a user-friendly developer portal interface, you should:

Make navigation logical, comfortable, and understandable by separating technical content from informational content.
Show the user the portal structure with a nesting level no deeper than two at first.
Predict the behavior of the grid at different resolutions for optimal display of content.
Pay attention to the design of methods by highlighting them in color.
Get rid of visual noise of icons in tables — text works better than symbols.
Keep the focus on the selected information.
Comply with accessibility standards and the principles of inclusive design.

You can see how we did it all on the Wrike developer portal.

I hope you’ve learned something useful about API portals and that this article will help you when designing or redesigning the API portal for your company. We won’t rest on our laurels but will continue to improve our portal.

//The article is written by Angelina Kulichkova, Web Designer @ Wrike