DEV Community: Lotanna Nwose

Why Microservices Need Webhook Gateways

Lotanna Nwose — Wed, 21 Jun 2023 14:16:35 +0000

A Webhook Gateway serves as a forward and reverses proxy to send and receive webhooks to client endpoints and from third-party providers. They are designed to enforce security, resilience and high availability on all webhook events for an organisation. We wrote a more detailed description here.

The image above describes the flow of webhook events from the microservices to client endpoints as well as from third parties to the microservices. In this article, we will discuss why webhooks gateways are relevant to the microservices architecture, and what common features are found in the webhooks gateway. Finally, we will discuss some of the caveats to bear in mind while adopting a webhooks gateway.

Why Do We Need Webhook Gateways?

The various advantages of a microservice architecture subsequently present unique challenges that Webhook Gateways are purpose-built to address.

Centralised Infrastructure to Decentralised Microservices

Microservice architectures split up several functions of an application into separate services, that are owned by different teams. This separation is typically based on a common domain e.g. Payments service, Notifications service etc. This design pattern engenders each team to build, deploy and maintain their services independently. Unlike a monolith application, teams are able to increase velocity and deliver features faster. This approach means increased complexity for webhook management: How are we able to route webhook events from third parties to the right microservice(s)? How are we able to route webhook events from backend services to client endpoints?

This is where a webhooks gateway comes in. They’re able to provide a central infrastructure capable of ingesting, and routing webhooks both internally to backend services and externally to client endpoints. This central platform also reduces the learning curve for new teams to add webhooks to their services.

Microservice Language and Protocol Agnostic

One of the major benefits of the microservice approach is the ability for teams to utilise the best tools for the job. For example, one team can decide to build their API using Rails, GraphQL and MongoDB, while another team can decide to build their API using Golang, gRPC and PostgreSQL.

Regardless of the technology stack chosen by each team. Webhook gateways rely on a consistent payload structure to send to client endpoints and an endpoint to receive from a third-party. As long as the payload format and structure remain consistent, developers can implement the business logic with any technology stack they prefer. While leaving the gateway to cross-cutting concerns like retries, rate limiting and signing the payload.

Services can be rewritten from Python to Rust and redeployed with the Gateway. To the client endpoints, the payload remains the same, and it can continue to rely on the payload format and structure to remain the same.

Routing to Microservices based on payload structure

When webhooks are ingested into your systems from third-party providers, in a monolith all events are routed to the same application all the time. However, in a microservice architecture, one or more microservice(s) can rely on the event from the provider to carry out separate actions.

Webhook Gateways can be configured to receive events and route them to one or more destinations. They can match both headers and payload to determine webhook's destination.

Traffic Control to prevent overloading of resources

Internet-facing services are common targets for malicious attacks and exploitation. They need to handle a sudden spike in requests from valid users and bad actors. This requires features like request throttling and blacklist capabilities to keep systems reliable and secure.

Webhook Gateways are an effective barrier against Distributed Denial of Service (DDoS) attacks—throttling the number of requests made to affected services, so the service isn’t overwhelmed and protecting it against becoming unresponsive.

Common Features & Benefits

A Webhook Gateway is located at the outer edge of your microservices and acts as a proxy to manage all ingress and egress webhook traffic. The Webhook Gateway handles several features:

Security

Webhook Events sent to client endpoints need to be securely delivered to client endpoints. Clients need to validate that the message has not been tampered with in transit, and they need to know that events are not being re-transmitted by malicious actors, in some sensitive environments they need to authenticate the webhook provider and authorise their IP address through their network firewall.

When receiving events from third-party providers (e.g. Stripe, Twilio ), consumers need to verify the webhooks before routing them to backend services for processing

Webhooks Gateway is able to centralise cross-cutting concerns like webhooks security and securely receive events from backend services, sign the payload, timestamp the payload, and deliver them reliably with a static IP address. Since they exist at the outer edge of your microservices they are able to prevent exposing any of your backend services directly to the internet and reduce the attack surface area for malicious actors.

Resilience

