Coding

In this article, we will discuss testcontainers library and how to use it to simplify our life when it comes to integration testing our code. For the purpose of this example, I am going to use a simple application with its business centered around reviews for some courses. Basically, the app is a service that exposes some GraphQL endpoints for review creation, querying, and deletion from a PostgreSQL database via Spring Data R2DBC. The app is written in Kotlin using Spring Boot 2.7.3. I decided to write this article, especially for Spring Data R2DBC, as with Spring Data JPA, integration testing with testcontainers is straightforward. Still, when it comes to R2DBC, there are some challenges that need to be addressed. Review the App So let’s cut to the chase. Let’s examine our domain. Java @Table("reviews") data class Review( @Id var id: Int? = null, var text: String, var author: String, @Column("created_at") @CreatedDate var createdAt: LocalDateTime? = null, @LastModifiedDate @Column("last_modified_at") var lastModifiedAt: LocalDateTime? = null, @Column("course_id") var courseId: Int ) And here is its repository: Java @Repository interface ReviewRepository : R2dbcRepository<Review, Int> { @Query("select * from reviews r where date(r.created_at) = :date") fun findAllByCreatedAt(date: LocalDate): Flux<Review> fun findAllByAuthor(author: String): Flux<Review> fun findAllByCreatedAtBetween(startDateTime: LocalDateTime, endDateTime: LocalDateTime): Flux<Review> } And here are the connection properties: YAML spring: data: r2dbc: repositories: enabled: true r2dbc: url: r2dbc:postgresql://localhost:5436/reviews-db username: postgres password: 123456 When it comes to testing, Spring offers a fairly easy way to set up an in-memory H2 database for this purpose, but… There is always a but. H2 comes with some disadvantages: First, usually, H2 is not the production DB; in our case, we use PostgreSQL, and it is hard to maintain two DB schemas, one for production use and one for integration testing, especially if you depend on some provider features (queries, functions, constraints and so on). To have as much confidence as possible in tests, it is always advisable to replicate the production environment as much as possible, which is not the case with H2. Another disadvantage might be the possibility of production migration to another database – in this case, H2 having another schema won’t catch any issues, therefore, is unreliable. Others might argue that you can have separate testing dedicated DB on a server, machine, or even in a different schema. Still, again, the hassle of maintaining schemas and the possibility of collision with some other developer`s changes/migrations is way too big. Testcontainers to the Rescue Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container. With Testcontainers, all the disadvantages mentioned above are gone: because you are working with the production-like database, you don’t need to maintain two or more different separate schemas, you don’t need to worry about migration scenarios since you’ll have failing tests, and last, but not least you don’t need to worry about another server/VM’s maintenance since Testcontainers/Docker will take care of that. Here are the dependencies that we are going to use: Groovy testImplementation("org.testcontainers:testcontainers:1.17.3") testImplementation("org.testcontainers:postgresql:1.17.3") There are different ways of working with Testcontainers in Spring Boot. Still, I will show you the `singleton-instance pattern` (one database for all tests) since it is much faster to fire up on a database instance once and let all your tests communicate with it. For this to work, I am going to create an abstract class holding all the Testcontainers instances/start-up creation logic. Java @Tag("integration-test") abstract class AbstractTestcontainersIntegrationTest { companion object { private val postgres: PostgreSQLContainer<*> = PostgreSQLContainer(DockerImageName.parse("postgres:13.3")) .apply { this.withDatabaseName("testDb").withUsername("root").withPassword("123456") } @JvmStatic @DynamicPropertySource fun properties(registry: DynamicPropertyRegistry) { registry.add("spring.r2dbc.url", Companion::r2dbcUrl) registry.add("spring.r2dbc.username", postgres::getUsername) registry.add("spring.r2dbc.password", postgres::getPassword) } fun r2dbcUrl(): String { return "r2dbc:postgresql://${postgres.host}:${postgres.getMappedPort(PostgreSQLContainer.POSTGRESQL_PORT)}/${postgres.databaseName}" } @JvmStatic @BeforeAll internal fun setUp(): Unit { postgres.start() } } } Let’s take a close look at what we have here. Here we make use of testcontainers ability to pull Docker images and therefore instantiate or database container. Java private val postgres: PostgreSQLContainer<*> = PostgreSQLContainer(DockerImageName.parse("postgres:13.3")) Here we make sure to override our R2DBC connection properties in runtime with the ones pointing to our newly created container. Java @JvmStatic @DynamicPropertySource fun properties(registry: DynamicPropertyRegistry) { registry.add("spring.r2dbc.url", Companion::r2dbcUrl) registry.add("spring.r2dbc.username", postgres::getUsername) registry.add("spring.r2dbc.password", postgres::getPassword) } Since we are using Spring Data R2DBC, the spring.r2dbc.url needs a bit more care in order to be properly constructed as, at the moment, PostgreSQLContainer provides only the getJdbcUrl() method. Java fun r2dbcUrl(): String { return "r2dbc:postgresql://${postgres.host}:${postgres.getMappedPort(PostgreSQLContainer.POSTGRESQL_PORT)}/${postgres.databaseName}" } And here, we make sure to start our container before all of our tests. Java @JvmStatic @BeforeAll internal fun setUp(): Unit { postgres.start() } Having this in place, we are ready to write some tests. Java @DataR2dbcTest @Tag("integration") @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class ReviewRepositoryIntegrationTest : AbstractTestcontainersIntegrationTest() { @Autowired lateinit var reviewRepository: ReviewRepository @Test fun findAllByAuthor() { StepVerifier.create(reviewRepository.findAllByAuthor("Anonymous")) .expectNextCount(3) .verifyComplete() } @Test fun findAllByCreatedAt() { StepVerifier.create(reviewRepository.findAllByCreatedAt(LocalDate.parse("2022-11-14"))) .expectNextCount(1) .verifyComplete() } @Test fun findAllByCreatedAtBetween() { StepVerifier.create( reviewRepository.findAllByCreatedAtBetween( LocalDateTime.parse("2022-11-14T00:08:54.266024"), LocalDateTime.parse("2022-11-17T00:08:56.902252") ) ) .expectNextCount(4) .verifyComplete() } } What do we have here: @DataR2dbcTest is a spring boot starter test slice annotation that can be used for an R2DBC test that focuses only on Data R2DBC components. @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) - here, we tell spring not to worry about configuring a test database since we are going to do it ourselves. And since we have an R2dbcRepository that delivers data in a reactive way via Flux/Mono, we use StepVerifier to create a verifiable script for our async Publisher sequences by expressing expectations about the events that will happen upon subscription. Cool, right? Let’s run it.io.r2dbc.postgresql.ExceptionFactory$PostgresqlBadGrammarException: [42P01] relation "reviews" does not exist Extensions in Action Bummer! We forgot to take care of our schema and data/records. But how do we do that? In Spring Data JPA, this is nicely taken care of by using the following: Properties files spring.sql.init.mode=always # Spring Boot >=v2.5.0 spring.datasource.initialization-mode=always # Spring Boot <v2.5.0 And by placing a schema.sql with DDLs and data.sql with DMLs in the src/main/resources folder, everything works automagically. Or if you have Flyway/Liquibase, there are other techniques to do it. And even more, Spring Data JPA has @Sql, which allows us to run various .sql files before a test method, which would have been sufficient for our case. But that’s not the case here, we are using Spring Data R2DBC, which at the moment doesn’t support these kinds of features, and we have no migration framework. So, the responsibility falls on our shoulders to write something similar to what Spring Data JPA offers that will be sufficient and customizable enough for easy integration test writing. Let’s try to replicate the @Sql annotation by creating a similar annotation @RunSql Java @Target(AnnotationTarget.FUNCTION) annotation class RunSql(val scripts: Array<String>) Now we need to extend our test’s functionality with the ability to read this annotation and run the provided scripts. How lucky of us that Spring already has something exactly for our case, and it is called BeforeTestExecutionCallback. Let’s read the documentation: BeforeTestExecutionCallback defines the API for Extensions that wish to provide additional behavior to tests immediately before an individual test is executed but after any user-defined setup methods (e.g., @BeforeEach methods) have been executed for that test. That sounds right; let’s extend it and override the beforeTestExecution method. Java class RunSqlExtension : BeforeTestExecutionCallback { override fun beforeTestExecution(extensionContext: ExtensionContext?) { val annotation = extensionContext?.testMethod?.map { it.getAnnotation(RunSql::class.java) }?.orElse(null) annotation?.let { val testInstance = extensionContext.testInstance .orElseThrow { RuntimeException("Test instance not found. ${javaClass.simpleName} is supposed to be used in junit 5 only!") } val connectionFactory = getConnectionFactory(testInstance) if (connectionFactory != null) it.scripts.forEach { script -> Mono.from(connectionFactory.create()) .flatMap<Any> { connection -> ScriptUtils.executeSqlScript(connection, ClassPathResource(script)) }.block() } } } private fun getConnectionFactory(testInstance: Any?): ConnectionFactory? { testInstance?.let { return it.javaClass.superclass.declaredFields .find { it.name.equals("connectionFactory") } .also { it?.isAccessible = true }?.get(it) as ConnectionFactory } return null } } Okay, so what we’ve done here: We take the current test method from the extension context and check for the @RunSql annotation. We take the current test instance – the instance of our running test. We pass the current test instance to getConnectionFactory , so it can take the @Autowired ConnectionFactory from our parent, in our case, the abstract class. AbstractTestcontainersIntegrationTest Using the obtained connectionFactory and ScriptUtils, we execute the scripts found on @RunSql annotation in a blocking-manner. As I mentioned, our AbstractTestcontainersIntegrationTest needs a tiny change; we need to add @Autowired lateinit var connectionFactory: ConnectionFactory so it can be picked by our extension. Having everything in place, it is a matter of using this extension with @ExtendWith(RunSqlExtension::class) and our new annotation @RunSql. Here’s how our test looks now. Java @DataR2dbcTest @Tag("integration") @ExtendWith(RunSqlExtension::class) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) class ReviewRepositoryIntegrationTest : AbstractTestcontainersIntegrationTest() { @Autowired lateinit var reviewRepository: ReviewRepository @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByAuthor() { StepVerifier.create(reviewRepository.findAllByAuthor("Anonymous")) .expectNextCount(3) .verifyComplete() } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByCreatedAt() { StepVerifier.create(reviewRepository.findAllByCreatedAt(LocalDate.parse("2022-11-14"))) .expectNextCount(1) .verifyComplete() } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun findAllByCreatedAtBetween() { StepVerifier.create( reviewRepository.findAllByCreatedAtBetween( LocalDateTime.parse("2022-11-14T00:08:54.266024"), LocalDateTime.parse("2022-11-17T00:08:56.902252") ) ) .expectNextCount(4) .verifyComplete() } } And here is the content of schema.sql from resources. SQL create table if not exists reviews ( id integer generated by default as identity constraint pk_reviews primary key, text varchar(3000), author varchar(255), created_at timestamp, last_modified_at timestamp, course_id integer ); And here is the content of reviews.sql from resources/data. SQL truncate reviews cascade; INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-1, 'Amazing, loved it!', 'Anonymous', '2022-11-14 00:08:54.266024', '2022-11-14 00:08:54.266024', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-2, 'Great, loved it!', 'Anonymous', '2022-11-15 00:08:56.468410', '2022-11-15 00:08:56.468410', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-3, 'Good, loved it!', 'Sponge Bob', '2022-11-16 00:08:56.711163', '2022-11-16 00:08:56.711163', 3); INSERT INTO reviews (id, text, author, created_at, last_modified_at, course_id) VALUES (-4, 'Nice, loved it!', 'Anonymous', '2022-11-17 00:08:56.902252', '2022-11-17 00:08:56.902252', 3); Please pay attention to create table if not exists from schema.sql and truncate reviews cascade from reviews.sql – this is to ensure a clean state of the database for each test. Now, if we run our tests, all is green. We can go ahead and do a little more to follow the DRY principle in regard to the annotations used on this test which can be collapsed under one annotation and then reused, like this. Java @DataR2dbcTest @Tag("integration-test") @Target(AnnotationTarget.CLASS) @ExtendWith(RunSqlExtension::class) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) annotation class RepositoryIntegrationTest() And basically, that’s it, folks. With the common abstract class, test extension, and custom annotation in place, from now on, every new database integration test suite should be a piece of cake. Bonus But wait, why stop here? Having our setup, we can play around with component tests (broad integration tests), for example, to test our endpoints - starting with a simple HTTP call, surfing through all business layers and services all the way to the database layer. Here is an example of how you might wanna do it for GraphQL endpoints. Java @ActiveProfiles("integration-test") @AutoConfigureGraphQlTester @ExtendWith(RunSqlExtension::class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) internal class ReviewGraphQLControllerComponentTest : AbstractTestcontainersIntegrationTest() { @Autowired private lateinit var graphQlTester: GraphQlTester @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun getReviewById() { graphQlTester.documentName("getReviewById") .variable("id", -1) .execute() .path("getReviewById") .entity(ReviewResponse::class.java) .isEqualTo(ReviewResponseFixture.of()) } @Test @RunSql(["schema.sql", "/data/reviews.sql"]) fun getAllReviews() { graphQlTester.documentName("getAllReviews") .execute() .path("getAllReviews") .entityList(ReviewResponse::class.java) .hasSize(4) .contains(ReviewResponseFixture.of()) } } And again, if you want to reuse all the annotations there, simply create a new one. Java @ActiveProfiles("integration-test") @AutoConfigureGraphQlTester @ExtendWith(RunSqlExtension::class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) @Target(AnnotationTarget.CLASS) annotation class ComponentTest() You can find the code on GitHub. Happy coding and writing tests!

