Month: September 2023

Posted on

Cypress Feature “Test Replay” Launched: Let’s Play With Test Replay

Category Image 080

Problem Statement

Before Cypress v13, test failures in CI have historically been captured through screenshots, videos, and stack trace outputs, but these artifacts provide limited information.

So Cypress comes with a new feature Test Replay in version 13.0.0. The introduction of features like “Test Replay” in Cypress v13 aims to bridge this gap by providing developers with a way to replay the exact test run and inspect various Aspects of it, such as DOM interactions, network requests, console logs, JavaScript errors, and more

Posted on

SQL Query Optimization: Combining Multiple Joins for Improved Performance

Category Image 101

I'm working on an SQL query for a complex reporting system that involves multiple tables and joins. However, the query's performance is not meeting my expectations, and I suspect that the way I've structured my joins might be inefficient.

Here's a simplified version of my query:

SELECT
    orders.order_id,
    customers.customer_name,
    products.product_name,
    order_details.quantity,
    order_details.unit_price
FROM
    orders
JOIN
    customers ON orders.customer_id = customers.customer_id
JOIN
    order_details ON orders.order_id = order_details.order_id
JOIN
    products ON order_details.product_id = products.product_id
WHERE
    orders.order_date BETWEEN '2023-01-01' AND '2023-12-31';

While this query returns the correct results, it's taking a significant amount of time to execute, especially when dealing with a large dataset.

I'd like to optimize this query for better performance. Could someone review my SQL code and suggest improvements or alternative approaches to achieve the same result more efficiently? Additionally, are there any indexing strategies or database design considerations that might help enhance the query's speed? Any insights or code optimizations would be greatly appreciated. Thank you!

Posted on

Chris’ Corner: Web Components Don’t Need You

Category Image 052

Dave Rupert blogged a bunch of reasons about why you probably aren’t using them yet. Some of it is technological, and more of it is historical, marketing, and psychological reasons. Then Dave, a pretty avid Web Components follower and advocate, followed up with another surprise. Should you rewrite your app to use them? Probably not.

It’s not that you shouldn’t use them because they aren’t good, it’s:

If your components only have one place to go, then you probably don’t need Web Components. Even if your components service a couple different apps or product teams that all use the same uniform tech stack, you probably don’t need Web Components. Where Web Components shine is when your components need to go to many places.

The grid of logos on https://arewebcomponentsathingyet.com/ tells that story: very big companies.

Nolan Lawson followed that up with Use web components for what they’re good at, a more specific take on this, which largely agrees with Dave. Big companies are reaching for them because they solve actual problems for them. But enterprise isn’t very present on social media, so you just don’t hear about it as much.

So why are big enterprises so gaga for web components? For one thing, design systems based on web components work across a variety of environments. A big company might have frontends written in React, Angular, Ember, and static HTML, and they all have to play nicely with the company’s theming and branding. The big rewrite (as described above) may be a fun exercise for your average startup, but it’s just not practical in the enterprise world.

Having a lot of consumers of your codebase, and having to think on longer timescales, just leads to different technical decisions. And to me, this points to the main reason enterprises love web components: stability and longevity.

If you have some of those problems, you’ll probably benefit from Web Components and could or should use them, or maybe you already are. If not, whatever. Nobody needs permission to use them, and plenty of companies are doing it without a single care about what the social media vibe is on them. Web Components still have some problems, and fortunately, are still being actively worked on, so the story should get better year after year, in case you’re on the fence and watching.

Nolan does shout out one thing Web Components excel at, obviously and immediately:

To me, [client-rendered leaf components are] the most unambiguously slam-dunk use case for web components. You have some component at the leaf of the DOM tree, it doesn’t need to be rendered server-side, and it doesn’t <slot> any content inside of it. Examples include: a rich text editor, a calendar widget, a color picker, etc.

Dan Ryan has another take: they can be really simple. He used a header component as an example, which didn’t buy them anything extreme — just a simple update for a simple benefit.

So what did this gain us? For this example not much really. But where it really shines for us is only loading the CSS needed for the components used on a given page. Most of our visitors only view a single campaign page which uses just a few components. Previously though we were bundling all our CSS into a single file and serving it to everyone.

I’m the biggest fan of Web Components when you can just pluck one off the shelf and use it for something useful, knowing it’s lightweight and flexible. Nolan’s own emoji-picker-element is a classic example. When I see one-off componentry that isn’t a Web Component lately, I immediately wish it was. Check out this OverlayScrollbars “plugin”. Wouldn’t it be awesome as an <overlay-scrollbars> component, making it declarative and easy to use? (Yes.)

But I’m down for bigger approaches, too, so long as they are solving a problem. Google’s Material Design is an example of that. Material 3 is their latest take, and it seems to be mostly leaning into native apps, with the web version “coming soon”. When it does, it appears as if it’ll be Web Components-based. That’s cool and maybe even a touch surprising, being that Google could have used it as a way to promote Angular. But just because they went Web Components doesn’t mean they didn’t go Angular, assuming they work nicely in Angular, which let’s just hope they do.

Allow me to end with a little linky-uppy: Tram-Lite. I really like how you just use HTML to define the whole component, then go on to use it elsewhere. It requires no build process and has a very native feeling. Actually, check out the principals — they seem sound to me. And I’m not just saying that because it works great on CodePen.

Posted on

Exploring the Basics of EMQX MQTT Broker Clustering: An Introduction

Featured Imgs 23

Welcome to the first post in our new series exploring the world of MQTT broker clustering.

If you're involved in the IoT (Internet of Things) space or have embarked on any journey involving real-time data transfer, you've probably come across MQTT (Message Queuing Telemetry Transport). MQTT is a lightweight, publish-subscribe network protocol that transports messages between devices, often known as the backbone for IoT.

Posted on

Optimizing Eloquent Model Performance

Featured Imgs 23

Laravel’s Eloquent ORM is a powerful tool that simplifies database interactions in PHP applications. While it makes development easier and more elegant, it’s crucial to optimize the performance of your Eloquent Models to ensure your application runs smoothly, especially when dealing with large datasets or high traffic. In this blog post, we’ll explore various techniques …

Continue reading "Optimizing Eloquent Model Performance"

The post Optimizing Eloquent Model Performance first appeared on Lucid Softech.