Managing HTTP Endpoints is one of the core responsibilities of a Webhook Gateway. Standard webhooks flow is a post request to an endpoint, and expect a 2xx status code in return, indicating success. However, these endpoints fail from time to time for several reasons: flaky networks, spikes in traffic, code or infrastructure changes that resulted in downtime, and degraded performance in the client’s application dependencies.

Due to the various types of issues that can prevent reliable webhooks delivery, webhook Gateways add important features like timeouts; to prevent waiting endlessly for responses, and retries; to automatically re-transmit webhook events, rate limiting; to deliver events to client endpoints at a steady pace the client can process, and circuit breaking; to prevent wasting system resources on zombie endpoints (i.e. endpoints that have failed consecutively over time)

Customer-Facing Dashboard

Debugging webhooks delivery is an important aspect of the responsibilities of webhooks providers to clients. Best practice enables engineers to debug webhook delivery without human interaction with the engineering team of the provider.

Webhook Gateways provide such a utility to generate rich customer-facing webhooks dashboard where users can directly (zero human intervention) debug webhook delivery issues and fix failing endpoints with a few clicks.

Multiple Data Source Options

Webhook Gateways need to be flexible and versatile. Microservices emit events through various channels. For example, building on Google Cloud, developers will often use Google PubSub to emit happening in one or more microservices, similar to AWS for Amazon SQS, and other tools like Kafka and RabbitMQ.

Plugging into all these options makes a webhook gateway such a versatile tool for streaming webhook events from multiple event-generating microservice to send the events to the client endpoints.

Caveats of using Webhooks Gateways

While there are several benefits to deploying a Webhooks gateway, there are some caveats to keep in mind when adopting a Webhooks gateway for your organisation, such as:

The webhooks gateway is a new software component in your environment. It would require learning and building expertise in it. Platform Engineers and SREs will need to integrate, deploy and maintain this new software component and build production excellence running the webhooks gateway.

By design, a webhooks gateway is responsible for webhooks traffic (inbound and outbound) of your organisation, This, therefore, becomes a single point of failure for the entire organisation. Webhooks gateway then needs to be designed for high availability to ensure no data loss for any webhook traffic.

In the end, webhook gateways aren’t one-size fits all. You can build a webhook gateway in-house or acquire an off-the-shelf solution like Convoy while analysing your system's unique requirements.

Final Words

A Webhook Gateway can enhance your microservice-based application with capabilities like secure webhook delivery with signatures, static IPs, resilience with retries, rate limiting, and customer-facing webhook dashboards. However, before adding a webhooks gateway to your application architecture, you need to understand what problems you’re trying to address, what events you’ll be sending and if the product you are choosing offers those features.

Convoy is the fastest open-source webhooks gateway available today. With Convoy, you’ll be able to configure advanced event routing, incoming and outgoing webhooks, and customer-facing webhooks dashboard, and securely deliver events with payload signing and Static IPs.

If you're exploring solutions for your webhooks, we welcome you to try Convoy Cloud for free today.

A little favour

If you feel like this article helped you understand Webhooks better! I would be super happy if you could give us a star! And let me also know in the comments ❤️
https://github.com/frain-dev/convoy

Thanks for reading!

5 Reasons Engineers do not use Webhook Gateways Yet

Lotanna Nwose — Fri, 16 Jun 2023 11:14:49 +0000

Speaking with platform engineers at events, in various online communities and even within the Convoy community validated the notion that managing webhooks in production is not always easy and can require a lot of effort. Platform engineers believe strongly in frictionless self-service developer experience, and solving for efficiency to quickly provide business value. Let’s take a look at why some haven't adopted a webhooks gateway such as Convoy to manage webhook events and integrations yet and what we are doing to change that.

Security Concerns

Webhooks can be vulnerable to attacks such as man-in-the-middle and replay attacks, which can compromise the security of the entire system. Some engineers worry that using a webhooks gateway could introduce additional security risks, particularly if the gateway is hosted by a third-party provider.