Today, 94% of organizations are using cloud technology, and this swift evolution to the cloud means security teams are handling more data and more alerts than ever. Additionally, threats and attacks are only increasing in frequency — it’s estimated that a cyber attack occurs every 11 seconds — and sophistication. But more often than not, security teams are overwhelmed because they don’t have the right tools and approaches to handle modern threat detection at scale. Security team leaders should have updated tools and approaches to help them protect their organization, and the best approach they can take is to adopt detection-as-code. Here's more about detection-as-code and its benefits, as well as some best practices to help you gain success as you begin to use detection-as-code in your security approach. The Benefits of Detection-as-Code What if threat detection could be flexible, tailored to your organization's needs, scalable, testable, and more? That's what detection-as-code is: An approach to writing detections that employs a universal programming language and software engineering best practices. Detection-as-code brings a number of benefits to your organization, starting with the ability for your team to write custom, high-quality detections that are tailored to what you need to be alerted to. By using a universal coding language like Python, you're moving away from restrictive domain-specific languages. As you build detections, you can reuse the code across workflows without having to start from scratch. Detection-as-code allows you to automate your work as well, decreasing human error and streamlining response time. As you increase automation, your team can focus more on fine-tuning alerts. Finally, utilize version control systems to help you know which version of detection you're currently working with or to revert to a previous version. Ultimately, detection-as-code offers standardization, sustainability, and reliability and is a forcing function for security teams to automate by default, operate at a higher scale, and improve team efficiency. So how can you get better at it? Four Best Practices If you're just starting to use detection-as-code or want to improve your approach, here are four best practices to help you grow and evolve your skills in leveraging detection-as-code for your organization. 1. Test, Test, and Test Some More One of the best things you can do as you build detections is to ensure that all of your detections are well-tested! Take a test-driven development (TDD) approach to your detection-as-code. You’ll discover blind spots early on, cover testing for false alerts, and evolve and improve your detection efficacy. Test for syntax and with real data to ensure you are able to check how these detections behave in the wild. 2. Learn Your Language One of the advantages of detection-as-code is that it frees you from restrictive domain-specific languages to use one that’s more universal. Security practitioners are already familiar with Python as a scripting language, and basic Python can be learned by anybody. The best way to help improve your threat detection is to become skilled at writing in Python. This ensures that you are writing code in ways that are sustainable, correct, and aligned with other software developers, which makes it easier to collaborate with your team. Use CI tools to make this easier for you, such as formatters, linters, and more. Learn from your team’s detection requirements; over time, you’ll improve your intuition, improving your security game. 3. Adopt a CI/CD Mindset Adopting a CI/CD mindset and responding more like software engineers can go a long way toward streamlining your detection processes. Continuously iterating on detection rules and alerts, testing those detections, and quickly deploying them not only allows you to be responsive in your improvements but allows you to leverage version control, unit testing, and other benefits. Above all, it allows you to leverage the power of automation in your workflows. 4. Get Creative With Code Writing code allows you to be creative because coding is problem-solving and unlocks new ways of approaching old problems. As such, teams who are writing sophisticated detections can begin to test more advanced methods of analysis, such as statistics, machine learning, graphs, and more. However, increasing sophistication doesn’t have to mean increasing complexity, as writing tailored code for your detections will actually simplify your approach. Modernizing Threat Detection Detection-as-code is the approach that will elevate your threat detection and make your security team better prepared, more efficient, and more creative with their response. But be sure that you're learning all the best practices around detection-as-code in order to make your efforts more pointed and successful.

While more and more users are moving towards an omnichannel approach, it is important to have a seamless user experience. One way to achieve this is by having a fully responsive application to ensure users have the best experience across platforms. There are numerous JavaScript libraries available for creating mobile/web app front-ends, but React is the best when it comes to creating a responsive application. In addition to supporting website front-ends, this well-equipped framework allows developers to create truly responsive web applications. Furthermore, React provides reusable custom HTML code for apps. Since React developers are in high demand for a variety of web app projects in different niches, technical recruiters find it hard to procure the right talent. So what steps must you take to seek out the most effective React developer for your firm? Read our in-depth recruiting guide to discover the greatest React skills for your team. This guide will explain the crucial React JS developer abilities to screen for when hiring a ReactJS developer. Top 12 Skills for ReactJS Developer The skillset of ReactJS developers should boast both technical as well as soft skills. Technical skills help them to perform the core duty of development, whereas soft skills help them perform better in a corporate setup. Let’s learn the technical as well as soft skills one by one. Technical Skills Following are the technical skills every ReactJS developer should have: 1. HTML + CSS Every ReactJS developer should have a firm grasp of developing well-crafted user interfaces and user experiences using HTML code and CSS scripts for websites and web applications. React developers should have the following skills in terms of HTML and CSS: Coding semantic HTML tags and CSS selectors and using them. Deploying a CSS reset. Understanding of the box model and how to reset the border-box. Deep understanding of flexbox. Knowledge of the principles to deploy responsive web designs. Properly using media queries in app projects. 2. JSX However, in React, you never really work solely on HTML. in fact, you work with a syntax extension (known as JSX) that is one of the remarkable parts of the React ecosystem. You may think of JSX as HTML-flavored JavaScript since it looks so much like HTML. Using JSX, you can work with it if you know HTML and CSS because you intuitively know how to do so. JSX is basically an abstraction on top of React.createElement() API. We can embed HTML elements in JavaScript and place them in the DOM without using createElement() or appendChild(). With JSX, we can write React applications without having to convert HTML tags into JavaScript objects. 3. JavaScript Fundamentals + ES6 The ReactJS developers must have a firm grasp of the fundamental concepts that JavaScript provides in order to rock React; in addition, ES6 skills are also essential. A React developer should have a sound understanding of the following: Function Declarations and Arrow Functions React applications are built using components. And these React components are composed of JS functions and classes. The JavaScript functions can be written in two different ways: either using the “function” keyword (aka, function declarations) or as an arrow function, which was introduced in ES6. In React, function declarations and arrow functions are employed to build function components. The greatest advantage of arrow functions is their conciseness. We can utilize several shorthands in order to write our functions so that we can remove excess boilerplate, resulting in a single-line function declaration. On the other hand, using function declarations rather than arrow functions allows you to bypass problems with hoisting. Because of JavaScript’s hoisting behavior, you can use multiple function declarations to create function components and put them in any order you prefer in a single file. DOM and Event Handling It is uncommon to manipulate the actual DOM elements in React. Remember that we now have the JSX abstraction at our disposal. The native event object that you get with regular DOM manipulation in React is actually encapsulated in a thing called the SyntheticEvent. Make sure you can attach a variety of events, such as `onclick`, `onchange`, `mouseenter`, etc., to HTML elements. Three Array Methods: .map(), .filter(), .reduce() Suppose we have an array and want to iterate over it to display each element as a JSX element. In this situation, we may employ the .map() method. It permits us to change each item in our array in the manner we desire, using the inner function. An arrow function is especially handy in this scenario. The function .filter() allows us to filter certain elements out of our array. For example, if we wanted to remove all names of programmers that started with ‘J,’ we could do so with .filter(). The critical thing to know is that both .map() and .filter() are just two versions of the .reduce() array method, which can turn array values into virtually any kind of data, including non-array values. Object Tricks While the ReactJS developers have to be skilled with arrays when working with React, they’ll need to be particularly competent in accessing and modifying object attributes. Unlike arrays, objects are used for storing key-value pairs in an organized manner. Every time an object is created, you must give it a property name and value. A very simple formula is to list the property name if it is identical to the value. Variables and Scoping The importance of knowing when and where you can access the data you require is crucial. Variables in JavaScript allow us to retain data in memory and access it later on within our applications. With ES6, we have new variables to store variables other than the traditional `var` keyword (such as `let` and `const`). You may follow the principle that `var` should be used unless you have a compelling reason not to, then default to `let` unless your linter tells you otherwise. Prototypal Inheritance and Object Creation In many aspects, React adheres to a functional programming paradigm. Still, the ReactJS developer must work in the world of classes, so you must learn how object creation occurs in JavaScript. If you understand how JavaScript’s prototype chain works, you will understand inheritance as a result. Of course, classes don’t exist in JavaScript, but the class keyword is merely syntactic sugar on top of the `object prototype` chain. 4. Git There is no question that Git is the most popular toolset for app developers across a wide range of skills and specialties. Because React is a robust JavaScript library with reusable components, working with the Git repositories to share code and other components with other developers is important. React developers can post and update web app projects on various coding platforms such as GitHub, Gitlab, and BitBucket using Git. Through this toolkit, developers can perform a wide range of activities, including merging different strategies, handling conflicts, pushing and pulling code changes, etc. The following are some of the key Git skills that React developers should have: Merging strategies and branching them appropriately. Merging conflicts handling. Tracking modifications via comments. 5. Node + npm You might wonder why the knowledge of Node is so important to being a React client-side developer. It is because, even though you can use React in any HTML document, there will likely be lots of other packages that allow you to extend the React library. The npm registry is where software developers go to get the software to help them build software. It sounds strange, but that’s all npm is a cloud storage facility for packages we call dependencies. The MERN (MongoDB, Express, React, Node) stack is a good example of a full-stack environment where front-end development is taken care of by React, while the back-end is handled by Node. It’s also important to note that developers can run React code directly in the Node environment, as well as the other way around, which improves their interoperability. 6. Redux One of the most significant drawbacks of React development is the asynchronicity of state updates. It’s critical for ReactJS developers to understand and utilize Redux because of this issue. Redux is a built-in state that controls and preserves the React library. Redux is not a data framework; it is an opinionated approach to working with data. The ideas behind Redux are similar to those of functional programming and immutability, but it is not a one-size-fits-all solution. Therefore, prior knowledge of basic React programming is essential. Developers use Redux’s scalability to accomplish state management. In addition, Redux helps developers create applications that behave consistently, are easy to test, and function similarly across environments by adopting functional programming and immutability principles. 7. Fetch Data from Both GraphQL and Rest APIs ReactJs is a front-end development framework and can be used to fetch data from the back-end in web app development. The most common method is to use a REST API to fetch data from the back end. However, GraphQL is the latest approach to fetch data from the back end. Having this ability will be of significant help to your ReactJS developers. Last but not least technical skill the ReactJS developers should have is hands-on experience in developing JS apps and deploying them on the cloud. Soft Skills In addition to technical skills, a ReactJS developer should also have soft skills to perform better in a corporate environment. The following soft skills are a must for ReactJS developers: 8. Excellent Communication It’s crucial for React JS developers to be able to articulate technical ideas in a manner that other team members and customers can comprehend. Because everyone on the team might work on the same project, it is important that everyone understands what the team members are trying to convey. 9. Problem-Solving React developers rely on problem-solving skills when debugging applications, addressing technical issues, or solving other problems. A logical approach to finding solutions is crucial as they can also apply their problem-solving skills to overcoming roadblocks at work, such as collaborating with team members on projects or meeting deadlines. 10. Team Player Working on a React Native project is more than just coding, testing, and prototyping. It takes a team of people to complete the job. A developer must collaborate with others to finish the product. Being a good team player is important to accomplish agile team goals, where teamwork and cooperation are key. 11. Creativity When building applications that can alter based on user input or other factors, React developers rely on their creativity. To solve problems like UI design, they must think of novel solutions, and novelty requires a substantial degree of creativity. 12. Accountability An individual who is well versed in ReactJS commits mistakes to stop a project from being derailed. They solve issues, write excellent code, are transparent in their work, and support their colleagues when they make a mistake. Conclusion Someone who knows JavaScript, ES6, HTML, CSS, JSX, Git, Node, and npm is needed to successfully deliver React JS projects. You should also look for someone who is good at communicating, solving problems, and working in a team. According to the job search site Indeed.com, over 10,000 ReactJS jobs are currently waiting to be filled. If you have trouble sourcing ReactJS developers, you can rely on our staff augmentation service so that you can focus on your core activities!