Convoy provides advanced webhook security with endpoint authentication, payload signing, rolling webhook secrets, replay attack prevention, and forward-compatible scheme upgrades. For data security and compliance concerns, you can self-host Convoy using the Community Edition or Convoy Enterprise on-prem.

Cost Considerations

We are currently in a bear market and so engineering teams are working towards capital efficiency so cost is another factor that is preventing engineers from adopting a webhooks gateway. Engineers worry that these costs will add up over time, particularly if they have multiple webhook integrations to manage.

We have made that decision even easier at Convoy, making the product free forever for developers and then having the best cost-effective pricing in the market today. Our commitment is to builders and we would continue to show that with our pricing strategies.

Integration Complexities

Readiness to integrate is another interesting issue, some of the startup to mid-level teams we have spoken to are sometimes spent for time. Some engineers are not ready to integrate with a new tool just yet, others might be in the middle of a project or not have the bandwidth to take on something new.

On the other hand, there is a general assumption that integrating new tools can take days and lots of effort. With Convoy, you can get up and running in a few minutes without even speaking to anyone. If you do need to, there is a growing community of platform engineers including the Convoy engineers available to answer questions at any time.

Lack of Awareness

Due to how relatively new the webhooks management space is, lots of platform engineers find Convoy from the content we put out, recommendations from their network and a small percentage from keyword searches. Also, just like any new space, lots of engineers are not aware of benefits and features that webhook gateways have out-of-the-box to make their workflows more efficient.

We are creating more valuable content around webhooks and breaking down its complexities, the more we do, the more you can find Convoy when you do a quick Google Search for anything webhooks related.

Resistance to Change

Many engineers are used to managing webhook integrations manually, and are hesitant to switch to a new platform or service. This is true, especially in large organisations where it takes months to go from one developer buy-in to team-wide adoption. This is the classic build or buy analogy, we do know that adopting a webhooks gateway can provide significant benefits, and significantly reduced debugging time exponentially as you scale.

With Convoy you can manage both incoming and outgoing webhooks, API providers can start their change management process by updating their Docs and telling their customers to receive their webhooks with Convoy. Time and resources saved by customer success teams using this approach is usually a good motivation to buy later on.

Wrapping Up

Do you have any unmentioned reason why you have not tried out the Convoy webhooks gateway? Convoy is a reliable webhook gateway for sending and receiving millions of webhook events with robust support for Retries, Rate Limiting, Static IPs, Circuit Breaking, and Rolling Secrets. You can secure your payloads, scale horizontally and get endpoint failure alerts to debug faster with Convoy. You should try it out here.

Help me out!

Thanks for reading!

10 Common Ways Engineers Use Webhook Gateways

Lotanna Nwose — Wed, 14 Jun 2023 16:05:31 +0000

Introduction

A webhook gateway is a webhook management tool that sits between a webhook provider and the webhooks consumer. It acts as both a reverse and forward proxy for webhooks. It can be deployed by both the API provider that sends webhooks and the consumer that receives webhooks to handle webhook events multiplexing and de-multiplexing respectively.

This article will consider ten of the most common use cases of a webhook gateway, with emphasis on the features offered by Convoy. Convoy is a high-performance open-source webhooks gateway to which platform teams can deploy to manage their webhooks end to end.

The use cases to be discussed are

Reliable Webhook Delivery
Routing in Microservices
Routing with Message Brokers
Static IPs
Security
Scale
Monitoring and Alerts
Easy Debugging
Geolocation Based Routing
Versioning

Reliable Webhook Delivery

Webhooks–which are simply HTTP push– fail frequently due to reasons that include but are not limited to downtimes, spikes in network requests, flaky internet, and expired SSL certificates.

A webhook gateway solves this problem by implementing features such as the following:

Retries: to automatically resend webhook events a specified number of times.
Circuit breaking: to stop sending requests to endpoints that have failed consecutively, thereby not wasting resources on a dead endpoint.
Rate limiting: to prevent overloading client endpoints by delivering events at a rate that the client can process.
Timeouts; to prevent waiting endlessly for response.

A webhook gateway like Convoy exists to ensure the deliverability of your webhook events by implementing these features, while the rest of your application handles other business logic.

Routing in Microservices

In a microservice architecture, many of the services send out webhook events, they may also receive events from third-party providers. How do you manage these ingress and egress webhooks traffic? A webhook gateway can be deployed and configured to route incoming webhooks to the services where they are to be consumed, in the same manner, it would receive webhook events from your services and forward them to client endpoints. This flow of events is illustrated in the image below.

Source: Why do microservices need a Webhooks Gateway?

Webhook gateways are able to determine the destination of webhook events by checking the header and payload of each request.

Routing with Message Brokers

Webhook events are asynchronous by nature and Message Brokers are designed to facilitate asynchronous communication, hence, your webhook deployment that integrates with message brokers allow you to completely bypass the shortcomings of REST API
Connections when sending webhook events.

Convoy recently announced the release of its Message Broker integrations to ingest webhooks from backend services to Convoy. For API providers, this means that they will be able to ingest webhook events from their backend services into Convoy using Message brokers. Convoy currently supports Google PubSub and Amazon SQS.

The diagram above illustrates Convoy pulling webhook events from a message queue and then sending them to a client endpoint. Convoy allows you to send events through both message brokers and a REST API. Read more about it in this blog post.

Static IPs

If you are an API provider that sends webhook to consumers who are in sectors where security is a top priority, they may have strict security policies that include whitelisting IPs for all inbound webhooks on their firewalls. To serve these consumers, you need to provide them with a Static IP address from which your events would be coming for them to whitelist. However, most modern ways of deploying applications make it such that IP addresses are ephemeral by default instead of Static.

One way to fix this is to deploy a webhook gateway that would serve as a forward proxy for your webhook-sending application. Convoy allows you to configure your outbound webhook events with a forward proxy which will have a Static IP.

The simplified diagram shows how the IP of your outbound requests changes as it is transmitted to a client's endpoints.

Security

On the consumer end, the webhook gateway is still the ideal point to implement several security mechanisms. Both the webhook publisher and the webhook consumer play complementary roles to secure requests against malicious attackers. Some security measures that API providers and consumers can apply at the webhook gateway level include:

Signed Payload: An API publisher can prevent a replay attack when they sign their payload and include a generated timestamp to their signature on each request. On the consumer side, the signed payload would be matched against each expected variable, to verify that the signature has not been altered.
Static IP: A consumer app would be able to verify that the Static IP address of all incoming webhook events is whitelisted.
Mutual TLS: Consumer apps equally use mutual TLS to ensure that connection requests from third-party providers are truly from the said provider.

Scale

We live in a world of APIs. Since APIs are the glue that holds the digital world together, it is not surprising that billions of webhooks are delivered every day. Below is an example of a Shopify BFCM Webhooks stats:

With a webhook gateway handling all of your webhook traffic, you can independently scale up and down during and after peak periods. This also means that your webhooks implementations stay decoupled from the rest of your backend services. If your webhook gateway is a SaaS like Convoy, the developers in your product team do not have to get deeply involved in the webhook implementation nor get caught up in its complexity, permitting them to focus on your core business product.

Monitoring and Alerts

Webhooks fail all the time, one reason is that App owners are constantly pushing changes to their apps. It is good behaviour for a webhook delivery system to be able to inform the app owner when their app is down. Convoy does well in this area as it allows you to implement different solutions for monitoring. For example, you can monitor uptime or monitor the average request per minute on your webhooks route, and flag it when they're below a certain threshold. Also, after an endpoint consistently fails, Convoy disables the endpoint and sends an email to the developers to triage.

Easy Debugging

In addition to enabling monitoring, a webhook gateway can make it easier to debug failed webhook requests. For example, Convoy includes a web interface where an operator can filter through event logs, search through the webhook payloads, see the response body from each request, discover the point where a webhook is failing, and even manually resend these webhooks. The dashboard is available to you whether you are an API provider or a consumer.

Geolocation-Based Routing