JavaScript is not a new name. It is the most popular and frequently used data processing language that runs on every system. Many developers have been extensively skilled in the JavaScript language, and thus it has been continuously improving and evolving. Node.js has been a widely used platform that successfully represents JavaScript everywhere. We have to admit that Node.js has transformed the screenplay of web development and allows developers to use JavaScript for backend development. Node.js has a large number of users with the largest developer community. But soon, JavaScript also launched Deno, and soon people started assuming that Deno would replace node.js. Therefore, a clash of Deno vs. Node.js is bound to happen. And why shouldn't they? After all, the developer of both Deno and Node.js happens to be the same person—Ryan Dahl. So, to clear all the clouds of confusion, today we will be talking about Deno vs. Node.js, Deno vs. Node.js performance, and which one is better. Let’s get started! Node.js vs. Deno: A Quick Overview Before giving any comparison, let’s have a quick overview of both. Both Deno and Node.js are runtime environments, and as I mentioned earlier, they were created by the same person. What Is Deno? First, to be clear, Deno is not a sub-branch of Node.js. It is a newly discovered runtime for carrying out JavaScript and TypeScript outer the web browser. The V8 JavaScript engine powers the Deno, and the core of the Deno is built in the Rust language. Deno was introduced by Ryan Dahl in 2018 during a presentation on the topic “10 things I regret about Node.js.” Deno was designed especially to control modern JavaScript and address various essential areas of Node.js. The aim of Deno is to streamline modules and build systems and offer a fast and secure server-side scripting environment. How To Install It # Mac/Linux brew install deno # windows choco install deno What Is Node.js? Node.js is also a back-end, open-source, cross-platform JavaScript environment. It sports a V8 engine and brings off Java script code outwards from the web browser. It provides nonparallel I/O and an event-run build that makes Node.js super agile and appropriate for scalable, real-time web applications. Node.js comprises a large client base, and it contains top organizations such as IBM, LinkedIn, Netflix, Microsoft, PayPal, Walmart, GoDaddy, AWS, and many more. It can be used for various purposes, but it is generally used for developing web servers and networking tools using JavaScript. Deno vs. Node.js: How Are They Different From Each Other? Security One of the main goals of Deno is to guarantee end-users the safety and security that Node.js failed to deliver. Thus, Deno is secured by default. It means the program operating with Deno has no file or network ingress unless it is mentioned. In Deno, the developer has to give access to an implementing script through command-line flags or dead-on runtime permission, similar to the browser execution. Deno, by default, limits the file system and network access to run the codes in the secure sandbox. However, Node.js permits access to the network and file systems, thus, in turn, making them susceptible to severe security concerns. When you work on Node.js, you will detect many such security issues that should be fixed to prevent your application from a ransomware attack. Package Management In Deno, the packages are integrated directly into the URL, which is contrary to Node’s npm. Deno goes for local or remote dependencies using links similar to the browsers. Whereas nom is the default package manager of Node.js. It is utilized to install and optimize public and private third-party packages. This online information on the package is called the npm registry. one can import modules and utilize dependencies as code: // http-server.ts import { serve } from "https://deno.land/std/http/server.ts"; for await (const req of serve({ port: 8000 })) { req.respond({ body: "Hi from Deno!\n" }); } APIs Node.js was introduced before the concept of JavaScript for async. Because of this, a majority of the APIs were introduced to support error-first retrieval. This exercise leads to wordy and clumsy codes. However, the Node.js programmers have ingressed the async syntax, and they have to manage the backward affinity through APIs. In Deno, things are nothing like this. It fosters modern JavaScript features and uses async functions. The Rust programming language offers promising abstractions called "Futures." Because of this, Deno makes it easier for developers to incorporate futuristic APIs into JavaScript. First-Class Typescript Support TypeScript is a prolongation of JavaScript that permits customers to offer type data. Deno carries TypeScript out of the box by using a TypeScript compiler with caching techniques. Node.js packages are encrypted in JavaScript. It does not have first-class typescript assistance, but it has a prevalent typescript that is extensively used in the Node.js world. Since Typescript is an umbrella term of Javascript, Deno can also drive it: // hello-world.ts const sayHello = function (greeter: string) { return `Hello from ${greeter}`; }; console.log(sayHello([..."node"].sort().join(""))); Module Deno employs the ES module as a default module structure. The ES modules are the general format for bundling JavaScript code. Node.js makes use of the CommonJS standard. Node.js does support the ES module, but it is in an experimental stage. Community Node.js holds the largest, most dynamic, innovative, and open-source communities all around the world. And it is all designed and maintained by the community. Therefore, most programmers use Node.js and run thousands upon thousands of apps. However, Deno is a new player in the market, and it is still in the evolving and growing phase. Deno vs. Node.js Performance This is the most awaited topic. As it covers the answer to the most asked question: Is Deno faster than Node.js? Or who wins the battle? Well, the wait is over. The answer to these questions will purely depend on what you want. Like, if you want more information through HTTP, then Node.js is a good choice as the C++ basis handles the majority of the data efficiently. But don't slash Deno that easily. In terms of dormancy, Deno is an undisputable leader. It genuinely works with lower delays. So, if you are thinking of developing a browser online game, then Deno could be your optimal choice. Its runtime will give more tools to offer average gamers a greater experience. Still, the overall image of the performance of Deno vs. Node.js is inconclusive. Both platforms are high-speed, with no significant difference between them. A Quick Comparison of Deno vs Node.js Factors DENO Node.js Language TypeScript, JavaScript JavaScript Release Year 2018 2009 Developers Ryan Dahl Ryan Dahl Managed By Deno, and community OpenJS Foundation Typescript Support in-built It requires additional packages. Community New and evolving. "Wide and strong" Security Permission-driven access Complete access Package .ts or.js Module NPM Modules ES Modules CommonJS ECMAScript Support In-built Not in-built Await Mechanism In-built Not in-built Written In Rust, Tokio C++ and Libuv. Used By Appwrite, Cloudless, the Tribe, Polar COP Netflix, Uber, PayPal, eBay, Trello, GoDaddy, Groupon, NASA, and more. Is Deno More Secure Than Node.js? The answer to this question is not that frank. Deno for JavaScript is a much more secure platform. This is because Deno needs various permissions for various actions. And beyond this, the Deno runtime starts everything in a highly protected sandbox. In contrast, Node.js focuses less on all the permission parts, thus giving some potential loopholes. The problem with Deno here is related to its package system. Node.js provides a centralized depository for all the libraries, while you can download Deno packages from several places. And seeing this feels like Node.js is still very far from being perfect. The NPM store of Node.js compiles several versions of the packages. And so, controlling things there is very easy. Because of this, scandals have taken place in the past. However, with Deno, one can achieve audits because they offer access to code rather than assembled options. This makes the Deno vs. Node.js competition a bit tricky. Although Deno is secure and well-tested, if you are building something large, you will need advanced libraries, and node.js will be best for this. Can Deno Replace Node.js? This question has been revolving from the very first day since the launch of Deno. Well, let’s answer this question. Deno is definitely better in some situations but inferior in others. So, to answer your question, you have to recognize your circumstances and requirements before making any decisions. And Deno has undoubtedly displaced Node.js. Deno is not a regular upgrade of Node.js. Even its developer, Dahl, has stated in several interviews that Deno is an alternative rather than a replacement for Node.js. And surely, in the future, Deno will attract many programmers. To Sum Up! The Deno vs. Node.js competition is always interesting to watch, especially after knowing that they are both developed by the same developer. Programmers use Deno for one set of tasks and Node.js for another because both are capable of tremendous backend development opportunities. There is still time for Deno to grow, and it won’t replace Node.js that easily. I am saying this because if you have read the whole article, you know that Deno is still like a baby in front of the huge Node.js community. Moreover, Deno has a bright future. What’s your point of view in this debate of Node.js vs. Deno.?