Another possible way to use your webhook gateway to scale your product is to deploy instances of it at various locations closer to your consumers. Routing webhook requests based on clients' location works similarly to the traditional API Geolocation Based Routing. There are several factors to put into consideration when deciding whether you need a geo-location-based routing solution. But the end result is the same when you do decide to implement it: you primarily mitigate issues caused by latency.

To illustrate how this would work in a real application; your backend services are deployed in a server in the UK, but you have consumer apps running in India. When you deploy Convoy as your webhook gateway closer to India and write webhook events to a message broker, Convoy automatically receives them and then routes them to your clients in India. Routing these events to clients in India would involve lesser network overhead because of the location of your webhook gateway.

This practice is common with API gateways, we think that in the case of a webhook gateway, this might only be relevant for a large company with several consumers in distant parts of the world.

Versioning

Webhook requests signatures evolve over time either in response to bug reports or the need for a new feature, but as they evolve, versioning these signatures become important as you gradually face out old features. Versioning also allows API consumers to adopt new changes to the signature at their own pace. The Convoy OSS and Cloud software also supports this
feature.

Conclusion

So far you have seen the most common ways that one can utilize a webhook gateway.
Convoy democratizes the best features of webhook infrastructures used at top tech companies such as Stripe and PagerDuty into a single binary. When setting up Convoy for your product, you can pick any of these features that suit your needs right out of the box.

Help me out!

What are Reverse-API Gateways?

Lotanna Nwose — Fri, 09 Jun 2023 08:51:05 +0000

Introduction

Webhooks are known as reverse APIs; this is because they reverse the usual flow of communication. So, instead of the client requesting data from the server(APIs), the server sends data to the client when a specific event occurs(Webhooks).
Now that you know this, let us dive into today's agenda!

What are Webhook Gateways?

A webhook gateway is a webhook management tool that sits between a webhook provider and webhook consumer. It acts as a reverse and forward proxy for webhooks. It can be deployed by both the API provider that sends webhooks and the consumer that receives webhooks to handle webhook events multiplexing and de-multiplexing respectively.

Why use a Webhook Gateway?

Speed is a competitive advantage in today's ever-changing user requirements. Development teams are required to move fast and deliver user value. More teams are adopting a serverless, micro-service, and service-oriented architecture to move fast. Teams are leveraging technologies like an API Gateway to consolidate duplicate tasks like authentication, rate limiting, circuit breaking etc. while product teams focus on their core business. With webhooks, teams and tech leads would need to answer the following questions:

How can we provide a consistent infrastructure to receive events from third-party providers and route these events to one or more micro-services to handle them?
How can we provide a consistent infrastructure to collect events from multiple backend services and send them to client endpoints?
How can we consolidate duplicate webhook responsibilities like endpoint authentication and security, rate limiting, and endpoint failure notifications?
Similar to API Gateways, how can we increase developer efficiency across the organisation, where webhooks become plug & play?
How can we provide an independent infrastructure to scale to handle webhooks traffic in peak periods? See Shopify BFCM Webhooks Stats.

Your challenge is offering developers in your organisation a simple and dependable experience in the face of any webhook complexity. A webhook gateway is a way to decouple all your microservices from your webhook implementations. When a microservice needs to send a webhook event, it should write to the broker, and the webhook gateway receives it and routes them to the right endpoint(s), whilst keeping track of everything.

Architecture of Webhook Gateways

The diagram above provides a high-level view of how a webhook gateway operates. We used AWS-specific elements but this can be any cloud environment - Azure, GCP, Digital Ocean, etc or even On-Prem. The arrows from the left show the flow of traffic from your backend services to client endpoints on the right, and the arrows from the right show the flow of traffic from third-party providers like (stripe, Twilio, etc.) to your backend services for processing.

Generally, to avoid vendor lock-in, a webhook gateway will (should) support multiple broker systems like Amazon SQS, Google PubSub, Kafka etc. to allow you to use the best broker for your scenario. Visit this page to learn about Convoy's internal architecture.

API Gateways vs. Webhook Gateways

Webhook gateways share similarities with API gateways such as Tyk and Kong

	API Gateway	Webhooks Gateway
Entrypoint	Entry into the API.	Exit from the API.
Key Metric	Throughput & Latency	Throughput
API Type	Synchronous API	Asynchronous API
Protocols	Multiple Protocols - HTTP, Websockets, gRPC	HTTP
Message Format	JSON, XML & Protocol Buffers.	Mostly JSON.
State	Stateless	Stateful

Conclusion

Convoy is the first ever open-source webhooks gateway to manage millions of webhooks end-to-end. If you’re exploring solutions for your webhooks, we welcome you to try out Convoy webhooks Gateway for free today.

Help me out!

If you feel like this article helped you understand Webhooks better! I would be super happy if you could give us a star! And let me also know in the comments ❤️
https://bit.ly/convoywebhooks

Thanks for reading!

Start Sending & Receiving Webhook Events today for FREE

Lotanna Nwose — Thu, 19 Jan 2023 11:13:40 +0000

Happy New Year! Today, we are making reliable Webhooks Management using Convoy free for all developers for life, yes! Forever!

Free for Developers Forever

Convoy is the very first open-source Webhooks as a Service tool to exist and we are incredibly excited and committed to our growing community. We are an engineering-led team, and community is at the heart of Open Source Software. Owing to this, we are making the Free Forever commitment to all developers who value efficiency in their workflow. This means Convoy Cloud will always be free for developers forever so that they would have a reliable tool to manage their Webhooks easily. The basic idea of this offering is to make sure that at any stage you can experiment with the product, and experience enough value so you can Pay-as-you-grow.

How the Market is Pricing Today

The market is relatively new but Zapier is a market leader within the no-code Webhooks space, the image below shows what they charge for successful events or tasks.

When you compare the offering above with our offering here, you will see we are selling a lot of value for $0.

So, with Convoy’s developer plan, you can send and receive hundreds of thousands of Webhook events per month, get community support, and a 3-day Data Retention Policy. Our hope is to reach developers, backend engineers, software engineers, and DevOps engineers who will experience the product and in turn get their teams to join the Convoy. Time to start building!

Wait, What’s The Catch?

You can read the full post and see for yourself here

If you enjoyed reading this, consider sharing it on social media for other cool people like you to read too.

Cheers!

Most in-demand tools for managing JS data in 2020

Lotanna Nwose — Fri, 14 Feb 2020 07:00:24 +0000

The "State of JavaScript 2019" report offers a glimpse into the future of frontend development. In this article, we'll review explore some tools for managing data that are poised to take center stage in 2020.

What is StateOfJS

The "State of JavaScript" report is an annual survey that records and beautifully visualizes the opinions of more than 21,000 developers around the world. The data points cover frontend web development frameworks, databases, state management, relationships between frameworks, reception and ease of use, languages that compile to JavaScript, mobile frameworks, build tools, JavaScript testing tools, and a whole lot more.
In my opinion, the "State of JS" report is the first JavaScript-only developer survey to gain universal respect in the JS community. Other popular resources include StackOverflow's annual developer survey and Jetbrain's "State of Developer Ecosystem" report, which query 100,000 and 7,000 respondents, respectively.

Data layer tools

To start, let's take a look at the most in-demand JavaScript tools that are used to manage data based on factors such as awareness, overall happiness, usage by company size and salary range, show of interest, ease of use, and reach.

Redux

Redux is an open-source JavaScript library for managing JavaScript application state. It is most commonly used with libraries such as React for building user interfaces. It was created by Dan Abramov and Andrew Clark and it helps you build apps that is consistent over various environments from client side to server side to even native. It has a powerful devtool that helps so much in debugging your app, it is currently being used by almost a million projects.
According to survey insights, Redux had a good 2019 as the retention rate even increased by 0.6% in the last 12 months. It is very remarkable to see that retention rate did not drop even though there was a little drop in the interest level.

Apollo

Apollo Client is a complete state management library for JavaScript applications. It handles user interface updates as well as requesting and data caching with a simple GraphQL query. Fetching data with Apollo Client guides you to structure your code in a predictable, declarative way consistent with modern React best practices. With Apollo, you can build high-quality features faster without the hassle of writing data plumbing boilerplates.
There is a big increase in the volume of return users of Apollo in the last 12 months, this volume rose from 11% to an impressive 24%. The knowledge and awareness gap is getting bridged as more people now know (and are willing to learn) about Apollo in the last year.