While performing UI automation testing on a webpage, we all try to work with the web elements such as buttons, texts, etc. Interaction with the WebElements in the DOM is made possible with the help of Selenium locators. However, there are some aspects of a web page that even the locators can’t manage. Pseudo-elements in CSS fall in that category. Without the correct information, these pseudo-elements can be very hard to automate. In this article, we will see how to handle pseudo-elements in CSS with Selenium WebDriver. Selenium is a powerful automation testing framework for checking complex web pages but pseudo-elements are tricky to automate. Selenium, when used in conjunction with the JavaScriptExecutor interface, helps to automate pseudo-elements. When testing your website, one must also ensure that the webpage functions as expected across various browser and OS combinations. Given that Selenium test automation is a cross-browser and cross-platform affair, you can perform automation tests at scale with the cloud-based Selenium Grid. What Are Pseudo-Elements in CSS? The combination of two words – pseudo and elements – can often lead to a misunderstanding, so let’s understand what exactly pseudo-elements are in CSS (Cascading Style Sheet). While using CSS on any web element, we usually apply a style all over it. But what if we want to apply a class only to a specific part of it and not to a complete element? I know what you are thinking. And the answer is YES. This is possible with the help of pseudo-elements. Pseudo-elements are CSS components used to style specified parts of a web element. These pseudo-elements can be used to apply CSS on a portion or a specific part of a web element, such as: Applying CSS on the first letter of an element Applying CSS on the first line of an element Inserting some text before the text of an element Inserting some text after the text of an element The pseudo-elements are defined with the help of a double colon (::), as shown in the below syntax: CSS selector::pseudo-element { property: value; } Common Types of Pseudo-Elements in CSS Before starting to work on the pseudo-elements in Selenium, let us first see some commonly used types of pseudo-elements in CSS. The ::first-line Pseudo-Element As the name suggests, the ::first-line pseudo-element in CSS is used to add special CSS styling only to the first line of the text and can be applied only to the block-level elements. Syntax: CSS selector::first-line { property: value; } Pseudo-Element in CSS Example ::First-line Pseudo-element Consider the below HTML code: HTML <!DOCTYPE html> <html> <head> <style> p::first-line { color: #00ff00; font-variant: small-caps; } </style> </head> <body> <p>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. </p> </body> </html> If you try to run the above HTML file, the output will be: As you can see, the desired Green colour (#00ff00) is applied only on the first line of the <p></p> element, and that is possible only with the help of::first-line pseudo-element. The ::First-letter Pseudo-Element As the name suggests, the ::first-letter pseudo-element in CSS is used to add special CSS styling only to the first letter of the text and can be applied only to the block-level elements. Syntax: CSS selector::first-letter { property: value; } Pseudo-element in CSS Example ::First-letter Pseudo-element Consider the below HTML code: HTML <!DOCTYPE html> <html> <head> <style> p::first-letter { color: #00ff00; font-variant: small-caps; } </style> </head> <body> <p>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. </p> </body> </html> If you try to run the above HTML file, the output will be: As you can see, the desired Green colour (#00ff00) is applied only on the first letter of the <p></p≶ element, and that is possible only with the help of ::first-letter pseudo-element. The ::before Pseudo-Element As the name suggests, the ::before pseudo-element in CSS is used to add unique CSS styling before the content of any element. Syntax: CSS selector::before { property: value; } Pseudo-Element in CSS Example ::Before Pseudo-element Consider the below HTML code: HTML <!DOCTYPE html> <html> <head> <style> p::before { content: "∴" } </style> </head> <body> <p>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. </p> </body> </html> If you try to run the above HTML file, the output will be: As you can see, the desired therefore symbol (∴) is applied before the <p></p> element, and that is possible only with the help of ::before pseudo-element. The ::after Pseudo-Element As the name suggests, the ::after pseudo-element in CSS is used to add unique CSS styling after the content of any element. Syntax: CSS selector::after { property: value; } Pseudo-element in CSS Example ::After Pseudo-element Consider the below HTML code: HTML <!DOCTYPE html> <html> <head> <style> p::after { content: "∴" } </style> </head> <body> <p>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. </p> </body> </html> If you try to run the above HTML file, the output will be: As you can see, the desired therefore symbol (∴) is applied after the <p></p> element, and that is possible only with the help of::after pseudo-element. Similarly, there are many more pseudo-elements available in the CSS, such as: The ::marker Pseudo-Element The ::marker pseudo-element in CSS is used to add special CSS styling to the list markers, such as unordered list bullet points, ordered list numbers, etc. Syntax: CSS selector::marker { property: value; } The ::selection Pseudo-Element The ::selection pseudo-element in CSS is used to add special CSS styling to the user-selected portion or content. Syntax: CSS selector::selection { property: value; } Backward Compatibility Similar to pseudo-elements, there also exists a CSS pseudo-class. To define a pseudo-class, a single colon (:) is used. Syntax: CSS selector:pseudo-class { property: value; } But, you might come across situations where a single colon is used for both – the pseudo-class and the pseudo-elements. This is because, before CSS3, both the pseudo-class and pseudo-elements had the same syntax. In CSS3, a double colon (::) was introduced for pseudo-elements instead of a single colon (:). So you might see the single-colon syntax used for both pseudo-classes and pseudo-elements in CSS2 and CSS1. For backward compatibility, the single-colon syntax is acceptable for CSS2 and CSS1 pseudo-elements. Consider the below table for a complete backward compatibility chart of pseudo-elements in CSS: Browser Lowest Version Support of Internet Explorer 8.0 :pseudo-element 9.0 :pseudo-element ::pseudo-element Firefox (Gecko) 1.0 (1.0) :pseudo-element 1.0 (1.5) :pseudo-element ::pseudo-element Opera 4.0 :pseudo-element 7.0 :pseudo-element ::pseudo-element Safari (WebKit) 1.0 (85) :pseudo-element ::pseudo-element Why Can’t Normal Locators Be Used To Automate Pseudo-Elements in Selenium? You must be wondering why we can’t use the normal Selenium locators to automate pseudo-elements in CSS. To understand that, let us first go ahead and try to automate them using the Selenium locators. Let us consider the following webpage: HTML <!DOCTYPE html> <html> <head> <style> p::before { content: "∴" } </style> </head> <body> <p>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. <br>The quick brown fox jumps over the lazy dog. </p> </body> </html> In this, as you can see, we have used a ::before pseudo-element, which is adding the, therefore (∴) symbol before the text of the button (i.e., Submit). Note: To help with the automation, I have uploaded this code in a sample GitHub repo. So let us try to automate this element using the CSSSelector locator in JavaScript. Java // Include the chrome driver require("chromedriver"); // Include selenium webdriver let webdriver = require("selenium-webdriver"); var By = require("selenium-webdriver").By; let browser = new webdriver.Builder(); let driver = browser.forBrowser("chrome").build(); driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); var element = driver.findElement(By.css(".submitButton::before")).getText(); element.then(function(txt) { console.log(txt); }); driver.quit(); Code Walkthrough: In the above code, the steps done are as follows: Java // Include selenium webdriver let swd = require("selenium-webdriver"); var By = require("selenium-webdriver").By; let browser = new swd.Builder(); let driver = browser.forBrowser("chrome").build(); First, the Selenium WebDriver is set up for the local Chrome browser. Java driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); Then the page where I have published the HTML code is opened in the local Chrome browser. You can use your local URL as well for this line. Java var element = driver.findElement(By.css(".submitButton::before")).getText(); Then the desired pseudo-element is called with the help of CSS Selector, and the result is stored in the variable element. JavaScript element.then(function(txt) { console.log(txt); }); Upon executing the findElement() method in the last step, the desired pseudo-element is called, and the result is stored in the variable element. It is then validated with the help of the then() method and printed to the console in the following line. driver.quit(); At last, the local browser is ended by destroying the Selenium WebDriver instance. Expected Output: Ideally, as per locators in Selenium, the above code should produce the value of the content property as output: "∴ " Actual Output: Upon executing the test, you get the output as NoSuchElementError. Why NoSuchElementError? Although the locator is correct, you cannot work with the pseudo-elements with normal Selenium locators. This is because the pseudo-elements in CSS on a webpage are treated as a JavaScript elements. It means that these pseudo-elements in CSS are executed in the front end at runtime when the page loads and not initially. This is why when the Selenium WebDriver wants to interact with these pseudo-elements, the code gives NoSuchElementError. Let Us Try In Java Consider the following Java code, which tries to use the CSS Selector Selenium locator and get the value of the pseudo-element. Java import org.openqa.selenium.By; import org.openqa.selenium.JavascriptExecutor; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class PseudoElements { public static void main(String[] args) { // Instantiate a ChromeDriver class. WebDriver driver = new ChromeDriver(); // Launch Website driver.navigate().to("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); // Maximize the browser driver.manage().window().maximize(); // Scroll down the webpage by 5000 pixels // JavascriptExecutor js = (JavascriptExecutor) driver; // js.executeScript("scrollBy(0, 5000)"); String text = driver.findElement(By.cssSelector(".submitButton::before")).getText(); System.out.print(text); driver.quit(); } } Upon execution, the Java code also gives the NoSuchElementException. How To Work With Pseudo-Elements In Selenium? Since the Selenium locators fail with pseudo-elements, the question arises is there any way to work with the pseudo-elements in Selenium? Yes. The pseudo-elements can be automated in Selenium with the help of JavaScriptExecutor. By definition, JavaScriptExecutor is an Interface that helps to execute JavaScript through Selenium Webdriver. Since pseudo-elements in CSS are treated as JavaScript, hence we can use the JavaScriptExecutors to interact with them. For example, to get the value of the content property in the above code, the JavaScriptExecutor code will be: Java script = "return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')"; var element = driver.executeScript(script); Let us see via a complete code. How To Work With Pseudo-Elements In Selenium JavaScript? In case you are new to JavaScript with Selenium, do check out our detailed tutorial on Automating Testing with Selenium using JavaScript. Consider the following test written in JavaScript to run on local Google Chrome. Java // Include the chrome driver require("chromedriver"); // Include selenium webdriver let webdriver = require("selenium-webdriver"); var By = require("selenium-webdriver").By; let browser = new webdriver.Builder(); let driver = browser.forBrowser("chrome").build(); driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); script = "return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')"; var element = driver.executeScript(script); element.then(function(txt) { console.log(txt); }); driver.quit(); Code Walkthrough: In the above code, the steps done are as follows: Java // Include selenium webdriver let swd = require("selenium-webdriver"); var By = require("selenium-webdriver").By; let browser = new swd.Builder(); let driver = browser.forBrowser("chrome").build(); First, the Selenium WebDriver is set up for the local Chrome browser. Java driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); Then the page where I have published the HTML code is opened in the local Chrome browser. You can use your local URL as well for this line. Java script = "return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')"; var element = driver.executeScript(script); The script to get the property value (content) of the class submitButton is written. It is then executed with the help of the driver.executeScript() method. JavaScript element.then(function(txt) { console.log(txt); }); Upon executing the script in the last step, the desired pseudo-element is called, and the result is stored in the variable element. It is then validated with the help of the then() method and printed to the console in the following line. driver.quit(); At last, the local browser is ended by destroying the Selenium WebDriver instance. Output: Upon execution of the above test, the output will be: As you can see, we have now received the ideal output: "∴ " How to Work With Pseudo-Elements in Selenium Java? The JavaScriptExecutor can be used to work with pseudo-elements in Selenium Java. Consider the following test written in Java to run on local Google Chrome. Java import org.openqa.selenium.By; import org.openqa.selenium.JavascriptExecutor; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class PseudoElements { public static void main(String[] args) { // Instantiate a ChromeDriver class. WebDriver driver = new ChromeDriver(); // Launch Website driver.navigate().to("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); // Maximize the browser driver.manage().window().maximize(); JavascriptExecutor js = (JavascriptExecutor) driver; String text = js.executeScript("return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')") .toString(); System.out.print(text); driver.quit(); } } Code Walkthrough: In the above code, the steps done are as follows: Java // Instantiate a ChromeDriver class. WebDriver driver = new ChromeDriver(); First, the Selenium WebDriver is set up for the local Chrome browser. Java driver.navigate().to("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); Then the page where I have published the HTML code is opened in the local Chrome browser. You can use your local URL as well for this line. Java // Maximize the browser driver.manage().window().maximize(); The browser is then maximized using the maximize() method. Java JavascriptExecutor js = (JavascriptExecutor) driver; String text = js.executeScript("return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')") .toString(); The script to get the property value (content) of the class submitButton is written. It is then executed with the help of the JavascriptExecutor.executeScript() method, and the value is retrieved as a String in the variable text. System.out.print(text); Upon executing the script in the last step, the desired pseudo-element is called, and the result is stored in the variable text. It is then printed to the console. driver.quit(); At last, the local browser is ended by destroying the Selenium WebDriver instance. Output: Upon execution of the above test, the output will be: Plain Text Starting ChromeDriver 90.0.4430.24 (4c6d850f087da467d926e8eddb76550aed655991-refs/branch-heads/4430@{#429}) on port 22874 Only local connections are allowed. Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe. ChromeDriver was started successfully. May 24, 2021 3:15:07 AM org.openqa.selenium.remote.ProtocolHandshake createSession INFO: Detected dialect: W3C "∴ " As you can see, we have now received the ideal output."∴ " Running Tests on Cloud-Based Selenium Grid The solution to the problems or limitations of the local Selenium setup is the cloud-based Selenium Grid. One such cloud-based Selenium Grid provider is LambdaTest. LambdaTest allows you to run your tests on its online cloud-based Selenium Grid on 3000+ browsers, browser versions, and operating systems with the help of Remote WebDriver. To run Selenium test automation on LambdaTest Selenium Grid, you need: A LambdaTest username and access key. Selenium Desired Capabilities to run your tests on the desired combination of browsers, browser versions, and operating systems. These Selenium Desired Capabilities are language-specific and can be easily written with the help of the LambdaTest Desired Capabilities Generator. For example, let’s say the browser we want to test on is Firefox, version 89, and the operating system macOS Big Sur. Also, let’s try it at a resolution of 1280×960. Browser: Firefox Browser Version: 89 Operating System: macOS Big Sur Resolution: 1280×968 So we can select the same capabilities from the capabilities generator. Let’s try to convert our local Selenium test automation setup code to execute on the LambdaTest platform. Executing Java Code on LambdaTest As the prerequisites, we first need to get the username, access key, and the desired capabilities. To set the username and access key, replace yours from your Profile section in the below code snippet for the Grid URL. Grid URL is your specific Remote WebDriver route on which the tests will be executed. JavaScript String gridURL = "http://" + username + ":" + accesskey + "@hub.lambdatest.com/wd/hub"; Next, get the above-mentioned desired capabilities for Java from the Capabilities Generator: Java DesiredCapabilities capabilities = new DesiredCapabilities(); capabilities.setCapability("build", "your build name"); capabilities.setCapability("name", "your test name"); capabilities.setCapability("platform", "MacOS Big sur"); capabilities.setCapability("browserName", "Firefox"); capabilities.setCapability("version","89.0"); capabilities.setCapability("resolution","1280x960"); We need to create the Remote WebDriver instance and initialize it with the above capabilities and Grid URL. Java DesiredCapabilities capabilities = new DesiredCapabilities(); capabilities.setCapability("build", "Cap Gen Demo"); capabilities.setCapability("name", "Win10 Firefox85 1280x800"); capabilities.setCapability("platform", "MacOS Big sur"); capabilities.setCapability("browserName", "Firefox"); capabilities.setCapability("version","89.0"); capabilities.setCapability("resolution","1280x960"); String gridURL = "http://" + username + ":" + accesskey + "@hub.lambdatest.com/wd/hub"; try { driver = new RemoteWebDriver(new URL(gridURL), capabilities); } catch (Exception e) { System.out.println("driver error"); System.out.println(e.getMessage()); } That’s it. Now we can use this Remote WebDriver instance to write and execute our test to show working on pseudo-elements in Selenium. Below’s the complete Java code: Java import org.testng.annotations.Test; import java.net.URL; import org.openqa.selenium.JavascriptExecutor; import org.openqa.selenium.WebDriver; import org.openqa.selenium.remote.DesiredCapabilities; import org.openqa.selenium.remote.RemoteWebDriver; import org.testng.annotations.AfterTest; import org.testng.annotations.BeforeTest; public class PseudoElementsOnLambdaTest { public static WebDriver driver; public static String status = "failed"; @BeforeTest(alwaysRun = true) public void setUp() throws Exception { DesiredCapabilities capabilities = new DesiredCapabilities(); capabilities.setCapability("build", "Cap Gen Demo"); capabilities.setCapability("name", "Win10 Firefox85 1280x800"); capabilities.setCapability("platform", "MacOS Big sur"); capabilities.setCapability("browserName", "Firefox"); capabilities.setCapability("version", "89.0"); capabilities.setCapability("resolution", "1280x960"); String gridURL = "http://" + username + ":" + accesskey + "@hub.lambdatest.com/wd/hub"; try { driver = new RemoteWebDriver(new URL(gridURL), capabilities); } catch (Exception e) { System.out.println("driver error"); System.out.println(e.getMessage()); } } @Test public static void test() throws InterruptedException { // Launch Website driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html"); // Maximize the browser driver.manage().window().maximize(); // Scroll down the webpage by 5000 pixels JavascriptExecutor js = (JavascriptExecutor) driver; String text = js.executeScript( "return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')") .toString(); System.out.print(text); status = "passed"; Thread.sleep(150); } @AfterTest public static void afterTest() { ((JavascriptExecutor) driver).executeScript("lambda-status=" + status + ""); driver.quit(); } } Upon Selenium test automation execution, you can see the test getting run on the desired environment configuration on the LambdaTest platform. Executing JavaScript Code on LambdaTest Similarly, let’s try to execute our JavaScript code on the LambdaTest platform. For a quick overview of automation testing with Selenium and JavaScript, do check out the below video from the LambdaTest YouTube channel. As the prerequisites, we first need to get the username, access key, and the desired capabilities. To set the username and access key, replace yours from your Profile section in the below code snippet for the Grid URL. Grid URL is your specific Remote WebDriver route on which the tests will be executed. Java String gridURL = "http://" + username + ":" + accesskey + "@hub.lambdatest.com/wd/hub"; Next, get the above-mentioned desired capabilities for Java from the Capabilities Generator: Java var capabilities = { "build" : "your build name", "name" : "your test name", "platform" : "MacOS Big sur", "browserName" : "Firefox", "version" : "89.0", "resolution" : "1280x960" } We need to create the Remote WebDriver instance and initialize it with the above capabilities and Grid URL. JavaScript LT_USERNAME = "username"; LT_ACCESS_KEY = "access key"; caps = { 'build': 'Mocha-Selenium-Sample', //Build name 'name': 'Your Test Name', // Test name 'platform':'MacOS Big sur', // OS name 'browserName': 'Firefox', // Browser name 'version': '89.0', // Browser version "resolution" : "1280x960", 'visual': false, // To take step by step screenshot 'network':false, // To capture network Logs 'console':false, // To capture console logs. 'tunnel': false // If you want to run the localhost, then change it to true }; var buildDriver = function () { return new webdriver.Builder() .usingServer( "http://" + LT_USERNAME + ":" + LT_ACCESS_KEY + "@hub.lambdatest.com/wd/hub" ) .withCapabilities(caps) .build(); }; That’s it. Now we can use this Remote WebDriver instance to write and execute our test to show working on pseudo-elements in Selenium. Below is the complete JavaScript code: JavaScript LT_USERNAME = "username"; LT_ACCESS_KEY = "access key"; exports.capabilities = { 'build': 'Pseudo ELements', //Build name 'name': 'Your Test Name', // Test name 'platform':'MacOS Big sur', // OS name 'browserName': 'Firefox', // Browser name 'version': '89.0', // Browser version "resolution" : "1280x960", 'visual': false, // To take step by step screenshot 'network':false, // To capture network Logs 'console':false, // To capture console logs. 'tunnel': false // If you want to run the localhost, then change it to true }; JavaScript var assert = require("assert"), webdriver = require("selenium-webdriver"), conf_file = process.argv[3] || "conf/single.conf.js"; var caps = require("../" + conf_file).capabilities; var buildDriver = function (caps) { return new webdriver.Builder() .usingServer( "http://" + LT_USERNAME + ":" + LT_ACCESS_KEY + "@hub.lambdatest.com/wd/hub" ) .withCapabilities(caps) .build(); }; describe("Pseudo-Elements " + caps.browserName, function () { var driver; this.timeout(0); beforeEach(function (done) { caps.name = this.currentTest.title; driver = buildDriver(caps); done(); }); it("Pseudo ELements JavaScript", function (done) { driver.get("https://monica-official.github.io/Pseudo-Elements/sample-pseudo-element.html").then(function () { script = "return window.getComputedStyle(document.querySelector('.submitButton'),'::before').getPropertyValue('content')"; var element = driver.executeScript(script); element.then(function (txt) { console.log(txt); }); }); }); afterEach(function (done) { if (this.currentTest.isPassed) { driver.executeScript("lambda-status=passed"); } else { driver.executeScript("lambda-status=failed"); } driver.quit().then(function () { done(); }); }); }); Upon execution, you can see the test getting run on the desired environment configuration on the LambdaTest platform. Conclusion The UI of a webpage is often very complex, and to test the complete UI, Selenium automation is one of the most effective ways. You might even come across complex pseudo-elements in CSS, but the method to work with these pseudo-elements in Selenium will remain the same. You can use the JavaScript Executor to automate the pseudo-elements in any language. Along with testing the UI, one must also ensure the cross-browser compatibility of the webpage. Since the local Selenium test automation setup can’t be used to ensure that, the cloud-based Selenium Grid like LambdaTest is efficient. We hope you learned how to work with pseudo-elements in Selenium.Thank you.

Flask is a lightweight Web application framework written with Python, which is called a "micro-framework" because it uses a simple core for extension of other features, such as ORM, form validation tools, file upload, various open authentication techniques, etc. MQTT is a lightweight Internet of Things (IoT) message transmission protocol based on publish/subscribe mode. It can provide a real-time and reliable message service for networked devices with very less code and smaller bandwidth. It is widely used in IoT, mobile Internet, intelligent hardware, IoV, power and energy industries, etc. This article mainly introduces how to use MQTT in the Flask project and implements the connection, subscription, messaging, unsubscribing, and other functions between the MQTT client and MQTT broker. We will use the Flask-MQTT client library, which is a Flask extension and can be regarded as a decorator of paho-mqtt to simplify the MQTT integration in Flask applications. Project Initialization This project is developed and tested with Python 3.8, and users may use the following commands to verify the version of Python. $ python3 --version Python 3.8.2 Use Pip to install the Flask-MQTT library. pip3 install flask-mqtt Use Flask-MQTT We will adopt the Free public MQTT broker that was created on the basis of the MQTT cloud service - EMQX Cloud. The following is the server access information: Broker: broker.emqx.io TCP Port: 1883 Websocket Port: 8083 Import Flask-MQTT Import the Flask library and Flask-MQTT extension, and create the Flask application. from flask import Flask, request, jsonify from flask_mqtt import Mqtt app = Flask(__name__) Configure Flask-MQTT Extension app.config['MQTT_BROKER_URL'] = 'broker.emqx.io' app.config['MQTT_BROKER_PORT'] = 1883 app.config['MQTT_USERNAME'] = '' # Set this item when you need to verify username and password app.config['MQTT_PASSWORD'] = '' # Set this item when you need to verify username and password app.config['MQTT_KEEPALIVE'] = 5 # Set KeepAlive time in seconds app.config['MQTT_TLS_ENABLED'] = False # If your server supports TLS, set it True topic = '/flask/mqtt' mqtt_client = Mqtt(app) For complete configuration items, please refer to the Flask-MQTT configuration document. Write Connect Callback Function We can handle successful or failed MQTT connections in this callback function, and this example will subscribe to the /flask/mqtt topic after a successful connection. @mqtt_client.on_connect() def handle_connect(client, userdata, flags, rc): if rc == 0: print('Connected successfully') mqtt_client.subscribe(topic) # subscribe topic else: print('Bad connection. Code:', rc) Write Message Callback Function This function will print the messages received by the /flask/mqtt topic. @mqtt_client.on_message() def handle_mqtt_message(client, userdata, message): data = dict( topic=message.topic, payload=message.payload.decode() ) print('Received message on topic: {topic} with payload: {payload}'.format(**data)) Create Message Publish API We create a simple POST API to publish the MQTT messages. In a practical case, the API may need some more complicated business logic processing. @app.route('/publish', methods=['POST']) def publish_message(): request_data = request.get_json() publish_result = mqtt_client.publish(request_data['topic'], request_data['msg']) return jsonify({'code': publish_result[0]}) Run Flask Application When the Flask application is started, the MQTT client will connect to the server and subscribe to the topic /flask/mqtt. if __name__ == '__main__': app.run(host='127.0.0.1', port=5000) Test Now, we use the MQTT client - MQTT X to connect, subscribe, and publish tests. Receive Message Create a connection in MQTT X and connect to the MQTT server. Publish Hello from MQTT X to the /flask/mqtt topic in MQTT X. We will see the message sent by MQTT X in the Flask running window. Publish Message Subscribe to the /flask/mqtt topic in MQTT X. Use Postman to call the /publish API: Send the message Hello from Flask to the /flask/mqtt topic. We can see the message sent from Flask in MQTT X. Complete Code from flask import Flask, request, jsonify from flask_mqtt import Mqtt app = Flask(__name__) app.config['MQTT_BROKER_URL'] = 'broker.emqx.io' app.config['MQTT_BROKER_PORT'] = 1883 app.config['MQTT_USERNAME'] = '' # Set this item when you need to verify username and password app.config['MQTT_PASSWORD'] = '' # Set this item when you need to verify username and password app.config['MQTT_KEEPALIVE'] = 5 # Set KeepAlive time in seconds app.config['MQTT_TLS_ENABLED'] = False # If your broker supports TLS, set it True topic = '/flask/mqtt' mqtt_client = Mqtt(app) @mqtt_client.on_connect() def handle_connect(client, userdata, flags, rc): if rc == 0: print('Connected successfully') mqtt_client.subscribe(topic) # subscribe topic else: print('Bad connection. Code:', rc) @mqtt_client.on_message() def handle_mqtt_message(client, userdata, message): data = dict( topic=message.topic, payload=message.payload.decode() ) print('Received message on topic: {topic} with payload: {payload}'.format(**data)) @app.route('/publish', methods=['POST']) def publish_message(): request_data = request.get_json() publish_result = mqtt_client.publish(request_data['topic'], request_data['msg']) return jsonify({'code': publish_result[0]}) if __name__ == '__main__': app.run(host='127.0.0.1', port=5000) Limitations Flask-MQTT is currently not suitable for use with multiple worker instances. So if you use a WSGI server like gevent or gunicorn make sure you only have one worker instance. Summary So far, we have completed a simple MQTT client using Flask-MQTT and can subscribe and publish messages in the Flask application.

While developing an application, we need to make some processing more robust and less fault-tolerant, especially when requesting remote services that may remain down for a long duration. In this article, we will introduce a new framework that aims to provide a declarative non-blocking retry support for methods in Spring-based applications using annotations. This framework has two main implementations: Thread pool task-based implementation: This implementation is based on ThreadPoolTaskExecutor without keeping the task executor thread busy during the whole retry processing, unlike the combination of @Async (see "Spring Boot - Async methods") and @Retryable (see "Retry Handling With Spring-Retry"). Indeed, when using the Spring traditional retry annotation, the thread that runs the method performs the whole retry policy, including waiting periods, and remains busy until the end. For example, if the ThreadPoolTaskExecutor has 10 threads with a retry policy that may take 5 minutes, and the application receives 30 requests, only 10 requests can be processed simultaneously and the others will be blocked for the whole 5 minutes. So the execution of the 30 requests may take 15 minutes. Quartz job-based implementation: This implementation is based on the Quartz library. It supports load-balancing, failover, and persistence if configured with JDBC JobStore. This means that even if a node in the cluster is down, the others can take over the operation and perform the retries. Basic Concepts Annotation In order to make a method retryable, you can annotate it with @AsyncRetryable and specify the following attributes: retryPolicy (mandatory): The policy bean name that defines the next retry time if an exception has been thrown during the method execution retryFor (optional): List of the exceptions for which the retry should be performed noRetryFor (optional): List of the exceptions for which the retry should not be performed retryListener (optional): The listener bean name that triggers events related to the annotated method execution The following example shows how to use @AsyncRetryable in a declarative style: Java @Bean public class Service { @AsyncRetryable(retryPolicy = "fixedWindowRetryableSchedulingPolicy", retryFor = IOException.class, noRetryFor={ArithmeticException.class}, retryListener = "retryListener") public void method(String arg1, Object arg2){ // ...do something } } In this example, if an exception of type IOException is thrown during the method perform() execution, the retry will be made according to the policy fixedWindowRetryableSchedulingPolicy. If an exception of type ArithmeticException is thrown, no retry will be made. All the events that happened during the method call are reported to the bean listener retryListener. Retry Policy The retry policy defines the next execution time for each failing execution. Indeed, when the annotated method throws a retryable exception, the retry policy bean is called in order to get the period to wait before calling the method again. This framework provides three basic implementations: FixedWindowRetryableSchedulingPolicy: This policy is used for retries with a fixed waiting period and a max attempt limit. StaticAsyncRetryableSchedulingPolicy: This policy accepts an array of waiting periods for each attempt. LinearAsyncRetryableSchedulingPolicy: This policy multiplies each time the previous waiting period by a coefficient in order to increase the duration of the next one. The coefficient default value is 2. The following example shows how to configure a FixedWindowRetryableSchedulingPolicy that will trigger the annotated method for the first time in 10 seconds, then make 3 retries within a waiting period of 20 seconds each. Java @Configuration public class AsyncRetryConfiguration { ... @Bean public FixedWindowRetryableSchedulingPolicy fixedWindowRetryableSchedulingPolicy() { return new FixedWindowRetryableSchedulingPolicy(10000,3,20000); } } Remark: It is possible to customize the retry policy by implementing the interface AsyncRetryableSchedulingPolicy. Retry Listener The retry listener is used to detect events during the retry processing life cycle. The AsyncRetryableListener interface is defined as below: Java public interface AsyncRetryableListener<T> { void beforeRetry(Integer retryCount, Object[] args); void afterRetry(Integer retryCount,T result, Object[] args, Throwable e); void onRetryEnd(Object[] args, Throwable e); } The methods beforeRetry() and afterRetry() are triggered respectively before and after the call of the annotated method. The method onRetryEnd() is triggered at the end of the retry process. The methods defined above are called nether the annotated method succeeds or fails. The methods' attributes are: retryCount: The current retry number result: The value returned by the annotated method in case of success args: The annotated method argument values in the same order e: The thrown exception during the execution of the annotated method; this value is null if the method is executed with success. How To Use It Thread Pool Task-Based Implementation In order to use the asynchronous retry feature based on the Spring Thread pool task scheduler, all you have to do is to add the following dependency: XML <dependency> <artifactId>async-retry-spring-scheduler</artifactId> <groupId>org.digibooster.retryable</groupId> <version>1.0.2</version> </dependency> Add the annotation EnableThreadPoolBasedAsyncRetry to a configuration class, and finally, define the retry policy bean as follow: Java @Configuration @EnableThreadPoolBasedAsyncRetry public class AsyncRetryConfiguration { /** * the annotated method will be triggered the first time after 1 second and will * perform 2 retries eatch 20 seconds in case of failure */ @Bean public FixedWindowRetryableSchedulingPolicy fixedWindowRetryableSchedulingPolicy() { return new FixedWindowRetryableSchedulingPolicy(10000,3,20000); } } Quartz-Based Implementation (In Memory) This configuration uses the RAM in order to store the retry jobs. It is not persistent and doesn't support load-balancing and failover. So retries will be lost if the server restarts. In order to use this implementation, add the following dependencies: XML <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> <dependency> <groupId>org.quartz-scheduler</groupId> <artifactId>quartz</artifactId> </dependency> <dependency> <artifactId>async-retry-quartz-scheduler</artifactId> <groupId>org.digibooster.retryable</groupId> <version>1.0.2</version> </dependency> Add a configuration class that extends DefaultQuartzBasedAsyncRetryableConfigAdapter: Java @Configuration public class RetryAsyncQuartzInMemoryConfiguration extends DefaultQuartzBasedAsyncRetryableConfigAdapter { @Bean public FixedWindowRetryableSchedulingPolicy fixedWindowRetryableSchedulingPolicy() { return new FixedWindowRetryableSchedulingPolicy(10000,3,20000); } @Bean("schedulerFactoryBean") public SchedulerFactoryBean schedulerFactoryBean(@Autowired QuartzSchedulerJobFactory quartzSchedulerJobFactory, @Autowired QuartzProperties quartzProperties) { SchedulerFactoryBean factory = new SchedulerFactoryBean(); Properties properties = new Properties(); properties.putAll(quartzProperties.getProperties()); factory.setQuartzProperties(properties); factory.setJobFactory(quartzSchedulerJobFactory); return factory; } } Finally, add the following lines to the application.yml file: Properties files spring: quartz: auto-startup: true job-store-type: memory Quartz-Based Implementation (JDBC) This configuration uses the database in order to store the retry jobs. It is persistent and supports load-balancing and failover, so retries will not be lost if the server restarts. In order to use this implementation, add the following dependencies: XML <dependency> <groupId>org.springframework</groupId> <artifactId>spring-tx</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> <dependency> <groupId>org.quartz-scheduler</groupId> <artifactId>quartz</artifactId> </dependency> <dependency> <artifactId>async-retry-quartz-scheduler</artifactId> <groupId>org.digibooster.retryable</groupId> <version>1.0.2</version> </dependency> Add a configuration class that extends QuartzDBBasedAsyncRetryableConfigAdapter as follows: Java @Configuration public class ConfigurationClass extends QuartzDBBasedAsyncRetryableConfigAdapter { @Autowired PlatformTransactionManager transactionManager; @Override public PlatformTransactionManager getTransactionManager() { return transactionManager; } @Bean public FixedWindowRetryableSchedulingPolicy fixedWindowRetryableSchedulingPolicy() { return new FixedWindowRetryableSchedulingPolicy(10000,3,20000); } @Bean("schedulerFactoryBean") public SchedulerFactoryBean schedulerFactoryBean(@Autowired QuartzSchedulerJobFactory quartzSchedulerJobFactory, @Autowired QuartzProperties quartzProperties, @Autowired DataSource dataSource) { SchedulerFactoryBean factory = new SchedulerFactoryBean(); Properties properties = new Properties(); properties.putAll(quartzProperties.getProperties()); factory.setQuartzProperties(properties); factory.setJobFactory(quartzSchedulerJobFactory); factory.setDataSource(dataSource); return factory; } } Finally, add the following configuration to the application.yml file: Properties files spring: quartz: auto-startup: true job-store-type: jdbc properties: org.quartz.jobStore.isClustered: true org.quartz.scheduler.instanceName: RetryInstance # optional org.quartz.scheduler.instanceId: AUTO # optional jdbc: initialize-schema: always # optional Remark: When using Quartz with a database, the retry will be executed with a delay due to Quartz implementation. To decrease the delay, you can change the value of the property org.quartz.jobStore.clusterCheckinInterval. The framework source code is published on GitHub.

Apache APISIX is built upon the shoulders of two giants: NGINX, a widespread open source reverse-proxy OpenResty, a platform that allows scripting NGINX with the Lua programming language via LuaJIT This approach allows APISIX to provide out-of-the-box Lua plugins that should fit most business requirements. But there always comes a time when generic plugins don't fit your requirements. In this case, you can write your own Lua plugin. However, if Lua is not part of your tech stack, diving into a new ecosystem is a considerable investment. Therefore, Apache APISIX offers developers a way to write plugins in several other languages. In this post, I'd like to highlight how to write such a plugin with Rust. A Bit of Context Before I dive into the "how," let me first describe a bit of context surrounding the Rust integration in Apache APISIX. I believe it's a good story because it highlights the power of open source. It starts with the Envoy proxy. According to the Envoy website: Envoy is an open source edge and service proxy, designed for cloud-native applications. Around 2019, Envoy's developers realized a simple truth. Since Envoy is a statically compiled binary, integrators who need to extend it must compile it from the modified source instead of using the official binary version. Issues range from supply chains more vulnerable to attacks to a longer drift when a new version is released. For end-users whose core business is much further, it means having to hire specialized skills for this reason only. The team considered solving the issue with C++ extensions but discarded this approach as neither APIs nor ABIs were stable. Instead, they chose to provide a stable WebAssembly-based ABI. If you're interested in a more detailed background, you can read the whole piece, "WebAssembly in Envoy." The specification is available on GitHub. Developers can create SDK for their tech stack. Proxy and API Gateway providers can integrate proxy-wasm in their product. Apache APISIX and proxy-wasm The Apache APISIX project decided to integrate proxy-wasm into the product to benefit from the standardization effort. It also allows end-users to start with Envoy, or any other proxy-wasm-compatible reverse proxy, to migrate to Apache APISIX when necessary. APISIX doesn't implement proxy-wasm but integrates wasm-nginx-module. It's an Apache v2-licensed project provided by api7.ai, one of the main contributors to Apache APISIX. As its name implies, integration is done at the NGINX level. Let's Code! Now that we have explained how everything fits together, it's time to code. Preparing Rust for WebAssembly Before developing the first line of code, we need to give Rust WASM compilation capabilities. Shell rustup target add wasm32-wasi This allows the Rust compiler to output WASM code: Shell cargo build --target wasm32-wasi The WASM code is found in: target/wasm32-wasi/debug/sample.wasm target/wasm32-wasi/release/sample.wasm (when compiled with the --release flag) Setting up the Project The setup of the project is pretty straightforward: Shell cargo new sample --lib #1 #1: Create a lib project with the expected structure. The Code Itself Let me first say that the available documentation is pretty sparse. For example, proxy-wasm's is limited to the methods' signature (think JavaDocs). Rust SDK is sample-based. However, one can get some information from the C++ SDK: WASM module is running in a stack-based virtual machine and its memory is isolated from the host environment. All interactions between host and WASM module are through functions and callbacks wrapped by context object. At bootstrap time, a root context is created. The root context has the same lifetime as the VM/runtime instance and acts as a target for any interactions which happen at initial setup. It is also used for interactions that outlive a request. At request time, a context with incremental is created for each stream. Stream context has the same lifetime as the stream itself and acts as a target for interactions that are local to that stream. The Rust code maps to the same abstractions. Here's the code for a very simple plugin that logs to prove that it's invoked: Rust use log::warn; use proxy_wasm::traits::{Context, HttpContext}; use proxy_wasm::types::{Action, LogLevel}; proxy_wasm::main! {{ proxy_wasm::set_log_level(LogLevel::Trace); //1 proxy_wasm::set_http_context(|_, _| -> Box<dyn HttpContext> { Box::new(HttpCall) }); //2 } struct HttpCall; impl Context for HttpCall {} //3 impl HttpContext for HttpCall { //4 fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action { //5 warn!("on_http_request_headers"); //6 Action::Continue } } #1: Set the log level to Apache APISIX's default. #2: Set the HTTP context to create for each request. #3: Need to implement Context. By default, all functions are implemented in Context, so implementation is not mandatory. #4: Likewise for HttpContext #5: Implement the function. Functions in HttpContext refer to a phase in the ABI lifecycle when headers are decoded. It should return an Action, whose value is either Continue or Pause. #6: Log - finally After generating the WebAssembly code (see above), we have to configure Apache APISIX. Configuring Apache APISIX for WASM Apache APISIX's documentation is geared toward Go. Still, since both Go and Rust generate WebAssembly, we can reuse most of it. We need to declare each WASM plugin: YAML wasm: plugins: - name: sample priority: 7999 file: /opt/apisix/wasm/sample.wasm Then, we can use the plugin like any other: YAML routes: - uri: /* upstream: type: roundrobin nodes: "httpbin.org:80": 1 plugins: sample: #1 conf: "dummy" #2 #END #1: Plugin name #2: At the moment, the conf attribute is mandatory and must be non-empty on the Apache APISIX validation side, even though we don't configure anything on the Rust side. At this point, we can ping the endpoint: Shell curl localhost:9080 The result is as expected: rust-wasm-plugin-apisix-1 | 2022/09/21 13:43:14 [warn] 44#44: *286 on_http_request_headers, client: 192.168.128.1, server: _, request: "GET / HTTP/1.1", host: "localhost:9080" Conclusion In this post, I described the history behind the proxy-wasm and how Apache APISIX integrates it via the WASM Nginx module. I explained how to set up your Rust local environment to generate WebAssembly. Finally, I created a dummy plugin and deployed it to Apache APISIX. In the next post, we'll beef up the plugin to provide valuable capabilities. The source code is available on GitHub. To Go Further: WebAssembly for Proxies (Rust SDK)

The other day I came across a cool HTML attribute I had never heard of before; capture. So I decided to make a video and blog post about it. Here’s a video format if you prefer that: You can put the capture attribute on inputs with the type of file, and you can give it a value of “user” or “environment“. The interesting thing about the capture attribute is for users coming to your website on a mobile device. If they interact with that input, instead of opening up the default file picker, it will actually open up one of their cameras. It could be the front-facing camera or the back-facing camera, depending on the value. If you set the value to “user“, it will use the user-facing or front-facing camera and or microphone. And if you set it to “environment“, it will use the outer facing or back facing camera and or microphone. To test it out myself, I created an index.html file that looked like this: HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width,initial-scale=1" /> <style> * { font-size: 1.5rem; } </style> </head> <body> <label for="environment">Capture environment:</label> <br> <input type="file" id="environment" capture="environment" accept="video/*" > <br><br> <label for="user">Capture user:</label> <br> <input type="file" id="user" capture="user" accept="image/*" > </body> </html> The only relevant part of the HTML is the two inputs. They both have a capture attribute and they both have an accept attribute. One is set to capture the “environment” with any type of video. The other is set to capture the “user” with any type of image. The capture attribute doesn’t really do anything interesting on a desktop. When I click the inputs, I see that it opens up the file picker. But here’s the interesting part… If I bring up that page on my phone and click the first input, my camera opens in the video recording mode. When I click the second input, my phone opens up the camera in image capture mode (for some reason, my phone doesn’t differentiate between front or back facing cameras though). When you actually snap a photo or video, that file is sent to the HTML input. How cool is that!?!? Now, anytime we talk about new web APIs or features, we have to discuss the compatibility and if we look at the support on caniuse.com, it doesn’t look great… But it actually makes sense because all of those unsupported browsers are actually desktop browsers where there isn’t a front-facing or back-facing camera. So it makes sense to only open up the file picker. But all the supported browsers are mobile browsers. So that feature is good to go. The other cool thing is even if a user comes to your application with an unsupported browser, it’s just going to fall back to the default file picker UI. Progressive Enhancement FTW!!! So that’s the HTML capture attribute. It’s a pretty cool way to add a nicer user experience if you know that your mobile users are going to be taking a picture or a video or a voice recording at the time of upload. Thank you so much for reading. If you liked this article, please share it. It's one of the best ways to support me.