GraphQL

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, this ensures your requests returns exactly the subset of the data object that you need at the particular instance. This makes it easier to evolve APIs over time, and enables powerful developer tools.
According to the survey insights, one very remarkable thing is that almost every developer now knows about GraphQL, the retention rate also increased from 20% to 38%. Getting started and all kinds of beginner content resources will greatly help the community as about 50% of developers would want to learn to use GraphQL.

Relay

Relay is known as the production-ready GraphQL client for React built for scale. Relay was designed to be performant from the ground up, and to support scaling your application to thousands of components, while keeping management of data fetching clean, and fast iteration speeds as your application grows and changes. Relay automatically aggregates the data requirements for your entire application, so that they can be fetched in a single GraphQL request. Relay also support executing GraphQL Mutations, optionally with optimistic updates, and updates to local data, while ensuring that visible data on the screen is always kept up to date.
In the last 12 months, more people have heard about Relay and over 2,000 projects use Relay currently. There is still a big awareness gap the Relay team should invest resources to fill especially in the React community, I believe this can be achieved by pushing out more beginner friendly content.

MobX

MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). The philosophy behind MobX is that if anything can be derived from the application state, it should be derived automatically. React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses.
Both React and MobX provide an optimal and unique solutions to common problems in application development. React provides mechanisms to optimally render UI by using a virtual DOM that reduces the number of costly DOM mutations. In the survey insights, we see MobX has gained a lot of attention in the past year, as about 70% of all the developers that were survey have heard about it. The interest level for MobX grew by 2% and the percentage of repeat users of MobX in the past year also increased by over 3%.

In general

Up until 2017, we have experienced this interest and satisfaction shift from Redux to newer players like GraphQL and Apollo. This says a lot about the organic growth experienced by the both and looking into the future, it is almost certain they are both here to stay. GraphQL especially had a great year in 2019, winning the award for the technology with the most interest.

Conclusion

Other data layer tools were also used by developers in the survey, most prominent were Vuex, Ember, NgRX, RxJS and others with Vuex taking the lead with a big gap. There is a chance that with more adoption and awareness, Vuex will become the next big thing after GraphQL in the data layer category. Which of these data layer tools do you use?

Top 12 React component libraries you should know about in 2019

Lotanna Nwose — Fri, 02 Aug 2019 08:47:23 +0000

React

React JS is a flexible and declarative JavaScript framework for building great user interfaces. It was built by the team at Facebook and it is currently being used by over 2 million projects on GitHub. It is relatively easy to create interactive user interfaces and build components-centric apps with this framework. It is also regularly maintained and has the fastest growing JavaScript community.

In this post you will be shown some React component libraries you should be familiar with in your workflow this year with focus on the regularly maintained ones, as there are more than 12 libraries out there.

Material UI

Material UI is one of the most popular React component libraries with over 48,000 stars on GitHub. The components and all the template elements are built according to the Google’s Material Design guidelines but are all React components. It ships with a lot of React templates and themes to help for customisation. It also provides a lot of UI elements out-of-the-box from cards to buttons to dialog boxes to icons and a lot of menus. It is also regularly updated as the last commit was a few days ago.

KendoReact

This is an interesting one, one of the many progress products that is really amazing. KendoReact is built specifically for development in React and has a 100 percent native mobile support out-of-the-box. Kendo ships with a set of components built by React developers with a world of experience for dialog boxes, guages, layouts, charts even animations. The components are also independent as they require no other dependency but React itself, it also has an import feature in the case that you already use an existing component library.

Blueprint

Blueprint is a React-based UI toolkit for the web built by the team at Palantir. It has currently been starred over 14,000 times on GitHub. It is arguably the best React UI library for data-driven projects like building a fintech user interface or interface for cryptocurrency or financial trade. It has a very extensive documentation for frontend development and it has great looking elements with nice finishes.

React Virtualized

If you are building React interactive interfaces for tables, grids and large lists, React Virtualized is the arguably the best UI component to use in your workflow. With over 16,000 stars on GitHub and regular updates with the last commit being last month. There are data-specific components you might not find anywhere else in the component list of React Virtualized like direction sorters and auto-sizers and masonry. Table configurations are also possible here. React Virtualized also comes with mobile support for Andriod and IOS out-of-the-box.

Evergreen

With over 8,000 stars on GitHub, Evergreen is one amazing React UI framework for building ambitious products on the web created by Segment. It contains very polished and nicely designed React components that works out-of-the-box. They are built to be very flexible as they follow React component guidelines, they are used as a design language for enterprise projects. The documentation is very easy to read, understand and implement and it is inspired by React Primitive UI. It was last updated few days ago showing it is regularly maintained.

React Bootstrap

Used by over 129,000 projects on GitHub, React Bootstrap is one of the most used React UI toolkit. As Bootstrap is also one of the biggest names in the CSS framework world, React Bootstrap brings you Bootstrap as you already know it into React components so you get too of your favorite frameworks in one, as every JavaScript inside Bootstrap core is replaced with React logic. Each component is interactive and accessible and ships with a lot of starter themes you can choose from to fast track your development process. It is also very regularly maintained as the last commit in the project is a few hours ago.

React Toolbox

React Toolbox is a set of React components that implements Google Material Design specification built on top of features like CSS modules, Webpack and ES6. It has a seamless Webpack integration and you can easily customize it. So much thought went into the documentation and it was also built using React Toolbox, there is a playground to test the various components in real-time. You can import components either individually or in bundles. It is being used by over 6,000 projects on GitHub and was last updated some months ago.

Belle

Belle is a configurable React component toolkit that provides you with a set of React components like Toggle, ComboBox, Rating, TextInput, Button, Card, Select and soon many more. Every one of these components are optimized for mobile and you are allowed to customize the styles yourself. These freedom can be in the individual component stylesheet or the global stylesheet. It is also optimized for accessibility with ARIA support. It has been starred over 2,000 times on GitHub and is regularly maintained too.

Reactstrap

Not to be confused with React Bootstrap, Reactstrap is a simple Bootstrap 4 and React component toolkit. It comes with create react app support which is a very big deal as a whole lot of React developers start their projects in the CLI with CRA. You can easily download it with your favorite package manager NPM or Yarn. It contains React Bootstrap 4 components that favor composition and control and does not depend on jQuery or Bootstrap javascript. However, popper is required for things like popovers, and auto-flipping drop-downs. It is currently being used by over 66,000 projects on GitHub and is regularly maintained, the last commit being some days ago.

Rebass

Rebass is a React primitive UI component built with modern styling conventions in mind like styled-components and emotion. It has 8 main components and those 8 have sub components, all being really small in size. It has very responsive and at the same time very easily-themeable style properties. It has a flexbox grid with box and flex components, it has been starred over 5,900 times on GitHub and is very regularly maintained.

React-md

React-md is a React component library that helps you creates a fully accessible material design styled website using React Components and Sass. With the separation of styles in Sass instead of inline styles, it is easier to create custom components with the existing styles. It allows for customizing your styles and it ships with this easy-to-read documentation which was also built with React-md. It is starred over 2,000 times on GitHub and the last commit to the project was few weeks ago showing that is regularly maintained.

Onsen UI for React

Onsen UI for React is a mobile UI library built with markup language and Javascript that integrates with React JS. It is a high-quality mobile apps supporting UI library for both IOS and Andriod. It is compatible with even other frameworks of JavaScript like Angular and Vue JS. The components uses pure CSS and no scripts to bring about behaviours. There are also custom elements available for use too. It is starred over 7,500 times on GitHub and is regularly maintained as the last commit is 12 days ago.

Conclusion

This has been a quick overview of a few React component libraries you should be familiar with in your workflow. There are a lot more and you can always make your choice according to your personal preference. The only important thing to note should be if the library is regularly maintained, happy hacking!